30人14月如何迭代40多版、完成4000+任务?网易首次公开手游研发模式

文/游戏陀螺 猫与海

在2015GDC China中国游戏开发者大会上,网易游戏项目管理总裁文富俊带来了以“比敏捷更敏捷”主题演讲,带来了《梦幻西游手游》的研发分享,并讲述了其手游迭代的“秘密”,这是网易游戏第一次在公开场合分享内部的核心研发模式。以下是游戏陀螺对本次演讲的整理与分享。

14个月,30人团队,完成4000+研发任务、40多版迭代,修复2000个bug

《梦幻西游手游》这个游戏研发历时14个月,我们至少完成了4000个独立的研发任务,然后在这个过程中修复了接近2000个bug,团队成员接近30人,其中策划7位,程序12位。14个月30个人做了多少东西?下面我们来一起看看。

首先,玩法系统超过50个:《梦幻西游》手游上市的时候,它的内容玩法丰富度是非常高的,大大小小接近超过50个系统,这个系统最早做出来的版本是没那么好玩的,这50多个系统每个都经历了多次的迭代。

然后,美术工作量超过12000个人天:大家觉得可能比较简单,因为梦幻有端游,手游照着这个端来做就行了,事实上来讲我们手游所有的美术资源都是重新设计、重新制作的。美术的工作量其实超过了12000个人天——大家可以想象一下对于手游产品来讲这是一个非常庞大的一个数字,其中角色超过130个,花去了4000个美术人天,然后场景也是超过三十个大的场景,总共的场景是超过180个屏。另外这个界面超过250个。

大家想象:我们总共研发是14个月,接近60周,我们要迭代40个版本,其中队伍我们迭代25个版本,宠物我们迭代了30个版本,伙伴系统我们迭代了40多个版本。

《梦幻西游手游》内容庞大,常规迭代模式将带来的问题

《梦幻西游》的手游有这么大的内容量,有这么多的美术内容,然后有这么多迭代,你怎么样在研发周期里面来持续迭代,持续打磨?然后在提升品质的过程中,又能够控制你的研发的进度?

常规很多行业是这样来做的:比如说一个月一个版本,大概四周左右一个版本,比如说14个月,那么总共有14个版本来迭代,这是一个常规的一个做法,但这样做法来讲对于网易游戏来讲,对于《梦幻西游》团队来讲有问题,什么问题?有几个挑战。

第一个挑战:前松后紧。以四周为例,游戏研发进度会出现存在前松后紧:比如说四周里面,大家知道研发过程中前三周一般都在进行中,所以来讲怎么说进度都是一些正常的,等到第四周的时候,我们把所有的研发人物把它组合起来,这个时候会发现有无数的话题没有修整,最终我们一个月最后整合出来的,却是一个品质有缺陷的内容,另外你下面的人物又来了,这样的一个迭代周期太长,存在前松后紧的一个问题,

第二个挑战:不够敏捷。来讲我们知道游戏研发、美术制作,它相当于是一个独立的一个进程,没法融合到这样一个流程里面,我们《梦幻西游》团队觉得这样还不够,不够敏捷,我们要更敏捷。

周版本:更快看到产品,更快在原有基础上做迭代

所以我们要采用一个什么样的模型迭代呢?在这个产品完成之后,我们在每一周都要有一个通过验证的,可以体验的游戏版本。

我们可以看到这样一个迭代过程:在一周里面我们要完成什么,这一周所有的内容制作,完成所有的分支管理,还要做完测试,还要把大的bug修复完,另外最后我们的策划还有验收,对于有的周版本,我们还会请外部玩家来对这个可以体验的版本来体验,然后来搜集他的反馈。所以我们要做的过程中需要把我们的需求细分:功能需求、美术需求、UI的需求,都要把它分拆到每一周里面,针对有的长期的需求,也要把它有中间的一个产物,来放到这个游戏版本中来,所以这是一个思路。

《梦幻西游手游》刚完成的第一版来讲其实它已经满足功能需求了,它已经可以用了,换句话来讲现在市场上绝大多数的评产品的话,大概属于第一个版本的水平,但对于《梦幻西游》设计团队来讲这不够的,我们要通过周版本把它做出来,做出来之后呢,我们的策划同学会在基础之上来看,需不需要再做深入的迭代,然后我们会做外部玩家的测试,或者启用我们的手游专业玩家来体验,体验完了以后,我们做出来第二版,然后再做出第三版,直到最后来讲我们做出这个版本。

大家如果现在去体验《梦幻西游》的话,会发现它又有变化了,它会更加的好用,周版本带给我们一个好处,我能够更快地看到我的东西,更快地在基础上来做迭代。

通过看板管理每周需求与任务,美术看板需建可见初模,效率提升超30%

你要做迭代,你需要有相应的一个支撑。首先我们是通过看板来管理每周的第一个看板是一个需求,或者是一个任务,整个团队来讲就说就基于这个看板来做工作,这个看板的周期是一周。所以所有的人只要把这个看板的任务搞定就可以了。

另外一个看板是这个缺陷的看板,除了这个以外,还有一个功能是物理看板,所以既有电子看板,也有物理看板来一起来做这样的一个事情。

我们也有相应的美术看板,这个是2004年6月份的一个看板的截图,我们是把18个伙伴的角色,把它分拆到每一个周版本里面,这样做,你需要匹配,把这个美术计划跟这个周版本来做这个可视化的匹配,另外每周都要有可见的一个美术资源。

什么叫做可见呢?比如说类似于模型,类似于初模,所以中间产物也要在中间体现,另外来讲大致的一万两千人监美术的制作,除了我们网易内部的制作之外,还有大量的外包,所以也需要有这个内部制作一个外包的平台可视化,让所有的成员了解到你这样一个进展。

