TGDF｜別太敏捷遊戲開發｜筆記&心得整理

為什麼別太敏捷開發? (取樣至網路)

本文章主要是由個人理解的筆記＆心得整理，由於個人想法可能存在偏差，不一定能完全傳達原講者的內容與意圖，若要完全了解講者之內容建議去觀看講者的演講。

[embed]

目錄
．前言/背景
．引進SCRUM(敏捷開發)
．演化
．結論
．心得

前言/背景

遊戲開發與軟體開發不同，遊戲開發是藝術+工程的集合。

本次演講內容主要圍繞在「Implosion 聚爆」開發時，遇到團隊開發的種種問題。

．講者

鐘志遠｜雷亞遊戲 技術長兼共同創辦人

[embed]鐘志遠 - 台北遊戲開發者論壇 雷亞遊戲（Rayark Inc.）技術長、共同創辦人。曾參與《Implosion》、《VOEZ》 、《Sdorica》、《Soul of Eden》等多款遊戲前後端開發，並協助規劃各專案開發流程，建立雷亞遊戲軟體開發的各項基礎建設。2017.tgdf.tw

(因為2015年的TGDF沒有網站，只好找年份較近的2017年介紹當作連結)

．Implosion 聚爆

[embed]

→ 開發時長共花費3.5年，以開發手機遊戲的時長算很久。

→ 有許多原因導致開發時長拉長，例如：

1. 企劃趕不上變化。
2. 程式寫得很好，但需要隨著企劃內容有相對應的變化。
3. 美術製作時，規格與實際使用的不符合。

團隊初期人數較少，協作成本較低且溝通上不太嚴謹也能勉強完成專案。但隨著團隊人數增加，以及專案規模變大的緣故，初期使用的方法浮現了更多的問題導致後續專案的開發時程會拉長。意識開發遊戲的方式需要改進。

引進SCRUM(敏捷開發)

．初期作法（不嚴謹的SCRUM）

1. 2週1次的Sprint Sprint 是團隊在固定時間內執行Task，以完成目前並交付產品的新功能或改進版本。
2. 在Sprint planning中產生Task
3. 每天15分鐘的Stand-up meeting Stand-up meeting是一種參與者以站姿進行的會議，讓團隊成員對開發進度進行彙報和許諾。
4. 2週後的Review

．實施效果

1. 優勢： → 團隊成員可以在開發階段的特定時間，一起看見遊戲內容並討論。
2. 問題： → 時間估計不準確。 → Sprint執行後還是會留有一些事項未完成。 → 事項做到一半時發現有更好的方案，且若要重製方案的話需要花費過多的成本。

．核心 SCRUM

1. Backlog 產品或專案的任務清單，通常由製作人提出，依照優先順序排列所有需求。
2. Story Point 用來衡量工作項目的複雜度或開發工時的相對估算值，根據團隊經驗來評估。
3. Planning Poker 團隊用來估算 Story Point 的方式，成員使用撲克牌上的數字投票，達成共識後確定最終估算值。
4. Velocity 團隊在一個 Sprint 內平均能完成多少 Story Points，可以用來預測未來 Sprint 的進度。
5. Burndown Chart 一種視覺化圖表，顯示 Sprint 期間剩餘的工作量，幫助團隊追蹤進度，確保按時完成任務。
6. Retrospective 每個 Sprint 結束後的會議，團隊透過討論「做得好的地方」、「可以改進的地方」，來優化未來的開發流程。

預估時間的公式 Planning Poker：評估 Story Point Velocity = Story Point / Time Cost Project Time Cost = Total Story Point in Backlog / Velocity

．使用後的效果

1. 效益： ．Burndown Chart：讓團隊成員更專注在現有工作上，同時也有凝聚團隊向心力的功用。
2. 困惑： ．Planning Poker：因遊戲開發涉及不同領域（程式、美術、企劃），對同一個 Task 的理解不同，導致 Story Point 估算差異過大。 ．Backlog：因遊戲開發過程中變動頻繁，導致Backlog 產出的結果也不夠準確。 ．Retrospective：當時的環境不易在檯面上檢討，以及若團隊成員未事先準備好需要檢討的問題，可能會在會議上發呆。

