游戏项目管理与敏捷方法有限公司计算机与互联网书籍

《游戏项目管理与敏捷方法（第2版）》阐述了精益敏捷中的看板与Scrum如何为游戏项目产生效能和价值。通过提供一个完整的蓝图，作者介绍了如何借力于精益敏捷来实现更，更快速和更经济的游戏交付，如何创造更有娱乐价值的游戏，如何保持工作与生活衡。书中包含作者帮助150多个游戏工作室取得了成功的宝贵经验，因地制宜地复制和应用这些经验，可以帮助整个游戏行业解决实际工作中的问题。

《游戏项目管理与敏捷方法（第2版）》的主题如下：

阐述如何应对手游、免费游戏和大规模敏捷游戏开发的现代挑战

大规模敏捷游戏开发过程以及如何管理首发，如何组建和领导敏捷团队

加入游戏开发团队的真实故事，增加了新的技巧提示

通过操作强的建议来阐明高级敏捷游戏项目如何创新

涵盖看板和敏捷方法论及Scrum，提供了具体的行动建议

全球有成千上万的专业游戏开发人员在用敏捷精益方法来极大地提速增效并乐在其中。本书为专业人士提供了更多的价值，无论开发什么类型的游戏，无论在开发中扮演什么角色，无论处于怎样的工作环境，都可以从本书中获得宝贵的经验和教训。

本书写给正在使用或渴望了解敏捷方法的游戏开发人员。书中提炼了与敏捷开发多个领域相关的信息，描述了如何在游戏行业这个的生态系统中运用敏捷方法。本书取材于2003年以来作者亲自参与的2001多个工作室的敏捷游戏项目。
　　至于非游戏行业的从业人员，则可以管中窥豹，通过本书了解一下游戏行业或者敏捷是怎么回事儿。本书适用于参与游戏开发的各专业人员，局限于特定的专业范围。毕竟，做美术资源的如果也能理解程序员所面临的挑战及其解决方案，也可以增强跨专业团队内部和外部的
　　协作。
　　在游戏行业的发程中，过去十年的变化超过以往任何一个十年。移动设备、数字化游戏商店、电子竞技、云端游戏化以及GaaS（Game 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。与他们的合作和学习，便成就了这本书。

第1章游戏行业所面临的危机电子游戏开发的拓荒期结束了。从前，独立游戏开发人员个个都是“全栈”，自个儿就可以全程负责策划①、编码和美术等一揽子活儿。现在，除了少数独立开发人员，这些工作大多已经有专业分工。今天的游戏行业，吸金能力大大超过了好莱坞。看起来，作为一个产业，游戏比以前成熟多了。然而，在游戏行业高歌的历史发展过程中，也犯过不少错误。举个例子来说，我们也干过抄作业这样的事儿，从其他传统行业依样画葫芦，简单照搬一些所谓的实践到游戏开发场景中。说句不好听的话，这就好比小小孩儿非要穿爹妈的旧衣裳，当然很不合体。用预先确定的宏大计划和流程来应对复杂程度相当高和不确定强的游戏开发，往往造成游戏上市后华而不实，很难成为真正受玩家欢迎的爆款游戏。再说，这种将就着凑合的方式还使游戏开发本身的乐趣丧失殆尽。最后，秉持着为成千上万玩家带来娱乐体验的初心，怀着满腔热入游戏行业的天才开发人员，在真入游戏行业之后，却深陷于暗无天日的996而备受煎熬，最后不得不带着多年积累下来的宝贵经验黯然转行。这样的事情，本来不应该发生。本章提供的解决方案首先，我们要看清楚问题的根源及其产生的原因。在本章中，我们要回顾游戏开发的发展历史，看一款游戏如何从昂的几个人两三个月就可以开发完，逐步发展到现在一个项目需要卜s人的团队花好几年的工夫才能完成。我们要展示这种继承自工业茸思想的开发模式是如何使游戏开发陷入危机的。在这种开发模式下人的创新和想象力遭到重创，不合理的计划频频施压，导致整个游没行业的工作环境不断恶化。与此同时，本章也是本书其余部分精益敏捷解决方案的基础，我们将逐步认识到为什么敏捷开发方法能够改变过去十几年游戏发展程。我们的目标是一方面确保游戏开发的商业可行，另一方面确保游戏创作本来的趣味。游戏开发简史最开始的时候，游戏开发更像是造硬件而非开发软件，不需要美术策划甚至程序这样的专业分工。20世纪70年代初期，游戏是一些特制的盒子或者卡带，电子工程师负责为每款游戏制作电路板。这样的游戏机只装一款游戏，最初出现在游戏厅，后来发展成为家用游戏机，可以在家里的电视机上玩，代表作有大名鼎鼎的过关游戏《乓》2

……