《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 工具回來。雖然部分工具確實幫助了團隊的專案推展，但鐘志遠發現也有許多部分為團隊帶來更多的困擾。

貼滿 Scrum Board 的工作室

　　以「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》的誕生。