真人拳皇项目Alpha阶段的回顾——史经浩

经过一个多月艰辛的努力,我们小组终于在1/14按时发布了真人拳皇的alpha版。按照计划,这一周是总结过去这段时间的经验教训,为即将到来的beta阶段作准备。回顾刚刚过去的一个多月,从plan阶段的天马行空,到后来的逐渐降级,然后分两步走的计划,我们走过了整个alpha开发的全过程,初步体验了正规软件开发。这当中,我们都收获了很多,有好的经验,也有不好的教训,经过今天软件工程课上组员的讨论,总结出了其中比较重要的几点。先说说教训吧。

  • 计划阶段要务实
    我们刚开始构想这个游戏时,完全是天马行空的想象,比如自动提取用户图片中的肢体部位,将它们重新组合成各种人物模型,再比如何种奇怪的招式、特效,游戏做好之后可以怎样恶搞等等。在第一个星期的plan阶段,大家都在津津乐道这些,并没有真正考虑其实现问题,在技术上可不可行,用户到底有怎样的需求,在两个月的时间里能不能做出来等实际问题。等到进入了coding阶段,才发现光要实现两个人对打这个基本功能就很不简单,需要自己从头开始写一个小的游戏引擎。做了一段时间,发现工作量还是蛮大的,于是就把原来设想的提取用户的全身图片改为只提取用户的头像,并且放到beta阶段来实现,实际上和我们之前的预期相比已经大打折扣。这个教训告诉我们,在确定下来做什么之后,一定要尽快的接触技术细节,考虑其实现难度,适当的取舍,不能只停留在头脑风暴阶段。否则很有可能到实现阶段发现技术上不可行,再回头补plan的功课,延误了进度。
  • 重要任务要分摊
    我们的dev有三个,说起来也不少,但是回头看看所写的代码,保守估计有2/3以上是一个dev写的,这样做给项目管理带来很大困扰。一方面,干活多的dev抱怨,大部分活都是我干的,压力很大;另一方面,另外两个dev也很委屈,没什么活要干,只是读懂别人代码。这样也给项目带来了不小的风险,因为重要的代码都是一个dev写,等于把鸡蛋都放在一个篮子里,如果哪天这个dev组里比较忙,或者其它原因,不能coding,整个项目的进度就会因此而被延误,其他人也只能干着急。所以说,模块化编程非常重要,coding能力比较强的dev,可以做dev master,统筹整个的coding工作,合理的把程序划分成各个模块然后分配下去,让每个dev都积极地参加进来,摆脱一人写代码,其他人读代码的现象。
  • 组员沟通要及时
    这个主要还是从一次事故中得出的教训。一次,某dev被要求描述人物招式动作的转换状态,当时对我们期望怎样的输出说的不是很清楚,于是这位dev就按照自己的理解用文字描述了转换状态,第二天Scrum时交给大家看,但是大家实际上期望的更为清楚的状态转换图描述,而不是文字的描述。虽然完成文字描述对画出状态转换图有很大的帮助,但毕竟有点南辕北辙。如果这个dev当时能够及时对不清楚的地方弄清楚,也不会发生这样的事情。组员之间的沟通不仅限于每天的scrum,有什么不清楚的地方,一定要及时的沟通,不然自己很有可能out of track,浪费了精力,更极大地挫伤了积极性。

当然,教训很多,这里就不一而足了。另一方面,能够按时发布alpha版并基本实现预期功能,我们还是有些心得的。

  • 分解目标——雪中送炭与锦上添花
    俗话说,一口吃不成大胖子。当我们在coding阶段意识到做这个游戏并不像我们想象的那么简单时,我们及时调整了策略,分析了什么事重要而基本的功能(雪中送炭),什么是可选的、不那么核心的功能(锦上添花),然后集中精力在alpah阶段实现核心的、基本的功能。我们能够按时的发布alpha版,实现基本的两人对打功能,很大程度上得益于目标的合理分解。试想,如果我们当时既想做两人对打,又要实现酷炫的特效、用户自定义等等,恐怕我们到现在什么也做不成,很难有可以deliver的东西出来。
  • 明确分工
    典型的一个软件项目团队有PM,dev和test三个角色,我们刚开始也是这样设置的。但是后来发现,因为我们是做游戏,需要很多的设计工作,比如人物的招式、照片的拍摄与处理等工作,很难归于上述三种角色的职能。于是我们又设立了两名designer,来进行设计工作。这样分工更加明确,也容易提高效率。
posted @ 2011-01-17 21:36  MSRA_SE_TEAM  阅读(532)  评论(2编辑  收藏  举报