内容简介

　　《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

精彩书摘

　　第1章 游戏开发危机四伏

　　游戏开发的拓荒期已然远去。昔日程序员单枪匹马——既做设计又做编码，还要负责美术表现——逐步被各有所长的集团军取代。游戏行业日渐走向成熟，盈利能力已经超过了好莱坞。作为一个产业，我们似乎成熟了。

　　游戏行业发展迅猛，但并非一帆风顺。我们从其他传统行业借鉴了一些不那么普遍适用的方法，将之套用于游戏开发，就像小孩穿着父母的旧衣服一样，极不合体。刻板的计划和规程难以应对游戏开发复杂度高和不确定性强的特点，往往导致最后出品的游戏华而不实，很难叫好又叫座。方法欠妥还使得游戏开发本身也丧失应有的乐趣。天赋异禀的有志之士满腔热情地踏入游戏行业，希望给千千万万的用户带来充满乐趣的游戏体验。然而，他们却暗无天日加班加点地在项目中煎熬，最后不得不带着多年的经验黯然离开这个行业。这实在是不应该啊。

　　在本章中，我们将回顾游戏开发的历史，看一款游戏如何从几个人月就可以出品，逐步发展到现在一个项目需要百人团队历时数年才能完成。我们将看看这种商业模式怎样一步步走向歧途。我们将逐步认识到为什么敏捷开发方法能改变过去十多年的游戏发展进程。我们的目标是确保游戏开发的商业可行性，确保游戏创作本来的趣味性。

　　本章将用AAA街机或游戏机作为成本说明的主要例子，因为它们存在的时间最长久。

　　游戏开发简史

　　起初，游戏开发更像是硬件而非软件开发，不需要美术、策划甚至程序员。二十世纪七十年代初期，电子工程师得为每款游戏制作固定电路来装游戏机。这类游戏最初出现在游戏厅中，随后可以在家里用电视机玩，比如大名鼎鼎的益智过关游戏《功破对方大门》（Pong）。

　　随着科技的进步，低成本的微处理器为游戏厂商生产更复杂的游戏提供了机会，可编程的硬件平台使得游戏机可以同时装载好多款游戏。这带动了后来大家耳熟能详的街机主板的出现并最终定型为带卡槽的家用机 。这标志着游戏产品从硬件转变为软件，开发者也逐渐由电子工程师转变为软件程序员。那时，一个程序员几个月就可以开发一款游戏。

　　英特尔的创始人之一戈登·摩尔（Gordon Moore）提出了摩尔定律：“集成电路上可容纳的晶体管数量每隔两年就会增加一倍。” 摩尔定律几十年来仍然有效（参见图1.1）。

　　图1.1 个人电脑微处理器晶体管数量的变化

　　摩尔定律推动着家用电脑和游戏机的不断发展。每隔几年就有性能远远超过前代的新型处理器下线。用户迫不及待地想体验它们强劲的性能，开发者也紧锣密鼓地推出各类杀手级产品来满足玩家的需求。对开发者而言，每隔两年主机平台的性能就会翻一番——芯片运算能力更强，图形图像处理能力更强，内存容量越来越大——这一切都如摩尔所料。

　　历代硬件革新都带来更高的性能和容量。3D表现，CD音质的游戏音乐音效以及高清画质的游戏画面让游戏越来越真实，同时也使游戏开发的成本日渐高昂。内存和外存容量也同样在增加。三十年前，Atari 2600只有1000字节的内存和4000字节的模块空间。如今PlayStation 3有50万倍的内存和1000万倍的存储容量！处理器速度和性能如梦似幻般地显著提升。

　　早期街机游戏的迭代开发

　　游戏开发最早的模式是与硬件性能和市场相契合的。在视频街机游戏的黄金时代（二十世纪七十年代末至八十年代初），《吃豆人》（Pac-Man）、《小行星》（Asteroids）、《太空侵略者》（Space Invaders）、《防御者》（Defender）都是最受欢迎的、极具影响力的“金矿”，一台价值约3000美元的街机每周可以赚1000美元。这股新的淘金热吸引了不少人的注意，然而许多一拥而上的街机游戏开发者在匆忙发行游戏之后相继破产。一次生产约1000台街机需要一笔相当可观的投资，如果这批机器装载的游戏很拙劣，那么这笔投资很容易被化作泡沫。

　　为了避免数百万美元的投资打水漂，开发者需要保证游戏达到最佳品质。因为当时的游戏软件开发成本极低，所以一个行之有效的办法就是在一款游戏投入硬件生产之前确认其品质，一旦无法达标则砍掉寻找新的方案。那时的游戏开发是高度迭代的，主管选一个游戏创意，用一个月开发出原型，月底的时候通过体验游戏原型决定是继续开发、投放测试或者中止项目。

