【1月】

　　· 上海游戏米果倒闭，旗下游戏停运

　　因2006年“员工封杀令”及2007年“这不是如来神掌”系列广告 ，而在国内闻名的上海游戏米果公司，于1月突然“濒临倒闭”，同时旗下的《如来神掌Online》、《真封神》等游戏宣告“全区全服停运”。

　　面对游戏米果及其游戏的“倒下”，众多玩家表示“国产游戏开发运营商再次让人心痛”!

　　· 2007年中国游戏产业年会在苏州召开

　　1月16日-17日，第四届中国游戏产业年会在古城苏州拉开帷幕。大会发布了《2007年中国游戏产业调查报告摘要》、中国版协游戏工委与17173.com共同编制的《2007年中国网络游戏研发力量调查报告》等重 要报告。

　　17日下午，2007年度中国游戏产业年会各大奖项公布，搜狐、盛大、九城、完美时空、网龙等在2007年取得优异成绩的 游戏、公司及个人得到了表彰。17173再次蝉联“中国十佳游戏媒体”第一名。

　　· 中国网络游戏用户总规模达4017万

　　据《2007年中国游戏产业调查报告》公布，中国网游用户总规模达4017万，比2006 年增长23%。其中，付费网游用户已达2236万，超过了总玩家人数的一半。预计到2012年，中国网游用户数将达8456万，2007年到 2012年的年复合增长率为17.6%。

　　· 新天下贰成网易首款免费游戏

　　在《大唐》、《天下贰》等产品均未达到预期目标之后，网易终于决定《新天下贰》采 用时间免费道具收费模式，以缓解竞争者、市场环境、投资人带来的诸多压力。

　　至2月公布Q4财报时，网易提出《新天下贰》、 《大唐豪侠2》、《飞飞》等3款产品均采用道具收费模式。

　　【2月】

　　· 久游正式宣布签约经典Q版网游续作《魔力宝贝2》

　　2月1日，久游网宣布，与日本史克威尔艾尼克斯正式签约，获得了 中国市场上Q版回合制网游代表作《魔力宝贝》的续作“魔力宝贝II”，在中国大陆、澳门地区的独家运营权，并将于今年夏季以后 由久游网在中国大陆开始运营。

　　· 历史特大雪灾冲击中国网游

　　1月中旬到2月初，中国南方遭遇罕见特大低温雪凝灾害，冲击了人们的日常生活，亦影响 了部分网游的运营和收入；美国投资研究分析师因此作出负面报告，中国网络游戏股股价整体下跌。

　　【3月】

　　· 北京欢乐时空面临倒闭

　　游戏运营商北京欢乐时空因韩方合作伙伴撤资而面临倒闭，这是2008年第二起被公开的游戏公 司倒闭事件。创立于2005年的欢乐时空，是一家与韩国合作成立的游戏企业，代理的韩国产品《欢乐君主Online》在本土化修改过程 中矛盾重重，是该公司陷入困境的主要原因。

　　· 完美时空7亿买大楼 公司规模将大幅扩张

　　3月中旬，完美时空宣布购买坐落于北京市朝阳区面积大约为55，000平方米的写字楼。总购买金 额约为7亿元人民币。新购买的写字楼将被用于作为完美时空的主要办公场所，以满足业务和人员扩张的需要。

　　5月份，金山亦斥资1.75亿购买了面积约为15,907平方米的7层办公大楼。

　　【4月】

　　· 盛大正式宣布唐骏离职

　　4月3日，盛大网络正式宣布唐骏将辞去公司总裁一职，转任公司CEO顾问，并继续担任公司董事 ；盛大CTO谭群钊接任总裁。

　　4月15日，唐骏正式加盟新华都集团，基本脱离游戏行业。

　　· 骏网高层权力斗争激化，CEO吴洪斌遭董事会罢免

　　一场旷日持久的董事会内部斗争，使这家国内首屈一指网游渠道商遭 到沉重打击。而原CEO吴洪斌被“罢免”后，仍握有北京骏网的控制权。

　　· 完美时空300万美金战略投资成都逸海情天

