原文轉自巴哈姆特新聞 http://gnn.gamer.com.tw/5/118415.html 《Implosion》首席工程師 以「別太敏捷遊戲開發」為題 闡述團隊不斷進化的心路歷程 （GNN 記者 Jerry 報導） 2015-07-24 23:59:35 　　邀請國內外知名開發者分享自身經驗的「台北遊戲開發者論壇（Taipei Game Developers Forum，簡稱 TGDF）」今（24）日進入最後一天，雷亞遊戲技術長兼共同創 辦人鐘志遠在本日下午以自身開發《Implosion》的經驗為例，透過「別太敏捷遊戲開發 」這樣的主題，分享了他一路走來的心得與想法。 鐘志遠在《Implosion》中主要負責的是程式面的工作，這款以科幻題材為背景的 3D 動 作 RPG，可是花費了 3 年半的時間才正式完工，遠遠高於一般手機遊戲的研發時程。 《Implosion》主美術 QQ 的小孩也從嬰兒成長到要上幼稚園了 　　鐘志遠坦言一開始本來以為做遊戲只要一點企劃，再加上多一點的程式以及大量的美 術就可以搞定了，但實際經歷過後便發現事情其實並不單純。往往企劃趕不上變化，程式 寫好了也常常要修正，連帶影響美術量產的格式也需要一改再改，如此一來便導致遊戲發 售日期無止盡地往後延後。台大電機系畢業的他，從中了解到開發遊戲與一般的軟體研發 非常不同，鐘志遠認為遊戲可說是藝術與工程的結合，是一門高深的學問。 由於經驗的不足，最初開發團隊使用了免費的 Google 表格來追蹤每個成員的工作進度， 但由於過程實在太不嚴謹，導致許多成員常常故意「忘記」去填表，導致工作效率低落， 每日工作進度與每週工作進度無異，專案推展的進度也總是快不起來。 　　而當雷亞遊戲正式成立並開始執行《Cytus》與《Implosion》的研發專案後，鐘志遠 發現隨著專案與團隊的規模愈來愈大，採用舊的方法已經不是一個好的選項，因此便採用 了知名的「敏捷開發（Scrum）」作為公司管理專案的方法與系統。 Scrum 是一種從 1990 年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對 快速變化的需求所設計出來的管理模型。Scrum 注重團隊之間的緊密協作、面對面的溝通 ，以及頻繁交付新的軟體版本等。 　　在最一開始，鐘志遠僅單純依靠書中學來的方法來學習在團隊中使用 Scrum 管理團 隊專案的進度，如此一來比起以往，團隊成員終於有了一個專門的時間來好好坐下來討論 計畫，也清楚接下來該做些什麼。團隊開始有了清楚的目標去執行，每兩個禮拜也有會成 果的 Demo 展示，讓產品經理能夠確實掌握大家的進度。 　　但事實上，一切並沒有那麼順利，在團隊跑了半年 Scrum 之後，種種問題也開始浮 出抬面。 　　此時鐘志遠開始檢討是不是自己對於 Scrum 不夠了解，一定是什麼地方錯了，因此 便去報名上了認證課程。並學習了更多以往不知道可以運用的 Scrum 工具回來。雖然部 分工具確實幫助了團隊的專案推展，但鐘志遠發現也有許多部分，為團隊帶來更多的困擾 。 以「Planning Poker」來說，這代表每個成員可以輪流舉排，顯示自己對某項工作所認定 的工作量需要多少點數，若是成員間所認為的點數大小差距過大，就需要說明原因。雖然 這項工具的立意看似良好，但實際上要執行卻會碰到許多難題。若以要製作一個可捲動的 UI 文件為例，程式可能會認為要 20 點，但美術會覺得這不是很簡單嗎？應該只要 3 點就好。 　　鐘志遠認為，因為團隊成員彼此之間，對於彼此領域的認知並不熟悉，因此常常會導 致各說各話，無法準確溝通的狀況。也因此，Planning Poker 針對每項工作產出的點數 往往就像擲骰子一樣，準不準得靠運氣。 　　一般來說，Scrum 可以藉由各項被量化的數字來估算出一個專案可能需要耗費的時間 ，如圖下所示。但就如同上述 Planning Poker 的例子，在團隊成員專業領域差異頗大得 狀況下，很多時候這些數字無法準確反映現況，也導致專案時間根本無法精算出來。 另外一個例子，是 Scrum 裡面所使用到的「檢討會議（Retrospective）」，好好使用的 話可以透過團隊成員來提出改善流程的方法，進而增加團隊效率。但實際實行起來，反而 大家都避重就輕，沒辦法直指問題核心。鐘志遠認為這可能是華人的民族性使然，導致大 家不擅長在檯面上互相檢討。 　　究竟是什麼原因，導致 Scrum 無法如同書本上所說的套用在雷亞的團隊上？在尋找 許多現實中的案例及方法後，鐘志遠發現 Scrum 並不是如同刻在石板上的真理，或是設 計良好的機械，只要照著說明書去操作，把時間和錢丟進去就能夠生出成果。 最終鐘志遠得到一個理論，Scrum 是一個成熟的敏捷開發團隊典範，但卻不是一個完全照 著走就能成功的教戰手冊。團隊學習 Scrum 運作就很像閱讀偉人傳記，從中讀者並無法 藉由模仿書中案例來邁向成功人生。鐘志遠認為團隊應該要藉由 Scrum 的作法發展出獨 特的工作模式，而不是直接拷貝，因為人是獨一無二的，所以人組成的團隊也是獨一無二 的。 　　從這個階段開始，鐘志遠便從 Scrum 的守則中取出適合的工具，再經過調整來針對 雷亞內部團隊來使用。例如讓團隊成員間彼此分享資訊，互相溝通的每日會議（Daily Meeting），或是讓大家有個共同目標，定下短期目標的 Planning 會議。 在遊戲開發的過程中，製作人當然也會希望檢視開發進度與成果，辛苦工作的成員也會希 望自己努力的結晶被看到，因此就有了 Review 檢視會議。 　　而優秀的製作人看到成果之後，當然也會想要修改、調整，讓遊戲變得更好，這就是 遊戲產業人員最害怕看到的「更改部分規格」。這近似打掉重做的過程，常常會導致團隊 士氣受挫，為了避免這樣的狀況太常發生，團隊便決定要執行更多次的 Planning 與 Review 會議，其中又盡量不更動內容，這樣的過程便是 Scrum 中常用的 衝刺（Sprint）。 鐘志遠認為，假設一個團隊沒有經過反覆試錯的過程，便直接採用上述的作法，便容易有 水土不服的狀況發生。就像學生不會因為看了勵志讀物，就變成人生勝利組。但管理者常 常有這樣的錯覺，一般來說管理者會相信只要採用了一套標準步驟，團隊的效率就會突然 一飛沖天。 　　但事實上團隊的每個人都要有這樣的想法，才能持續地提昇效率。若是只有團隊的領 導者認同這樣的作法，那就沒有意義。 　　鐘志遠覺得這樣的作法，需要管理職很謹慎的看待，因為團隊中的被管理者，很有可 能會與管理者產生距離，像是成員若是沒辦法吐露真心話的話，就會導致即使團隊發生問 題也收不到任何回饋的狀況。鐘志遠以自身的經驗為例，表示身為產品經理，就算只是一 個小小的指責都可能會讓團隊士氣渙散。像是之前曾經有成員提了想法，但卻馬上被他打 槍。但後來才發現自己其實沒有考量到企劃、程式等等連帶影響的狀況，導致自己做了錯 誤的判斷，讓團隊很有挫折感。 每個成員若是都可以觀察、找出問題並提出改變的建議，進而調整團隊。此時若是每個成 員也都相信改變的力量，最終便能形成正向的循環，成為一個符合 Scrum 敏捷開發的團 隊 　　鐘志遠同時也以動畫《閃電霹靂車》為例，表示人需要的是如同阿斯拉般，可以與主 角一起進化的系統，而不是天才也無法完全駕馭的凰呀。 　　此外為了克服合作以及溝通的問題，然後啟動改進的循環，鐘志遠認為建立兩好的團 隊文化非常重要，因為遊戲開發大多時候的過程都會需要人與人的互動，文化才是真正能 影響人與人之間的東西。而若是要建立成功的文化，則必須讓團隊中的每個成員，都必須 對以下兩個問題非常了解，而且具備自我省思的能力。 1. 專業沒有被尊重 2. 專業沒有辦法接納來自非專業的看法 專業沒有被尊重 　　以第一點來說，當程式企劃彼此信任不夠，便會給出似是而非的建議。身為專業的人 知道這些建議不是那麼好，但當下無法反駁，其中也可能是因為職位差距的問題，但是如 此一來團隊之間便會產生某些負面的刻版印象，例如「製作人就是喜歡用抄的，程式就是 喜歡用舊的，怕麻煩不愛用新引擎」，如此一來便會影響團隊的速度與品質。 　　鐘志遠以《Implosion》為例，表示遊戲中的裝備可分為普通、進階與卓越三個等級 。在遊戲的開發過程中，就曾有人反映最高級的武器應該可以讓主角有著超越超級賽亞人 3 的強度，砍敵人就像砍菜一樣，這樣才合理。 雖然說這樣的建議聽起來很合理，但由於遊戲關卡有限，沒有那麼多空間將拿到卓越裝備 的角色，在破關的過程中拉回適當的難度。此外由於《Implosion》的重點是戰鬥中帶給 玩家的挑戰，若是武器設計地太強，後面關卡躺著也可以過的話，就違背遊戲本身的主軸 ，也會降低遊戲體驗。 　　鐘志遠認為尊重專業看起來很簡單，但其實很難。大部分的問題都像冰山，真正浮出 抬面被檢視到的不多，只有在做事的人才能發現冰山下面較難被發現的東西。 　　因此鐘志遠認為，尊重專業不是了解到「我要尊重」而以，而是要深深地輸入到潛意 識中才行。 -- 專業沒辦法接納來自非專業的看法 以上的影片是《Implosion》最早針對 Xbox 平台所打造的版本，雖然畫面不錯，但與廠 商交涉的過程不是那麼順利。就在當時，團隊也剛好經歷手機遊戲崛起的時間點，因此製 作人便提出想要改成在手機上製作的想法。 　　但當時擔任主程式的鐘志遠認為兩個平台特性相差太多，這樣的作法根本不可行，便 強力否決掉這項提議。為了改變鐘志遠的成見，團隊中的主美術 QQ 利用手頭上僅有的資 源，打造了一個在手機上運行的 Demo，證明即使在手機上也可以呈現不錯的效果，也因 此讓鐘志遠發現自己下的決定太過武斷，狠狠地被打臉。現在回頭，鐘志遠非常感謝有了 QQ 的建議，否則便不會有手機版《Implosion》的誕生。 以剛才的例子來說，鐘志遠認為當初在討論的時候應該好好去分析前因後果，而不是依賴 直覺去下決定，這樣容易產生盲點。很多人常常說專業是如何地不被尊重，但其實專業也 是有盲點，檢討自己也最困難。 　　另外一個導致專業無法運作的，則是太過專注會導致專業人員無法接受或了解外來的 有效建議，或是無法做出比眼前結果更好的決定。以下圖來解釋的話，若是從起點開始往 右，若是只專注在局部，那最多可能只能停留在 A 點，而無法更上層樓至更高的 B 點。 企劃、美術與程式都有各自想要追求的東西，鐘志遠認為這就是所謂的「局部最佳問題」 。他認為一款好的遊戲不一定要在每個環節都追求到極致。但當專精不同領域的成員在討 論一件事情的時候，彼此之間提出的問題卻可能會激怒對方，衍生出「專業 vs 非專業」 的狀況。 　　這時為了找到平衡點，了解到什麼樣的問題「我」才能夠提出建議？鐘志遠認為團隊 成員應該要有共識，了解到「當非專業的人發現妳的問題時，並不是因為他們比你厲害， 而是因為你正在解決眼前正前方的問題，你把背後留給他們掩護」。有了這樣的信任，團 隊才能啟動改進的循環，讓團隊愈來愈好。 總結 　　一個優秀的團隊並不是遵守 Scrum 的教條與規則就好，而是需要可以不停地改進自 身運作效率，一切都操之在團隊的手中。 遊戲開發沒有真理，鐘志遠表示只要能讓遊戲變得更好，任何方法他都願意去嘗試。同時 他也希望藉由這次的分享，讓更多的台灣團隊在下週為自己的專案所努力的時候，可以思 考改進的方法，進而讓台灣遊戲產業更加進步。 ------------------------------------------------------------------------------ Nothing is truth. Everything is permitted. 沒有什麼是真理。為了進步和改進，一切都是允許的。 -- 這世界並不美麗， 正因此而美麗無比。 "The world is not beautiful,~~ ~~therefore, it is!!" --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.8.244 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Rayark/M.1437921004.A.5A7.html ※ 編輯: wind3434 (1.160.8.244), 07/26/2015 22:30:29 ※ 編輯: wind3434 (1.160.8.244), 07/26/2015 22:30:56