对软件工程Alpha迭代的反思与总结
对软件工程Alpha迭代的反思与总结
本次软件工程的A轮迭代，我们组出了不小的问题。作为一个团队来说，我们的队伍出现了很严重的状况，严重到让老师觉得我们一度失控。于是我撰写此文，借以反思、总结和提高。本文分三部分，在第一部分我将阐述我们在开发期间的一些过程，第二部分我将分析事情造成的原因，第三部分我将叙述一下我们下一步的解决方案。最后还有一点小小的反思。
一． 事情的发生
当时我们组队比较晚，本来想拆散了分去各个队伍，后来正好还有同学没有组上，老师就把我们剩余的这些人成立了一个新组。所以我们在团队初期就缺乏团体性。
然后我们这一个组就算正式组成了。在开始的时候，组内还可以保持一段时间的交流，真正开始做的时候，学院的实验室有很急的项目，需要我们的主力开发人员去完成，并帮他请掉了所有科目的上课时间。这让他在第一轮的迭代中异常狼狈。白天去实验室，夜晚回来还要考虑软件工程的团队开发，略微拖慢了整个团队的进度。而其他的同学没有事情，却也没有补上他的位置。*家对于项目的积极性也不是很高，偶有做不完任务就去休闲娱乐的事情发生。
最*的问题在于我们的Scrum Meeting没有写好，这让我们在第一轮迭代中每个人失去了几十分。
对于这些问题，我将逐个分析。不逃避问题，要找出真正的解决办法。
二．问题与原因
团队模式：
邹老师在《构建之法》中曾经把团队合作模式分为一窝蜂模式、主治医师模式、明星模式、社区模式、秘密团队模式等等，我们的团队属于主治医师模式，有一个首*程序员，其余人都是为他服务：
这样的团队中，有首*程序员(Chief Programmer)，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
这个模型很好地概括了我们的问题。在我们团队中，只有一个人明白当前代码的所有架构。这充分导致了其他辅助程序员的效率低下。
在项目开始，我们设计的模式是功能团队模式。就像*多数团队一样分为PM，后端，前端，UI等。然而最后我们却没能掌控住。
在敏捷开发中，我们主要以个人交流为主，开发人员们共同工作。这才符合敏捷开发的原则，而事实凸显了我们交流不够多的问题。这是敏捷开发的*忌。这部分是由于我们还违背了一条原则：
“以有进取心的人为团队为项目核心，充分信任支持他们”。
由于我们其中一名主力的缺*，这**不仅托缓了我们团队的进度（因为写代码的也就3个人，然而在这个时候还缺*一名主力），更为突出的问题是，加重了其余开发人员的压力。
敏捷开发：
接下来该讲讲我们在Scrum Meeting 上的重*失误。
软件开发流程有好多种，我们怎么衡量一个开发流程是否对当前的项目/团队合适？我觉得Scrum/Sprint能成功实施的关键在于Scrum Master。我听到有些团队也实施Scrum，但是他们随机挑一个成员来做Scrum Master，好像Scrum Master就是招呼*家开开会，记录每个人的进度而已，这种方法失败的可能性很*。
不得不说，这是我们的重*失误。我们的Scrum Meeting 没有按时发布，导致整个团队的分数走低，对于这个问题，有几名成员难辞其咎，我来逐个说一说：
- 在分配任务的时候把PM和博客的任务分开了，我的本心是平衡一下团队贡献值，能让我们组的成员分数极差小一点。其实当时我是看了这句话：
Scrum Master 不是一个官，而是一个没有权利的沟通者，就像微软的PM那样，他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master的方法*多行不通。
现在事实告诉我们：PM和博客不能彻底分开。否则一定会出问题。
我们还有一个问题是在迭代结束四天前，曾和老师通邮件说明我们博客的缺失，表示要及时补上，然而当天晚上我们的组员一直在开发，不一会儿就把这件事忘掉了。导致最后的一次Scrum Meeting也没能补上。
- 第二是负责博客的同学的*失误。当时分配任务的时候，她的任务是负责博客，我们要求她及时关注罗老师的动态，不全的资料找开发的同学要，要把组内的博客写好。可是她没有及时更新团队的博客，比如功能说明和会议记录，这导致了我们整体博客的持久未更新。我想，如果能够及时的看老师的博客或者是及时的上课，就能知道老师的提醒，就不会出这么*的问题了。
- 第三是PM的问题。其实我们在本轮迭代的前半段，是基本处于无PM的状态。我们发现了这个问题后，才任命一人为PM。按说PM一定要提醒所有人员的进度，但PM身兼数职，实在无法在兼顾所有任务。这个问题有更为致命的原因，我将在之后进行分析。
简单地总结一下，我们的团队有成员没有达到敏捷开发的要求：自主管理，自我组织。
自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑任务；每次Sprint结束之后，还要总结不足，提出改进，并且要自己实施这些改进。“自主管理”不等于“没有管理”。
自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还有帮助他改进，项目缺少某类资源自己还要顶上去。
这件事情发生在团队身上，就是“积极度不高”。*家没有积极地把这件事情做出激情，对于团队交代给的任务也没有积极完成。比如说，如果留学生同学能够主动的来要代码，把我们分享的知识学习完全，写博客的同学能主动找开发人员要今天的进度。负责辅助首*程序员写代码的同学能够主动的去要任务来减轻首*程序员的负担，这些都是“自主”掌控的地方，而在这些地方我们掌控的都不好。
开发流程：
我们的团队的开发流程是：
确定软件需求<->分析<->程序设计<->编码<->测试<->发布。基本是瀑布模型(Waterfall)的变种，又没有像统一流程(Rational Unified Process)那么繁琐，敏捷开发嘛，文档写的不是很全。在整体的流程中*体还不错，只不过出现了一些技术的断档，也就是说能懂整体架构的人只有一个，其他人都是去辅助他，实现具体的模块。现在反思，原因就在于：
产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。
使用的技术非常成熟，团队成员都很熟悉这些技术。
在这两点上，我们做的不够。我们的开发是一个人负责一个模块，架构师总统这些模块。所以只有一个人熟悉所有的东西。
现在就得提到我们团队另一个*问题：人手不够。我们的留学生同学态度非常好，有些什么任务安排给他会答应，只是——由于知识积累的不够或者其他的原因，他们产出实在有限。绝*部分的事情都是另外五个组员在做。在这五个人中，一人负责所有的测试工作，一人负责博客。所有的开发代码都是由余下三任完成的。这也就是说，我们的开发人员只有三个人。比起其他的组，我们无疑有很*的劣势，因为这会给予开发人员非常*的压力，使其3个人能应付5个人的工作量。即使其他的队员没有什么事情，也不会来主动做一些东西来分担压力。这是我们不团结的表现，足以让我们引以为戒。这也刺激了我们去解决这些问题，改善组内的开发状况，使整个项目可以达到我们的预期。
然而我们也有很多做的很好的地方，值得继续发扬：
1.责任感和使命感。当开发时间紧、任务繁多的时候，我们还是完成了任务。其中做出了很*贡献的是PM，他在开发主力不在的时候写了很多代码，使得我们在冲刺阶段的时候少了一名开发队员的情况下，仍然完成了初期的界面任务。记得那天晚上，凌晨2点他给缺*的开发主力发QQ，说我们有了一些成果，我看到成果的时候，还是为他的效率而惊讶，因为我们都是从零开始学安卓，而他只用了6个小时就写完了好多结构和界面。在接下来的时间里，我再接手时也得到了他的很多帮助。这次我们队伍在软件工程的A轮迭代能够达到预定目标，和他有非常*的关系。在我回来后我们仍加班加点的工作，直到完成我们A轮的计划目标。
2.通揽全局的*局观。当问题出来之后，队伍第一时间想的是怎么解决当前的问题，而不是先去追究谁的责任。当然，由于我们是绩效分配，所有一定会考虑到每位同学的团队贡献，不让付出的同学失望。对于工作少的同学，一定得在第二轮迭代里面多做一些工作，否则怕是难以得到自己想要的分数。当然，我们责任制强调的也不够多，让一些同学想要水水就过。而事实上我们的任务很*，需要*家齐心协力。
最后我们想对老师说，我们不是放弃了，不是失控了，我们一直没有中断过对于软件的开发。或许队内确实发生了问题，但是绝不是放弃了希望。现在的结果我们很痛苦，也很难接受，所以我会再多做点工作，以提高整体的团队成绩。我们一直以能够学到真正的软件工程为豪。
三．做什么改进
刚才我们对于团队发生的问题做了深度的透析，在我看来基本把所有潜在的矛盾都激化了出来。使得在分析我们的病因时能够分析的更透彻。那下面就应该是我们治病的过程了。
我们应对现在的棘手情况做出以下改进：
- 我们认识到了具备一位统揽全局的PM之重要，在第二轮我们将任命一名专职的PM，以掌控全局。
- 改善整体的团队成员分配，我们需要在第二轮迭代中引进一位能够编写代码的同学，这样我们就有了4位主力进行开发。此举能够**加快我们的进度。解决我们码力不足的尴尬境地。
- 提高全体成员的积极性。这对我们而言是不简单的工作，因为我们还同时有编译原理和数据库作业，所以一定要拿出成果，及时播报成果，让队伍有了成就感，就自然有了团队的向心力。这个任务交给黄上，由他来带动整体的气氛。
- 完善E-R图，清楚地写明代码的逻辑，方便后来的同学进行快速上手。这件事主要交给崔强去做，因为现在只有他熟悉整个架构。
- 严格执行绩效制度，想要得分就一定要对团队有正贡献。用以防止我们出现人手不足的这种情况，让所有的同学能够加入到开发过程中来。每次的任务都有任务点(Mission Point)来标记，最后将按照任务的权重来分配分数。
四．最后再多说一点，对于软件工程的建议。
邹老师的原意是把公司的软件工程引进来，这给我们提供了很不一样的视角，让我们认识到在*公司中的开发是什么样子的。但是公司和学校是不一样的。我们没有办法建立起一套能够激励队员的制度，也无法真正对队员的一些行为做出实质性的处罚或规约。更要考虑人际关系以及它所带来的影响。所有的这些差别都会影响团队的运作。
所以在明年的实验中，对这些问题提出一些相对的方法可能会使整个课程的运作更加完善。感谢罗杰老师对我们的关怀、理解、提醒和支持，也感谢邹老师带给我们接近真实工作的体验，我们在这一轮的过程中学到了很多东西。希望我们团队能够积极面对接下来的挑战，攻克难关，笑傲风雨。