演化

Scrum 並非一套固定的教戰手冊，而是提供一個理想團隊的典範與標竿。

團隊不應單純模仿 Scrum 就期望成為完美團隊，而應從中借鑑並靈活應用，因為每個團隊都有自己需要解決的問題。

．實際運用

1. 程式想要增加工作效率。要知道其他人員有沒有做一樣的事、美術or企劃能不能使用工具等。 → Daily 會議確認事項
2. 團隊內要有共同目標，不該是多頭目標，彼此才能夠配合。 → Planning 會議確認下次的共同目標
3. 製作人會想要定期檢視進度，且團隊成員也想看到成品。 → Review 會議
4. 在經過Review會議後，通常製作人or企劃會有新的想法想要更改or調整內容。 → 讓Planning與Review次數增加，且盡量不修改遊戲規格

．理論觀點

不會有一個神奇的方法，能夠在短期內通過簡單地套用到團隊中，就讓團隊的績效一飛衝天。

節錄至演講影片19:03的PPT

培養團隊，促進團隊往正面的方向去演化，逐步優化，最終找到適合自己團隊的節奏。 團隊的成長不應只靠 Team Leader 帶領，而是每位成員共同思考、提出改進，讓團隊整體進步。

節錄至演講影片19:50的PPT

．謹慎調整

團隊的成長來自不斷的 觀察 → 討論問題 → 提出方案 → 調整，形成良性的迭代循環。

節錄至演講影片20:17的PPT

→ 團隊成員各有不同的背景與個性，因此溝通時需格外謹慎，以避免誤解。 → 指責或缺乏信任的決定，可能會讓團隊氛圍倒退，甚至導致彼此的不信任感加深。 → 挫折多半來自溝通不順以及誤會，建立良好團隊文化至關重要，讓成員在信任與理解的基礎上合作。

建立良好的團隊文化

開發遊戲 90% 都是人與人的互動，唯有真正的文化，才能影響人與人的互動， 最後提升團隊的競爭力。

．尊重專業

當團隊成員在做決定時，都是基於該人員的專業知識再做決定。然而，當團隊內部信任不足時，非專業人員可能會提出似是而非的建議。作為專業人士，當事者往往能辨識這些建議的問題，並意識到它們可能並非最佳選擇。但因為各種因素（如職位高低或其他組織因素等等），可能導致當下反駁，最終導致：

1. 專案進度與品質下降
2. 團隊成員逐漸不再追求卓越 → 專業意見得不到尊重，團隊成員可能失去動力，不再積極提出最佳解決方案。

Implosion 裝備等級制的實際案例： 遊戲的裝備有三種等級，「Normal」、「Advanced」、「Excel」，等級越高越厲害。

節錄至演講影片25:46的PPT

→ 非專業人員： 到了遊戲後期，拿到Excel等級的裝備時，看起來不厲害，應該要像超級賽亞人3一樣，砍怪應該要像砍菜才對？

→ 專業人員（企劃）： ．因為關卡數量並不多（32關2周目）且較精緻。 ．而 Implosion 這款遊戲偏向 動作遊戲 而非 ARPG 的遊戲，最主要專注在戰鬥中的反應以及戰鬥中如何解決問題的難度。

若是設計成超賽3一樣，當拿到Excel等級裝備時，難度曲線沒有辦法拉回一個適當的難度曲線。

→ 解決方案：兩種方案都建置出來，並讓QA人員遊玩並選擇出一種方案，最後是決定維持企劃的方案。

大部分非專業人員看到的問題都是浮出水面的問題，只是冰山的一角，實際上問題並沒有非專業人士想的這麼簡單，還有另外90%的問題需要解決。

節錄至演講影片27:27的PPT

而改善這個問題，並非只要單純認為尊重專業就好了，也要把這樣的想法刻印在淺意識當中，這樣才會建立對專業問題的敏感度。 另一方面專業人員也會犯錯，專業人員也該對非專業人員傾聽以及包容。

．接納非專業的看法

