l

2012年7月16日 星期一

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概念,當然是沒提到什麼跨界開發或是遊戲開發的議題。

image

照片左方身高最高的那位就是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。

沒有留言:

張貼留言