凝聚数十年经验：《Scrum敏捷游戏开发》

[美] Clinton Keith 著；何龙海 译。

清华大学出版社，2015年5月出版。

内容简介

《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

前  言

本书为正在使用或渴望了解敏捷方法论的游戏开发者所写。书中提炼了与敏捷开发有关的多个领域的信息，并描述了如何将其应用于独特的游戏开发行业。本书凝聚着十几个工作室在过去六年里进行敏捷游戏开发的宝贵经验。

非游戏行业的从业人员，如果很想了解这个行业或者想知道敏捷是怎么回事儿，也可以从本书中获得乐趣。本书的目标是供各个专业的游戏开发者阅读，所以不会过度局限于只供某一个专业分工理解的范围。毕竟，美术师也需要理解程序员所面临的挑战与解决方案，使得跨专业团队能够更协调地工作。

正如书名一样，本书将集中描述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）的开发者都在使用本书中描述的实践。基于本人的技术背景，我与大家分享了许多经历，对于敏捷程序员而言，也确实还有更多选择，但本书的目标读者是整个游戏圈的人。书中还有经历和经验，它们来自许多具备各种专业背景且在各种平台上开发各类游戏的人，非常值得读者参考和借鉴。