转至游戏大观 http://www.gamelook.com/?p=1616

简介
Boomzap是一个完全虚拟的工作室。我们没有办公室，每个人都使用弹性工作时间在家工作。我们的团队包括了十多个全职员工，以及来自世界各地的兼职员工，如美国，日本，马来西亚，新加坡，俄罗斯，菲律宾。他们其中的大多数人一年只见过一次面，甚至很多核心的团队成员都从未彼此见过面。更不可想象的是，我们当中的很多成员都过着具有移动性的生活：例如我本人经常在西雅图，新加坡和横滨之间穿梭。我们从2005年开始就一直用这种方式工作，并取得了令人满意的成效。

我曾经多次被问起我们是怎么成功的使用这种工作方式的，我很乐意分享这其中的经验。虽然本文可能更适合于想我们这样的小型的偏外包行的工作室，但是传统大型工作室的管理者们应该也能从中获得一些有用的信息。首先我想说明一下为什么我们会采用目前这种工作方式，这种在家工作的分布式办公模式有什么优势：

接触到世界各地最好的开发者：我们能雇佣全球任何地方的任何人，而不用担心办公地点和护照等问题。我们的员工不必远离他们的居住地，远离他们的交际圈，来和我们一起工作。事实上，我们有些员工正是居住在十分偏远的地方，为我们工作，他们的家距离最近的游戏公司也有上百英里。

更低的劳动力成本＋更低的生活成本＝快乐的开发者（Lower Labor Costs + Cost of Living Adjustments = Happy Developers）：因为亚洲的薪筹水平比北美要低，所以我们的人力成本很有竞争力。但是我们并没有把这当成是雇佣廉价劳动力的机会，我们没有根据当地的收入水平而降低员工的薪水，而是统一按照新加坡的薪筹水平来支付员工工资，不管员工在哪个国家。可能对于美国和英国的开发者来说这不是最好的策略，但是对于俄罗斯，马来西亚，菲律宾这些地方的员工来说，他们得到的薪筹在当地应该算是最好的。这样我们就能够聘用到这些地区最好的开发者，并让他们觉得非常开心。

更低的日常开销：我们不用为办公地点，电脑，用电，咖啡机甚至是便笺纸而花钱。当然我们的确会花一些钱来帮助员工们购置开发设备，但是要知道他们是游戏开发者，即使我们不帮他们购买，他们自己家里通常会拥有他们所能买得起的最好计算机。我们只是避免了传统办公室里的重复开销，并用这些省下来的钱来更好的补偿我们的员工罢了。

自由高效地安排工作和生活：我们的工作方式允许团队中的每个人自己安排工作时间，将工作效率最大化。这不仅节省了很多通常会被浪费掉的时间，例如成员之间的交流时间等，也让员工们能够有更多的时间去做一些在传统公司中不可能做到的事，例如上函授学校，在学校教书等等。这种自由度所能为员工带来的好处和快乐是其它任何传统工作方式都无法比拟的，是无法简单用时间和金钱来衡量的。

工作与生活的平衡＋金钱＝忠诚无私的员工：简单来说，这种工作方式最终的结果就是我们的员工非常乐意为Boomzap工作。任何管理者都知道留住优秀的员工是公司成长的关键因素之一，我们的这种工作方式就是不仅让我们能从世界各地招聘到最好的员工，而且能留住他们。事实上，从2005年至今，我们还没有一个员工主动离职。

这些听起来很不错，不是吗？是的，确实很不错。但是其中的奥秘在于你能像管理一个传统工作室那样去管理一个虚拟的分布式的工作室。我们的具体管理策略很难在这里详细表述，所以在此我仅仅列出我们管理一个虚拟开发工作室的最重要的10条策略。简单来说，这些策略虽然对于我们来说很适用，但是你需要根据你的团队具体情况，你们的工作流程，团队结构来综合考虑这些是否适用于你们。

10条戒律
#1: 我们从不记录工作时间
我管理Boomzap所遇到的第一个问题就是：“你怎么知道他们是否在工作？”回答很简单：“无所谓。”我知道一个专业的开发者在40个小时一周的工作时间中能够完成多少工作。每周一我将这些工作分配下去，期望它在周末的时候能被完成。如果完成了，我不在乎他们花了多少时间去完成它。如果没完成，他们就得周末继续工作来确保它的完成。事实上，我非常希望他们能在40小时内完成我分配的任务，然后用剩余时间去做自己高兴做的任何事。

关于这个问题的经济帐很简单：如果你想鼓励你的员工更高效的工作，你就不能把“工作时间”固定下来，因为如果工作时间成为了常量，工作质量和数量就会反而成为变量。在传统工作室中，“工作时间”是固定不变的常量，对于高效完成工作的最好奖励就是你会获得更多的工作安排。更糟糕的情况是，在传统模式下，较差的员工所遗留下来的工作要交给较好的员工来做，因为较好的员工在相同时间内能完成更多的事情。这样你在不经意间就给了较差的员工一个奖励：少做些事，剩下的让较好的员工去做吧。这真的很糟糕。

相反在Boomzap，我们把工作质量和数量当作常量，然后允许员工自己用时间来衡量自己的工作效率：他们有一个任务列表和一个最低标准，然后自己安排时间去完成这些任务。如果他们能更快更好地完成任务，他们所获得的奖励就是有更多的剩余时间用来休息。如果他们不能完成任务，很快他们就会发现自己周末经常需要加班。在这种模式中，不具备效率的员工自然会被淘汰，因为他们有太多的工作需要加班去完成。同时，效率高的员工会发现自己拥有了更多的自由支配时间——自由支配时间就是对员工的一种很好的奖励。每天都能让你的好员工获得奖励，这可是很不错的魔咒哦。

#2: 我们会做Daily Build（每日构建）
在一个你不能在大厅里游走，查看每个人都在做什么，并给他们分配任务的虚拟工作室中，你需要一种至关重要的机制，来检查人们每天都在做什么，并对他们的工作给予反馈。为了解决这个问题，我们有一套非常严格的Daily Build策略。每一天结束的时候，我们会构建一个包含了所有最新美术资源和设计要素的游戏版本。我们根据这个最新的游戏版本来评价这一天的工作。这也是我们用来评价工作的唯一标准。我对员工的工作反馈当中有90％都是直接来自于这个daily build。我确保员工每天能拿到这份反馈意见，这样他们就能知道他们十分在朝着正确的方向前进。这样的daily build以及反馈过程是我们这个公司的生命血液。如果我们的daily build走向失败，那么整个项目也就走向失败了。

#3: 我们将全职员工和基于项目的特别员工混合编制在一起
有些工作只要有足够多的初级员工就能做得很好，有些工作交给擅长这方面的人来做，能做得更快更好，没必要使用你最好的资源来做所有的工作。问题是你很难用固定不变的薪水来长时间留住初级员工和专才。所以我们的策略是留住那些高级的通才，并让他们来做游戏中的核心设计和架构工作，然后将大量的内容制作外包给那些专门做这方面的人，以及我们雇佣的一些工作室。因为在任何时候我们的项目当中都有超过一半的成员是来自于我们雇佣的一次性合同工，这些人员是我们能够根据需要随时变更的，或者是根据需要缩减项目组成员，而不必裁减任何我们的员工。这对于现金流的控制及其有用。

关键在于我们外包的目的不是在于减少成本——事实上我们的很多合同工的成本比正式员工还要高——我们外包的目的是将我们工作室的空闲时间风险转移出去。举例来说，我们会将所有的网页，声音，大量的手绘背景，人物肖像等工作外包出去。这些工作都是熟练工们可以高效高质量完成的工作，并且都是只在项目开发中的某些特定阶段才需要的。当我们需呀他们的时候，我们支付比正常水平高的报酬给他们，而当我们不需要他们的时候，不用为了“解雇他们”而付出任何开销。

#4: 我们是否雇佣他为全职员工主要取决于他的性格
我们的工作方式对于成熟的，主动的，富于自律精神的人来说是最好不过的。但可惜的是很多优秀的程序员，美术和策划并不适合在家里依照自己的作息时间表来工作。你必须及其小心地进行测试，不要雇佣那些不适合这种方式的人。

我们的做法是对于每一个要加入我们工作室的成员，先进行一个月的考核，然后给他3个月的试用期。即使是我们很熟悉的开发者也是如此。第一个月的考核主要是考核对方的专业能力，判断他是否有能力完成这个工作。3个月的试用期里则是对他性格和自我管理能力的综合考察。有几次我们缩短了对一些人的3个月的试用期，随后我们便后悔了。此后我们再也不随便缩短试用期，对于不是很熟悉的人，我们甚至会延长3试用期。

这里的底线是，如果你将要让你的员工以这种方式工作，你必须要认识到有一些人——甚至包括一些十分优秀的程序员——就是无论如何也无法适应这种工作方式的。但是对于那些独立自主，善于自我激励的人，这种工作方式能起到很好的作用。

一些人将这种现象解释为“虚拟工作室不能雇佣那些年轻的没有经验的开发者”，我们不同意这个看法。我们的一些最好的员工恰恰是那些年轻的，很有动力的实习者。而那些无法适应这种方式的人往往是一些接受过专业训练的，有长期的传统游戏工作室经验的人。这里最重要的不是经验而是工作动力和个人品质。

#5: 我们用“基于项目的联盟结构”来取代权威
另一个我经常被问起的关于Boomzap结构的问题是：“你不能跟他们会面和交谈，那你到底怎么管理这些人呢？”用一个制作人的说法来问就是：“你怎么保证团队中的人所做出来的东西就是你想要的呢？”回答很简单，我们不保证。公司中的每个员工都被分配在一个特定的项目中。他们知道他们所在的项目是什么，在项目里他们有很大的自由和权利。我们的策划所做的是高度抽象化的设计，就像我们的任务一样。我们不对我们的员工做细致的管理，并不是因为我们讨厌细致的管理，仅仅是因为要做到细致管理，光是大量的邮件就够你受的了。相反的，我们建立3到4个人的小组，我们允许他们按照自己的意愿去做游戏。我们对他们的管理非常松散，给了他们足够的自由度，让他们能够自己做决定。

这种方法相对于传统的集中管理式的工作室来说，更像是一堆独立项目所组成的联盟。每个小组都有独立的权利可以对设计做出很大的改动，而不必去问总部这样做是否合适，由此而减少了大量的沟通成本。这种方法对于一个项目能力很强的团队来说，可以收到很好的效果，而对于项目能力较弱的团队来说，由于缺少了整体把握，可能会导致项目失败。所以了解你的员工的能力很重要。

