这样的工作流程让网易在14个月修复2000个bug | 游戏葡萄
作为今年最成功的手游产品，从研发初期30个人的团队起，就制定了周版本迭代的制度。并且一直沿用至今。这样的一种迭代方法，让他们在14个月的研发周期内，高效的完成了4000个独立任务，修复了2000个bug。
说到这里葡萄君想提一下现场的小插曲，在文富俊演讲的问答环节结束之后，现场的一位观众突然起身要求主持人给他一个机会发问，并且表示这个问题非常重要，必须此时此刻在会场问出来。勇敢的小哥最终得到了这次发问的机会，随即抛出了一个犀利值满分的问题：“游戏行业已经加班如此严重了，我想请问采用周版本迭代，您觉得现在加班还不够吗？”
文富俊则很明确的表达了他的观点“第一，以周为单位并不是说为了提升了大家的工作强度，而是我们得到的好处对得起这样的困难。第二，从逻辑上讲，我们可以更快迭代、打磨精品。此外，我们为什么要配备一个PM？就是为了控制需求。周版本相对月版本来说，工作强度确实会增加，但并不是说我们鼓励大家来加班做这样的事情。”
这个小插曲自然是从业者和唯成功论的游戏行业之间长久以来存在的价值观冲突，但是行业里面仍然有大量的从业者希望能够像梦幻一样成功吧。下面，我们整理了这场干货满满的分享。
今天的演讲主要包括几个内容，首先是简单介绍一下《梦幻西游手游》的研发历程，然后会针对我们周版本的迭代进行一个讲解，然后更进一步，日版本的迭代。最后跟大家分享一下我们在这个过程中的经验和教训。
研发历程
《梦幻西游》的研发历程是14个月，这段时间我们至少完成了4000个独立的研发任务，修复了2000个bug。团队人员接近30人，7位策划，12位程序，7位QA以及4位UI。
再看我们做了多少东西：
首先是玩法系统方面。《梦幻西游手游》在上线的时候，内容、玩法是非常丰富的，大大小小总共超过50个系统。在研发过程中我们针对每一个系统都经历了多次迭代，这些系统最早做出来的时候是没那么好玩的。
其次是产品美术。大家可能觉得《梦幻西游》有端游，美术比较简单，照着端游来做就行了。事实上我们所有的美术资源都是重新设计，重新制作的。整个过程，包括美术的工作量都是非常大的，超过了12000个人/天。对于一款2D产品来讲，这样的工作量是非常庞大的。细分的话，角色超过130多个，这花去了美术4000个人/天；然后场景超过30个大场景，总共超过180个场景。
然后是UI界面。所有的界面超过250个，我们迭代了很多个版本。比如说助战系统，就这个界面我们迭代了40多个版本。
我们总共研发了14个月，接近60周，这段时间里我们总共迭代了这么多个版本，比如队伍，我们迭代了25个版本；宠物，我们迭代了30个版本。这里也就有这样一个问题：这样一个手游，又有这么大的工作量，有这么多美术内容、版本迭代，怎样在有限的周期里来持续迭代、打磨？怎么控制研发进度？
我们先看看传统实现大概是什么样的。我用Scrum为例，比如1个月1个版本，那么14个月，就会有14个版本来迭代，这是一个常规的做法。但这样的做法，对《梦幻西游手游》团队来说是有问题的，存在几个挑战：
第一，大家都知道游戏研发分前、中、后期，以4周为例，前3周都在研发进行中，等到第4周的时候，就会发现无数的bug。那么在1个月的时间里我们出的内容就是一个品质有缺陷的内容。这样也就出现一个问题：我们能不能迭代？有无数bug等着修复，体验有很多问题，那么最关键的就是去修复bug，而不是马上去做迭代。对于我们来说这传统的做法有很大的问题。
第二，游戏研发是瀑布模型，是一个串行的过程，我们《梦幻西游手游》觉得这样传统的做法不够迅捷，所以我们采用的是周版本的迭代。
我们是如何迭代的？
首先，我们在团队完成demo之后，我们每一周都会拿出一个可以通过验证、可以体验的游戏版本，然后我们在迭代过程中，就通过上一周的游戏版本来做迭代。在整个游戏研发过程中，对核心的研发人员来讲，他的核心任务就是把当周的游戏版本搞定，这就足够了。那么我们在这一周里边，就要完成这一周的所有内容，完成所有的分支管理，同时还要做完测试，要把bug修复完。
另外，我们的策划最后还要验收。对于这样一个周版本，我们还会邀请外部玩家来体验，并收集他的反馈。所以我们把系统、功能需求、UI需求、美术需求等都分散到每一周里面，这是思路。为什么要做么做？
举个例子，比如《梦幻西游手游》中的助战这个功能，我们总共迭代了40多个版本。第1版其实已经满足了基本功能，目前市场上大多数产品所实现的也就是这第1版呈现出来的功能。但根据我们设计的思路，《梦幻西游手游》团队认为这样的效果对我们来说是不足够的，我们就要通过周版本把更好的效果做出来。每一个版本出来之后，我们的策划会首先验证是不是需要再做迭代，然后我们会邀请外部玩家来体验，体验完了再做下一个版本，直到最后一个。
助战系统历代版本变化
从这里边我们看到，周版本可以让我更快地看到我的东西，并且可以更快速地做迭代。
做迭代，需要相应的支撑，要足够便捷。我们通过看板来管理每周的任务。第一个看板是一个需求、任务看板，整个团队就根据这个看板来做工作，所以这个看板的周期是一周，那么所有人只需要当周把看板上的任务搞定就OK；另一个看板是缺陷看板。除了这两个，我们还有另外一个看板是目的看板。所有看板一起来完成这样的事情（管理每周任务）。
当然这个只是基于系统玩法功能，还不够。我们会有一个专门给美术的看板，我们把所有的角色等内容都分散到了每一周里面，所以就需要对每一周的美术计划和周版本做一个可视化的匹配，中间产物也是要有体现的。另外，12000个人/天的工作量，除了我们网易内部的美术，也有大量的外包资源，所以也应该有一个内部制作到外包的一个平台，所有的进展都应该体现出来。
这样看上去，按周来搞定版本，我们比原本一个月出一个版本甚至两周一个版本的效率提升了30%以上。这是我们内部的数据。
但是，一个周版本所花时间是5天，这个版本还是有问题的。
在一个周期里，有多少人会在第一天提交？如果不加以管理，绝大多数同学会在最后一天提交他的任务。可以想象一下，如果大家都在最后一天才提交，我们能在这一周出一个很好的版本吗，可以体验的，没有bug的？所以要做规划。
我们可以看到上图中的纵轴是数量，横轴是时间。最开始在一周里面，大概第三天的时候我们只完成了1/4的任务，那最后两天一定是加班、熬夜。这不是一种好的状态。所以我们作了规划。我们把工作负荷分到每一天里面，每一天的工作强度都是差不多的，到最后不至于赶工。通过这样一种调整思路，我们的效率和品质能够比前面的方法提升了20%。
那这样的迭代需要什么条件？
首先，要有一个有经验的产品制作人。
其次，这个产品团队要是一个成熟的团队。包括前面有谈到周版本中的计划，所以更需要一个专注的美术team和产品team来参与。
然后，需要一个配套的项目管理和协作平台，这样才能精细化到每一天每一个任务每一个bug。
从这些来看，周版本已经够敏捷了，但它是不是完全满足了产品的需求？
我们提出了日版本和双日版本。在产品进入冲刺阶段的时候，我们需要每天或者每两天就出一个版本，这样的话我们每天或者没两天就能看到产品效果。也就是说，在周版本的基础上，我们还会有一个日版本或者双日版本来看产品效果。具体执行方面就是早上会有任务的发布，到晚上就必须要有一个可以体验、可以进行游戏的版本进行提交。要注意，这个版本是团队30多人所有任务全部提交之后的一个版本。当然，这个版本对游戏品质的要求不一定有那么高，但一定要能看到变化。
不过这样的日版本和双日版本对工作强度要求非常高。我们做了一个统计，采用双日版本，整个团队30多人，大概的工作时间在13~14小时；如果采用日版本，还会更高。所以这样的模式是不能每天都进行的，我们就在冲刺阶段采用。
两个疑问
可能大家会问我，你这样的方法可不可信，能不能推广？
这个问题其实比较简单，举个例子。网易另外一款游戏，我们也是采用了周版本迭代的一种方式，从经验和教训的角度，我们把一个月或者4~6周的一次迭代化成以周为单位进行迭代。以月为单位的传统方式，常常会有前面松懈，然后冲刺，再休整，再冲刺的阶段，这样的做法团队的疲劳度会非常高。而我们以周为单位更多地强调每周的版本，效率提高了超过30%。
第二个问题，是不是说迭代周期越短越好？
并不是说未来的产品一定要以周或者3天5天为单位来做迭代。事实上采用周版本的迭代方式会产生更高的代价。另一方面，迭代周期越短会带来越高的工作强度。从另一个角度来说，游戏研发是创意工作，很多岗位是需要思考时间的，比如策划，我们要求就没那么高，他需要思考。但总的来讲，这样一个迭代是比传统方法要敏捷很多的，能够帮助小团队持续高效地做出精品产品。