Implosion 製作時遇到平台相關問題的實際案例： 原本開發的平台是以XBOX為目標，用了許多次世代的相關技術，但因為與外部窗口討論上並非那麼順利

→ 非專業人員（Lead Artist）： 提出平台轉換到手機上發售也行？

→ 專業人員（講者本人）： 手機以及XBOX的平台差異過大，不太可能。

→ 非專業人員（Lead Artist）： (拿了一些美術素材兜了一個DEMO，實際上手機上也能跑出幾乎與XBOX平台差不多的視覺效果，狠狠的打臉了講者本人。)

→ 解決方案：轉移到手機平台上開發。

就算非專業人員提供的建議不被採納，專業人員也應提出客製化的數據(如：Benchmark)，即使在不能驗證的情況下，也該去分析該事情的風險和利與弊。

專業人員在做決策時通常不會100%跟隨自身的專業，會帶一些直覺、甚至懶惰的去給出回應，最後產生專業的盲點。

．專注眼前

專注眼前問題能提升工作效率，但可能產生見樹不見林的問題。

假設製作好遊戲是在下面這個曲線尋找對大值，一般會想要在 「B點」 結束會是最佳值，但實際上會卡在 「A點」 就結束了，那是因為太專注於眼前的工作，以致產生見樹不見林的問題。

節錄至演講影片31:28的PPT

「每個人只看見自己眼前的那一部分」

．局部最佳化問題（Local Optimum Problem） → 企劃人員會覺得好遊戲就是要史詩。 → 美術人員會覺得好遊戲就是要精緻。 → 程式人員會覺得程式架構就是要能順應各種變化。

實際上一個好遊戲 → 劇情史詩不一定是好遊戲。 → 美術精緻不一定是好遊戲。 → 當程式人員設計能夠順應各種變化的程式時，往往與實際上修改的方向不大一致，因此程式應該專注於 精準且簡潔的設計，並確保剛好滿足需求即可，不需要撰寫能夠包羅萬象的架構，因為更可能提高維護成本或是增加Bug的機率。(極至編程所提倡的想法)

．避免局部最佳化問題

1. 找到溝通平衡點，建立共識。
2. 非專業與專業間互相掩護與支持，形成信任機制。
3. 優秀團隊在不斷迭代中調整SCRUM的規則，最終形成適合自身的運作模式。

優秀的團隊並非嚴格遵守SCRUM，而是不斷迭代改善自身的運作效率，選擇團隊需要的SCRUM規則，甚至自己改善SCRUM的規則，最後慢慢成為優秀的團隊。

．改善SCRUM

1. 移除Planning Poker，實質效益不大，把時間拿去思考/分析問題。
2. 移除Story Points和Velocity，這段時間統計的數據除了非常費時外，也不準確。
3. 改進Stand-up meeting，團隊成員在Scrum board前討論工作，能夠凝聚團隊向心力，且發現企劃和美術的東西不易在Scrum board呈現出來，所以在Stand-up meeting後，會去各個成員的位子上查看成品長怎麼樣，這樣能夠更快收斂遊戲好和壞的地方。

結論

團隊合作才是所有遊戲開發的核心

1. SCRUM只是一種典範不是教條
2. 持續改進
3. 建立良好文化
4. 尊重專業 及 聆聽非專業的聲音

Nothing is truth. Everything is permitted. (出自 Assassin’s Creed)

遊戲開發沒有真理，只要能進步的方法都該去嘗試。

心得

講者引用《刺客教條》的名言，恰到好處地傳達了核心思想。 每個團隊都有各自的挑戰，唯有透過不斷的「觀察、討論問題、提出方案、調整」的迭代，才能持續優化開發流程，真正提升效率。此外建立良好的團隊文化同樣重要，專業與非專業人員應該彼此理解、順暢溝通，否則不僅會影響開發品質，甚至會拖慢開發進度以及降低遊戲品質。這種持續精進的過程，也是團隊邁向頂尖的必經之路。 當團隊的開發流程與溝通機制逐步優化後，才能真正實現「敏捷」開發。而在觀看完本次演講後，也讓人更深刻理解為何主題會是 「別太敏捷遊戲開發」。