经过一个多月艰辛的努力，我们小组终于在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，来进行设计工作。这样分工更加明确，也容易提高效率。