有一句话是这么说的，接受那些并不是你所期望的，但是被完成得很好的工作，是成功的关键。在传统游戏工作室里，最常见的情况是整个项目组耗费了大量的时间，仅仅是为了实现其中某一个人的梦想，然后他们就在这无止尽的追求中反复修改，返工，试图让游戏更接近他的想法。请将项目托付和授权给你的项目组成员，客观地去取舍那些不是你想要的但是做得很好的东西。这样做有两大好处：1）你的组员们会由衷地感到高兴，因为他们自己做的东西能被最终放在游戏里面，而不必为了别人的想法去改变什么；2）有些时候那些你不想要的东西的确会比你脑子里的想法要更好一些。

记住，将项目托付给组员的同时，要将责任也托付给他们。如果你想要你的组员们真正地对自己的工作负起责任来，你就不能老是低估他们的工作，总是强迫他们按照你的意愿去返工。“这是不是我想要的？”这个并不是问题。你最好这样问自己：“这是不是玩家所喜欢的东西？”

#6: 我们雇佣那些会做实事的管理者
我们这种工作方式的一大优点是你无法隐藏那些对项目没有贡献的成员。那些潜伏传统大型工作室里，老是做一些“过程优化”和“促进会议”工作的中层管理者们在一个虚拟的工作室里就找不到这样的事可做。我们也一点儿也不因此而想念他们。团队中的每个人，甚至包括公司组建者，都会在项目里承担一定的工作，例如脚本编辑，测试，关卡设计等。因为我们评价一个员工的唯一标准就是他的工作有多少被包含在了我们的游戏中。正因为我们的管理者被迫要与项目的技术层面打交道，他们会对团队中的每一个成员在做什么都了如指掌，对某项工作到底要花多少人力来完成也会更加清楚。这样对项目所带来的好处是不言而喻的。

#7: 我们依赖于3P：PowerPoint, Prototypes（游戏原型）, Photoshop
我希望我不是第一个告诉你这话的人，但是的的确确是没有人会阅读设计文档。事实上，当我以前在一个比较大型的工作室上班的时候，我就养成了一个习惯，我会在那些超过50页的设计文档中的某处插入一句话：“谁看到这句话我就给他5美元。”然而10年来从没有一个人来找我要过这5美元。这是个真实的故事。有问题的是，业界找到了一种方法来改变这种状况，开会，开大量的会议。然而作为一个虚拟工作室，我们不能像他们那样大量开会，我们甚至都不能彼此见面，因此我们只能想出另一种解决方法。

首先，我们用一个很短的PowerPoint演示稿来作为游戏的最初设计。这个PowerPoint文档中全是图片，扫描的手绘图，从其他游戏中引用的截图，google中搜索到的各种图片。是的，一个没有文字的文档。这个文档基本上是游戏中所有状态画面的设计草案，描绘出这个游戏大致的样子以及它的玩法。接下来，我们让程序员基于这份文档做出一个粗糙的游戏原型，原型中的图片就用PowerPoint文档中的图片，没有合适图片的就用灰色方块来替代。这个游戏原型，加上我们每天对于它的反馈和改进记录，就构成了我们的“策划案”。过了一段时间之后，当这个游戏原型变得真正好玩起来了，我们的美术就从这个原型游戏的截图开始，在Photoshop中设计它的画面，然后给出游戏mockup版本所需的所有图形资源。

当这些都完成之后，我们就进入完整开发阶段。通常会有一个人坐下来，利用现有的PowerPoint文档和游戏原型，列出一些列简单的任务列表，表明要让这个原型变成最终产品，还有哪些工作是需要去做的，这样的一些列表加上PowerPoint文档和与游戏原型，3者就构成了一个更接近于策划案的“策划案”。我们的大多数游戏都只有不超过20页的文档，而且我们还在考虑这20页是否太多了点。

#8: 我们使用“制作人兼程序(Producer-Programmers)”
我们开发中的另一个强大的秘密就是，我们的每一个项目都由一个制作人兼程序来负责。他是一个具备较高专业技能的程序员，不仅要完成游戏的核心代码，而且要从整体上来把握这个产品，把握这个游戏里面的所有方方面面。我们以这样的结构来搭建项目组有几个原因，最重要的一个原因就是：这样一来，与美术和音乐制作者打交道的人就是那个要把这些资源加入到游戏中的人。这样就减少了很多沟通环节，减少了很多由于沟通而带来的误差。而且这样一来制作人就可以直接去实现和测试自己的新想法，而不是当制作人有了新的想法后，要先去给程序员解释，然后再由程序员来实现。

#9: 我们创建了一套“简明可靠（Idiot-proof）”的工作流程
传统开发工作室经常需要消耗大量的“沟通时间”来帮助美术，策划和音乐制作者将他们的工作内容集成到游戏中去。因为我们没法让两三个人围坐在一张桌子周围来解决这类问题，也因为让我们的程序员来撰写详细的资源集成文档是一种浪费和幼稚，我们会花很长的时间来开发相应的自动化工具，确保所有这些资源能很简单地被加入到游戏中。

我们最大的工具就是Excel，我们用它来编写各种资源脚本，例如精灵列表，声音文件列表，关卡设计变量，物体变量，国际化字符串等等。每个Excel表格中会有一个很大的“导出”按钮，用来导出资源脚本，任何人都不能随意修改其中的内容。请记住，自动化意味着所有的错误都是系统错误，都是可以快速定位和解决的。同时因为所有的人都能很容易地阅读Excel表格，并填充里面的变量，大多数人都能清楚地知道如何将他们手头的资源集成到游戏中，这些过程都不需要程序员来干预。

我们的关卡设计工具也是很简单的。它们都是符合“所见即所得”思路的编辑器，可以直接从游戏中开启，仅用鼠标即可完成大多数操作。这让我们的设计人员能高效地设计和测试游戏中的关卡。因为决定哪些Excel表格会被游戏引擎处理的人同时也是导出Excel表单和关卡编辑器数据的人，这个过程保证了绝对的简明可靠。

#10: 我们只雇佣技术型的美工
最后需要说明的是，事实上我们没有多少全职的美术人员。我们会将大量的美术工作外包出去，尤其是各种花纹，背景，肖像，故事插图等等。所有这些都能迅速地被那些外包团队完成，然后返给我们，我们仅需要少量的工作将这些资源整合到游戏中即可。我们团队中的美术都是技术型的，他们对于我们的开发工具和相关技术比较了解，例如字体，动画物体，粒子，用户界面等。这样我们不仅可以不用在团队中维持那些概念美术，而且也避免了让我们去交那些临时合同工使用我们的工具。

虚拟工作室的9个关键工具
下面这些是我们的虚拟工作室中实际使用的用以帮助我们开发的工具。这个部分不是帮下面这些工具打广告，只是这些工具跟我们的所有人都合作愉快。你可能知道更好的选择，但我只是告诉你我们的选择：

1. CVS: 如果你在开发中还没有使用任何版本控制系统，那么迟早你会发现自己将大量的人力浪费在了解决无休止的文件错乱，版本错乱的问题中。在传统工作室中是如此，在虚拟工作室中这显得更加重要。你使用何种工具并不重要，但你一定要至少使用一种。我们用的是CVS，但这只是我们的选择。任何你觉得方便的工具都可以。

2. Basecamp: 我们项目中使用的一个小巧的在线团队合作工具。每月只需25美元，就能让我们创建无限量的工程，让发行商合作伙伴能直接看到我们的日常项目管理情况，创建项目进度的简单报表。方便地发布每天的新版本和项目日志。每当有新消息发布时还能自动发送通知邮件，你能通过回复邮件来自动将你的反馈发布到网站上。很酷。

3. MSN Messenger: 我们的工作室与MSN息息相关。我们要求所有员工在工作时保持MSN在线。他们还必须设置“如果我在xx分钟内不活动，则自动显示成离开”，这样我们就能知道我们是否能跟他们交谈。我们还要求他们在MSN中设置个性签名来表明他们目前正在做什么。因此如果他们要去看医生，就写上“看医生，3点回来”，或者当他们在做项目中的任务中时，就会写上“绘制背景图片”之类的。这样每个人都知道其他人都在做什么，而不必总去打扰别人。如果有人需要安静思考，那他就把自己的状态设置为“忙碌”。我们有条严格的规定“不要轻易去打扰正在忙碌中的人，除非有特别紧急的事”。所以如果有人想集中精力思考代码，或者解决难题，他们就可以避免被打扰而分散精力。但如果真的有紧急情况会影响到其他人的工作进度，我们依然能够及时联系到他。

4. SkypeIn 和 SkypeOut: 除了经常使用免费的Skype语音电话之外，我们还是用SkypeOut来呼叫真实电话。戴着耳麦来使用的话就比用手机要方便，能解放双手，而且价格很便宜，打到全世界各地都是2美分一分钟，接近于免费。更方便的是你能设定一个真实电话号码作为你的SkypeIn号码，让别人通过真实电话来呼叫你的Skype账号，对方会感觉就像在打本地电话一样。我们的工作室SkypeIn号码设在西雅图，因为我们的大多数雇员生活在那里，拨打本地号码会让他们感到无比亲切。你还能设定SkypeIn号码的转呼，这样当你指定的号码无人接听的时候还能转呼到任何其它电话上，包括你的手机。它还带有一个语音邮箱！最终的效果是，无论你身在何处，身在美国的人能免费呼叫你，你也能以两美分一分钟的价格呼叫任何人。这样，你的电子通讯交流问题就解决了。

5. Earth Class Mail: 怎样才能方式你的合作伙伴将支票和合同寄错地址？首先，强迫他们采用电子文档进行往来。Automated Clearing House（美国的一种基于电子自动清算系统）是免费使用的，大多数合同都能被扫描并转换成pdf格式。对于那些觉得有必要亲自去写支票和传统信件的Luddites（惟恐失业而反对用机器生产者），你可以在Earth Class Mail里建立一个邮箱，他们会将邮寄给你的真实信件的信封扫描，然后给你发送一封电子邮件通知。然后你对这封信下达指令，你可以转发这封信，粉碎它，或者打开它并扫描信件内容。这并不是免费服务，但是对于那些少量的你必须去接收的纸质信件来说，这种服务是很便宜的。他们在全美都有服务点。要小心：当你设置这个邮箱的时候，一定要选择non-PO-box类型，因为有时候邮递员不会投递PO邮箱。

6. MyFax: 在地球上，如果你拥有一台打印机，那你就没有理由去购买一台传真机。只要在MyFax设置一个账号，就能让所有发送给你的传真变成电子邮件发送给你。它不仅简单干净又便宜，更能重要的是，它能让你不管身在何处，都能拥有一个固定不变的，在美国的，完全免费的传真号码。

7. PayPal: 我想我没必要再告诉你如果你需要付款给全球各地的人，PayPal是你唯一的选择。我们使用它支付薪水给所有的美国和欧洲员工，这样不仅能立刻到账，还能生成一个很棒的支付记录。而且因为你能以多种形式为PayPal账户充值，你可以利用这点来形成一个短期的信用卡效果，用以缓解一定的资金短缺问题。

