Week1TeamHomework#1fromZ.XML总结学长经验教训

谭传奇学长&＃xff1a;
　　我们的弯路可能是&＃xff0c;一开始没有从最基础的部分开始迭代开发&＃xff0c;一开始就想的太远了一些&＃xff0c;每一步开的有点太大了&＃xff0c;所以可能有些东西最后就连不上&＃xff0c;也没有能够按时完成。如果可以先做出一个能用的版本&＃xff0c;然后再不断完善&＃xff0c;至少不会跳票&＃xff0c;但我们可能有的部分做的足够好&＃xff0c;有的关键部分就没时间做&＃xff0c;结果就是整个东西无法发布

王安然学长&＃xff1a;

　　经过第一次迭代开发&＃xff0c;团队合作的很多问题暴露出来。

1. 设计不足。一个软件工程的设计到实施&＃xff0c;其实是很重要一步。在我们的项目中&＃xff0c;为了满足游戏设计的需求&＃xff0c;我们的软件工程设计中保留了很多的可扩展性&＃xff0c;但是却没有足够关注到细节&＃xff0c;没有给出所有具体的要求。在实施工程的时候经常发现有的问题在设计中找不到参考&＃xff0c;导致开发人员的效率低下。
2. 开发人员水平有限。分配任务的时候经常有说这个事儿做不到&＃xff0c;或者压根不知道怎么做&＃xff1b;验收工作频出意外&＃xff0c;DEV写了一个模块之后&＃xff0c;验收的时候发现模块质量不行&＃xff0c;代码质量低是其次&＃xff0c;无法按照给定的接口工作。
3. 工作分配及目标不够明确&＃xff0c;PM在分工时&＃xff0c;没有对各项工作进行足够细致的描述&＃xff0c;也没有设立一个明确的短期目标&＃xff0c;使得开发人员对自己的工作目标模糊&＃xff0c;没有验收时标准的参考。
4. 在M1阶段&＃xff0c;开发人员工作时和相关模块开发人员、PM的联系太少&＃xff0c;总是PM下达任务&＃xff0c;Dev之间缺乏联系。对于工作目标中模糊的部分采用了模糊处理&＃xff0c;验收时代码没有达到预期的效果。M2阶段效果好了一些。
5. 有关游戏制作的特殊性。游戏制作大家都是第一次&＃xff0c;一个游戏玩起来基本的逻辑也许不复杂&＃xff0c;但是难在它对交互效果要求极高&＃xff0c;如果只能满足基本的逻辑正确而交互效果极差&＃xff0c;那这段代码必然失败。为了提供一个优秀的游戏体验&＃xff0c;好的美工重要&＃xff0c;开发人员要写出交互效果良好的代码也很重要。开发人员自身需要有一定交互设计功底&＃xff0c;并且有美术功底或者有美工的指导&＃xff0c;这是我们的大部分组员都缺乏的&＃xff0c;这也导致了后期的用户评价都是“游戏很好玩&＃xff0c;但是不协调&＃xff0c;不好看”。程序员&＃xff0c;有心无力&＃xff0c;没办法……
6. 错误的预估了项目的大小。我们都没有制作游戏的经验&＃xff0c;没有想到&＃xff0c;这样一款比较简单的游戏都需要这么大的工作量。这导致了最后的跳票。
7. 另外&＃xff0c;工程项目本身也存在很多问题&＃xff0c;使用跨平台C&＃43;&＃43;游戏引擎编写的一个不好就是我们没捣鼓出来配合VS进行代码质量管理的有效方法。而且游戏程序的测试也相当复杂&＃xff0c;我们仅能采用大量测试工程来分开游戏单位测试&＃xff0c;保证没有意外错误和运行效果&＃xff0c;最低限度是保证代码逻辑功能正确。

　　学长感受&＃xff1a; 我们觉得碰到这种情况&＃xff0c;就应该把游戏设计那人吊起来&＃xff0c;把文档写到游戏逻辑的每个角落&＃xff0c;每个效果都有动画演示和运算函数&＃xff0c;然后大家照着文档开始干&＃xff0c;缺一否则皆不能安天下。否则光干游戏设计的人工作量也不够大。

 

总结

　　从各位学长的经验教训来看&＃xff0c;开发一个游戏确实很麻烦。我们小组目前的计划也是开发一个游戏。所以学长的经验对我们来说&＃xff0c;十分有帮助。重要的一点是&＃xff0c;PM的规划&＃xff0c;DEV的执行有严重的脱节。程序编写一开始设想的过大&＃xff0c;在大的里面又想很多细节的东西。根据学长描述&＃xff0c;导致开发效率较低。
　　我们希望能借鉴学长提出的思路&＃xff0c;对于一个项目&＃xff0c;先进行基本的&＃xff0c;最简单版本开发。然后再扩展程序。计划通过3~4次快速的迭代开发&＃xff0c;使得程序由简单变复杂。由能用变好用。在debug方面&＃xff0c;我们希望对于整个程序进行分块&＃xff0c;然后编写自动补全函数的辅助debug代码。来并行调试。这个样子可以使得每个人负责的程序有效的&＃xff0c;正确的完成。

编辑&＃xff1a;肖俊鹏