　　Atari等公司把新开发的实物模型游戏机置于游乐中心其他游戏机旁，以此来现场测试游戏概念。几天后Atari就可以通过清点游戏币收入的多少，来决定是大规模生产、调整调试或者干脆取消。某些游戏如《攻破对方大门》的早期原型非常成功，导致硬币盒溢出，现场测试还未结束，游戏机硬件就已经坏了（Kent 2001）！

　　这种迭代开发方法帮助Atari等公司持续产出高品质的游戏产品。然而，因为硬件成本的降低，市场上劣质游戏的比重日益增加，导致街机市场在二十世纪八十年代中期开始出现下滑。几乎每个人都可以低成本生产和制作固定模块式的家用游戏机。之前因为投入极高，所以每款游戏都会小心谨慎地不断验证其品质，但这种开发方式已不复存在。当市场充斥着低质量的游戏产品之后，消费者就会把钱花到别处。

　　早期的方法论

　　在视频游戏开发早期，单独一个人的工作并不需要所谓的“开发方法论”。短短几个月就能迅速开发出一个游戏。当视频游戏硬件变得日益复杂后，制作游戏的成本也随之提高。单个程序员再也难以依靠一己之力充分发挥游戏主机日渐强大的性能。他们需要分工明确的项目团队。例如，图形图像处理能力的提升可以使屏幕呈现出更精细、多彩的图像，它开创了一片天地，任由真正的艺术家挥洒才华。软件部分和美术部分已经成为商业游戏最大的成本。

　　游戏开发的耗时在最近十多年间从3～4人月激增至30～40人月。

　　为了降低日益增加的风险，许多公司从其他行业引入了瀑布开发方法。瀑布开发源自Winston Royce在1970年发表的一篇著名论文 ，指将大型软件项目的开发切分为多个线性阶段，前序阶段与后续阶段依次衔接，开发成本也随着开发的进展逐渐提升。从拟定整个开发计划开始，然后是编码，最终将各模块集成并进行测试，每一个步骤都需要尽量降低对后续更高成本阶段的潜在风险。

　　许多游戏开发项目都在用瀑布式方法进行开发。图1.2为游戏开发项目中典型的瀑布式开发阶段。

　　瀑布式方法论划分了一系列线性开发的阶段，完成设计后再进行分析，以此类推。Royce在瀑布式开发中还提到了一种迭代行为，即经常回顾。游戏开发项目同时也引用了这一行为，当测试阶段出现问题时不断返回前面的阶段进行重新设计。但主要的设计工作还是在项目早期，测试工作主要在后期完成。

　　图1.2 瀑布式游戏开发

　　具有讽刺意味的是，这篇有名的论文，其本意却是为了证明这种模型的方法论有缺陷，是会导致项目失败。事实上，虽然“瀑布开发”总被提及，但他本人却从来没有用过“瀑布”这个词。

　　极端模型的终结

　　在游戏行业早期，发布后就大卖的游戏可以为游戏商吸金上千万美元。相对于几个月的投入，如此丰厚的回报显然非常划算。高利润引发了投资潮。人们为了一日暴富蜂拥而上。不幸的是，只有很少一部分游戏获得了如此的回报。但只要成本可控，开发者愿意在各式各样的新创意上赌一把，说不定又会大卖呢！一个热卖游戏可以为无数次失败买单，这就是所谓的“一将功成万骨枯”模式，即极端模式。

　　此后三十多年，游戏行业的销售额稳步上涨 。图1.3显示视频游戏市场在1996—2008年间的销售增长状况。每年持续增长约10%。很少有类似的持续稳定的市场。

　　图1.3 全球视频游戏市场

　　尽管硬件性能遵循着摩尔定律，但制作游戏的工具和流程却不然。到了二十世纪九十年代，游戏需要一个小型团队长达好几个月的时间进行制作。游戏开发成本因此不断提高，基本符合摩尔定律，直至今天（参见图1.4）。

　　游戏研发成本的增幅远远大于市场营收的增幅。每年发行的游戏总数并未减少，玩家购买一款游戏产品的花费也只增加了25%（通胀调整值） 。这极大冲击了极端模式，因为现在一款失败作品消耗的成本比30多年前高出好几百倍，一款热卖作品带来的利润可以对冲的亏空严重缩水。如果游戏研发成本保持现在的增势，过不了多久，即便每款游戏都大卖，也都只能勉强保本。

　　图1.4 AAA游戏的制作投入状况

