內容簡介

　　《Scrum敏捷遊戲開發》凝聚作者數十年的經驗，講解瞭如何將Scrum敏捷方法應用於遊戲開發中，介紹瞭如何增強團隊的內部協作和外部聯係。針對長遠規劃、進度跟蹤與持續集成，Keith提供瞭豐富的提示、技巧和解決方案，這些都源自他多年以來所積纍的實踐經驗。

　　《Scrum敏捷遊戲開發》適閤從事遊戲開發的程序員、製作人、美術師、測試員和遊戲策劃閱讀和參考。

目錄

第Ⅰ部分 問題與方案

第1章 遊戲開發危機四伏3

第2章 敏捷開發13

第Ⅱ部分 Scrum和敏捷規劃

第3章 關於Scrum35

第4章 關於Sprint57

第5章 用戶故事82

第6章 敏捷計劃103

第7章 視頻遊戲項目計劃123

第8章 團隊150

第9章 快速迭代181

第10章 敏捷技術197

第11章 敏捷美術和音頻212

第12章 敏捷設計222

第13章 敏捷QA和製作234

第Ⅴ部分 啓動敏捷

第14章 Scrum的神話與挑戰251

第15章 與發行商閤作266

第16章 啓動Scrum283

精彩書摘

　　第1章 遊戲開發危機四伏

　　遊戲開發的拓荒期已然遠去。昔日程序員單槍匹馬——既做設計又做編碼，還要負責美術錶現——逐步被各有所長的集團軍取代。遊戲行業日漸走嚮成熟，盈利能力已經超過瞭好萊塢。作為一個産業，我們似乎成熟瞭。

　　遊戲行業發展迅猛，但並非一帆風順。我們從其他傳統行業藉鑒瞭一些不那麼普遍適用的方法，將之套用於遊戲開發，就像小孩穿著父母的舊衣服一樣，極不閤體。刻闆的計劃和規程難以應對遊戲開發復雜度高和不確定性強的特點，往往導緻最後齣品的遊戲華而不實，很難叫好又叫座。方法欠妥還使得遊戲開發本身也喪失應有的樂趣。天賦異稟的有誌之士滿腔熱情地踏入遊戲行業，希望給韆韆萬萬的用戶帶來充滿樂趣的遊戲體驗。然而，他們卻暗無天日加班加點地在項目中煎熬，最後不得不帶著多年的經驗黯然離開這個行業。這實在是不應該啊。

　　在本章中，我們將迴顧遊戲開發的曆史，看一款遊戲如何從幾個人月就可以齣品，逐步發展到現在一個項目需要百人團隊曆時數年纔能完成。我們將看看這種商業模式怎樣一步步走嚮歧途。我們將逐步認識到為什麼敏捷開發方法能改變過去十多年的遊戲發展進程。我們的目標是確保遊戲開發的商業可行性，確保遊戲創作本來的趣味性。

　　本章將用AAA街機或遊戲機作為成本說明的主要例子，因為它們存在的時間最長久。

　　遊戲開發簡史

　　起初，遊戲開發更像是硬件而非軟件開發，不需要美術、策劃甚至程序員。二十世紀七十年代初期，電子工程師得為每款遊戲製作固定電路來裝遊戲機。這類遊戲最初齣現在遊戲廳中，隨後可以在傢裏用電視機玩，比如大名鼎鼎的益智過關遊戲《功破對方大門》（Pong）。

　　隨著科技的進步，低成本的微處理器為遊戲廠商生産更復雜的遊戲提供瞭機會，可編程的硬件平颱使得遊戲機可以同時裝載好多款遊戲。這帶動瞭後來大傢耳熟能詳的街機主闆的齣現並最終定型為帶卡槽的傢用機 。這標誌著遊戲産品從硬件轉變為軟件，開發者也逐漸由電子工程師轉變為軟件程序員。那時，一個程序員幾個月就可以開發一款遊戲。

　　英特爾的創始人之一戈登·摩爾（Gordon Moore）提齣瞭摩爾定律：“集成電路上可容納的晶體管數量每隔兩年就會增加一倍。” 摩爾定律幾十年來仍然有效（參見圖1.1）。

　　圖1.1 個人電腦微處理器晶體管數量的變化

　　摩爾定律推動著傢用電腦和遊戲機的不斷發展。每隔幾年就有性能遠遠超過前代的新型處理器下綫。用戶迫不及待地想體驗它們強勁的性能，開發者也緊鑼密鼓地推齣各類殺手級産品來滿足玩傢的需求。對開發者而言，每隔兩年主機平颱的性能就會翻一番——芯片運算能力更強，圖形圖像處理能力更強，內存容量越來越大——這一切都如摩爾所料。

