内 容 简 介

本书凝聚作者数十年的经验，讲解了如何将Scrum敏捷方法应用于游戏开发中，介绍了如何增强团队的内部协作和外部联系。针对长远规划、进度跟踪与持续集成，Keith提供了丰富的提示、技巧和解决方案，这些都源自他多年以来所积累的实践经验。

本书适合从事游戏开发的程序员、制作人、美术师、测试员和游戏策划阅读和参考。 

Simplified Chinese edition copyright © 2015 by PEARSON EDUCATION ASIA LIMITED and Tsinghua University Press.

Original English language title from Proprietor’s edition of the Work.

Original English language title: Agile Game Development with Scrum by Clinton Keith © 2010

EISBN: 97803211618528

All Rights Reserved.

Published by arrangement with the original publisher, Pearson Education, Inc., publishing as Pearson Education.

This edition is authorized for sale only in the People’s Republic of China (excluding the Special Administrative Region of Hong Kong and Macao).

本书中文简体翻译版由Pearson Education授权给清华大学出版社在中国境内(不包括中国香港、澳门特别行政区)出版发行。

 

前    言
本书为正在使用或渴望了解敏捷方法论的游戏开发者所写。书中提炼了与敏捷开发有关的多个领域的信息，并描述了如何将其应用于独特的游戏开发行业。本书凝聚着十几个工作室在过去六年里进行敏捷游戏开发的宝贵经验。
非游戏行业的从业人员，如果很想了解这个行业或者想知道敏捷是怎么回事儿，也可以从本书中获得乐趣。本书的目标是供各个专业的游戏开发者阅读，所以不会过度局限于只供某一个专业分工理解的范围。毕竟，美术师也需要理解程序员所面临的挑战与解决方案，使得跨专业团队能够更协调地工作。
正如书名一样，本书将集中描述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中的角色和实践及其在游戏开发中的应用。描述如何围绕游戏的愿景进行沟通、如何规划功能特性并在短期和长期时间内不断迭代开发取得进展。
第Ⅲ部分描述敏捷开发如何贯穿于整个游戏开发项目中，包括在制作过程中有一些情形可以将精益（Lean）原则和看板（Kanban）实践作为Scrum实践的补充。这部分重点探索和敏捷团队有关的问题，阐述如何将Scrum扩展为支持大型团队（而且这些人员甚至可能分布在全球各地）。此外，这一部分还总结了团队如何通过具体的手段（即减少对游戏各方面进行迭代所需要的时间）来持续提升开发效率。
第Ⅳ部分阐述多个专业领域的人员如何在敏捷开发团队中有效合作。这部分描述每个专业分工内的领导角色以及这些领导角色如何与Scrum角色相对应。
第Ⅴ部分详细描述将敏捷实践引入工作室和发行商时所面临的挑战及其应对方案。克服文化惰性，将敏捷原则结合应用于每个工作室的个性化过程中，同时还不能牺牲敏捷的好处，这不是一朝一夕就可以达成的，还有接二连三的挑战。这一部分将引导读者认识和应对这些挑战。
尽管本书希望成为各位读者开始敏捷游戏开发之旅的起点，但读完本书绝不意味着学习的结束。关于Scrum、极限编程、精益、看板、用户故事、敏捷规划和游戏开发等，还有很多非常值得阅读的书籍，它们都可以帮助我们进行持续改进。
iPhone、PC及大型多人在线游戏（MMOG）的开发者都在使用本书中描述的实践。基于本人的技术背景，我与大家分享了许多经历，对于敏捷程序员而言，也确实还有更多选择，但本书的目标读者是整个游戏圈的人。书中还有经历和经验，它们来自许多具备各种专业背景且在各种平台上开发各类游戏的人，非常值得读者参考和借鉴。