注：因为PayPal在某些国家的手续费过高，我们已经决定放弃使用它了。我们正在寻找一种替代方案，但是目前我们还在继续使用它。请根据您的具体情况考虑。

8. Your Mailing List Provider: 如果你在管理者一个休闲游戏工作室，你会有大量的电子邮件往来。有很多解决方案，但是最超值的是YMLP.com。它有一个很好的工具用于从各种来源中导入地址簿，还能直接从我们的网站中收集新的联系人地址。最重要的是即使你不能使用自己的笔记本电脑，也能从任何地方获取完整的邮件列表。你也能方便地分配邮件列表职责，从而让不同的人同时维护这个邮件列表，每个人都能拥有对问题的详细讨论记录。

9. 移动性的装备: 最后但也是很重要的一点，每次在购买新设备的时候，考虑它的移动性。我的家用工作站是一台Acer笔记本，自带内置摄像头和一块小型可折叠的第二屏幕。我还拥有一台USB供电的便携式袖珍扫描仪，一个迷你打印机和一个耳麦用于Skype。所有这些都能塞进一个小手提箱里（虽然我不是机场安全岗里的时髦青年）。我能在3分钟内打包我的所有设备然后带着他们前往任何地方。任何拥有一台桌子和Internet连接的地方都能作为我的办公室。提示：只有对于不太常用的东西才选择非USB供电的款式。这在跨洋履行中很有用，能让你的笔记本变成一个电源转换器，为所有周边设备提供电力。
总结
我并不期望我们的运作方式能适合所有其他人，但是我可以向你保证：这种方式对我们很有效。我希望你能从这里找到有用的东西，更希望你能联系我，告诉我你的想法，以及你们是怎么解决跟我们类似的问题的。
下面是关于这篇文章的讨论：
问：你们从这多多不同国家雇佣人员，怎么处理各地的法律问题呢？你们的公司需要在所有这些国家都注册吗？

答：不是，我们在美国和新加坡有注册，所以在这两个地方我们雇佣正式员工，而在其他地方我们只雇佣合同工（采用的合同只覆盖到了商业游戏开发的相关条款）。
问：你们怎么处理员工将开发完成的游戏泄露给盗版者这样的威胁？

答：就跟常规公司一样处理。如果是无意的，我们就严厉责备并警告他。如果是故意的，就解雇他。不知道美国或者英国公司还有什么不同的解决方式，除了诉讼他（浪费时间）或者报告警察。
问：我还注意到了Boomzap所开发的是一些“微型”游戏。

答：更准确的说法是“休闲”游戏。我们的团队的确也能大到包含10-12个人，但是我不会用这样的团队去开发像战争机器，刺客信条这样的游戏。并不仅仅是因为你会面临众多管理和控制问题，单单是将10-12GB的海量数据在Internet上频繁传输，就会对项目造成巨大的延误作用。我们的团队一般是3-7个人，包括处理图像和声音外包的人。
问：你们说你们会做Daily Build，但是你们怎么定义“一天的结束”呢，因为你们的团队成员可能遍布在各个时区。

答：每个项目里我们都会指派一个程序员作为构建管理员（Build-master），团队中的所有其他人都要在他指定的最后期限内提交自己的工作成果，然后他就会在每天自己工作完成之后构建一个当天的版本。实际的构建时间可以根据项目组各成员的工作时间，大家一起商量指定一个时间。
问：这方法只能在你有很强的管理能力的情况下才能起作用，这也是为什么团队规模不能很大的原因，如果你的管理层次变得更为复杂，而传统面对面的管理方法又用不上的话，这种方法就肯定不行了。当每个成员都具有责任心的时候，这样的团队行为才更像是一个商业行为。总之这种方法有好有坏。

答：有个方法可以缓解这种情况，就像我刚刚提到的，相对于一般游戏公司，我们倾向于雇佣更专业一些的人，这很有用。我们当中有很多人都有妻子和儿女，在虚拟工作室里工作让我们能更容易地照顾我们的孩子。你也能通过组建更小的团队来解决这个问题，10-12个人的组织会在虚拟环境中变得有些模糊，同时拥有3个5-8人的团队，每个团队拥有自己的确定权，这样会更好一些。最后，你必须雇佣优秀的制作人，他会花费大量时间去玩这个游戏，跟团队成员讨论这个游戏，并且直接参与游戏开发过程（是的，这意味着他们要制作关卡，测试，优化等。所有我们的制作人都会身兼策划的角色）。
问：从我个人观点来看，这种商业模式其实是“坐享游戏业界的成功果实”，因为你们没有培训，不能帮助员工提升自己的水平。

答：从某种程度上来说是对的。但事实上我们拥有一个非常强大的实习计划，并且我本人也是一直教授游戏开发课程的。我本人还是新加坡一些大学和研究机构的顾问，所有有机会能接触到一些非常有潜力的对游戏开发感兴趣的学生。没能让他们加入进来真是可惜。

对于我的学生，我们提供他们每周20小时的兼职打工机会，直到他们毕业。事实上在过去的两年中我们有两个游戏的策划是由这样的内部实习生来完成的。

    以下是一位项目经理的工作日志片段，我们从他的工作日志来看项目经理的工作：

    //编者注：（不知啥原因，这段缺少，百度也没找到）

    以上只是项目经理工作的片段，相信每个项目经理应该都有自已悲惨的故事，程度恐怕只有过之而无不及。项目经理到底应该有那些看家本领呢？

一个称职的项目经理应该要其备以下的能力：

1. 要易于沟通

    笔者在2002年时曾经亲自问过美国的一位项目管理专家－Dr. William Wells（曾任美国阿波罗登月计划的计划主持人），问他一位项目经理最需要具备的功夫是什幺。那时他的回答是「一位项目管理最需具备的有三件事，第一是沟通，第二是沟通，第三还是沟通」。

    请您回想一下，在执行项目时，你花费最多时间在什么部份？跟领导报告工作进度、跟客户介绍产品及说明工作成果、跟项目成员交待工作、跟单位内的其它人员争取支持、跟合作厂商协调配合事项．．．对项目经理来说，一天内大部份的时间几乎都是在跟人沟通。

    沟通，可以很简单，也可以很复杂。对于部份人来说，反正沟通就是把我的意见表达出来吗，有什么难的。可是在项目过程中有那幺多的人与项目有关，因此要考量的，不仅是把意见表达出来而已，而在于「在什么样的时间，运用什么样的方式，将什么样的信息，传达给什么样的人」。

    很多项目经理都是属于「被动式的项目经理」。就是「你先说你要什么项目信息，我想办法去弄这些信息出来给你」。因此，信息整理的工作基本上是没有列入工作管制的，只能够见招拆招，抱着应付的心态来面对信息的供应。

    如果换个比较主动的角度来看，项目经理先了解每个与项目有关的人想要知道什么，这些信息一定有重复的地方，然后将这些信息做个整理归类，不等你开口要，我就先提供给你，让你对项目没有疑惑，化被动为主动。这些信息整理归类的动作，直接就纳入在项目经理的工作管制之中，这样对项目经理而言，也没有任何的「意外」。

    讲起来简单，做起来其实也不难，二个小时就可以做好沟通计划，几个步骤掌握住就好：

(1) 认识项目干系人
(2) 分析项目干系人的信息需求
(3) 依照信息需求找出信息种类
(4) 将信息种类归类
(5) 决定信息传递的周期
(6) 决定信息传递方式
(7) 搜集信息
(8) 传递信息
(9) 检讨信息传递成效

2. 要想的周全

    项目经理有点像魔术师。事前先考虑要表演那些魔术，然后将道具准备好，跟助手、灯光及舞台配合，先仿真演练几遍，指示每个人互动方法，并且事先想到如果发生问题时如何处置；确认都没有问题后，开始表演；表演时要掌控会场气氛，使整个场子有高潮迭起的感觉；如果环节出了问题，要马上能够应变，使节目能够继续下去，而不是就此停顿；节目结束后，感谢每个人的合作，同时检讨整个表演的过程需要改进的地方，如此一段表演才算正式收尾。

    项目经理的责任就是掌控全场，把这段表演完美无缺的呈现出来。不过太难了，执行过的项目的人都知道，首先客户的需求不容易了解，其次计划时间不够，再来执行时问题重重，等到收尾时只能草草了事。

    表演魔术可以事先演练，找出问题先解决，执行项目可没办法先来一遍。因此项目经理能不能够将未来半年、一年或二年如何执行及因应先「演」过一遍，就对项目的成功有很大影响了。而这就靠项目经理做「计划」的功夫。做计划其实是很烦人的事，相信每个人都有经验。必须考量有多少时间、要怎幺做、有谁可以做、技术上是否可以支持、关键技术是否可以掌握等，做到这个地步，恐怕早已是满身大汗。

    //编者注：很不错的小方法

    做个小练习：取一张白纸，在纸的上缘首先将要交给客户的产品以树状方式画出来。然后在纸的中间，将如何做出这项产品的主要工作步骤（5-6个即可），以流程图的方式由左至右用箭头连起来；需要供货商供货或其它单位配合的部份，以分支的方式指向各主要步骤。

    上述步骤，就是整个计划的基础了。由上图，可以发展出细部的工作步骤及时间、所需的人力资源及预算需求、采购品项及合同商要求等。如何发展出这些细节，限于篇幅，尔后再论。

    这样还不够的。再取一张白纸，将执行这些工作步骤所可能产生的问题列出来。这个是很关键的步骤，列的愈多，将来临机处理的状况愈少（试想如果项目执行过程中可能发生100个问题，你能事先考量到99个，你只要去担心那突然出现的1个；但如果你只事先考量到1个，那结果可就不得了了）。这些问题，就是你要先期处理，以减少处理意外状况的时间。

    二张纸，一个计划的框架就成形了。这样其实还不足以执行项目，但是最起码项目经理先将整个项目执行过程大概想了一遍（就有如魔术师先行彩排一样），同时也建立一个以后细部计划的基础。由以上的练习来看，做计划并不难，重点在于去不去想，去不去做。