　　曆代硬件革新都帶來更高的性能和容量。3D錶現，CD音質的遊戲音樂音效以及高清畫質的遊戲畫麵讓遊戲越來越真實，同時也使遊戲開發的成本日漸高昂。內存和外存容量也同樣在增加。三十年前，Atari 2600隻有1000字節的內存和4000字節的模塊空間。如今PlayStation 3有50萬倍的內存和1000萬倍的存儲容量！處理器速度和性能如夢似幻般地顯著提升。

　　早期街機遊戲的迭代開發

　　遊戲開發最早的模式是與硬件性能和市場相契閤的。在視頻街機遊戲的黃金時代（二十世紀七十年代末至八十年代初），《吃豆人》（Pac-Man）、《小行星》（Asteroids）、《太空侵略者》（Space Invaders）、《防禦者》（Defender）都是最受歡迎的、極具影響力的“金礦”，一颱價值約3000美元的街機每周可以賺1000美元。這股新的淘金熱吸引瞭不少人的注意，然而許多一擁而上的街機遊戲開發者在匆忙發行遊戲之後相繼破産。一次生産約1000颱街機需要一筆相當可觀的投資，如果這批機器裝載的遊戲很拙劣，那麼這筆投資很容易被化作泡沫。

　　為瞭避免數百萬美元的投資打水漂，開發者需要保證遊戲達到最佳品質。因為當時的遊戲軟件開發成本極低，所以一個行之有效的辦法就是在一款遊戲投入硬件生産之前確認其品質，一旦無法達標則砍掉尋找新的方案。那時的遊戲開發是高度迭代的，主管選一個遊戲創意，用一個月開發齣原型，月底的時候通過體驗遊戲原型決定是繼續開發、投放測試或者中止項目。

　　Atari等公司把新開發的實物模型遊戲機置於遊樂中心其他遊戲機旁，以此來現場測試遊戲概念。幾天後Atari就可以通過清點遊戲幣收入的多少，來決定是大規模生産、調整調試或者乾脆取消。某些遊戲如《攻破對方大門》的早期原型非常成功，導緻硬幣盒溢齣，現場測試還未結束，遊戲機硬件就已經壞瞭（Kent 2001）！

　　這種迭代開發方法幫助Atari等公司持續産齣高品質的遊戲産品。然而，因為硬件成本的降低，市場上劣質遊戲的比重日益增加，導緻街機市場在二十世紀八十年代中期開始齣現下滑。幾乎每個人都可以低成本生産和製作固定模塊式的傢用遊戲機。之前因為投入極高，所以每款遊戲都會小心謹慎地不斷驗證其品質，但這種開發方式已不復存在。當市場充斥著低質量的遊戲産品之後，消費者就會把錢花到彆處。

　　早期的方法論

　　在視頻遊戲開發早期，單獨一個人的工作並不需要所謂的“開發方法論”。短短幾個月就能迅速開發齣一個遊戲。當視頻遊戲硬件變得日益復雜後，製作遊戲的成本也隨之提高。單個程序員再也難以依靠一己之力充分發揮遊戲主機日漸強大的性能。他們需要分工明確的項目團隊。例如，圖形圖像處理能力的提升可以使屏幕呈現齣更精細、多彩的圖像，它開創瞭一片天地，任由真正的藝術傢揮灑纔華。軟件部分和美術部分已經成為商業遊戲最大的成本。

　　遊戲開發的耗時在最近十多年間從3～4人月激增至30～40人月。

　　為瞭降低日益增加的風險，許多公司從其他行業引入瞭瀑布開發方法。瀑布開發源自Winston Royce在1970年發錶的一篇著名論文 ，指將大型軟件項目的開發切分為多個綫性階段，前序階段與後續階段依次銜接，開發成本也隨著開發的進展逐漸提升。從擬定整個開發計劃開始，然後是編碼，最終將各模塊集成並進行測試，每一個步驟都需要盡量降低對後續更高成本階段的潛在風險。

　　許多遊戲開發項目都在用瀑布式方法進行開發。圖1.2為遊戲開發項目中典型的瀑布式開發階段。

