基本信息
内容简介
目录
第Ⅰ部分 问题与方案
第1章 游戏开发危机四伏 3
游戏开发简史 3
早期街机游戏的迭代开发 5
早期的方法论 6
极端模型的终结 7
三大危机 9
创新乏力 9
价值缩水 10
工作环境恶化 11
一线曙光 11
拓展阅读 12
第2章 敏捷开发 13
为何项目如此困难 14
从“项目总结”中学习 14
问题 16
新增特性 16
盲目乐观的计划 18
产品制作过程中的挑战 18
前言
本书为正在使用或渴望了解敏捷方法论的游戏开发者所写。书中提炼了与敏捷开发有关的多个领域的信息,并描述了如何将其应用于独特的游戏开发行业。本书凝聚着十几个工作室在过去六年里进行敏捷游戏开发的宝贵经验。
非游戏行业的从业人员,如果很想了解这个行业或者想知道敏捷是怎么回事儿,也可以从本书中获得乐趣。本书的目标是供各个专业的游戏开发者阅读,所以不会过度局限于只供某一个专业分工理解的范围。毕竟,美术师也需要理解程序员所面临的挑战与解决方案,使得跨专业团队能够更协调地工作。
正如书名一样,本书将集中描述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。在与他们的合作和学习过程中,就有了这本书。
本书的组织结构
第Ⅰ部分首先讲述游戏业的发展史。游戏业的产品和开发方法论是如何变化的?预算膨胀、严重超期和恶性加班是由哪些因素造成的?这一部分最后概述敏捷,讨论敏捷开发价值观如何帮助解决游戏开发管理中出现的问题。