　　逸海情天曾开发2D回合制MMORPG《倚天剑与屠龙刀》。通过此次投资，完美 时空在中国西南方的研发基地中占有了一席之地。

　　· 九城战略注资韩国《劲舞团》发行商G10

　　4月下旬，九城宣布以约3800万美金入股韩国游戏开发公司G10，所占比例略高 于10%。九城在争夺《劲舞团》代理权失败后，转而通过控制开发商分享《劲舞团》的收益，也能借此控制上游的游戏研发，为《劲 舞团2》国内顺利运营做好基础。

　　【5月】

　　· 九城新总裁上任，推“四维战略”

　　5月22日，原中华网总经理陈晓薇女士正式出任第九城市总裁一职，协助董事长兼 CEO朱骏进行公司的经营管理及战略发展规划。关于“四维战略”，即，做好现有服务的同时，推动游戏多元化和自主研发，并建设 互动性游戏社区。

　　· 万众一心众志成城，游戏行业共助震灾

　　5月12日，四川汶川发生8级特大地震。灾难之后，整个游戏行业积极行动起来 ，与全国人民一同贡献力量救助震灾，捐款累计超过1亿元人民币。

　　同时，全国网络游戏在5月19日-21日停服3日，以示哀悼。

　　· 北京光宇维思濒临倒闭

　　5月，国内网络游戏研发公司北京光宇维思科技有限公司，因投资合作伙伴撤资而濒临倒闭。 2004年6月创建的光宇维思，多年以来旗下数款网游作品迟迟未在国内正式运营，糟糕的盈利情况引发了公司与资方的冲突，致使投 资方一撤了之。

　　【6月】

　　· 网龙转香港联交所主板上市

　　持续良好的业绩，使网龙6月24日在香港联交所从创业板成功转至主板上市。网龙将从此拥 有更便利的融资条件和更为广阔的发展空间。

　　· 软星解散 《仙剑》开发团队融资自立门户

　　软星解散后，《仙剑奇侠传四》核心开发团队于6月获得融资，组成新团队“烛龙科技 ”。

　　· “辽宁女”事件引发热议

　　5.12地震之后，互联网上出现“辽宁女视频辱骂灾区人民”事件，并与久游网《劲舞团》联 系起来。久游网力图澄清，为此发起了一场对于网游行业竞争的讨论，呼吁同行们为了游戏行业整体形象和发展着想，拒绝恶意竞争 ，营造良好氛围。

　　· 暴雪公布《暗黑破坏神3》

　　6月28日，在《暗黑破坏神2》的7年后，暴雪公布了这个全球闻名的游戏系列的最新作。暗黑系列不单是单机游戏中的经典，也是早期网络游戏所模仿的对象。而《暗黑破坏神3》，无疑成为整个游戏行业关注的新焦点。

　　【7月】

　　· 巨人5100万美元收购51.com 25%股权

　　在网络游戏与网络社区互相融合的产业发展趋势下，此次双方跨平台合作的主要目标，是将社区用户与网络游戏用户结合，为巨人和51.com带来新的增长空间，增强各自的竞争力。

　　· 游诚遭遇资金危机 《战火》濒临停运

　　国内网游开发运营商游诚时代，由于出现资金周转困难，宣布解散整个运营团队仅保留研发团队。 游诚于2007年推出的原创网游《战火》，运营投入巨大但收入欠佳。在得不到新投资的情况下运营团队遭到瓦解，游戏陷入困境。

　　· 金山停运《新石器时代》Q版之祖谢幕

　　7月4日，金山公司宣布旗下网游《新石器时代》将于8月2日停止运营，这标志着经典老牌网游《石器时代 》的彻底终结。《石器时代》于2001年1月由北京华义推出，是Q版网游之祖。在大陆停运的原因是，日本开发商DigiPark终止了这款 游戏在中国台湾和大陆地区的授权。

　　· 第六届Chinajoy在上海顺利举行

　　7月17-19日，第六届Chinajoy在上海新国际博览中心举行。据举办方统计数据，本次展会上展示 了近400款游戏，来自国内外的近11万观众莅临展会。

　　【8月】

　　· 网易签约暴雪战网与《星际争霸2》