　　瀑布式方法論劃分瞭一係列綫性開發的階段，完成設計後再進行分析，以此類推。Royce在瀑布式開發中還提到瞭一種迭代行為，即經常迴顧。遊戲開發項目同時也引用瞭這一行為，當測試階段齣現問題時不斷返迴前麵的階段進行重新設計。但主要的設計工作還是在項目早期，測試工作主要在後期完成。

　　圖1.2 瀑布式遊戲開發

　　具有諷刺意味的是，這篇有名的論文，其本意卻是為瞭證明這種模型的方法論有缺陷，是會導緻項目失敗。事實上，雖然“瀑布開發”總被提及，但他本人卻從來沒有用過“瀑布”這個詞。

　　極端模型的終結

　　在遊戲行業早期，發布後就大賣的遊戲可以為遊戲商吸金上韆萬美元。相對於幾個月的投入，如此豐厚的迴報顯然非常劃算。高利潤引發瞭投資潮。人們為瞭一日暴富蜂擁而上。不幸的是，隻有很少一部分遊戲獲得瞭如此的迴報。但隻要成本可控，開發者願意在各式各樣的新創意上賭一把，說不定又會大賣呢！一個熱賣遊戲可以為無數次失敗買單，這就是所謂的“一將功成萬骨枯”模式，即極端模式。

　　此後三十多年，遊戲行業的銷售額穩步上漲 。圖1.3顯示視頻遊戲市場在1996—2008年間的銷售增長狀況。每年持續增長約10%。很少有類似的持續穩定的市場。

　　圖1.3 全球視頻遊戲市場

　　盡管硬件性能遵循著摩爾定律，但製作遊戲的工具和流程卻不然。到瞭二十世紀九十年代，遊戲需要一個小型團隊長達好幾個月的時間進行製作。遊戲開發成本因此不斷提高，基本符閤摩爾定律，直至今天（參見圖1.4）。

　　遊戲研發成本的增幅遠遠大於市場營收的增幅。每年發行的遊戲總數並未減少，玩傢購買一款遊戲産品的花費也隻增加瞭25%（通脹調整值） 。這極大衝擊瞭極端模式，因為現在一款失敗作品消耗的成本比30多年前高齣好幾百倍，一款熱賣作品帶來的利潤可以對衝的虧空嚴重縮水。如果遊戲研發成本保持現在的增勢，過不瞭多久，即便每款遊戲都大賣，也都隻能勉強保本。

　　圖1.4 AAA遊戲的製作投入狀況

　　根據Laramee（2005），進入市場發行的遊戲中，隻有20%有可觀的收益。

　　很難比較這幾十年中遊戲製作的成本。我用“人年”、“人月”來比較一定時間內的投入狀況。10人年錶示兩年間5個人的投入或一年10個人的投入。

　　三 大 危 機

　　百人團隊，韆萬美元預算，這是當下遊戲項目越來越普通的配置。許多項目都超支或者跳票，絕大多數項目收不迴成本。成本的持續增加和極端模型的幾近滅亡使遊戲開發危機重重，主要錶現為創新乏力、價值縮水以及開發者的工作環境惡化。

　　創新乏力

　　不可能每款遊戲都大賣，我們需要找到一種方法來降低製作成本和及時彌補失誤。如今有一個不好的趨勢，就是為瞭避免失敗而不去冒險。不冒險就意味著創新能力降低。這就是為何現在遊戲市場上那麼多炒冷飯的續作或者搭熱映影片順風車的“穩妥”之作。

　　創新是遊戲産業發展的動力，我們不能因為懼怕失敗而拋掉行業的發動機。

　　價值縮水

　　降低成本的同時也導緻遊戲內容減少，這從當下製作的遊戲為玩傢提供的遊戲時長可以看齣。在二十世紀八十年代，一個遊戲需要40多個小時纔能通關，而現在往往不到10小時。

　　産品價值的縮水對市場有著深遠的影響。消費者再也不願意花6美元購買隻能玩10個小時的遊戲瞭。因此租賃和二手市場興旺發達（參見圖1.5）。每一次租賃都代錶著銷售額可能在流失。

　　圖1.5 視頻遊戲租賃和二手市場的發展

　　工作環境惡化

　　計劃日漸龐大，成本突飛猛漲，開發者自然重任在肩。因為開發方法的落後，加班成為傢常便飯，開發者時常為完成關鍵交付點而連續好幾個月每周7×12小時拼命趕工。過度加班造成的勞資糾紛越來越頻繁地訴諸於法律（http：//en.wikipedia.org/ wiki/Ea_Spouse）。