　　根据Laramee（2005），进入市场发行的游戏中，只有20%有可观的收益。

　　很难比较这几十年中游戏制作的成本。我用“人年”、“人月”来比较一定时间内的投入状况。10人年表示两年间5个人的投入或一年10个人的投入。

　　三 大 危 机

　　百人团队，千万美元预算，这是当下游戏项目越来越普通的配置。许多项目都超支或者跳票，绝大多数项目收不回成本。成本的持续增加和极端模型的几近灭亡使游戏开发危机重重，主要表现为创新乏力、价值缩水以及开发者的工作环境恶化。

　　创新乏力

　　不可能每款游戏都大卖，我们需要找到一种方法来降低制作成本和及时弥补失误。如今有一个不好的趋势，就是为了避免失败而不去冒险。不冒险就意味着创新能力降低。这就是为何现在游戏市场上那么多炒冷饭的续作或者搭热映影片顺风车的“稳妥”之作。

　　创新是游戏产业发展的动力，我们不能因为惧怕失败而抛掉行业的发动机。

　　价值缩水

　　降低成本的同时也导致游戏内容减少，这从当下制作的游戏为玩家提供的游戏时长可以看出。在二十世纪八十年代，一个游戏需要40多个小时才能通关，而现在往往不到10小时。

　　产品价值的缩水对市场有着深远的影响。消费者再也不愿意花6美元购买只能玩10个小时的游戏了。因此租赁和二手市场兴旺发达（参见图1.5）。每一次租赁都代表着销售额可能在流失。

　　图1.5 视频游戏租赁和二手市场的发展

　　工作环境恶化

　　计划日渐庞大，成本突飞猛涨，开发者自然重任在肩。因为开发方法的落后，加班成为家常便饭，开发者时常为完成关键交付点而连续好几个月每周7×12小时拼命赶工。过度加班造成的劳资纠纷越来越频繁地诉诸于法律（http：//en.wikipedia.org/ wiki/Ea_Spouse）。

　　由于难以兼顾工作和生活，一些有才华的游戏开发者逐渐开始转行。有数据显示，游戏开发者告别行业时的平均工龄低于10年 。这也妨碍了游戏产业积累经验培养有经验的领导来进行游戏开发管理方法的创新。

　　一 线 曙 光

　　尽管现实很骨感，但还不至于到绝望的地步。其他产业也曾面临过类似的危机，但最终都走向了改良和创新。

　　我们需要转变。游戏市场是健康的。新的游戏平台（如iPhone和在线发布等）为小型项目提供了新市场。游戏产业依然处于幼年时期，需要在未来十年间转变调整。找寻新方法新出路共同克服重重危机是非常有意义的。

　　本书介绍了游戏开发的一些思路，比如如何以团队形式来组织员工并营造出一种各尽其能、力求创新和有诺必践的氛围，如何在游戏开发的过程中找寻“乐趣”——去糟粕留精华，不断加强游戏乐趣。敏捷开发不是指不制订工作计划，而是如何制订一份更灵活的计划，可以在开发过程中根据实际情况迅速调整适应。

　　本书讨论的敏捷游戏开发方法以Scrum为主，也包括极限编程（XP）和精益方法（Lean）。书中提供了游戏开发实践，这些实践在多个游戏工作室得到印证。当初，游戏开发更像是废寝忘食也乐此不疲的爱好，而绝非枯燥乏味的工作，惟愿时光倒流，让游戏研发的乐趣回归。在回顾过去的同时，我们也需要放宽视野，为适应iPhone和在线下载等新兴市场做好准备。

　　拓 展 阅 读

　　Bagnall， B. 2005. On the Edge： The Spectacular Rise and Fall of Commodore. Winnipeg， Manitoba： Variant Press.

　　Cohen， S. 1984. Zap： The Rise and Fall of Atari. New York： McGraw-Hill.

　　……

前言/序言

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

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

　　正如书名一样，本书将集中描述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中的角色和实践及其在游戏开发中的应用。描述如何围绕游戏的愿景进行沟通、如何规划功能特性并在短期和长期时间内不断迭代开发取得进展。

　　第Ⅲ部分描述敏捷开发如何贯穿于整 Scrum敏捷游戏开发 [Agile Game Development with Scrum] 电子书 下载 mobi epub pdf txt

好书，正好研究用，与工作相辅相成

挺好的挺好的挺好的挺好的挺好的挺好的

好东西，受益匪浅

huuuuuuu九一九一

很好很好很好很好很好

明明翻译有好几个人，为什么作者只写一个人？

不错的书，很有意义

明明翻译有好几个人，为什么作者只写一个人？

好书推荐给大家