游戲項目管理與敏捷方法（第2版） ( 簡體 字) |
| 作者：[美]克林頓·基思（Clinton Keith）著 周子衿 譯 | 類別：1. -> 遊戲 -> 遊戲程式 |
| 譯者： |
| 出版社：清華大學出版社 |  3dWoo書號： 54574
詢問書籍請說出此書號！【缺書】
NT售價： 795 元 |
| 出版日：4/1/2021 |
| 頁數：553 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787302574880 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：本書寫給正在使用或渴望了解敏捷方法的游戲開發人員。書中提煉了與敏捷開發多個領域相關的信息，描述了如何在游戲行業這個獨特的生態系統中運用敏捷方法。本書取材于2003 年以來作者親自參與的200 多個工作室的敏捷游戲項目。
至于非游戲行業的從業人員，則可以管中窺豹，通過本書了解一下游戲行業或者敏捷是怎么回事兒。本書適用于參與游戲開發的各專業人員，局限于特定的專業范圍。畢竟，做美術資源的如果也能理解程序員所面臨的挑戰及其解決方案，也可以增強跨專業團隊內部和外部的
協作。
在游戲行業的發展進程中，過去十年的變化超過以往任何一個十年。移動設備、數字化游戲商店、電子競技、云端游戲化以及GaaS（Game as a Service）等，都在挑戰著我們對游戲制作過程及方式的假設。盡管我不能說大多數工作室都用好了敏捷，但在過去的十年，敏捷確實給我們帶來了實實在在的好處。
敏捷與游戲開發如何結合呢？對我來說，這個想法開始于2002 年我在颯美工作室（Sammy Studio）的時候。和其他許多游戲工作室一樣，我們之所以想換用敏捷開發，是因為當時面臨著一場災難。颯美工作室是日本颯美2002 年創建的，當時的目標是在西方游戲行業迅速建立起主導地位。為此，颯美工作室獲得了投資并被授權為此不計一切代價。
作為老司機，我們幾個項目經理迅速建立了一個項目管理結構，用Microsoft Project Server 來幫助管理當時旗艦級游戲《黑暗標靶》的所有項目細節。
《黑暗標靶》有一個宏大的計劃，它的產品定位是“叫板”《光暈》這樣的第一人稱射擊名作，意欲和它一較高下。那時，我們的想法是，只要有資源及規劃軟件，就不會有搞不定的問題。
可是，沒有過多久，問題接踵而至。不到一年，我們就已經落后于計劃六個月，并且形勢還在加劇惡化。這是為什么呢？
不同學科的專業人員各有各的計劃安排：每個學科方向都有各自的計劃，團隊允許各個成員可以大部分時間各行其是。就拿動畫技術來說，動畫技術的開發有自己的計劃，它需要用到很多獨特的動畫特性，這些特性只有先做完，才能證明它可以用于動畫。如果各有各的計劃安排，就會出現這樣的后果：動畫程序員這邊在做會被打斷的手和腳，動畫師那邊卻還在嘗試做動畫過渡效果。為了對齊諸如此類的計劃問題，必須定期對日程安排進行大的調整。
要想讓最新版本的游戲運行起來， 總是需要額外付出更多的精力。準備E3 演示版的時候，調試和修修補補， 我們整整花了一個多月的時間才勉強生成一個可以接受的版本。即便如此，現場演示仍然需要一個開發人員守在演示設備旁邊，時不時地重啟機器。
估計與進度安排總是過于樂觀：從小任務到大的里程碑交付，計劃中的每一項似乎都延期了，無一例外。計劃外的工作更是需要團隊抽出私人時間來完成或延期完成。就這樣，熬夜和周末加班成了項目團隊的常態。
管理層總是忙于“救火”，沒有時間去考慮長遠目標：我們的管理者每周都從一堆問題中選一個出來，然后組織開一整天的會集中解決。問題產生的速度超出了我們的解決能力。我們根本沒有時間去看方向，去展望項目的未來。
類似的問題層出不窮，舉不勝舉。說起來都是淚，舊的還沒有被解決掉，新的又涌進來了。許多問題都來源于我們無法預見到項目（哪怕一個月之后）的細節，這些細節正好是修正詳細計劃中各種假設的必要條件。重要的問題是我們做計劃的方式錯了。
最后，日本母公司插手，進行了人事大變動。這個舉措傳達出一個明確的信號：管理層事先已經允許調用所有的資源，所以，一旦出問題，團隊都得自己擔責。于是乎，他們通知我們盡快整改。這一來，不只是我們的工作，就連工作室的生存也岌岌可危。
就在那個走投無路的至暗時刻，我開始研究其他項目管理方法。當時，敏捷實踐（比如Scrum 和XP）對我們來說并不新鮮。颯美工作室原來的CTO（首席技術官）讓我們嘗試過XP，還有個項目主管也嘗試過一些Scrum 實踐。等我讀完Schwaber and Beedle (2002) 之后，我確信Scrum 就是我們的“救星”。
了解Scrum 之后，我們覺得自己找到了有利于發揮游戲開發團隊技能與激情的體系。這個過程很有挑戰，因為Scrum 的規則比較傾向于IT 項目的程序員團隊，所以看上去不是特別適合游戲開發環境。
于是，我開始展開一系列的探索，探索敏捷開發對游戲開發人員的意義，琢磨哪些具體實踐適合游戲開發領域。從2005 年起，我就開始公開講敏捷游戲開發。其時，颯美工作室正在為Xbox 360 和PlayStation 3 開發游戲。動不動就是一百多人的團隊，項目一旦失敗，動輒就是上千萬美元的損失。遺憾的是，不少人誤會了敏捷，有些人甚至盲目地認為它就是解決問題的“銀彈”。
2008 年，在與幾十個工作室的上百名游戲開發人員交談后，我覺得自己非常樂于幫助他們采用敏捷開發方法，于是決定成為一名全職的獨立教練。現在，我每年都會指導若干個工作室團隊，通過公開課的方式來培訓游戲開發人員，使他們成為認證的Scrum Master。與他們的合作和學習，便成就了這本書。
關于第2 版
第2 版在第1 版的基礎上，新增了50％的內容，同時還根據我們過去十年的工作成果對現有的大部分內容進行了修訂。比如，Scrum 和看板雖然現在已經發展成為全球使用最廣泛的框架，仍然處于穩步的發展中。通過應用“檢視- 適應”原則，幾百萬個團隊紛紛投身于實驗，深入探索和積累更多的經驗和智慧，了解如何實現高度協作以及如何做出更好的產品。
自2010 年本書第1 版發布以來，敏捷和精益的采用、揭示和傳播方式已經發生了很多變化。和大多數創新一樣，早期采用者看到了成功以及隨之而來的“淘金熱”。工作室為了解決自身的問題，病急亂投醫之中倉促采用敏捷，于是許多根本就不理解游戲開發挑戰的教練和培訓師四處兜售他們的“特效藥”。就這樣，游戲行業遭受重創，敏捷或者說Scrum 和看板成了“背鍋俠”。
幸運的是，針對敏捷和精益，開始涌現出更加務實的觀點。現在，正如工作室所見，這些實踐和價值觀可以融入工作室定義和負責的工作過程中。不打上特定的標簽，持續試驗和保持專注，已經成為成功打造游戲的王道。
第2 版體現了這種務實的觀點。它更深入地介紹了我有幸獲得的行業實戰經驗。相比其他的因素，它更為看重游戲和開發人員。
本書的組織結構
第Ⅰ部分首先講述游戲行業的發展簡史。比如，游戲行業的產品和開發方法論是如何變化的？預算超支、計劃嚴重超期和惡性996 是由哪些因素造成的？最后概述敏捷，討論敏捷的價值觀如何幫助解決游戲開發管理中出現的問題。
第Ⅱ部分描述Scrum 和看板的作用與實踐及其在游戲開發中的應用。描述如何圍繞游戲的愿景進行溝通、如何規劃游戲特性的開發并在短期和長期不斷迭代中取得進展。
第Ⅲ部分描述敏捷開發如何貫穿于整個游戲開發項目中，展示了短期迭代用到的實踐如何擴展用于整個游戲，這樣一來，在整個游戲開發過程中，不只是特性的開發方式可以管理，還有游戲內容的創建，都是可以計劃、安排和持續優化與改善的。
包括制作過程，還有一些情形可以將精益原則和看板實踐作為Scrum實踐的補充。這部分重點探索和敏捷團隊有關的問題，闡述如何將Scrum 擴展為支持大型團隊（而且這些人員甚至可能分布在全球各地）。此外，這一部分還總結了團隊如何通過具體的手段（即減少對游戲各方面進行迭代所需要的時間）來持續提升開發效率。
第Ⅳ部分解釋了多個專業領域的人員在敏捷開發團隊中是如何實現有效協作的，描述了每個學科專業的主管角色及其如何對應于Scrum的各個角色。
第Ⅴ部分詳細描述敏捷實踐對工作室和發行商的挑戰及其應對方案。這部分描述工作室在過去十年如何通過避免典型的坑和轉變團隊互動來克服文化惰性，從而最終改善開發環境。
第Ⅵ部分帶領讀者超越基礎實踐，進一步深入到為敏捷開發團隊和工作室提供教練指導。分享了如何推動規模化敏捷的邊界和大型AAA游戲如何在分布式團隊的敏捷精益實踐。探索了如何通過敏捷來撬動新的平臺、技術和想法，游戲如何賦能于教育和醫療等行業。
盡管本書希望成為各位讀者開始敏捷游戲開發之旅的起點，但讀完這本書并意味著學習結束了。關于Scrum、極限編程、精益、看板、用戶故事、敏捷規劃和游戲開發等，還有很多非常值得精讀的書，它們都可以幫助大家走在持續改進的路上。
iPhone、PC 及大型多人在線游戲（MMOG）的開發者都在使用本書描述的實踐。基于本人的技術背景，我與大家分享了許多經歷，敏捷程序員確實還有更多選擇，但本書的目標讀者是整個游戲圈。書中還有許多經歷和經驗，它們來自專業背景不同且在各種平臺上開發各類游戲的人，值得大家參考和借鑒。
致謝
自本書第1 版問世以來，我一直在世界各地出差、培訓和指導團隊，您可以在本書中一見端倪。我每年大約訪問20 個工作室，我一直為此深感榮幸。但做游戲的每個人都有相同的特質，屬于同一個部落。在我看來，這個部落中，個個有創意，人人有激情。他們和我分享了他們的故事、艱辛和創意。在此，我要向他們表達最誠摯的謝意。
這本書的完成，前后花了一年。在這段時間里，我從審閱初稿并幫助我確定寫作方向的讀者那里獲得很多反饋意見和建議。感謝Bruce Rennie，James Birchler，James Everett，David West 和Justin Woodward 審閱書稿并提出了他們的想法。
有了Andie Nordgren，Brian Graham，Bruce Rennie，Caroline Esmurdoc，Dante Falcone，David West，Erik Theisz，Grant Shonkwiler，Greg Broadmore，James Birchler，James Everett，Justin Woodward，Kalle Kaivola，Michael Riccio，Rory McGuire，Shelly Warmuth 和Tim Morton 的參與和審閱，第2 版對我來說，更加容易了。
非常感謝培生的所有人，包括Haze Humbert，她的執著、遠見以及從頭到尾對本書的支持。感謝Tracy Brown，Lori Lyons 和Paula Lowell 的精心編輯。
我要向拜訪過的各個工作室的所有人表示感謝，感謝他們的合作，感謝他們讓我有機會向他們學習。最后，感謝視覺特效公司Magnopusa 優秀的小伙伴們。
我要感謝我的導師兼朋友邁克·科恩（Mike Cohn）。邁克當年以教練身份訪問了我們高月工作室。他的教練成果斐然，啟發了我也想成為一名教練。沒有他的支持和鼓勵，我不可能邁出這一大步。
a 譯者注：公司創始人之一本? 格羅斯曼（Ben Grossmann）是奧斯卡獲獎的視覺效果總監和虛擬現實（VR）導演，2012 年的《雨果》一片榮獲奧斯卡的最佳視覺特效獎。2014 年，他憑借著《星際迷航：暗黑無界》第二次榮獲奧斯卡獎提名。之后，他與另外兩名電影人聯合創立了VR 視覺特效公司Magnopus。自成立以來，成功交付的項目超過了65 個。其中有教育工具Mission ISS，能讓人進入國際空間站，控制設備，完成任務，甚至走到空間站外。此外，還配合電影《銀翼殺手2049》創作了Memory Lab，觀眾可以看到真人表演。再有就是創作了皮克斯工作室的VR 版《尋夢環游記》，讓觀眾探索電影中的世界。此外還創建了平臺Disney Movies VR。 |
內容簡介：《游戲項目管理與敏捷方法（第2版）》凝聚了作者數十年的從業經驗，講解了如何將精益敏捷方法中的Scrum 和看板應用于游戲項目的管理中，介紹了如何在尊重開發、美術、策劃等專業能力的前提下充分發揮每個人的優勢。與此同時，作者還針對長遠規劃、進度跟蹤與持續集成提供了豐富的提示、技巧和解決方案。
《游戲項目管理與敏捷方法（第2版）》適合游戲行業從事開發工作的程序、制作、美術、測試與策劃等崗位的人員閱讀和參考。 |
目錄：簡明目錄
第Ⅰ部分 問題與解決方案
第1章 游戲行業所面臨的危機3
第2章 敏捷精益開發15
第Ⅱ部分 Scrum和敏捷規劃
第3章 關于Scrum47
第4章 關于Sprint75
第5章 不是團伙，而是優秀的團隊109
第6章 看板121
第7章 產品Backlog135
第Ⅲ部分 敏捷游戲開發
第8章 用戶故事169
第9章 敏捷與發布計劃193
第10章 視頻游戲項目管理217
第11章 快速迭代255
第Ⅳ部分 敏捷規范
第12章 敏捷與技術實踐273
第13章 敏捷與游戲美術和音效293
第14章 敏捷與游戲策劃307
第15章 敏捷QA與制作323
第Ⅴ部分 啟動敏捷
第16章 Scrum的神話與挑戰343
第17章 與干系人合作361
第18章 團隊敏捷轉型385
第Ⅵ部分 追求卓越
第19章 指導團隊走向卓越407
第20章 自組織和領導力429
第21章 規模化敏捷游戲團隊465
第22章 實時游戲開發509
第23章 只有更好，沒有最好537
詳細目錄
第Ⅰ部分 問題與解決方案
第1章 游戲行業所面臨的危機3
本章提供的解決方案4
游戲開發簡史4
早期街機游戲的迭代開發6
早期的游戲開發方法7
極端模型的終結9
四大危機10
創新乏力10
價值縮水11
工作環境惡化11
來自手游和實時游戲的
挑戰12
成效或愿景12
第2章 敏捷精益開發15
本章提供的解決方案15
什么是敏捷16
什么是精益17
項目究竟難在哪里18
通過項目復盤來學習19
問題21
敏捷和精益，相得益彰26
游戲開發為什么要用敏捷和
精益27
成本與品質28
先明確核心樂趣29
多迭代，快失敗30
敏捷價值觀應用于游戲
開發30
精益原則在游戲開發中的
應用34
敏捷項目是什么樣的37
敏捷開發39
項目制vs實時制40
部署前的發布41
敏捷精益所面臨的挑戰42
成效或愿景42
第Ⅱ部分 Scrum和敏捷規劃
第3章 關于Scrum47
本章提供的解決方案49
Scrum的歷史49
大局51
Scrum價值觀54
Scrum原則54
產品Backlog，Sprint和發布55
產品Backlog55
Sprint57
發布58
Scrum的角色59
Scrum團隊60
開發團隊61
ScrumMaster61
PO67
客戶和項目干系人70
“雞”和“豬”71
規模化Scrum72
成效和愿景72
第4章 關于Sprint75
本章提供的解決方案75
全景圖75
計劃會76
Sprint目標77
第一部分：Sprint優先級
會議77
第二部分：Sprint計劃會78
Sprint的時間長度82
項目干系人的反饋83
計劃會和評審會的開銷84
Sprint規劃能力84
追蹤項目進展87
任務卡87
燃盡圖87
任務板91
作戰室92
每日Scrum站會93
實踐93
改進每日站會95
Sprint評審會97
小游戲的評審97
遠程的項目干系人98
游戲工作室干系人99
玩家99
坦誠的反饋99
Sprint回顧會100
會議100
記錄并跟進結果101
Sprint帶來的挑戰102
Sprint被中斷102
Sprint重置103
Sprint目標存在哪些
問題104
提早完工106
成效或愿景106
第5章 不是團伙，而是優秀的團隊109
優秀的團隊是什么樣子的110
本章提供的解決方案111
團隊的敏捷之路111
跨專業團隊113
通用型專家114
自管理115
團隊規模115
成效或愿景118
第6章 看板121
本章提供的解決方案121
什么是看板122
可視化工作流122
度量工作流124
管理工作流125
評審和回顧的節奏127
改進工作流128
減少批次大小和浪費128
減少交接128
應對瓶頸129
與Scrum的區別132
成效或愿景132
第7章 產品Backlog135
本章提供的解決方案135
一次決定命運的會議136
為什么策劃案會失敗137
產品Backlog138
PBI139
產品Backlog的優先級排序139
持續規劃140
允許改動和出現新問題142
鼓勵團隊參與和合作142
創建產品Backlog142
管理產品Backlog144
Backlog的梳理144
哪些人什么時候來參與
梳理活動144
產品Backlog的排序技巧145
如何定義“完成”150
債務類型150
管理債務151
開發團隊的DoD和項目
干系人的DoD152
面臨的挑戰155
失職的產品負責人155
代理產品負責人156
產品負責人委員會157
筒倉產品負責人158
如果產品負責人有注意力
缺陷……159
如果產品負責人目光短淺160
如果產品負責人距離團隊
比較遠162
成效或愿景163
第Ⅲ部分 敏捷游戲開發
第8章 用戶故事169
語言障礙170
本章提供的解決方案170
什么是用戶故事171
詳細程度172
接收條件（CoS）173
為用戶故事使用索引卡175
用戶故事的INVEST原則176
獨立的176
可協商的177
有價值的178
可估算的179
大小合適的180
可測試的181
用戶角色181
收集故事183
拆分故事186
根據研究或原型來拆分187
根據連詞來拆分187
按進度或價值劃分188
其他拆分技巧188
用戶故事的優勢189
面對面交流189
每個人都能理解用戶故事190
成效或愿景191
第9章 敏捷與發布計劃193
本章提供的解決方案194
什么是發布計劃195
發布計劃會195
確立一個共同愿景196
估算特性的大小199
速率199
估故事點需要花費多少
精力200
在什么場景下估算故事
大小201
故事點202
故事點的替代方案207
用故事點做發布計劃209
更新發布計劃211
營銷演示與集成Sprint212
成效或愿景214
第10章 視頻游戲項目管理217
《海岸午夜俱樂部》的故事218
本章提供的解決方案219
最小可行的游戲219
合同221
商定固定發售日期222
管理風險224
將風險納入產品Backlog225
需要有階段劃分226
制作階段226
混合階段228
用一系列發布來管理各個
階段228
精益開發230
開發債231
開發前衡量開發任務231
Scrum在開發階段會面臨
哪些挑戰233
看板與精益開發236
怎么用好Scrum250
轉為Scrum團隊251
成效或愿景252
第11章 快速迭代255
本章提供的解決方案256
影響迭代開銷的因素256
對迭代時間進行度量和顯示257
度量迭代時間257
顯示迭代時間258
個人迭代和build迭代259
個人迭代259
build迭代260
成效或愿景268
第Ⅳ部分 敏捷規范
第12章 敏捷與技術實踐273
本章提供的解決方案274
問題274
不確定性274
變更引發的問題276
后期變更成本276
預先設計的大架構277
敏捷方法279
極限編程（XP）279
調試286
優化287
成效或愿景290
第13章 敏捷與游戲美術和音效293
本章提供的解決方案294
對敏捷心存顧慮295
主美：美術領導力297
美術與跨專業團隊298
創造性張力298
美術QA299
建立美術方面的認知300
克服“未完成”綜合癥301
預算302
最后一步：音頻303
切換到看板304
成效或愿景304
第14章 敏捷與游戲策劃307
本章提供的解決方案308
策劃并不會創造知識308
最后一刻，策劃才能見到
游戲的真面目310
Scrum游戲策劃310
每個團隊都要有策劃嗎311
文檔的作用311
車庫地板上的零部件312
基于集合的設計317
策劃主管的角色320
策劃是PO嗎321
成效或愿景322
第15章 敏捷QA與制作323
敏捷QA323
本章提供的解決方案324
QA的問題324
大多數QA都只是QC325
敏捷測試并不是一個獨立的
階段326
敏捷游戲團隊中QA的職責326
QA，融入團隊還是共享329
每個團隊有多少名測試329
使用錯誤數據庫330
試玩331
QA的未來333
敏捷制作334
敏捷項目中，游戲
制作人的職責334
制作人擔任
ScrumMaster335
制作人作為PO助理336
制作人擔任PO337
游戲制作人的未來337
成效或愿景338
第Ⅴ部分 啟動敏捷
第16章 Scrum的神話與挑戰343
本章提供的解決方案343
銀彈的迷思344
Scrum可以為我們解決
所有問題344
FUD(懼惑疑心理戰術）345
Scrum的挑戰349
Scrum作為流程和文化
轉變的工具350
Scrum的目的是增加價值，
而非任務跟蹤351
保持現狀與持續改進的對比352
盲目崇拜Scrum354
Scrum并非普遍適用于
所有人355
加班加點356
壓榨357
成效或愿景359
第17章 與干系人合作361
本章提供的解決方案362
哪些人是干系人362
典型的挑戰363
關注得太晚364
里程碑付款與合作關系364
迭代限制366
第一方問題366
發布日期受制于投資組合366
建立信任，減輕恐懼367
恐懼368
理解敏捷369
發行方的PO370
盡早面臨項目挑戰371
管理制作計劃372
減輕恐懼373
敏捷合同374
不按計劃迭代375
固定發行日期377
敏捷的前期制作階段380
階段門模型380
成效與愿景382
第18章 團隊敏捷轉型385
本章提供的解決方案385
團隊敏捷轉型的三個階段385
學徒階段387
熟練階段392
大師階段400
成效或愿景403
第Ⅵ部分 追求卓越
第19章 指導團隊走向卓越407
什么是“卓越的團隊”407
為什么需要教練的指導408
本章提供的解決方案408
教練技術408
我的教練之路409
教練的立場410
引導412
教練工具414
通過教練來提升團隊績效415
心理安全感416
共同目標416
責任共擔416
工作協議417
根因分析法417
團隊成熟度模型418
團隊協作的五大障礙418
塔克曼模型419
情境領導力420
教練工具和實踐421
放松情緒422
愛心卡片墻422
鼓舞人心的便條423
閃電演講424
團隊的社交活動424
衡量團隊的健康程度425
團隊懺悔室426
360度評估427
成效或愿景427
第20章 自組織和領導力429
本章提供的解決方案430
自組織430
維爾福軟件431
超級細胞工作室433
團隊的成長434
領導力438
敏捷領導力438
工作室的領導力439
專業學科的領導力440
主管角色441
指導442
評審442
服務型領導443
系統思考444
把惡性循環變成良性
循環444
向系統外尋求446
內在動機447
自主447
精通447
目標448
心流448
尋找難度適中的挑戰450
技能提升450
工作室的教練451
角色轉換452
大規模Scrum：少即是多453
Scrum采用策略455
橋頭堡團隊455
全面部署459
成效或愿景462
第21章 規模化敏捷游戲團隊465
本章提供的解決方案465
規模化敏捷所面臨的挑戰466
一葉障目，游戲愿景呢466
后期加人467
大型團隊之間的溝通468
該不該規模化469
對錯誤的流程進行規模化470
MAGE框架471
整體聚焦到游戲上471
溝通、目標和自治472
系統思考472
以正確的方式規模化472
產品Backlog473
工具和思維導圖474
專業崗位集中化，組件
分散化474
團隊的組織結構475
支柱475
特性團隊475
組件團隊476
制作團隊477
支持團隊477
工具團隊479
合用團隊480
集成團隊480
特性領域團隊481
實踐社區481
產品所有權483
額外增加的角色485
項目管理支持485
補充角色485
游戲的核心支柱486
發布486
發布規劃486
落實發布計劃489
組隊489
更新發布計劃490
使用項目板490
Sprint491
Sprint日期要對齊492
SoS（ScrumofScrums）493
Sprint計劃會495
Sprint評審會496
Sprint回顧會497
管理依賴關系498
團隊的組成498
發布規劃會499
團隊依賴關系管理500
減少專家的依賴關系500
分布式開發和分散式開發501
分布式VS分散式501
分布式團隊面臨的挑戰501
分散式開發的挑戰504
成效或愿景506
第22章 實時游戲開發509
本章提供的解決方案510
游戲即服務510
為什么實時游戲也需要敏捷511
DevOps和精益創業512
反饋環512
實時游戲和戰斗機512
實時游戲的反饋環513
度量反饋環517
第一部分：計劃517
要有愿景518
建立玩家模型518
建立目標519
確定增量步驟519
提出假設519
第二部分：開發521
確定和度量整條流水線521
映射改進流水線的方法522
縮減批次大小524
實時游戲的QA526
第三部分：部署和支持526
持續交付527
實時支持工具529
第四部分：度量與學習533
度量結果534
召開回顧會，更新愿景534
成效或愿景534
第23章 只有更好，沒有最好537
本章提供的解決方案537
工作可視化538
特性板538
故事地圖541
為新的平臺開發游戲545
開發首發游戲546
并行開發547
敏捷和獨立游戲開發549
獨立游戲開發的魅力550
獨立游戲開發的挑戰550
敏捷開發如何提供幫助550
成效或愿景552
結語555 |
| 序： |