3. 要能够预测结果

    日前一个朋友赴美，飞机误点，航空公司没有宣布会担误多久时间，因此在机场枯坐了三个钟头。搭乘那班班机的乘客，有的人需要转机，有的人有亲友在目的地机场接机，有的人初次访美。此时在机场看到每个人都是焦虑的眼神，焦虑的原因在于他们无法知道误点多少时间，所以没有办法控制之后的行程。你的项目是不是也是如此？

    计划是「想」，执行是「做」。真的去做的时候，碰到需求、能力、技术、管理、人力等问题，都会影响到执行效果。虽然最后都可以完成，但是如果无法推测完成的时间、成本及产出，项目经理就像是那些旅客一样──彷徨无助。所以项目经理除了要会做计划之外，还要能综合研判情势，预测项目时间、成本及产出的结果。

    以一个一年的项目来说，开始之后，项目经理就负了成败责任，所有的压力都落在项目经理肩上。每天项目经理要想的，不应该只是谁的问题要怎幺解决，今天的日子要怎么过，而是一年后的今天，我是否可以将客户要的东西按时交付、公司的项目盈余目标可以达成、今天无法达成的，剩下的时间里我应该怎么处理才能达成。所以总的来看，项目经理不仅要做Micro Management（细节管理），同时还要做到Macro Management（总体管理）。而要做到Macro Management最基本的作法就是从全面预测项目结果，并且采取各种因应作法。

    要如何预测结果？今天工作延误，明天也会延误，后天也照样会延误，以后到底要如何补回来呢？传统的项目经理在现在这个时点是没有概念的，结果是到项目要结束前才在赶工，到那时候才发现所要花的钱早就把利润吃光了。

    比较好的作法是今天发生问题了，找出原因，评估这个问题如何解决。如果一定得增加时间及人力，那幺假设今天这个工作得延长二周，照着时程表推下去，所有相关工作，包含对人力资源、合同商、成本的影响为何都要找出来；再往下看，推到项目完成期限，是否会延误（不是所有工作的延误都对项目完成时间有影响的！）；如果有影响，就要思考后续的工作要如何先期调整，以适度的调配资源。要做这些评估，较简单的方式，可能仍得借助项目管理软件。目前项目管理软件，不论是国内或国外的，都能做到计划功能，也能够经由计划的调整，去分析对整体的影响。

    项目经理的工作其实是很复杂。对于一个不愿意看全局的项目经理，这些步骤全部在不知不觉中被省去。但是对于一个企业来说，由一位没有看家本领的项目经理来执行重要的项目，公司的时间、名誉、获利及质量保证，不仅仅是儿戏。您的项目经理有没有这些看家本领呢？

“开会”，在现在的商业运转中，这两个字的名声非常不好，因为真正能通过会议这个形式取得什么成果的很少。我记得Dilbert（美国漫画家）曾经有一幅漫画这样画的：几个人围着桌子坐着，会议组织者说“今天会议没什么特别的议程。像往常一样，我们就就抱怨下、做些没什么干系的发言就好了”。

现在会议基本上就是这样的，大部分的会议都是无序的、没有激情的、没有效率的。但我们的会议是可以开的更好的。

当我决定写一篇关于如何开展有效会议的文章，我找到了Marissa Mayer (Google搜索产品的副总裁，see BusinessWeek.com, 6/19/06, “Marissa Mayer: The Talent Scout”)，在我所认知的人中，她在会议方面有着最丰富的知识，并且她领导创造了当今一些最有创新意义的产品，这也让我为她在会议组织方面的才能上加了不少分。

Mayer平均每周开差不多70个会议（SweetRiver译注：会霸…囧rz…），并且作为最后一道关卡来把关Google工程师、项目经理向Google创始人Sergey Brin和Larry Page来陈述、推销他们的想法的机会。一共有8个由directors, managers和engineers组成的团队在产品开发的各个阶段，向Mayer汇报。

在Google这样的公司里，大部分的工作都在会议中开展，Mayer的目标就是确保她的团队有明确的工作指令、战略方向以及有足够支撑行动的信息，并且同时让他们感觉有前进的动力并受到了尊重。Mayer她成功开展高效会议的6个秘诀就是：

1. 有一个明确的议程

Mayer要求每个会议都必须有明确的议程，内容包括参会者希望讨论的问题的大纲以及他们将如何最有效地利用自己的时间。当然，议程需要有一定的灵活性，Mayer觉得议程更多地扮演这样一个角色的工具：议程迫使参会者仔细思考自己希望在会议上所达到什么目标以及如何最好地去达成这样的目的。

2. 指定专门的note-taker（SweetRiver注：和我们一般概念上的“会议记录员”还不一样）

Google的会议一大特色就是有很多的投影…..。一面墙上投影现在的presentation，旁边会再有一个投影仪展示当前会议的记要（SweetRiver注：原文想要表达的意思应该是不仅要找一个专门的会议记录员，还要专门的投影实时地展示当前会议的记要，以确保参会人员能在会议上达成真正的一致），可能旁边还会有一个投影显示着一个4英尺高的在走的计时器！！Google高管们相信，通过制作一份官方的记要，可以最大程度地马上消除不准确性和不一致性。

那些没能参加会议的人会收到一份会议的记要。当有人试着回想会议的决定、团队前进的方向、接下来需要做什么工作，他们可以有这样的标准官方记要参考。

3. 钻小会（Carve out micro-meeting）

Mayer留了大量的小块时间段去参加那些有特定议题或者关于特定项目的小会。比如，在她与创始人兼CEO – Eric Schmidt的每周2小时的会议中，她会抽出5-10分钟间隔（或者更长，这根据主题而定），去参加那些特定领域的会议，如关于站点表现的周例会、新产品发布等等。

如果有什么紧急情况发生，这种方式给了Mayer足够在会议前调整议程的灵活性。这也慢慢让会议变得更有重点。Mayer对她的团队成员也是采取同样的策略，更多是5-10分钟的短交流（她的行程安排所允许的最短时间段），而不是30分钟的促膝长谈。通过这样地在一个大块时间段钻出时间参加小会，她可以收获更多。

Mayer有着engineering和computer science方面的背景经验，自嘲地称这些micro-meetings是“降低流水线上的延迟” (reducing latency in the pipeline)。这就是说，如果她的一个员工想跟她讨论一个问题，这位员工可以在Mayer的某一个大的时间块上跟她预约一个10分钟的micro-meeting，而不是等她下一个空闲的30分钟，——这30分钟可能2个星期都等不到。

4. Hold office hours.
SweetRiver译注：Hold office hours的意思可以看下Harvard Business Review的这篇文章。其实就是类似“答疑时间”的这样一个概念，即某人固定时间待在office里，保证你在这段时间的时候能找到他，跟他交流。这样的“答疑时间”可以让你更加亲近您的员工、更加了解公司内的事情、更加有机会听取意见和新的idea、更加有效的处理来自下层的一些问题，特别让你不会变成那种永远看不到的untouchable的神人一样。我没有想出比较好的中文词组来表达这个意思，所以下面都会保留英文。

Mayer的这条秘诀来自她在Stanford做computer science教师的经验，她也是在Stanford遇到了Google的两位创始人。Mayer的office hour每天下午4点开始，每次一个半小时。

员工将他们的名字写在她office外面的一块白板上，然后她按照先进先出的方式对队列进行处理。有时候是PM需要她在一次市场活动上的认同，有时候是一些员工想向她sell（推销）自己的一个想法或者设计 (see BusinessWeek.com, 6/30/06, “Inside Google’s New-Product Process”).

