SouthSeven团队项目Screaming Drummer alpha迭代事后分析

Alpha版本迭代完成了，接下来我们来回顾一下整个过程。

1、团队配合与效率

纸上得来终觉浅，实践以后发现，还真的，应了邹老大的那些话。我们的团队经历了团队形成-发生分歧-渐渐默契-共同创造的这样一个过程。最开始的时候，形式一片和谐，但是PM过于独断，甚至有些专横，这导致了团队成员的不满。在沟通形式上，也出现了PM和团队成员产生矛盾的情况。好在后来通过双方的努力，矛盾被平安化解，每个人也都逐渐互相地了解了对方的性格，能够逐渐地“理解对方的观点”——而不再是一味地坚持自己的态度。在最后几天的冲刺中，团队成员间的默契渐渐形成，大家共同奋战，团队士气高涨，最终按时完成了初期设定的目标。可以说，我们已经从五个独立的工作单元凝聚成了一个能够让人看到特色的团队。尽管还有很多需要改进的方面，但是就第一个迭代的短短十天而言，我们的团队正在健康地成长。

在迭代过程中，沟通的问题已经暴露出来。例如Daily Scrum 8的晚上发生了这样的问题——Jun被分配到Artwork线程工作，这样必然就会涉及到游戏引擎方面代码的使用。但是一开始引擎方面与美工方面没有进行沟通，导致美工错误解读了引擎的使用方法，开始往引擎里注入一些Dirty code（此处是指，为了实现某个特定功能而修改了引擎本身的代码），引擎方面的开发人员看到这种情况就非常恼火——你不懂这段代码的话，那么干嘛要去修改他呢？美工方面也是如此——我实现了我的功能，但你又说动了你的代码，明明就是接口没有留好嘛。

这个问题要分成两个层面来看。

其一，分工问题。最初PM指定的“美工“的职责是生产一些位图供引擎开发人员使用；但是后来美工人员却发现，引擎部分缺少能够支持某种特定功能的Routine（例如显示动画）。美工方面没有正确地将需求传达给引擎方面，而是自己开始以一种完全不同的视角介入到引擎开发中——这样做非常危险，通常会产生出一份双方都无法维护的代码。而引擎方面，由于代码一直处于一个单一开发人员的掌控中，注释不完善，接口没有规范，也就自然不能告诉美工正确的实现方法。从这个层面来看，得到的教训是——绝对不要给某个人分配一个泛泛的任务。能够清楚定义的任务必须落实到细节——既然早就能想到，那为什么要把它变成项目进行过程中的资源浪费呢？下次分配任务一定要这样写——引擎方面负责接受来自美工的特性需求，并给美工提供必要的测试接口。美工方面不涉及到修改引擎代码的工作，只负责生产位图文件，并使用/申请来自引擎的显示特性。这样是不是会好一些。

其二，不要做秘密小分队。假设这种定义模糊的任务确实出现了，我们也不能就此缴械投降。假设两个线程及时沟通并把撞车结果反馈给PM的话，那么事情也不会变得太糟糕。这一点其实不只存在在任务撞车的情况下——有一天PM修改了大量代码，但是没有及时反馈给引擎开发者（那一天TFS服务器处于离线状态，这也是出现问题的原因之一），导致开发人员生产了一些功能相似但是却不兼容的实现——最后不得不舍弃掉其中的一份，包括那个实现中对未提交Bug的修正（最悲剧的是那些Bug重新变回了未知Bug，我们不得不重新测试一遍）——看来沟通不仅要有效，还要及时呀。

2.人员配给

我们团队一共5人，其中分成了三个Thread，两个人负责Game Engine与Logic，两个人负责Voice Module，PM负责各部分之间的粘合。事后看来，这种分配方式还算比较有效，但是也出现了一些问题——这种按照Thread分配任务的方式会让团队成员产生一种局部独立性，两个Thread之间没有任何的交互，每个人也就觉得“啊～大概做好了自己的部分项目也该完成了吧”，于是也就不关心其他Thread的进展。这种静态的分配方式最终导致了一个悲剧——Voice Module部分提前达到了较完善的水平，于是骏骏骏被重新调配到Artwork线程开展全新的工作——这样和毫无计划其实也就相差无几了。于是Artwork部分阵脚大乱，到最后一天的时候部分图片仍然没有完成（因为大家都不是很适应），而且所有人都参与到了这项工作中，形成了“五人搬砖”的野蛮方法。针对这一点，在Beta版本中，工作的分配将会有一定的调整，形成一些交集（但是不要两个人写作一份代码），这样即使不参与对方的开发过程，至少切换过去之后不会毫无感觉。

3.目标制定与实现

最初制定的目标全部实现了，并且很多P2的任务也完成得不错。但是一个致命的问题是——直到最后，都有人不知道我们的游戏到底有个什么玩头。评分系统的逻辑的第一个实现与主流游戏相去甚远（哪有打不上Note要扣分的啊！）判定系统的手感生硬缺乏快感。追根数源，那应该是User Story做得太烂，而且Game Specification没有明确地Materialize出来。这个PM应该负主要责任，Beta版本的User Story定会设计得更加像“用户体验”而不是一个个的任务——一旦开发人员都不知道用户想要什么，事情就变得很糟糕——到底要做给谁用呢？

所以，目标的定制不一定就是一堆技术指标，什么“识别三种声音”，“延迟XXX毫秒以内”——“用户爽了”才是我们的终极目标，嗯哼。

4.开发规范

完全就是个悲剧。。。要接口没接口，要文档没文档，每天只管Burn down，遇到新任务也没有及时添加进去——Issue栏目只有一个Item，Bug栏目更惨——没有Bug啊！Zero Bug啊！完全是科幻啊！这一点上PM也应该负责，因为他最开始不自量力地说了一句话——文档就交给我来补充吧。结果到后来他发现，自己其实也就只是勉强能以别人生产代码的速度来读懂它们而已，根本没有精力来帮助每一个人补充必要的文档。大部分团队成员甚至没有“文档”这么一个概念。而各自独立的开发人员们又会觉得，反正就我自己用用，写神马接口啊，通通Private得了。。。

所以PM决定，Beta开始的时候，首先再Review一下以前的代码，适当重构，并进行文档/接口方面的基本培训。（话说，强烈建议邹老大给大家讲讲这两个方面。PM自己也不过是个新入行的菜鸟而已。）

另外，Bug反馈机能效率无限低的原因可能出在Dev/Test概念暧昧模糊（互相测试到底是什么，到底测了吗？还是自己消灭了所有Bug）。Beta阶段将做出一些调整，明确Test任务。

还有，Work Items过期失效一定要及时更改。千万不能出现“每天随意烧几个Item满足一下波荡图“的情况。

5.PM的协调

我们组的PM通常都在几个Thread之间不停跑路——哪个线程缺少人手，他就会出现在哪个地方。几个Thread之间出现无法沟通的情况时，他会以自己的理解来试图为双方梳理——但是，仅仅是自己的理解而已。（正在写这个文章的就是PM，话说第三人称没关系么？）有好几次，差点因为自己的错误理解而导致分配错误的任务。这种情况其实应该被称为“不具备括放性能”吧——事情少还好，事情一多起来，总不能让PM一个人的精力成为整个团队的效率瓶颈吧？所以，PM认为自己只能算是“基本合格”地解决了Alpha迭代中的问题。在接下来的Beta迭代中，一定要建立更科学的协调机制，让团队成员能够高效展开自助协调。

差不多就写这么多了，把上面的问题解决了，我们的团队将在Beta迭代中变得更加健壮有力。