标签：

对软件工程Alpha迭代的反思与总结

　　本次软件工程的A轮迭代，我们组出了不小的问题。作为一个团队来说，我们的队伍出现了很严重的状况，严重到让老师觉得我们一度失控。于是我撰写此文，借以反思、总结和提高。本文分三部分，在第一部分我将阐述我们在开发期间的一些过程，第二部分我将分析事情造成的原因，第三部分我将叙述一下我们下一步的解决方案。最后还有一点小小的反思。

一、事情的发生

　　当时我们组队比较晚，本来想拆散了分去各个队伍，后来正好还有同学没有组上，老师就把我们剩余的这些人成立了一个新组。所以我们在团队初期就缺乏团体性。

　　然后我们这一个组就算正式组成了。在开始的时候，组内还可以保持一段时间的交流，真正开始做的时候，学院的实验室有很急的项目，需要我们的主力开发人员去完成，并帮他请掉了所有科目的上课时间。这让他在第一轮的迭代中异常狼狈。白天去实验室，夜晚回来还要考虑软件工程的团队开发，略微拖慢了整个团队的进度。而其他的同学没有事情，却也没有补上他的位置。大家对于项目的积极性也不是很高，偶有做不完任务就去休闲娱乐的事情发生。

　　最大的问题在于我们的Scrum Meeting没有写好，这让我们在第一轮迭代中每个人失去了几十分。

　　对于这些问题，我将逐个分析。不逃避问题，要找出真正的解决办法。

二．问题与原因

团队模式：

       邹老师在《构建之法》中曾经把团队合作模式分为一窝蜂模式、主治医师模式、明星模式、社区模式、秘密团队模式等等，我们的团队属于主治医师模式，有一个首席程序员，其余人都是为他服务：

              这样的团队中，有首席程序员(Chief Programmer)，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。

这个模型很好地概括了我们的问题。在我们团队中，只有一个人明白当前代码的所有架构。这充分导致了其他辅助程序员的效率低下。

       在项目开始，我们设计的模式是功能团队模式。就像大多数团队一样分为PM，后端，前端，UI等。然而最后我们却没能掌控住。

       在敏捷开发中，我们主要以个人交流为主，开发人员们共同工作。这才符合敏捷开发的原则，而事实凸显了我们交流不够多的问题。这是敏捷开发的大忌。这部分是由于我们还违背了一条原则：

“以有进取心的人为团队为项目核心，充分信任支持他们”。

       由于我们其中一名主力的缺席，这大大不仅托缓了我们团队的进度（因为写代码的也就3个人，然而在这个时候还缺席一名主力），更为突出的问题是，加重了其余开发人员的压力。

敏捷开发：

       接下来该讲讲我们在Scrum Meeting 上的重大失误。

              软件开发流程有好多种，我们怎么衡量一个开发流程是否对当前的项目/团队合适？我觉得Scrum/Sprint能成功实施的关键在于Scrum Master。我听到有些团队也实施Scrum，但是他们随机挑一个成员来做Scrum Master，好像Scrum Master就是招呼大家开开会，记录每个人的进度而已，这种方法失败的可能性很大。

       不得不说，这是我们的重大失误。我们的Scrum Meeting 没有按时发布，导致整个团队的分数走低，对于这个问题，有几名成员难辞其咎，我来逐个说一说：

1. 在分配任务的时候把PM和博客的任务分开了，我的本心是平衡一下团队贡献值，能让我们组的成员分数极差小一点。其实当时我是看了这句话：

Scrum Master 不是一个官，而是一个没有权利的沟通者，就像微软的PM那样，他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master的方法大多行不通。

       现在事实告诉我们：PM和博客不能彻底分开。否则一定会出问题。

我们还有一个问题是在迭代结束四天前，曾和老师通邮件说明我们博客的缺失，表示要及时补上，然而当天晚上我们的组员一直在开发，不一会儿就把这件事忘掉了。导致最后的一次Scrum Meeting也没能补上。

1. 第二是负责博客的同学的大失误。当时分配任务的时候，她的任务是负责博客，我们要求她及时关注罗老师的动态，不全的资料找开发的同学要，要把组内的博客写好。可是她没有及时更新团队的博客，比如功能说明和会议记录，这导致了我们整体博客的持久未更新。我想，如果能够及时的看老师的博客或者是及时的上课，就能知道老师的提醒，就不会出这么大的问题了。
2. 第三是PM的问题。其实我们在本轮迭代的前半段，是基本处于无PM的状态。我们发现了这个问题后，才任命一人为PM。按说PM一定要提醒所有人员的进度，但PM身兼数职，实在无法在兼顾所有任务。这个问题有更为致命的原因，我将在之后进行分析。

简单地总结一下，我们的团队有成员没有达到敏捷开发的要求：自主管理，自我组织。

       自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑任务；每次Sprint结束之后，还要总结不足，提出改进，并且要自己实施这些改进。“自主管理”不等于“没有管理”。

       自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还有帮助他改进，项目缺少某类资源自己还要顶上去。

       这件事情发生在团队身上，就是“积极度不高”。大家没有积极地把这件事情做出激情，对于团队交代给的任务也没有积极完成。比如说，如果留学生同学能够主动的来要代码，把我们分享的知识学习完全，写博客的同学能主动找开发人员要今天的进度。负责辅助首席程序员写代码的同学能够主动的去要任务来减轻首席程序员的负担，这些都是“自主”掌控的地方，而在这些地方我们掌控的都不好。