Mayer说: “我们很多有意思的产品都是在这个office hour里捣鼓出来的，Google News, Orkut [Google's social networking site]（SweetRiver译注：这里作者居然给Orkut加了一个英文注释，看来Orkut是比较痿，囧~~）, Google Reviews, and Google Desktop这些产品的idea都是首先在这种office hour里出现的”。在这短短的一一个半小时的office hour的时间中，Mayer可以开多达15个会议，平均每个人7分钟的时间…….

5. 要数据，不要政治 （Discourage politics, use data）
Mayer曾经谈到的“9个关于创新的意见”（”Nine Notions of Innovation”）中的一条就是“要数据，不要政治”(see BusinessWeek.com, 6/19/06, “9 Notions of Innovation”).

一个公司里，如果老板会根据他对人的喜好而不是他对产品和设计的客观想法来做决定，如果参加会议的人都会觉得老板会给他所喜欢的人所作的设计开绿灯时，那这条意见就非常有必要了。

Mayer相信这样的价值倾向会让员工士气低落，所以她把审批流程（approval process）变成了科学。Google会根据一些明确的度量指标来选择好的设计。选择是基于价值以及事实，而不是个人关系 （Designs are chosen based on merit and evidence, not personal relationships）。

Mayer不希望在设计会议上听到类似“I like”这样的句子，譬如“I like the way the screen looks”。而她会鼓励类似“he experimentation on the site shows that his design performed 10% better”这样的言论。Google是建立在客户反馈数据驱动的企业文化上，而不是建立在内部政治上（现在很多的企业都是），所以对于Google来说，“要数据、不要政治” works。

6. Stick to the clock.
为了给会议增加点压力以保持参会人员的注意力，Google的集会一般都会非常特色地在墙上都投影一个巨大的计时器，给特定的会议或者议题做倒计时…..。这真的真的就是一个网上可以下载的timer，跑在PC上，然后投影到4英尺大小。

想想当从会议室外面来看里面的情况，那一定非常疯狂：墙上同时投影着若干的影像：presentation, transcription（参第2条）, 然后还有一个mega-timer！不过，在Google，it makes sense，在创造性的混乱中引入结构！！通过这个Timer给会议带来的轻微的压力感使会议保持on schedule。

Mayer同时对这个timer也有一个忠告：对timer保持健康的幽默感。(同时，我对Mayer的采访的timer也快到到时间了，但是Mayer让timer变成了一个有趣、友善的提醒物，而不是对我们谈话的粗鲁打断。)

请记住，这些会议技巧在Google里用的很好。虽然可能并不适用你们公司，但这六个秘诀应该可以给你一点如何让会议不浪费时间、更加有效的良好的启示。

Scrum与传统方式之间的不同

在使用Scrum之前，公司或者开发团队多多少少已经有一些成型并且大家都已经习惯的开发模式。打个比方说，策划先行，然后召集大家讨论策划案，之后得出程序和美术的工作量再定义出里程碑拟订好开发计划，然后大家开始正式分头动工。在这个开发流程中，开发人员面临的最大困难是策划案也就是需求的变化量非常大，并且这种变更，很大一部分情况可能是直到里程碑快结束的时候，大家才一起意识到有些功能压根就无法实现或者勉强实现的效果并不理想。这时似乎只剩下修改策划案这一条路。于是大家对于无论如何严格的审核策划案，到中途总是会以这样那样的理由变更的情况已经习以为常。因为需求变更而导致产品推出时间可能一推再推，以至于最后不得不砍掉一些功能才能确保产品在可以接受的时间之内被推出。

尽管传统的开发方式可能有些地方老是出问题，但大多数情况下大家也会比较倾向于下次注意点，而不是尝试一套新的开发方法。在MMO的开发模式的选择上，Scrum在许多地方的确可以解决传统模式所遇到的问题，比如Scrum能在拥抱变化这一点上极大的帮助开发者。类似这样的优点，在Scrum的拥护派看来，可以列出好几页来。但是，要说服一个原有的团队选择一种新的开发模式来代替大家已经熟悉的方式，光列举优点是不够的，我们也需要直面Scrum与现有模式的其他差别，有些甚至是Scrum的劣势。

1． 每次提交可运行的版本

Scrum的精髓在于拥抱变化，并强调通过频繁的交付来获得及时的反馈，以便于尽可能快的调整不合理的需求。但对于某些大型MMO而言，比如MMORPG，系统的复杂度往往超出我们的想象。如果没有一款已经使用过的引擎，光是前期对低层技术的开发就是一个漫长的过程，如果采取Scrum的方式，要求每一小段时间提供一个可运行的版本无疑是一个噩梦。而对于同时进行的策划案的撰写，要求提供一个反应策划内容的版本更是困难。Scrum在这个阶段如何开展，是需要克服的一个问题。

2． Sprint的划分

相对于传统的基于里程碑的开发，Scrum要求划分出一个个相对较短的Sprint。并且每个Sprint需要有可以提交的版本，以及一个比较明确的可以体验的目标。而在MMO的开发中许多工作，比如系统架构设计，数据库设计，美术概念讨论等都很难在Sprint中体现出来，也就无法通过Sprint Review的形式获得反馈。但是这些东西又跟所有的人的工作息息相关。Scrum如何在能够保持紧密沟通的同时，对类似的相对独立的部分也照顾周全？

3． Scrum的管理

Scrum是一个强调自我管理的开发方式。无论是Stand Up Meeting还是Sprint Planning的时候都要求少干涉多聆听。对于项目经理来说，某些时候参与感很差，总是好像找不到自己在团队中合适的位置。但是项目经理又不得不对进度负责，面对各个并行的小组，每天都可能有大量新的task提出，又有大量task被否决，如果你这个时候去问项目经理“我们到底能不能按时完成，如果推迟，那还需要多久”这样的问题的话，他也许只能对你摇摇头。我们在使用Scrum的时候，进度管理上的缺失也是我们需要直接面对的问题。

类似的问题，在我们推广Scrum的时候可能会遇到很多。为什么会有如此的问题归纳一下，原因可能如下：

1． Scrum最早来自于软件工程，虽然现在扩展到开发的各个方面，由于其自身的限制性，注定要面临许多困难。（笔者曾经听说过某公司号称用Scrum进行管理，要求销售，HR部门都实行Scrum方式，很难想象这是一种怎么样的Scrum。）

2． MMO开发本身结合了跨平台，分布式，周期长，变动大等多个开发难题， Scrum能够很好的解决一些问题，但对需要长期规划的问题明显缺乏控制力。

融合：和其光 避其尘

在笔者看来，Scrum是一种优秀的开发方法，许多特征的确证明了它比它的前辈们更好的解决了游戏开发中所遇到的诸多问题。可是，如同它的前辈一样，Scrum并不是游戏开发中的那颗Sliver Bullet，再次应征了Brooks大师所言。所幸的是，我们可以使用Scrum与传统开发方式“混血”式执行的办法，根据自身情况，灵活的选择有利的方面执行，对不适应的地方进行改进，从而能最大限度的在MMO游戏的开发中发挥出Scrum的威力。

笔者有幸在参与的一些项目中使用过Scrum方法，同样也经历了Scrum与本土MMO开发结合时候遭遇的种种尴尬。笔者认为，Scrum对于MMO游戏的开发，有其利也有其弊，对于整体进度的把握以及对于文档工作的控制Scrum做得并不是十分到位。对于任何一种开发方法论而言，执行团队都需要从自身实际的条件出发，选择性的使用。最怕的是盲目执行，暴力式地推行，而其他软件的工作却不跟上，执行的团队并不明其所以，最后可能搞得人人谈敏捷而色变，失败当然是一个必然的结果。笔者始终认为，工具，方法始终是死的，如何使用才是真正出学问的地方，只有从自己实际出发，冷静分析，在合适的地方用合适的工具，才能做到庖丁解牛，游刃有余。

那么Scrum应该如何结合传统的MMO开发方式呢？我们从项目开发的各个阶段来一一分析，如何让Scrum发挥自己的威力。

项目前期

项目前期我们面临的问题有哪些？首先是产品尚未成型，团队也许对将要制作的产品并没有一个十分清晰的概念，更谈不上对项目规模的预估。其次有一大堆技术性的难题摆在团队面前。这些难题能否解决，如何解决，都势必会对策划案的成型有决定性的影响。这个时候，我们可以分两头采取不同的开发模式。

对于将面对的技术难题，这个时候目标明确，团队规模较小。比较适合采用Scrum的形式一一攻克这些问题。我们可以把大家公认会遇到的难题列举出来，通过Scrum Planning的形式分解成一个个User Story再划定各个问题的优先级和互相的依赖关系，然后分别组建Scrum团队。这个时候的目标很明确，即得到这些难题的解决方案。我们希望在这个阶段结束的时候，程序对所要面对的技术问题心中有数，策划也对哪些能做哪些不能做有一个清楚的认识。同时我们还希望对一些我们必须要克服的东西，在这个阶段已经能产生一些行之有效的工作流程。

对于Scrum小组的组建，这个阶段我们可以以程序为主，策划和美术作为某些User Story的Customer，负责对程序工作成果的审查。为避免过早的陷入需求更改的陷阱，这个时候策划除了验收成果之外，不应过多的干涉程序实现的方法，而仅仅在设计User Story的时候提出自己的意见（事实上很多User Story应该由策划和美术直接提出）。在Sprint的划分上，我们可以以2～4周的标准划分。尽量将这个阶段控制在2～4个Sprint之内（这取决于团队的大小和技术基础）。对于一些经过验证存在困难的User Story可以在每个Sprint Review结束后的Planning Meeting上经大家讨论做少许更改，让下一个Sprint向更接近我们的目标（切实可行的解决方案）的方向上前进。对于Scrum的范围，笔者建议尽量不涉及高耦合的工作，将涉及多个方面的User Story拆分成相对独立的部分再分头进行。举个例子来说，可以将服务器端和客户端的技术难题分开进行，对于涉及服务器端和客户端交互的功能再单独提出来作为一个Scrum，尽量保证工作的粒度比较小，减少互相依赖的关系。我们的首要目标是证明技术可行性，这对整个流程的开展有一定的好处。

对于策划案以及美术风格的概念设计，这个时候则采取较为传统的方式，由策划和美术师内部产生。策划在对程序的Scrum小组提出User Story的同时即提出了自己的疑问，在程序执行Sprint的过程中获得对自己提出问题的反馈，进而决定自己的策划案如何撰写。美术则在这个时候确定美术风格，以及在与程序Scrum小组合作的过程中确定某些美术工作的工作流程。笔者不建议这个时候就加入程序对策划案进行讨论，这也许和某些团队采取的方式不同。这种方式对策划和美术的要求较高，既需要向程序的Scrum小组提出User Story，并从审查中获得反馈；也需要保持设计工作的相对独立，做好策划案的前期工作。这需要策划或美术在前期就对中期可能发生的问题有所预见，向程序有针对性的提出需要测试的地方而不是等待程序来告诉你不可行。如果这个时候能有富有经验的产品经理或者制作人来负责这两方面的协调工作，也是一个确保这个过程可以顺利进行的有效因素。对于程序美术在前期就加入讨论，笔者是持保留意见的。比如曾经经历过的一个项目就因为太早冻结策划案以至于美术和程序花了几天来讨论每个UI元素的具体坐标是多少，但最后却不得不尴尬的面临因为用户体验不友好而更改UI方案的情况。

在这个阶段结束的时候，我们应该得到一个策划案的初稿，起码完成了整个系统以及世界的架构，可以估计出项目将来在程序，美术和策划工作上的规模。还应该有几套行之有效的工作流程，能根据项目的预计规模估计出将要投入的人力和项目需要进行的时间，以便于之后的市场等多项工作的计划和开展。接着，我们就便可以投入更多资源进入正式开发的阶段。

项目中期

在MMO项目中期，我们面对的主要问题是对整体进度的把握，确保能按时推出我们需要的版本。其中面临最主要的难题就是对需求变更的控制。这个方面Scrum有其决定性的优势，但如何在高度拥抱变化的同时又不失对进度的把握是Scrum在这个阶段所要面临的问题。笔者建议这个时候需要根据团队对Scrum的熟悉程度来选择不同的解决办法，分别采取以Scrum方式为主导传统方式为辅的方式，或者反之。

对于一个熟悉Scrum的团队而言，笔者的建议是在正式开发之前，整个团队坐在一起，讨论策划案。将策划案中划分的各种系统分解为不同阶段的User Story，再通过团队之间的讨论以及各组之间的工作配合需要制定出优先级。现在我们有了一大堆由策划案分解出来的User Story，这些User Story有一定的依赖关系和不同的优先级，这时候根据我们的需要将这些User Story组合成不同的Sprint，再视这些Sprint的目标和内容组合成不同组合，每个组合我们可以视之为一个里程碑。如果你的项目的时间预算非常有限，你可能会倾向于将一些不是很重要但如果不完成其他部门就无法开展工作的User Story先行制作；如果你的时间充裕，你则可能更倾向于先有一个完备的系统设计以及一个方便扩充的灵活架构，让其他部门暂时等待或者做其他的事情。总之，这一切取决于项目具体的需要和团队资源，并没有孰是孰非之分。

由User Story来构建里程碑这对团队的Scrum能力而言是一个考验，需要团队对User Story乃至Sprint的划分有一定经验，并且能够预见整个过程中可能面临的风险。选择合适，制定好的，可实现的User Story可以规避很多由于后期Sprint变更时候带来的连锁反应。这也是为什么笔者建议有一定Scrum经验的团队选用该方法的原因。

对于初次尝试Scrum的团队，可以尝试采取相对保守的方法。通过传统的方式对策划案进行技术评估后，划分出里程碑，然后根据每个里程碑的目标制定User Story，再划分Sprint。这在一定程度上降低了对User Story制定上的要求。同时在每个Sprint结束的时候根据Sprint完成情况结合里程碑的目标对User Story进行修正。听起来似乎和上个方式大同小异，但执行过程中可以省略对Sprint筛选和组合的过程，可以说目标更加明确，对尝试达成这个目标的团队来说也相对轻松一些。

无论采取什么样的方式，对于进度的管理上都是需要按照传统的方式划分里程碑。这可以方便我们把握项目整体进度,防止由于Sprint过多并且更改过快以至对项目整体进度没有概念。每个里程碑就像一扇扇保险门，明确里程碑所要达到的目的以后就不再轻易变更，严格控制好里程碑中间Sprint的变更范围。从某种意义上讲，这种互相结合的方式能够有效降低项目中期由于变更过多而造成进度失控的风险。

这个阶段的Scrum团队的组建也不同于项目前期。这时一个Scrum团队是一个包含程序，美术，策划乃至市场人员的复合小组。这个阶段中的Sprint的之间的变更乃至小组成员的身份的变化也会更加复杂。同一个Sprint中一个User Story的执行者可能是另一个User Story的Customer，需要在开发过程中保持高效的沟通。小组成员也并不是固定不变，在一个Sprint结束之后根据下个Sprint的目标可能组合成不同的小组。比如这2周做NPC交易的小组成员，可能下个Sprint会和其他人组成摆摊系统的Scrum小组。重要的是我们作为一个整体的团队如何达成每个Sprint的目标，而不是保持单个Scrum小组的独立性，毕竟灵活性也是Scrum的一大优势。

这是一个频繁迭代的阶段，也是游戏内容不断增加和修正的过程，在每个Sprint结束的时候，我们都应该得到一个可以运行的版本用于衡量该Sprint的目标是否达到。策划要在每个Sprint review之后总结更正自己的设计，美术也随着一个个Sprint的完成，看到自己的作品一批批导入到游戏中的效果。所有这些都需要建立在团队成员之间高效的沟通，以及默契的合作之上。这也对团队的自我管理能力也提出考验。

在项目中后期，我们会面对成批从QA部门反馈的bug以及为配合市场活动而临时增加的开发需求。Scrum的灵活性在这个时候可以得到进一步的发挥，随着投入资源的增多，我们可以对这些工作内容建立单独的Scrum团队，用于解决这些琐碎但庞大的新增需求。别忘了，Scrum是最善于解决目标相对明确的短周期需求。

随着Sprint的一个个进行，里程碑的一个个完成，我们终于走到项目交付和维护的时候，这个时候我们面对的是单机游戏不曾经历的维护和运营阶段。

项目后期

一个MMO的开发并不随着产品发行的结束而结束，无休止的维护和资料片的推出是团队必须要面对的现实。同时团队人员的更迭也需要在这个时候开始进行。我们慢慢要把原来开发团队的部分人员抽离出来，以便于开始新的项目。对现有项目的维护和对新加入人员的培训是我们在项目后期需要面对的主要问题。

项目后期的工作，笔者看来分为两大类，一是原有系统的BUG，运营商的2次开发需求以及来自于市场或者策划方面的活动需求，二是并行的资料片开发。先说资料片开发，开发量和内容都基本上相当于项目中期的一个或两个里程碑，对于Scrum的处理方式可以按照项目开发中期的方式通过复合的Scrum团队来处理。通常会在版本控制系统中建立一个平行的分支进行开发，值得注意的是需要随时准备集成对原有版本的改动。对于第一类问题，则通常不会涉及太多原有系统的改动，可以单独建立程序或者美术+程序的Scrum小组进行有针对性的开发。通常这个时候，进度已经不会再成为压力，对积累了开发阶段Scrum经验的团队来说，不会有太大问题。值得一说的是如果不是自主营运，对来自运营方的需求如果要对方来适应Scrum的开发模式可能有点强人所难。好消息是来自运营方的需求并不会像我们可爱的策划案一样频繁变更。Scrum小组定义好一个接口人以后可以仍然按照自己习惯的方式进行开发，把哪些恼人的外部沟通工作扔给接口人吧，这样可以在一定程度上降低我们沟通的成本。

Scrum的过程控制工具

在使用Scrum的过程中，尤其是周期比较长的项目，对于负责项目进度控制的人来说，整体进度把握和对基础架构工作的控制都是比较头痛的问题。这时，有许多工具可以帮助我们对目前的风险和进度有一个清楚的认知。

可交付物件列表（Deliverable Check List）

不同于其他采取Scrum方式进行开发的软件项目，MMO的开发过程中，文档还是扮演着相当重要的角色。一个MMO可能产生上万甚至百万字的文档工作量，我们既需要保证开发的高速和灵活，也要保证这些文档的创建和维护。在项目的各个阶段我们需要有一个或者多个可交付物件列表。这个列表可以方便我们跟踪策划案，美术工作量，以及诸多程序设计的文档的制作情况。

列表中的每一项都是一个可提交的物件，每个物件都需要设定相关的负责人，审批人以及预计完成时间。这种列表是传统开发方式的产物，然后在Scrum进行的过程中，这些物件可以作为一个个User Story分布在各个阶段的Sprint中，也可以独立在Scrum之外。通常这些文档可以作为某个阶段结束的标志，然后再以这些文档为基础来做下个Sprint的Planning。通过维护这样的一个列表，我们可以对一定范围内的整体工作量有所控制，能够弥补原本Scrum在这点上的不足。

每天编译 （Daily Build）

存在着多个并行的Scrum小组就意味着会可能同时存在多个不同的版本。前面建议大家在Scrum过程中尽量将不同Scrum小组目标的耦合度降低正是为了减少系统集成的时间。有不少团队采取分头开发，然后在一个约定的时间统一进行系统集成的办法。然而笔者并不建议采用这种方式，主要原因是随着分头开发的持续，各个小组之间并不清楚对方在做什么，代码上产生的差异会累积下来。等到做系统集成的时候，有时候会被迫面对二者只能取其一或者又要花费大量的时间来修改已经完成的系统的尴尬情况。这个时候，建立一套每天自动编译最新版本的系统可以帮助你化解这个方面的危机。

这个系统每天会从版本控制系统中更新最新的代码来编译一个可运行的版本，并自动做一些简单的系统测试工作。这里的测试工作相当简单，往往只要能保证启动程序或者连上服务器端这样的基本功能。当编译出错或者系统测试无法通过的时候，该系统能够通知相关人员，从而迫使程序员在上传代码的时候做好merge工作。为了合并好代码，不同的Scrum小组之间也需要经常沟通，以了解对方的工作进展，帮助程序员养成符合Scrum精神的工作习惯。

向下燃烧进度表（Burn down Chart）

对于Sprint与Sprint之间，乃至里程碑与里程碑之间的完成情况，通过Burn down chart这个工具我们可以随时了解任务的完成情况以及和计划的偏差。同时Burn down chart也能很好的反映在项目进行过程之中，user story的变更情况。

拿下面的一个burn down chart来说。

这是一个持续了3周的sprint，这个表反应的是在这个sprint过程中所有任务每天的完成情况。这里每天的完成百分比是由从第二天在每日起立会议以后收集到的任务完成情况决定的。我们可以看到在4-28和5-2这两天的计划曲线有一个起伏，这是由于当天有新增加的任务，这对我们Sprint review的时候评估这个Sprint的完成情况可以起到参考作用。

其他的比如告示板，索引卡，Sprint Planning等工具和方法，一般的Scrum的书籍都有介绍，笔者在这里就不再一一列举。笔者主要列举的是基于MMO的Scrum开发过程各个层面上的简单进度控制工具，以帮助团队及早发现风险，并得出应对之策。

推广Scrum过程中要注意的问题

向一个已经有过开发经验团队推广Scrum的方式并不是一件轻松的事情。没注意好的话，往往最后流于形势，不仅团队的积极性没有调动起来，甚至会让人产生反感。

环境的营造

使用一个类似Scrum这样自组织式的开发方式的时候，需要特别注意的是对于整个Scrum环境的营造。尤其不要流于形式，不然就真的是费力不讨好的事情了。笔者遇到的一个很典型的例子是：Sprint Review之前，程序的版本并没有集成编译过。于是为了准备Review中需要演示的东西，花了大半天的时间来合并代码并修改，演示结果可想一般。更糟糕的是，在user story被否决了以后，团队的积极性受到打击，对Scrum也颇有微词。

让团队真正理解什么是Scrum并不是简单跟大家宣读一下章程这么简单。持续的培训和心得交流是一个比较好的办法，有助于让团队了解每一步的意义和目的。同时还要鼓励大家多沟通交流，在Planning的时候提出自己的想法，多了解同伴的工作情况。不能再像原来一样各家自扫门前雪。

团队适应能力

谈团队素质是一个比较尴尬的问题，中国的游戏业毕竟还非常年轻。笔者的一个朋友曾经跟笔者抱怨过，原来尝试过Scrum方法，但试行了半年之后就放弃了。理由是Scrum太讲究团队的自我管理能力，他的团队并不能很好的适应这种自我管理的方式，而他的团队中还不乏有多年经验的开发人员。笔者的观点则是团队的适应能力跟团队成员的态度有关。我们当然不能苛求所有的团队成员都有多年的开放经验，尤其是项目失败经验，以便于他们理解Scrum可以帮他们解决多少他们曾经遇到过的问题。同样，就算有多年经验，抱着原来的方式不放，觉得这些新东西只是花招式，还不如自己的老三套来得实在也要不得。

团队是否能很好的适应Scrum方法，跟团队是否抱着积极开明的学习的态度有关。这在一定程度上也是依赖于团队内部的环境建设。而团队成员中参差不齐的素质笔者认为并不是太大的问题，我们并不需要所有人都能够对任务的规划和分解深刻把握，团队成员在这个高度强调沟通的环境中反而成长会更为迅速。

多次交付VS多次迭代

多次迭代并不等于多次交付，这是Scrum常有的一个误区。在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候我们需要Review的是哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除了拒绝通过这些相关的User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

有些时候这也取决于我们的User Story是否范围太大太空以至于无法实现。这也对要求我们提出更具体可实现的User Story，否则就需要及时拒绝它或者再细化。

结队

是否结队编程这个问题，笔者是持保留意见的。曾经有过一段不太愉快的结队经历，虽然不是随时“面向显示器编程”但相当时候两个人坐在一起写一段代码是常有的事情。个人认为在两人没有达到足够默契的程度的话，还是不要轻易尝试结队开发。而对于Scrum来说，除了结队，也可以通过buddy check（在提交代码前交由另一人检查提交）来确保互相对工作情况的了解。同时前面提到的每天Merge同伴的代码也是一个帮助团队成员互相了解工作情况的好机会。

最后

Scrum毕竟是个新东东，大家还正从适应中慢慢了解和熟悉。但从笔者看来，它的确是目前最适合游戏开发的方法论之一。除了能够从容应对需求的变化之外，他鼓励沟通的方式也能一定程度上激发团队的创造力，促进团队内气氛。在面对中国式MMO的开发上，灵活的把Scrum和传统方式相结合，通过不同的工具进行控制，能很好的弥补原来Scrum对长期进度缺乏控制，以及文档管理缺失的一些劣势，从而发挥其在需求管理，针对性解决问题上的优势，更好的解决我们在开发过程中可能会遇到的问题。

许多游戏团队发现Scrum的价值后就迅速采用.引入的价值是提高了速度,游戏以一个经常反复的速度提示项目主题.并让团队和用户频繁地通过改善游戏来相互反应.然而当团队进入制作阶段,发现Scrum的价值减少了.

许多团队在项目生命周期的晚期放弃了一些Scrum实践又回到传统的瀑布实践方式.他们称这种方法为”Scrum和瀑布的混合”.这篇文章将解释背后的原因及引入一些精益制作及看板的概念作为采用瀑布实践的替代方法.

精益和看板可以回答许多团队使用Scrum面临的问题,而且它们不需要团队放弃敏捷的方法.这些实践方法基于真实世界的产品制作经验,它们改进了56%的关卡制作成本.

在游戏业以外的大部分敏捷项目中,没有开发阶段.没有概念(concept)阶段,没有预制作(pre-production)阶段或制作(production)阶段.这些项目从发行（release）开始，每个发行发布一个新版本给客户，比如Firefox这样的应用程序每一个月左右发行一个新版本。而大部分游戏需要几年后才拿到一个发行版本。

消除（Eliminating）阶段是一个很大的敏捷好处；瀑布阶段比如测试阶段强迫测试关键活动被推迟到项目最后的话，这样修复臭虫（fixing bugs）的成本会很高。在项目开始的规划（planning）阶段尝试创建关于什么功能是有趣的及创建关联工作的详细知识。不幸的是最好的知识来自于执行，这就是为什么非常详细的预先规划（pre-planning）会失败。

对于许多游戏，在游戏制作过程中仍然需要分不同阶段。有两大原因：

被交付的无论什么质量的内容有个起码的底线。 60美元的游戏必须提供8至12小时的游戏。这代表了大部分的开发成本和由游戏性产生的时间。这需要一个预制作阶段（pre-production phase ）用于发现游戏乐趣及一个制作阶段（production phase）用于大规模制作内容，为了8到12个小时的游戏体验。

发行商有一个投资组合驱动的市场模型。他们的投资制约了游戏的目标.为了获得发行商的审批（其中包括市场及特许经营/知识产权所有权的审批），开发商在项目开始的概念阶段（concept phase）需要创建一个详细的概念论述。之后开发商不能太偏离整个项目的设想。

预制作可更自由地反复进行创意设计及探索各种可能性。制作期间，我们创建数以千计的资产依赖于我们在预制作阶段所发现的经验教训。这些资产在制作阶段变更会发生成本障碍。

例如，考虑一个团队在制作一个平台类型的游戏。平台游戏（如任天堂的马里奥系列）挑战玩家用于开发在变化莫测的环境中的导航技能。制作团队将创建数以百计的资产取决于角色移动指标，如“角色能跳多高”或“玩家能抓取的最低高度”。制作资产取决于这些指标。

如果这些指标在制作中期被变更，它可能会造成严重破坏。例如，如果设计人员变更了角色跳跃高度，数以百计的暗礁或障碍不得不被修改。这可能使在最昂贵的开发阶段创建了大量的无用付出。

在预制作阶段发现和锁定这些指标是很关键的。这并不意味着我们不能在制作过程中使用敏捷。我们如何才能不改变敏捷。用更适用更渐进式的流程（如精益）代替使用迭代和渐进的流程（如Scrum）

冲刺和制作

资产创造的确定性和顺序工作，也不符合冲刺迭代周期。如果我们把制作想象成工厂组装生产线，那么2到4周迭代周期是没有意义的。工厂不会每隔四周后空下来再决定将来构建什么东西。

组装生产线更频繁的复制产品需要即时逐步改进。完成资产复制的生产线时间成为制作团队的新节拍.

Scrum任务公告板及制作团队

冲刺开始时，Scrum团队将提交一份由他们预估的完整任务集。这些任务集被放在任务公告板上，供每人每天复查。许多任务可以顺序工作或并行工作。

如果一个任务在等另一个任务，就可以继续做其他的任务。有组织的任务执行流程将促进团队沟通并防止他们停滞。Scrum任务公告板正很好地表示了为了各个冲刺目标，大量在被顺序执行的任务。

然而当我们有一长串序列的任务必须按顺序完成那么我们失去一些并行执行任务的好处。任务必须按顺序完成，工作必须经一个可预见方式的流动，用于确保制作团队中的许多专家不在等待工作。Scrum任务公告板不能用于表示很长制作流水线的工作流。

Scrum任务公告板用3到4个任务状态表示

- 还未开始（Not started yet）
- 进行中（In progress） 
- 需要审批（Needs approval） 
- 完成（Done） 

这些在预制作阶段足够了。在任务进行中实际上在不同工种间有许多来回，这是正常的。然而当我们进入制作阶段，在游戏中看到一些制作完成的资产之前可能有一个长的任务链。例如，出现在游戏中的一个单一关卡需要发生如下的步骤。

这是一个大量任务的简化及发生在每个游戏关卡制作中的递交（hand-offs）过程。这个流程中的每个任务在它递交给下一个前必须发生。

如果在工作流中有一个步骤失败或延误，将影响到整个工作流中剩下的其他几个步骤。让我们套用一个任务公告板为一组任务:

以上任务公告板告诉我们剧本（script）完成后概念美术（concept art）要在关卡设计前完成审批。立即显现出一个问题—整个工作流交叉依赖的可见性没有在任务公告板上被表示出来。也许概念美术审批已被停滞了。

对其它任务这意味着什么？这意味着它们都被延迟了！谁来为延迟买单？正在做调整的人，或许甚至是音频设计的人。任务公告板主要的好处是给团队提供他们正在操刀的任务的可见度。在这个案例中工作流因为内部依赖性而失去了可见度。

Scrum任务公告板上表示工作流的另一个问题是：

当第一组任务正在被执行时，后续的工作是什么？音频设计者在概念美术等待审批时在做什么？

他们可以创造环境的声音或者一些填充者工作，但这没有最有效地使用他们的时间。Scrum任务公告板在每个冲刺（Sprint）结束时被清空。制作中，我们不想清空制作线。我们希望能持续地填充，使工作流中的每个人每天有工作做。

那如何在制作阶段使用敏捷？

我们需要删除一些迭代开发特征并在制作期间变得更规范。但我们不想放弃对变更的反应能力，制作从来没有100%的效率。

我们永远不能预测每一个潜在的问题。我们有找到大量改善产品的权力直到游戏发卖。因此我们不想完全放弃敏捷。

如果我们设定了固定时间表（schedules）和最后期限（deadlines）。我们希望的最好结果是匹配时间表。无计划的问题将继续出现并威胁这些时间表。我们需要的仍然是敏捷实践；实践的期望不仅关注变更而且把注意力集中在不断提高我们制作的资产品质。

精益制作及如何应用

精益开发与制作的根源可追溯到20世纪40年代的丰田（Toyota）。在20世纪90年代，许多汽车制作商和其他制造行业都采用了精益原则的思想。

过去十年中，在不被考虑的传统制造行业领域,包括软件开发的许多行业中都看到了它的运用。精益原则集中精力消除浪费，快速发布，增强团队及全局控制（其他好处—见文章结尾的参考书籍）

我们也可以把这些原则应用到游戏开发。像汽车制造业一样，在制作中我们有一个长长的工作链或工作流，需要一些专家按顺序工作。

像汽车制作也一样，劳动力成本及错误是迄今为止最大的成本。我们需要录用覆盖”制造线上”所需技能的每个人来提高我们制作及设计能力。汽车业几十年前发现的，指派生产线上每个人以完成一套固定的任务并没有达到最好的效果。

平整制作

平整制作是一种精益技术用于减少浪费及理顺制作中的波动。这使我们以恒定可预见的节拍创建制作资产。

制作中我们花的大部分时间是无用工（或活动），这些成果不会添加到最终产品。通过我们的努力专注减少这些无用工，我们可以得到一个巨大的生产力的提高。

看板

凡使用Scrum的会使用一个简单的看板系统。日语中单词Kan意思是“信号”，ban意思是“卡片”。因此kanban是指“信号卡片”。看板是工作的“牵引系统”。

一张看板卡片是一个触发行动的信号。看板随处可见。当你下一次在星巴克喝咖啡时你可以看到一个适当的看板系统！

在Scrum中，每个团队成员每天基于完成工作在板上“推拉”一张卡片。没有人在按预定义的节拍推动工作。

我们可以选用一些看板实践方法，这些用来可视化一个复杂制作流程并让我们运用精益原则使制作流程尽可能有效率。

平准化(均衡化)公告板

一个平准化公告板是使用卡片来表示工作能力及整个工作流程的价值流的看板系统。

如上所述，当你使用Scrum任务公告板时，你正在使用一个非常简化的平准化公告板来表示一个3到4个阶段的价值流。我们可以通过增加步骤来扩大制作规模，以我们关卡制作的价值流为例：

现在我们有8个状态用于每个关卡，它们代表了价值流的6个阶段及在两端关卡制作没有开始和关卡制作完成的两个状态。在平准化公告板上旋转典型的任务流程使之变为状态。

该公告板在关卡制作中对于工作流程的沟通比Scrum任务公告板更清晰。

应用精益原则

现在我们已经展现了关卡制作的价值流，我们可以开始应用一些精益原则来逐步提高关卡制作。第一步我们需要审视价值流的周期时间。

周期时间是从左边剧本（script）作业开始到调整阶段（Tuning Pass）完成的总共时间。我们的例子，以上一个关卡需要16周的周期时间。通过减少周期时间使我们可以更有效率。

-更快的周期时间意味着更高的生产力。 
-东西下线越频繁，我们就越能解决制作生产线的问题。 

-我们可以更容易地找出浪费（无用工）及解决这些问题。 

有许多方法用来减少周期时间。第一个方法是通过缩小工作流中工作项规模。对于我们关卡制作的例子来说，我们可以通过把关卡分割成部分或区域。

每个区域大约花12天才能通过价值流—而不是每个关卡16周。因此，我们平准化公告板看上去像以下这样：

一个平准化公告板显示了一个区域通过价值流每个阶段的过程。在上面的例子中，区域1通过了每个阶段并被转交到结束时最后调整阶段。该公告板表现了完美地平衡跨越价值流每一步的工作流。

最初它不会以这种方式发生。在某些列中会出现断层而在其它列中出现工作堆积，但这样做：这些问题一旦发生能马上可见，当我们发现了问题的本质后，就可以开始修复清楚地看到的问题。

如何改善流程

现在我们有一个看板并在运行中，我们必须努力使其尽可能有效。平准化公告板将每天告诉我们,在我们的工作流程中哪里有断层哪里有工作堆积。我们不仅希望保持平衡而且希望工作流动尽可能迅速。

我们的例子中，如果每个区域需要12天才能通过整个价值流，我们要想方设法减少周期时间直到我们在不牺牲用户可接受最低水平的品质。

我们有一些工具来改善流程：

    - 时间盒      
    - 平整工作流 
    - 减少浪费  

时间盒

时间盒是每个使用Scrum的开发者工具，一次冲刺是一个2到4周的时间盒。在一次冲刺中我们坚持并且只有我们能提供的功能。这样的好处是创建一个价值能被加入游戏的可预见的节拍。

在制作中，我们借此又向前迈进了一步。我们在价值流每个阶段启动时间盒。例如，我们可能给音频设计师10天给一个特定区域添加声音。这和Scrum任务中不同之处在于音频设计人员将预估自己的工作并告诉客户他们愿意的承诺。

在制作中这种变化，因为我们在预制作中了解了给一个区域音频设计应该需要多少时间。品质变成了你用时间盒资产控制的变量。我们不强迫美术在一个规定时间内满足一套质量。

输入是时间盒（我们愿意为这些资产支付的成本），输出是品质，这是美术在一个限定时间内能提供的。

时间盒资产的关键是找到一个正确的时间盒大小。如果你选了一个太短的时间盒，那么品质会有问题。例如，如果高解像度关卡几何的时间盒设定为一天，那美术将给我们一个用没有贴图的方块填充的关卡！这肯定比用户想要的品质低。

另一方面，如果给区域的时间盒是2个月，我们最终可能会是一个到处错综复杂的详细几何区域。这绝对是漂亮的，但对用户来说带来的成本太高了。这是用户（Scrum中产品拥有者）的工作以创建的制作资产来对投资回报率（ROI）负责。

产品拥有者必须考虑玩家对游戏资产的期望。当我工作在一个开车游戏时，我会告诉我们的美术要把重点放在决策“90英里每小时的艺术”。质量条应基于玩家在全速驾驶看到的设置。如果我们陷入40小时创建一个完美的灭火器，这额外的成本将在玩家以90英里每小时穿过时被浪费！

产品拥有者必须始终在他脑子里保持成本/价值曲线。

以上表示用户价值不是直接反映创建资产的成本.当你在资产(如方块堆成的城市)上花太少投入,用户价值就会太低.玩家可能会注意到路边假装消防栓的黄色方块.

超过一定成本,投资回报也将会减少(如在一个开车游戏做一个1000面的消防栓).我们不是把品质关联到成本.而是用户价值关联到我们付出的努力.我们不想”给想要巨无霸的用户提供鱼子酱”.

平整工作流

时间盒使我们录用一个非常强大的看板.每列的卡片表示价值流每个阶段的工作能力.正如我们以上所看到的,每个阶段一次只能处理一个区域.这就是每个阶段的工作能力,如果我们在每个阶段只有一个人在工作.

时间盒是为价值流开始寻找平衡的工作流程的第一步.然而存在一个问题,在这个流程中每个阶段的付出需要是不同长度的时间盒.这可能导致工作断层和堆积.

例如,如果我们的关卡设计师一周内布局了一个关卡,但高解析度美术师需要两周,那么对高解像度美术可能有许多工作堆积.反之,如果原画设计师需要2周完成每个区域的原画美术,那关卡设计师可能正在等工作,无事可做:

我们必须找到方法来平衡工作流,使每个人每天有事可做.一个方法是平衡每个阶段的付出以实现整个系统同样的工作流程.

例如,如果我们想使一个区域在10天内通过工作流程,我们开始寻找团队每个成员工作每个阶段的时间盒的付出

阶段(Stage)
 每区域人天(People days per zone)
 
剧本(Script)
 5 days
 
概念(Concept)
 10 days
 
关卡设计(Level design)
 20 days
 
高解像度美术(Hi-res art)
 30 days
 
音频设计(Audio design)
 10 days
 
调整阶段(Tuning pass)
 7 days
 

概念美术师和音频设计师需要10天,每区域10天很符合我们的周期时间.然而其它几个阶段需要的时间是不同的.剧本和调整要低于每阶段10天.剧本作家也许必须帮助两个团队.在调整阶段的设计人员可以帮助关卡设计或甚至测试.

对那些超过每区域10天的阶段,我们需要开始加人用并行来缩短时间.例如,我们可以增加第二个关卡设计师.两个关卡设计师可能有效地在10天内完成一个区域.

由于高解像度美术师需要每区域30天,我们也许必须用3个高解像度来平衡我们的工作流.有三种不同方法用于加人来解决问题

1.    多个高解像度美术师可以同时工作在同一个区域.

2.    细分高解像度阶段为更详细的特定工作流程(如贴图美术,道具美术,静态几何美术)

3.    多个高解像度美术师并行工作在不同区域.

所有这些方案工作在不同情况下的.方案1不是最好的因为我们的关卡编辑工具不支持同时在一个区域编辑.方案2不是最好的是因为这个特定的工作流也不是平衡的.

而且我们已经完成大部分贴图和道具.我们选择方案3.每个高解像度美术师仍然需要每区域30天,但工作被错开使整个高解像度工作在每10天完成.

我们的平准化公告板看上去如下:

每个人有一个区域的制作能力.通过增加关卡设计师和高解像度美术师,我们可以在每个阶段添加更多的卡片,因为我们需要加更多的制作能力.

我们现在设立了一个时钟频率,它是对关卡制作的每个阶段是相同的.这个时钟频率(我们的例子中是10天)被称为”节拍时间”.通过维护甚至改善整个价值流的节拍时间,我们平整制作及真正有效改善我们解决的浪费.

减少浪费

我们可能很高兴地在这里止步了.我们已经有一个适度平衡及可预见的制作流水线.许多开发商将满足现状.然而精益制作的工具使我们可以走得更远！

首先精益的原则是减少浪费.我们已解决许多在设立平准化公告板后标记出来的浪费,但我想强调一些其它特别针对游戏制作的方面.

许多这些浪费可以被团队自己标记和纠正.这是理想的消除浪费方法.主要的工具是时间盒.时间盒在团队找方法使其更有效时将产生微妙的压力.在我们上述例子中,我们确定一个周期时间是10天及平衡整个工作流来改善效率.

当产品所有者要求团队减少周期时间到9天会发生什么事?我们将失去10%的资产价值.令人惊讶的是我们不.第一反应是紧缩周期时间,如果对团队来说消除效率低下的工作方法.

让我们使用一个真实的例子.一个制作项目,在关卡制作中区域制作的周期时间是10天.当他们想减少20%的周期时间,他们面临了一些瓶颈.

最大的瓶颈是概念设计阶段.他们只有一个可用的原画美树师,并且该原画美术师和其它原画美术师坐在一起.该原画美术师花10天来给每个区域创建十来个图纸.没有其它方法使更快地获得这些原画图纸.

在小组讨论中抖出关卡设计师和高解像度美术师并没有真的需要所有这些图纸.因为原画设计师是个分离的团队,许多概念设计是基于错误的假设.概念美术师不喜欢听到他大部分工作被忽略.

方案是把这个概念美术师移到关卡设计师和高解像度美术师的旁边.这样让他们讨论设计图及正在完成工作的质量条.因此,少得多的图纸,这需要加以创造及实际改善最终产品.

这是一个工作递交产生浪费的例子(由精益原则定义的7个浪费之一).文档是一个移交浪费主要源头.文档的作用是记录知识.但它不能代替面对面的交谈.通过在工作流每个移交处使用这种方法,该团队在跨越每个阶段时同样可以节省时间.团队座位区应根据平准化公告板本身重新安排.

在上述例子中,团队从16周制作一个关卡变为每周制作一个区域,每个关卡7个区域,最终的改善是关卡制作的成本改进了56%.

改善品质

注重品质是精益制作的原则.精益制作是最大限度地减少价值流中每个阶段无需完成的工作.这使得变更被引入的更频繁,因为这将无用组件的债务保持很低.

这是丰田等汽车公司提高汽车品质并主导市场的关键.如果你在汽车生产部分发现一个缺陷,它将很容易引入一个改进部分当没有大量旧零件在库存时.

这个理念也可以转化到装配线.在丰田工厂车间,如果任何一个装配线工人看到有缺陷的车他就会按下附近的一个大按钮.如果那个问题不能在随后的20分钟内修复的话,整个工厂装配线马上停止直到问题被修复.这对品质的贡献是其它公司所不能比拟的,通过使用精益制作原则使之成为可能.

此外,我们通过整理完成制作的批次来减少周期时间.我们改进了迭代的周期.用我们的例子,我们可以每周玩到完成的区域像他们”复制出制作流水线”

我们不必等16周,整个关卡完成后才能玩.这一周的循环使我们更快地体验关卡并在我们决定花许多时间来创建关卡区域的剩余工作前引入变更.

如果我们并行建造所有的关卡而且直到工作完成了90%后才发现问题(如渲染或内存预算或游戏性品质)我们将要面对不得不抛弃已完成的大量工作或者发卖低品质的工作以满足最后期限.汽车企业当它们决定扔掉库存中大量有缺陷的部件,也是同样的问题.

外包

外包在资产制作中有其好处和地位.然而许多工作室已发现外包限制了迭代的次数,这些发生在创建大量资产如关键角色或关卡.有限迭代会影响到品质或引入昂贵的返工,这些限制了外包的成本收益.

精益制作方式演变成和外部供应商一起工作.这些对制造业如汽车制造都是必不可少的.供应商成为精益制作公司必须要自己变得精益.和精益供应商不同的关键是他们给主要制作线提供小批量零件.这样做是为了以较低成本提高品质

如何转化到游戏制作?我们的例子,我们不想外包整个价值流.关键是外包整个价值流中不需要高技能的部分,高技能部分就留给自己做.一般在关卡制作中,你想在工作室内能够保持大的任务布局而且外包也是被用于布局中的几个部分.

这个例子是一般整个关卡的环境集或资产集合.如果你在创建一个大城市的关卡,你将外包所有的小物如灯箱海报,油箱,车辆,建筑构件,背景音乐等等.这些环境集将被带进设计图阶段(高解像度美术和音频设计).这可以让他们在自己的工作室继续设计图迭代.

我们外包的关卡制作价值流如下:

外包资产在早期关卡概念开发阶段被确定给外包足够的交货期.许多设计工具支持异步引入外包组件.一个例子是Unreal Engine 3编辑器.数据包系统可以用代理资产,这些可以被一次自动替换整个游戏资产的所有实例.

如果其他团队仍在使用Scrum?

制作期间,不是所有的迭代都没有用.团队仍然在不影响制作的领域进行游戏创新.对这些团队冲刺仍然是有价值的.这些组如何和使用看板的组一起工作?

Scrum团队仍然可以使用看板驱动制作.如果我们在一个4周冲刺内有一周的周期时间,制作团队仍然可以显示每冲刺4个周期的审查结果.制作团队不必作冲刺计划,但他们仍然需要定期回顾.另外每日Scrum对制作队员仍然是个有用的实践.仍然会出现障碍这需要由团队解决.

结论

逐步地使用这些实践方法来创建关卡资产.制作一个简单游戏关卡的成本从16周变成了7周(7个区域*1周/区域).这表示改进了创建一个关卡成本的56%并且只需非常简单的工具或技术就能达到.

这只是一个开始.精益制作表明改进可以用外包代替或扩充工作室可能想自己做的大量关键资产工作的外包需求。

像Scrum一样,采用并精益实践要根据你自己的环境进行调整.关键是获取过程的可见度并创建有意义的指标.时间盒资产创建是有挑战的.大部分美术人员在工作中没有把品质作为一个变量考虑.产品所有者的关键作用将其远景不仅是最终的产品也要有责任控制投资回报率.

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Guo_zanhua/archive/2008/11/17/3321368.aspx