Week1 Team Homework #1 from Z.XML-总结学长经验教训
谭传奇学长：
我们的弯路可能是，一开始没有从最基础的部分开始迭代开发，一开始就想的太远了一些，每一步开的有点太大了，所以可能有些东西最后就连不上，也没有能够按时完成。如果可以先做出一个能用的版本，然后再不断完善，至少不会跳票，但我们可能有的部分做的足够好，有的关键部分就没时间做，结果就是整个东西无法发布
王安然学长：
经过第一次迭代开发，团队合作的很多问题暴露出来。
- 设计不足。一个软件工程的设计到实施，其实是很重要一步。在我们的项目中，为了满足游戏设计的需求，我们的软件工程设计中保留了很多的可扩展性，但是却没有足够关注到细节，没有给出所有具体的要求。在实施工程的时候经常发现有的问题在设计中找不到参考，导致开发人员的效率低下。
- 开发人员水平有限。分配任务的时候经常有说这个事儿做不到，或者压根不知道怎么做；验收工作频出意外，DEV写了一个模块之后，验收的时候发现模块质量不行，代码质量低是其次，无法按照给定的接口工作。
- 工作分配及目标不够明确，PM在分工时，没有对各项工作进行足够细致的描述，也没有设立一个明确的短期目标，使得开发人员对自己的工作目标模糊，没有验收时标准的参考。
- 在M1阶段，开发人员工作时和相关模块开发人员、PM的联系太少，总是PM下达任务，Dev之间缺乏联系。对于工作目标中模糊的部分采用了模糊处理，验收时代码没有达到预期的效果。M2阶段效果好了一些。
- 有关游戏制作的特殊性。游戏制作大家都是第一次，一个游戏玩起来基本的逻辑也许不复杂，但是难在它对交互效果要求极高，如果只能满足基本的逻辑正确而交互效果极差，那这段代码必然失败。为了提供一个优秀的游戏体验，好的美工重要，开发人员要写出交互效果良好的代码也很重要。开发人员自身需要有一定交互设计功底，并且有美术功底或者有美工的指导，这是我们的大部分组员都缺乏的，这也导致了后期的用户评价都是“游戏很好玩，但是不协调，不好看”。程序员，有心无力，没办法……
- 错误的预估了项目的大小。我们都没有制作游戏的经验，没有想到，这样一款比较简单的游戏都需要这么大的工作量。这导致了最后的跳票。
- 另外，工程项目本身也存在很多问题，使用跨平台C++游戏引擎编写的一个不好就是我们没捣鼓出来配合VS进行代码质量管理的有效方法。而且游戏程序的测试也相当复杂，我们仅能采用大量测试工程来分开游戏单位测试，保证没有意外错误和运行效果，最低限度是保证代码逻辑功能正确。
学长感受： 我们觉得碰到这种情况，就应该把游戏设计那人吊起来，把文档写到游戏逻辑的每个角落，每个效果都有动画演示和运算函数，然后大家照着文档开始干，缺一否则皆不能安天下。否则光干游戏设计的人工作量也不够大。
总结
从各位学长的经验教训来看，开发一个游戏确实很麻烦。我们小组目前的计划也是开发一个游戏。所以学长的经验对我们来说，十分有帮助。重要的一点是，PM的规划，DEV的执行有严重的脱节。程序编写一开始设想的过大，在大的里面又想很多细节的东西。根据学长描述，导致开发效率较低。
我们希望能借鉴学长提出的思路，对于一个项目，先进行基本的，最简单版本开发。然后再扩展程序。计划通过3~4次快速的迭代开发，使得程序由简单变复杂。由能用变好用。在debug方面，我们希望对于整个程序进行分块，然后编写自动补全函数的辅助debug代码。来并行调试。这个样子可以使得每个人负责的程序有效的，正确的完成。
编辑：肖俊鹏
