Scrum框架下的跨界開發(3):遊戲開發的四個階段

July 15 19:48~22:00

講到跨界開發，遊戲業應該算是軟體開發產業別裡面，「跨很大」的一個行業。所以Teddy就在想，看看做遊戲的人如何處理「跨界開發」的問題，從中偷學一些過來。前兩天翻開《Agile Game Development with Scrum》這本書，找到了若干蛛絲馬跡。不過先講結論，這本書中的跨界開發，跟Teddy心中所想的差蠻多的。故事說來話長，要分幾集才講得完。

話說Teddy跟這本書的作者Clinton Keith，還有一點點小淵源。2009年10月，Teddy去上Certified ScrumMaster課程的時候，其中一位講師就是Clinton Keith。不過當時主要還是講授Scrum概念，當然是沒提到什麼跨界開發或是遊戲開發的議題。

照片左方身高最高的那位就是Clinton Keith，右方是Bas Vodde。

言歸正傳，要講到遊戲界的跨界開發，就要先介紹一下Keith在書中所介紹的遊戲專案所經歷的四個階段（不管這些遊戲專案是否採用敏捷方法，都會經歷這四個階段）。

1. Concept：在此階段不斷地產生新的想法、原型設計，然後將不合適的想法與原型丟棄。此階段的主要目的就是要產生可以獲得遊戲出版商認可的概念，這樣專案才可能繼續進行。
2. Pre-production：團隊探討遊戲要如何才會好玩，然後做出一些實際的「東西」（書中稱之為asset，應該是包含圖片、動畫、模型、聲音、程式等）以便讓後續的production階段可以接手繼續完成。
3. Production：依據pre-production的成果，團隊專心於開發出一個8-12小時的遊戲。這一個階段之所以稱之為production（量產），有一個重要的假設，那就是基本的遊戲架構與所使用的技術在pre-production階段就已經決定了，所以在production階段就只要卯起來把8-12小時的遊戲給做出來。
4. Post-production：此階段主要做三件事---polishing、hardware testing、bug fixing。Polishing就是對遊戲做作後的修飾與調整，hardware testing雖然在每一個階段都會做，但是獲得Microsoft或是Sony硬體認證的這種測試，由於費用很高，所以只會在最後的階段才做。Bug fixing就不用特別解釋了，就是拼命解bug啊。

看到這邊眼尖的鄉民不知道有沒有覺得哪裡怪怪的？再給各位一分鐘想一下…

對啦，想起來了吧。這四個階段，怎麼跟RUP的四個階段那麼的像啊。

1. Inception
2. Elaboration
3. Construction
4. Transition

很奇怪耶，這本書不是在談Scrum嗎，為什麼會跑出這四個階段？雖然一般Scrum的書告訴大家的概念是：專案經過多個sprint之後，在某個固定的時間點釋出。或是每一個sprint都可以釋出產品。但是，這並不表示所有類型的專案都可以套用這麼「自由」的開發模式。有些類型的專案，例如這邊提到的遊戲開發，從「發想」、「概念驗證」到「量產」、「準備交付」，是有一定的節奏，所以將專案分成四個階段將有助於遊戲的開發。

***

寫到這邊Teddy有一個感想，那就流程是死的，人是活的。只要流程的「精神」有維持住，依據專案的特性，適當地加以調整並無不可。但是這就是開發流程困難之處，調得好專案進行的順利，還可以到處宣揚自己的開發流程有多棒。調適得不好，就到處怪東怪西的，把流程批評的一文不值，然後又回到最不花腦筋的「爆肝流程」。

話說當Teddy在採用Scrum之前，最熟的流程是RUP。當Teddy剛開始採用Scrum的時候，其實也是混雜著若干RUP的精神，像是將use case driven調整成story driven，而architecture centric的精神也隱含在Teddy套用Scrum的步驟中。之前RUP與多年開發程式的經驗，有了Scrum這個更好的框架之後，反而有助於團隊導入Scrum（但是，要小心不要亂套，不然會死得很難看）。

回到「跨界開發」這件事，依據Scrum的精神，要組成cross-functional team。Teddy曾經在「Scrum框架下的跨界開發(2)」提到，光是「開發人員本身就存在著跨界開發的問題」。Teddy以前的經驗是，採用pair programming、shared code的方式，想辦法慢慢地打破開發人員的界線。一旦這個界限打破之後，團隊的整個開發流程、靈活度、生產力都有很驚人的提升。但是，如果團隊裡面有UX設計師、動畫設計師、3D模型設計師，這些人要如何跟程式設計師搞在一起？這時候pair programming與shared code還可以用來幫助解決跨界的問題嗎？

Teddy目前的想法是：可以，但是隨著專長差異越大，就越無法完全解決，困難度也變得越高。

說來話長，簡單的講，這又是context的問題，等以後Teddy整理得比較清楚再跟鄉民們分享。總之，讀完《Agile Game Development with Scrum》這本書關於跨界開發的章節，喚醒了Teddy以前常用的一種解決問題的方法：在某個context底下，如果問題很難解決，就嘗試著跳脫原本的context，到一個更大的context底下，嘗試尋找問題的解。所以，跨界開發的問題就變成了：

1. 先思考在Scrum與敏捷實務做法之下，哪些方法可以解決跨界開發？
2. 剩下沒有被解決的問題（套用pattern的術語，就是unresolved force），需要搭配哪些方法，或是在更大的context之下是否有解（例如，將專案開發分成不同的階段，然後在各個階段採用不同的跨界合作策略）？

***

但是無論如何，在敏捷方法的精神與基礎之下，尋求跨界開發的可能性應該是一種可行的方法。

***

友藏內心獨白：腦袋中突然冒出了problem frame這兩個字…XD。