　　8月13日，网易关联公司上海网之易获得《星际争霸II》、《魔兽争霸III》及资料 片，以及暴雪战网在中国大陆的3年独家运营权。如何防止“盗版”将成为网易运营战网盈利的重要环节。

　　【9月】

　　· 华尔街唱空中国网游，上市企业回购股票反击

　　由于美国次贷危机引发的金融风暴，以及海外资本市场分析人士普遍不 看好中国网游企业，中国网游概念股虽业绩良好，股价却频频下跌。为此，巨人、盛大、九城、网易、搜狐等多家企业先后回购股票 ，即是为挽回投资者信心，亦是进行自我投资。

　　【10月】

　　· 韩国权威媒体撰文称“中国网游竞争力正在赶超韩国”

　　10月10日，韩国权威媒体《朝鲜日报》发文称，中国的网游产 业无论是规模还是竞争力，都迅速赶超韩国，并正准备取代韩国，成为新的网游神话。

　　· 中华网统一游戏品牌，光通、17Game退出历史舞台

　　10月24日，中华网游戏集团宣布，统一旗下游戏品 牌为CDC Games，而此前在国内闻名的两大游戏品牌–光通、17Game，均被弃用，就此退出历史舞台。

　　· 第六届网博会成功举行

　　10月23日-26日，第六届中国国际网络文化博览会在北京举行。

　　· 网游产业2008年第三季度同比增51.9%

　　艾瑞咨询发布的《2008年第3季度中国网络游戏市场监测报告》研究显示，2008 年第3季度中国网络游戏市场规模同比增长51.9%，环比增长7.7%，达54.7亿元。在全球金融危机中，网络游戏作为内需型产业，反而 被描绘出更多美妙的前景。

　　· 完美时空收购《流星OL》及《笑网》

　　27日，完美时空签约台湾昱泉，获得《流星OL》以及《笑傲江湖OL》的发行权及 销售独占许可。此外，完美时空还将获取使用昱泉跨平台游戏开发引擎的许可。这份协议总金额大约为1500万美元。　　

　　【11月】

　　· 我国首个网络成瘾临床诊断标准出台

　　11月8日，我国首部《网络成瘾诊断标准》粉墨登场，试图将网瘾纳入精神病诊断 范畴。该《标准》是某些机构个人打着“网瘾治疗”旗号，实则意图牟利的畸形产物，遭到社会各界人士的指责。

　　· 虚拟货币交易征收个税20%

　　11月10日，虚拟网络交易发展迅猛，围绕着虚拟物品的交易，产生了在游戏 中以 获取虚拟物品为工作的职业玩家、炒作游戏点卡和虚拟物品的炒家等等，实际上已经成了产、供、销一条龙的网上交易市场。据有关 资料显示，当前国内互联网已有几十亿元人民币规模的虚拟货币在流通。

　　· 金山高期待作《剑网3》首亮相

　　11月20日，金山高期待作《剑网3》开始技术测试，参测人员普遍认为这是一款“用心 做的游戏”，比较看好其前景　

　　【12月】

　　· 武汉某网游代练公司获得营业执照

　　这是国内首家以网游代练、打钱为主营业务的企业获得工商部门的“合法”认定。 此事引起包括CCTV在内的众多媒体关注，而一向坚决反对代练的国内网游商对此均未作表态。

　　· 《魔兽世界》3.0开放

　　《魔兽世界》无疑依旧是目前网游中的当红游戏，国服《巫妖王之怒》的迟迟不开放也是玩家们 早就料到的。不管如何，在08年接近尾声的时候，3.0总算来了，也算是好事一桩吧。

　　· 高期待韩国网游《永恒之塔Aion》开测

　　12月12日，盛大代理的高期待韩国网游《永恒之塔Aion》开测，这款人气极高 的网络游戏，在视觉和听觉上带给人震撼。NcSoft的4年研发与盛大的运营，强强联手，给大家留下深刻的印象。

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对长期进度缺乏控制，以及文档管理缺失的一些劣势，从而发挥其在需求管理，针对性解决问题上的优势，更好的解决我们在开发过程中可能会遇到的问题。