【GDC分享】文富俊：梦幻西游手游研发周迭代的秘密
嘉宾介绍
文富俊：
网易项目管理与培训发展中心总裁/网易游戏学院院长
文富俊是网易游戏的项目管理专家，主要负责网易游戏的项目管理和培训发展的推进和管理工作。文富俊具有丰富的游戏行业项目管理经验，特别擅长端游研发大团队精细化项目管理和手游研发敏捷项目管理，并建立其适合游戏研发的项目管理体系。
正文：
一款游戏，没有迭代，是很难生存下去的，尤其是手游，很大程度上，手游的成功与迭代有着密切的关系。有的手游是一个月迭代一次，有的是半个月迭代一次，基本上维持在这样一个时间间隔，迭代也就是版本的更新，迭代的时间周期过短，对团队的要求也就更高。
我们梦幻西游手游之所以如此的成功，可以说与迭代至关重要，因为我们的迭代是周迭代，也就是我们的产品一周就会有以此的更新，一周一迭代，对团队的工作量要求肯定是很大的，那么一款游戏如何实现周迭代，怎样在每周都能够有内容进行更新，下面我就来给大家分享一下我们梦幻西游手游研发周迭代的秘密。
首先说下我们的研发历程
我们的梦幻西游手游研发历程总共是14个月，看看我们在这14个月里做了什么事情，这段时间我们至少完成了4000个独立的研发任务，修复了2000个bug，而我们的这个团队的人员接近了30人，其中7位策划，12位程序，7位QA以及4位UI。
再来看看我们具体做了些什么
首先是我们的玩法系统方面，梦幻西游手游在上线的时候，内容、玩法其实是非常丰富的，大大小小总共有超过50个系统，在研发过程中我们针对每一个系统都经行了多次的迭代。
其次是产品美术方面，大家可能觉得梦幻西游这个IP因为有端游方面的经验和技术，美术会比较简单，照着端游来做就行了，然而事实上我们所有的美术资源都是重新设计和重新制作的，整个过程中，我们美术的工作量都是非常大的，基本上超过了12000个人/天，在行业中，这对于一款2D产品来讲，这样的工作量是十分庞大，如果细分的话，我们产品中的角色超过130多个，制作这么多的角色共花去了美术4000个人/天，场景有超过30个大场景，总共超过180个场景。
再就是UI界面方面，我们产品的所有界面超过250个，我们因此迭代了很多个版本，比如说紧紧助战系统这个界面，我们就迭代了差不多40个版本，还有队伍系统，我们迭代了25个版本，宠物系统，我们迭代了30个版本。
我们这个产品历时14个月，差不多60周，所有的这些迭代我们都是在一段时间内完成的，那么大家肯定就有这样一个问题：这样一个手游，又有这么大的工作量，有这么多美术内容、版本迭代，你们是怎样在有限的周期里来持续迭代、打磨？怎么控制研发进度的呢？
那我们先来看看传统实现大概是什么样的，我用Scrum来举例，比如1个月1个版本，那么14个月，就会有14个版本来迭代，这是一个常规的做法，但这样的做法，对《梦幻西游手游》团队来说是有问题的，存在几个挑战：
第一，大家都知道游戏研发分前、中、后三个时期，以4周为例，前3周都在研发进行中，等到第4周的时候，就会突然发现无数的bug，这一周就算紧急修复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天为单位来做迭代。事实上采用周版本的迭代方式会产生更高的代价。另一方面，迭代周期越短会带来越高的工作强度。从另一个角度来说，游戏研发是创意工作，很多岗位是需要思考时间的，比如策划，我们要求就没那么高，他需要思考。但总的来讲，这样一个迭代是比传统方法要敏捷很多的，能够帮助小团队持续高效地做出精品产品。