目    录
第Ⅰ部分  问题与方案
第1章  游戏开发危机四伏 3
游戏开发简史 3
早期街机游戏的迭代开发 5
早期的方法论 6
极端模型的终结 7
三大危机 9
创新乏力 9
价值缩水 10
工作环境恶化 11
一线曙光 11
拓展阅读 12
第2章  敏捷开发 13
为何项目如此困难 14
从“项目总结”中学习 14
问题 16
新增特性 16
盲目乐观的计划 18
产品制作过程中的挑战 18
为何采用敏捷游戏开发 20
知识是关键 20
成本与质量 21
先明确核心乐趣 22
消除浪费 24
将敏捷价值观应用于游戏开发 24
个体和交互高于过程和工具 24
可运行的软件高于详尽的文档 26
客户协作高于合同谈判 27
响应变化高于遵循计划 28
敏捷项目是什么样子的 28
敏捷开发 30
整个项目 31
敏捷面临的挑战 32
拓展阅读 32
第Ⅱ部分  Scrum和敏捷规划
第3章  关于Scrum 35
Scrum的历史 36
宏观大局 38
Scrum原则 40
Scrum的组成 41
产品Backlog 41
Sprint 42
发布 43
Scrum的角色 44
Scrum团队 45
团队 46
Scrum采用的关键说法 46
ScrumMaster 46
创造共享愿景 51
产品Backlog的责任人 52
发布管理 52
Sprint计划会议和回顾会议 53
客户和项目干系人 53
“鸡”和“猪” 54
Scrum可大可小 55
小结 56
拓展阅读 56
第4章  关于Sprint 57
全景图 57
计划会 58
Sprint优先级会议 58
Sprint计划会议 59
Sprint长度 62
客户反馈 62
计划和回顾时间 64
计划Sprint的能力 64
追踪进展 65
任务卡 66
燃尽图 66
任务板 69
作战室 70
每日Scrum例会 70
实践 71
Sprint评审会 72
单个团队内的评审 72
跨团队评审 73
发行方干系人 74
工作室干系人 74
坦诚的反馈 75
回顾 75
会议 75
记录并跟进结果 76
Sprint失败 77
Sprint中断 77
Sprint重置 78
当团队失败时 78
时间耗尽 79
提早完成任务 80
小结 81
拓展阅读 81
第5章  用户故事 82
一次重要的会议 82
什么是用户故事 84
详细程度 85
满意条件（CoS） 87
为用户故事使用索引卡 89
用户故事的INVEST原则 89
独立的 89
可商讨的 90
有价值的 92
可估算的 92
大小适当的 93
可测试的 94
用户角色 94
如何定义“完成” 96
收集故事 97
用户故事的优势 100
面对面交流 100
每个人都能理解用户故事 101
小结 102
拓展阅读 102
第6章  敏捷计划 103
为什么要进行敏捷计划 103
产品Backlog 104
产品Backlog优先级排序 104
持续计划 106
预见未来 107
预估故事大小 107
应该花多少精力进行预估 108
在哪里预估故事大小 109
故事点 110
计划扑克 111
故事点大小和斐波那契数列 111
理想天数 112
发布计划 113
发布计划会议 113
公布计划 116
更新发布计划 116
杂志演示与强化Sprint 117
小结 119
拓展阅读 120
第Ⅲ部分  敏捷游戏开发
第7章  视频游戏项目计划 123
《午夜俱乐部》的故事 123
最低要求的功能集 124
阶段的需要 126
开发阶段 126
混合阶段 127
用发布来管理各个阶段 128
敏捷项目中的制作阶段 130
产品阶段的工作 130
制作阶段Scrum所面临的挑战 132
精益生产 135
使用Scrum 147
转变Scrum团队 148
小结 149
拓展阅读 149
第8章  团队 150
伟大的团队 151
团队的Scrum方法 152
跨职能团队 153
自我管理 153
自我组织 154
团队规模 156
领导力 157
游戏团队和协作 160
特性团队 161
功能团队 162
制作团队 163
公共结构团队 163
工具团队 164
资源池团队 165
集成团队 165
缩放和分布式Scrum 166
大型团队的问题 166
SoS 167
PO层级 169
统一的Sprint日期 170
实践社区 172
避免依赖性 173
分布式团队 175
小结 179
拓展阅读 180
第9章  快速迭代 181
迭代开销从哪里来 182
迭代时间的测量和显示 182
测量迭代时间 183
显示迭代时间 183
个人迭代和版本迭代 184
个人迭代 185
提交的变更 186
失败告示 189
小结 192
拓展阅读 193
第Ⅳ部分  敏捷游戏开发四大要素
第10章  敏捷技术 197
面临的问题 197
不确定性 198
变更引发问题 199
后期改动的成本 199
太多预先架构系统 200
敏捷方法 201
极限编程 201
测试驱动开发 202
结对编程 204
调试 207
优化 208
小结 211
拓展阅读 211
第11章  敏捷美术和音频 212
我们用敏捷方法解决问题 212
对敏捷的担忧 213
美术主管 214
美术对跨领域团队的影响 215
创造性的张力 216
美术QA 217
构建美术知识 217
克服“未完成”综合症 218
预算 219
“链条终端”的音频 220
合作生产 220
小结 221
拓展阅读 221
第12章  敏捷设计 222
问题 223
设计不会创造知识 223
项目后期，游戏逐渐成形 223
Scrum与游戏设计 224
多个团队共用一个设计师 224
文档的作用 224
车库地板上的零部件 225
基于集成的设计 229
主设计师的角色 232
设计师是PO吗 232
小结 233
拓展阅读 233
第13章  敏捷QA和制作 234
敏捷品质保证 234
QA问题 235
敏捷测试不是一个独立的阶段 236
敏捷游戏团队中QA的职责 237
QA融入团队还是共用 239
每个团队有多少名测试人员 239
使用错误数据库 240
体验测试 241
QA的未来 243
敏捷制作 243
敏捷项目中制作人的职责 243
制作人作为ScrumMaster 244
制作人作为PO提供支持 245
制作人作为PO 245
制作人的未来 246
小结 246
拓展阅读 246
第Ⅴ部分  启动敏捷
第14章  Scrum的神话与挑战 251
银弹的传说 251
Scrum包治所有疑难杂症 252
Scrum包管项目如期发售 252
恐惧、不确定性和怀疑 253
开发无止境 253
时尚管理风潮 254
双重标准 255
变化皆坏事 255
没完没了的会议 256
Scrum的挑战 257
Scrum作为工序和文化转变的工具 258
Scrum关注的是增加价值，而非任务跟踪 259
现状与持续改进 260
盲目崇拜Scrum 261
Scrum并不是人人都适用的 262
加班 262
压榨 263
小结 265
拓展阅读 265
第15章  与发行商合作 266
挑战 266
迟来的关注 267
里程碑支付与合作 268
有限迭代 269
第一方问题 269
投资组合驱动日期 270
建立信任，减轻恐惧 270
恐惧 271
理解敏捷 271
发行商PO 272
及时迎接项目挑战 273
管理制作计划 274
减轻恐惧 275
敏捷合同 275
不按计划迭代 276
固定的发行日期 278
敏捷的前期制作阶段 280
阶段性评审模式 280
小结 282
拓展阅读 282
第16章  启动Scrum 283
导入Scrum的三个阶段 283
学徒阶段 284
用工具取代每日例会 287
熟练阶段 288
大师阶段 295
采取策略 297
桥头堡团队 298
全面部署 301
小结 304
拓展阅读 304