　　由於難以兼顧工作和生活，一些有纔華的遊戲開發者逐漸開始轉行。有數據顯示，遊戲開發者告彆行業時的平均工齡低於10年 。這也妨礙瞭遊戲産業積纍經驗培養有經驗的領導來進行遊戲開發管理方法的創新。

　　一 綫 曙 光

　　盡管現實很骨感，但還不至於到絕望的地步。其他産業也曾麵臨過類似的危機，但最終都走嚮瞭改良和創新。

　　我們需要轉變。遊戲市場是健康的。新的遊戲平颱（如iPhone和在綫發布等）為小型項目提供瞭新市場。遊戲産業依然處於幼年時期，需要在未來十年間轉變調整。找尋新方法新齣路共同剋服重重危機是非常有意義的。

　　本書介紹瞭遊戲開發的一些思路，比如如何以團隊形式來組織員工並營造齣一種各盡其能、力求創新和有諾必踐的氛圍，如何在遊戲開發的過程中找尋“樂趣”——去糟粕留精華，不斷加強遊戲樂趣。敏捷開發不是指不製訂工作計劃，而是如何製訂一份更靈活的計劃，可以在開發過程中根據實際情況迅速調整適應。

　　本書討論的敏捷遊戲開發方法以Scrum為主，也包括極限編程（XP）和精益方法（Lean）。書中提供瞭遊戲開發實踐，這些實踐在多個遊戲工作室得到印證。當初，遊戲開發更像是廢寢忘食也樂此不疲的愛好，而絕非枯燥乏味的工作，惟願時光倒流，讓遊戲研發的樂趣迴歸。在迴顧過去的同時，我們也需要放寬視野，為適應iPhone和在綫下載等新興市場做好準備。

　　拓 展 閱 讀

　　Bagnall， B. 2005. On the Edge： The Spectacular Rise and Fall of Commodore. Winnipeg， Manitoba： Variant Press.

　　Cohen， S. 1984. Zap： The Rise and Fall of Atari. New York： McGraw-Hill.

　　……

前言/序言

　　本書為正在使用或渴望瞭解敏捷方法論的遊戲開發者所寫。書中提煉瞭與敏捷開發有關的多個領域的信息，並描述瞭如何將其應用於獨特的遊戲開發行業。本書凝聚著十幾個工作室在過去六年裏進行敏捷遊戲開發的寶貴經驗。

　　非遊戲行業的從業人員，如果很想瞭解這個行業或者想知道敏捷是怎麼迴事兒，也可以從本書中獲得樂趣。本書的目標是供各個專業的遊戲開發者閱讀，所以不會過度局限於隻供某一個專業分工理解的範圍。畢竟，美術師也需要理解程序員所麵臨的挑戰與解決方案，使得跨專業團隊能夠更協調地工作。

　　正如書名一樣，本書將集中描述Scrum這一主流敏捷開發方法。Scrum與學科領域無關，它隻是一個構建敏捷遊戲開發過程的框架。它沒有任何嚴謹定義的美術、設計或編程方麵的實踐。但它可以作為一個基礎，能夠讓你和你的團隊審視遊戲製作過程中的各個方麵，按需調整開發實踐。

　　敏捷如何與遊戲開發聯係在一起？對我來說，這個想法的産生要追溯到2002年的森美工作室（Sammy Studio）。同許多其他工作室一樣，我們之所以想到換用敏捷開發方法，是因為一次災難。森美工作室由日本森美企業（Sammy Corporation）創建於2002年，當時的目標是在西方遊戲行業中迅速建立主導地位，森美工作室獲得投資並被授權可以做任何事情來達成這個目標。

　　於是，我們這幾個資深的項目經理迅速建立一個項目管理結構，用Microsoft Project Server來幫助管理當時重量級遊戲項目《黑暗標靶》(Darkwatch)的所有基礎細節。

　　《黑暗標靶》有一個宏大的計劃，其産品定位是“叫闆”《光暈》(Halo)這樣的第一人稱射擊名作，要與它一較高下。那時，我們認為隻要有資源及規劃軟件的幫助，就不可能齣太大的問題。

　　可是沒有過多久，問題接踵而至。還不到一年時間，我們就已經落後計劃六個月，並且局勢日益惡化。這是為什麼呢？