开发流程：

　　我们的团队的开发流程是：

　　确定软件需求<->分析<->程序设计<->编码<->测试<->发布。基本是瀑布模型(Waterfall)的变种，又没有像统一流程(Rational Unified Process)那么繁琐，敏捷开发嘛，文档写的不是很全。在整体的流程中大体还不错，只不过出现了一些技术的断档，也就是说能懂整体架构的人只有一个，其他人都是去辅助他，实现具体的模块。现在反思，原因就在于：

　　　　产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。

　　　　使用的技术非常成熟，团队成员都很熟悉这些技术。

　　在这两点上，我们做的不够。我们的开发是一个人负责一个模块，架构师总统这些模块。所以只有一个人熟悉所有的东西。

　　现在就得提到我们团队另一个大问题：人手不够。我们的留学生同学态度非常好，有些什么任务安排给他会答应，只是——由于知识积累的不够或者其他的原因，他们产出实在有限。绝大部分的事情都是另外五个组员在做。在这五个人中，一人负责所有的测试工作，一人负责博客。所有的开发代码都是由余下三任完成的。这也就是说，我们的开发人员只有三个人。比起其他的组，我们无疑有很大的劣势，因为这会给予开发人员非常大的压力，使其3个人能应付5个人的工作量。即使其他的队员没有什么事情，也不会来主动做一些东西来分担压力。这是我们不团结的表现，足以让我们引以为戒。这也刺激了我们去解决这些问题，改善组内的开发状况，使整个项目可以达到我们的预期。

　　然而我们也有很多做的很好的地方，值得继续发扬：

　　1.责任感和使命感。当开发时间紧、任务繁多的时候，我们还是完成了任务。其中做出了很大贡献的是PM，他在开发主力不在的时候写了很多代码，使得我们在冲刺阶段的时候少了一名开发队员的情况下，仍然完成了初期的界面任务。记得那天晚上，凌晨2点他给缺席的开发主力发QQ，说我们有了一些成果，我看到成果的时候，还是为他的效率而惊讶，因为我们都是从零开始学安卓，而他只用了6个小时就写完了好多结构和界面。在接下来的时间里，我再接手时也得到了他的很多帮助。这次我们队伍在软件工程的A轮迭代能够达到预定目标，和他有非常大的关系。在我回来后我们仍加班加点的工作，直到完成我们A轮的计划目标。

　　2.通揽全局的大局观。当问题出来之后，队伍第一时间想的是怎么解决当前的问题，而不是先去追究谁的责任。当然，由于我们是绩效分配，所有一定会考虑到每位同学的团队贡献，不让付出的同学失望。对于工作少的同学，一定得在第二轮迭代里面多做一些工作，否则怕是难以得到自己想要的分数。当然，我们责任制强调的也不够多，让一些同学想要水水就过。而事实上我们的任务很大，需要大家齐心协力。

　　最后我们想对老师说，我们不是放弃了，不是失控了，我们一直没有中断过对于软件的开发。或许队内确实发生了问题，但是绝不是放弃了希望。现在的结果我们很痛苦，也很难接受，所以我会再多做点工作，以提高整体的团队成绩。我们一直以能够学到真正的软件工程为豪。

三．做什么改进

       刚才我们对于团队发生的问题做了深度的透析，在我看来基本把所有潜在的矛盾都激化了出来。使得在分析我们的病因时能够分析的更透彻。那下面就应该是我们治病的过程了。

       我们应对现在的棘手情况做出以下改进：

1. 我们认识到了具备一位统揽全局的PM之重要，在第二轮我们将任命一名专职的PM，以掌控全局。
2. 改善整体的团队成员分配，我们需要在第二轮迭代中引进一位能够编写代码的同学，这样我们就有了4位主力进行开发。此举能够大大加快我们的进度。解决我们码力不足的尴尬境地。
3. 提高全体成员的积极性。这对我们而言是不简单的工作，因为我们还同时有编译原理和数据库作业，所以一定要拿出成果，及时播报成果，让队伍有了成就感，就自然有了团队的向心力。这个任务交给黄上，由他来带动整体的气氛。
4. 完善E-R图，清楚地写明代码的逻辑，方便后来的同学进行快速上手。这件事主要交给崔强去做，因为现在只有他熟悉整个架构。
5. 严格执行绩效制度，想要得分就一定要对团队有正贡献。用以防止我们出现人手不足的这种情况，让所有的同学能够加入到开发过程中来。每次的任务都有任务点(Mission Point)来标记，最后将按照任务的权重来分配分数。

四．最后再多说一点，对于软件工程的建议。

　　邹老师的原意是把公司的软件工程引进来，这给我们提供了很不一样的视角，让我们认识到在大公司中的开发是什么样子的。但是公司和学校是不一样的。我们没有办法建立起一套能够激励队员的制度，也无法真正对队员的一些行为做出实质性的处罚或规约。更要考虑人际关系以及它所带来的影响。所有的这些差别都会影响团队的运作。

　　所以在明年的实验中，对这些问题提出一些相对的方法可能会使整个课程的运作更加完善。感谢罗杰老师对我们的关怀、理解、提醒和支持，也感谢邹老师带给我们接近真实工作的体验，我们在这一轮的过程中学到了很多东西。希望我们团队能够积极面对接下来的挑战，攻克难关，笑傲风雨。

对软件工程Alpha迭代的反思与总结

标签：

原文地址：http://www.cnblogs.com/Buaa-software/p/4966590.html