这样看上去,周版本按理说你已经落实到周了,你把周版本搞定了,那么效率就提升了,那么我们统计了一下,比普通的一个月为版本或者是两周一个版本,我们采用周版本的效率大概提升了30%以上,这是我们内部的一个数据。

提前规划将工作强度分解到每一天,效率、数据提升约25%

但在一个周版本里面,一周是五天它还是有问题的,大家知道是什么问题呢?前面讲了前松后紧,有多少人会在第一天提交呢?如果不加以管理的话,绝大多数同学都会在最后一天来提交他的任务,所以大家想一想最后一天来提交任务,我们能够把它整合成一个很好的一个版本吗?很难。

所以需要做计划做规划,这个图是一个没有做管理的,这是一个变总的一个蓝图,它是以半个小时为单位,纵坐标是我的任务数量,横坐标是时间。我们可以看到最上面这种红色代表什么?没有开始完成工作,所以没有采用计划管理的方法。我们可以看到在这个第三天的时候,我们才完成这么多内容,所以一周里面我们第三天才完成了大概四分之一的任务,大家想象一下最后结果是什么样?加班,最后两天拼命加班熬夜,所以这个也不是一个好的状态。

所以我们要怎么做呢?我们可以看到这样子,我们做好规划,然后把工作复合到每一天里面,也就是说每天的工作强度是差不多的,而不是放到最后来赶工,所以这是一个思路。通过这样的一个调整,我们发觉我们制作的效率、品质、内部数据,大概能够比前面能够提升大概25%左右。

前提条件:经验、成熟、执行力、配合

然后我们再来看看这样一个周版本的迭代,它是有前提条件的,首先这是有经验的才能制作的,另外一个来讲比如说这个产品团队来讲,应该是比较成熟的一个产品团队,举个简单例子,我们说我们要完成一个周版本的内容,如果说有人说我答应了要完成,结果最后说我不完成,这种来讲也就是说你缺乏执行力是不行的。

另外一个来讲,前面讲的最后美术计划,需要你专职的美术的PM和产品的PM来参与,另外一个来讲你需要有配套的这种项目管理或者协作的平台,才能支持任务精细化到每一天,到每一个任务,到每一个人。所以这样一个周版本实施完了之后,效果非常好。

日版本和双日版本:冲刺阶段的特殊处理,大招不能每天放

然后我们又有问题了,周版本已经够敏捷了,但是不是完全满足产品的需求,是不是还可以更加快?于是我们又做一些探索:这里面又提到一个叫日版本和双日版本,就是在产品进入一个冲刺阶段的时候,我们希望每天或者每两天有一个完成的版本,每天都能体验到变化,每天都可以看到迭代的一个结果,也就是在周版本里面还有一个双日版本或者是一个日版本,那么跟前面讲的也是一样的早上有一个任务目标,到了晚上必须最后得到一个经过测试的可以体验的游戏的版本。

它对品质不一定要求那么高,但是要能看到变化,大家可以想象一下这样的一个双日版本、日版本,工作强度会我们也做了一个统计,大概采用双日版本,整个团队三十多个人,大概当天的工作时间大概是在13到14个小时,如果说采用这个日版本那么还会更高,所以你想象一下这个东西是大招,能不能每天放?这是不行的,所以关键时间冲刺阶段我们来用这样一个双日版本、日版本,所以我们最后经验来讲,它是没办法作为一个持续存在的。

结语:在实践中勤思考,方法论也需要持续迭代

最后再来总结一下我们这样一个做法或者经验和教训:

首先,这样的方法有没有可复制性,能不能推广?大家比较关心这个问题。这个问题也比较简单,给大家举一个例子,目前排名第二的,网易游戏的《大话西游》,在研发过程也是采用同样的一套模式。我们采用周版本迭代的经验和教训来讲,第一,我们把这种一个月或者四到六周的这样一个敏捷迭代,变成了以周为单位。因为以一个月为单位的常常来讲会出现前面松,后面怎么样?冲刺然后再修整,再冲刺的一个阶段。而采用以周为单位,我们更多的是强调每周的一个评论数据,所以这效率一定高,前者比后者来讲大概会高出30%左右,因为整个团队通过冲刺之后疲劳度非常高,它的效率反而是降低的,这是第一个。

第二个,是不是迭代周期越短越好?未来做产品,是不是一定要一周或者三天五天迭代?实际上来采用以周为迭代方式,第一个是要有更高的管理代价,管理代价是什么?比如说前面这个团队,有三十个人的团队要有专职的产品的PIM,要有美术的PIM来做计划,来做技术跟进,来做相应的一个携同,这是第一个。第二个则是更高的一个工作强度,从周版本来讲,它比这个采用月版本的工作强度更高,大家可以想象一下,一般情况下版本能不能顺利、正常的下单?一般都会有问题的,因为还要把绝大多数的话题都修整完,没有出现新的话题,修整完了之后才能结束。

第三,需要思考。游戏研发是创意的这样的工作,所以对很多岗位来讲,是需要思考时间的。说我采用周版本,像一辆战车一周一周60周这样开过去效率很高,但是如果你缺乏思考,那么你有可能也会有问题的。

另外,这个周版本做法也不是一个定律,它也要持续的迭代,做更进一步的加强与改良。但总之来讲,这样一种迭代方式,是比现在的传统的这种敏捷更加敏捷,能够真正帮助团队持续的、高频率打磨出我们游戏的一种方法。

游戏陀螺

关注泛游戏产业,为游戏创业者服务

网站

官网 | youxituoluo.com

英文 | gamegyro.com

日文 | jp.gamegyro.com

合作联系

(0)

相关推荐