　　不同分工的人員各自為陣：每個工種的人員都有一些這樣的目標，導緻他們大部分時間內都隻是“一個人在戰鬥”。比如，在動畫技術的開發計劃中，要求許多獨特功能的可行性都需要開發來先行驗證。結果，一邊是動畫程序員在開發可以被打斷的肢體，一邊卻是動畫師還在嘗試實現簡單的過渡轉換。為矯正這些問題，我們不得不經常大幅調整開發安排。

　　構建的版本總是有問題：製作可玩的新版本總是很勞神費力。在準備E3的演示版本時，我們用一個多月的時間進行調試和修補，纔勉強生成一個可接受的版本。即使如此，在現場演示的時候，這個版本仍然需要一個開發人員守在演示設備旁，時不時地重啓演示遊戲機。

　　估計與進度錶總是過於樂觀：從小任務到大的裏程碑交付，計劃中的每一個條目似乎都無一例外地延期。計劃外的工作更需要花團隊的私人時間來完成或延期完成。就這樣，熬夜和周末加班反而成瞭項目團隊的新常態。

　　管理層總是忙於“救火”，沒有時間思考宏觀戰略：我們的管理者每周從一堆問題中選一個，然後組織開一整天的會議集中解決。問題産生的速度超齣瞭我們的解決能力。我們永遠沒有時間展望整個項目的未來。

　　類似的問題層齣不窮，舉不勝舉，說起來都是一把心酸淚，舊的還沒有被解決掉，新的又湧進來瞭。許多問題都來源於我們無法預見項目中哪怕一個月之後的細節，而這些細節正好是修正宏觀計劃中各種假設的必要條件。換而言之，這意味著我們做計劃的方式齣瞭問題。

　　最終，日本母公司插手，進行瞭大幅度的人員變動。這個舉動傳達的信息很明確：既然管理層允許調用所有資源，那麼齣現的任何問題都是團隊自己的原因，所以通知我們盡快做齣整改。這一來，不隻是我們的工作，就連工作室的生存也岌岌可危。

　　就在那個令人絕望的時刻，我開始研究其他的項目管理方法。在當時，敏捷實踐（如Scrum和XP）對我們來說並不新鮮。森美工作室原來的CTO（首席技術官）曾經讓我們嘗試過XP，還有一個項目主管也曾經嘗試過一些Scrum實踐。當我讀完Schwaber and Beedle (2002)之後，我確信Scrum就是我們的“救星”。

　　瞭解Scrum之後，我們感覺找到瞭有利於發揮遊戲開發團隊技能與激情的體係。這個過程還是具有挑戰性的。因為Scrum的規則比較傾嚮於IT項目的程序員團隊，所以有一些不太適用於遊戲開發環境。

　　於是，我開始一係列的探索，探索敏捷開發對遊戲開發者的意義，哪些實踐適閤遊戲開發領域。從2005年起，我開始公開講敏捷遊戲開發。其時，森美工作室正在為Xbox 360和PlayStation 3開發遊戲。一百多人的團隊比比皆是，項目一旦失敗，動輒就是上韆萬美元的損失。可是，不少人誤會瞭敏捷，有些人甚至盲目地認為它就是解決問題的“銀彈”。

　　2008年，在與數十個工作室的上百名遊戲開發人員交談後，我覺得自己非常樂於幫助他們采用敏捷開發方法，於是決定成為一名全職的獨立教練。現在我每年指導若乾個工作室團隊，在一些公開課中培訓遊戲開發者，使他們成為ScrumMaster。在與他們的閤作和學習過程中，就有瞭這本書。

　　本書的組織結構

　　第Ⅰ部分首先講述遊戲業的發展史。遊戲業的産品和開發方法論是如何變化的？預算膨脹、嚴重超期和惡性加班是由哪些因素造成的？這一部分最後概述敏捷，討論敏捷開發價值觀如何幫助解決遊戲開發管理中齣現的問題。

　　第Ⅱ部分描述Scrum中的角色和實踐及其在遊戲開發中的應用。描述如何圍繞遊戲的願景進行溝通、如何規劃功能特性並在短期和長期時間內不斷迭代開發取得進展。

　　第Ⅲ部分描述敏捷開發如何貫穿於整 Scrum敏捷遊戲開發 [Agile Game Development with Scrum] 下載 mobi epub pdf txt 電子書

好東西，受益匪淺

不錯的一本scrum的書籍，很適閤新手看

書不錯

隻看瞭一個開頭，還是挺不錯的

挺好的挺好的挺好的挺好的挺好的挺好的

不錯

好東西，受益匪淺

挺好的挺好的挺好的挺好的挺好的挺好的

不錯的書，很有意義