265手游,让游戏更精彩!

游戏敏捷开发思考

敏捷开发在我刚在游戏公司上班的时候就被领导喊得火热。这种阶段性的可发布的开发方式因为被大厂所神话,也让公司为之痴迷,似乎用这种开发方式就能解决游戏当中所有现存的问题。所以公司当时也一直风靡着用敏捷开发来提高数据的想法。

在使用一段时间之后,我并没有理解到底什么是敏捷开发。开发的节奏的大方向还是没什么变化,到了要出包的时候,依旧会加班到深夜。我就产生了好奇,是敏捷开发的问题,还是公司的问题?

中间偶尔也断断续续的看过一些敏捷开发的文章,对它也有一定的了解了。

之后在京东上发现了这本书,终于能揭开它神秘的面纱。

读完第一遍之后,就发现了问题,原来前公司其实对敏捷开发的理解也只是一知半解。也只是停留在形像而非神像。

当时项目也有每日例会,阶段性版本,燃尽图。为什么没有像书中一样那么让我激动的开发情绪?

重要的区别就是——人。

项目经理乃至总监,也不完全知道什么是敏捷开发。我把我现在依稀记得的几个问题记录下来。

  • 早上的每日例会上有对一下开发内容,但是并非是自下而上,让每个开发的人自己描述。而是项目制作人拿着笔记本电脑,一圈人围在会议室里看着投影上的PPT看自己的的开发任务,然后说问题。整个会议非常沉闷无聊。大家也不关心别人的工作内容,只有偶尔轮到自己的时候会抬起头看看,说说完成时间。这样其实很尴尬,似乎每当轮到我的时候,就会有一种自己要努力维护好自己的工作内容,怕有什么错露出来,让领导看见。
  • 在公司实行敏捷开发的时候,我并不知道项目当前阶段完整的开发内容。哪怕是在sprint截至时间快到的时候也依旧会有策划临时加功能。
  • 每个阶段结束和开始的时候也没有正规的sprint会议,只是一群策划被叫去开会,程序开发的时候出现什么问题都找不到人来问。
  • 唯一一次的变化,主策希望所有人都给游戏提建议,包括程序和美术,那次意见收集会上,一下子收集到了300多条建议,可惜没有好好保留下来。

敏捷开发更像是阶段性的跑步,把游戏开发这个马拉松,变成多个小段的短跑,在每次短跑的时候找出缺点和持续的优化。大家对这个阶段小跑的目标应该非常清晰。

总结

这个事已经事一年半以前了,现在记下,防止之后自己也犯下同样的错误。

Stay hungry,Stay foolish

游戏排行

热门信息

热门标签