前言

本书写给正在使用或渴望了解敏捷方法的游戏开发人员。书中提炼了与敏捷开发多个领域相关的信息，描述了如何在游戏行业这个独特的生态系统中运用敏捷方法。本书取材于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。与他们的合作和学习，便成就了这本书。