敏捷开发团队管理：几个真实案例与经验总结

敏捷开发团队管理：几个真实案例与经验总
结
动身点：结果导向
机敏开发团队的外在行为是“结果导向”，而内在支撑则是“团队工作”(TeamWork)。

所谓结果导向，就是直指结果，而不拘泥于形式。

可以被拘泥的“形式”各式各样，比如方式、方法、流程、文档、部门、分工、职责……都是形式。

这些形式原来是设立来帮助实现更好的结果的，但是假如拘泥于此，则可能起到反作用。

假如认真端详机敏宣言中右侧的内容，就会发觉他们都属于形式，而非结果：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
这些形式曾经保证了众多早期军工、航天、航空项目的成功，但若在任何行业任何项目——比如机敏开发出现时的互联网行业——拘泥于此，就可能导致失败。

可怕的是，左侧的4条，也是形式而非结果。

所以对机敏宣言的正确理解是：在现今的多数行业中，假如以结果导向为动身点，则左侧的形式赛过右侧的形式。

支撑点：团队工作
为什么说团队工作利于结果导向的实现?
有一个兄弟射雁的例子可以说明：三个兄弟看着大雁飞过，一个说要射下来烤着吃，一个说要炖着吃，另外一个则要炒着吃，三人争吵不下，大雁都飞走了。

比如有一个Bug，人们不去分析怎样改正怎样预防，而是争论是谁的责任;比如有一个任务，人们不去分析怎样做最快，而是争论应当谁做;比如有一个变更，人们不去分析变更前后甲乙方是否有利，而是争论应当哪些部门走怎样的流程;比如有一个产品，人们不去分析怎样做才能成功，而是争论成功后应当怎样考核……就很难直指结果，而陷入部门和个人的纷争之中。

这里倒不是说后者不需要考虑，而是说动身点问题。

假如思索问题的第一念头是“我”“我们”“他”“他们”，那么团队协作就建立不起来，机敏开发也做不好。

几个真实案例
这几个团队都是我自己亲身经历的团队，从质量的角度来分析机敏团队的工作方式。

•第一个是一个较为大型的团队，约有25～30人，研发一个单一产品。

这个团队在一年半的时间里边，从5个人成长为25人，其中有一半人员来自刚毕业不到半年的本科或硕士(在20XX 年，还很难找到“有10年经验的编程人员”);在这个团队拥有25名成员的时候，只有1～2个测试人员。

按一般的常理而言，这个产品应当面临很大的质量问题，
因为这些新来者应当编写大量的缺陷，而测试人员又严重不足，不足以发觉这些缺陷。

但实际状况是，这个产品是我后来经历的全部大型团队中最好的一个，包括后来拥有众多测试人员的团队;此产品运行于CCTV，属于高度实时性和牢靠性的产品;此产品在上市7年左右的时候占有市场的60%份额(之后数据不详)……
•第二个团队可以说是个团队，也可以说是个个人，是我之后为某家军工企业开发的一个小软件。

“无损检测系统”项目历时3.5个月，涉及步进电机、超声波扫描卡等各种软硬件，尽管就这么多人工，最终甲方说做了个“国内领先的无损检测系统”(只能说可见国内行业底子之差)。

一个人开发，当然只能自己开发自己测试，但是质量却是有史以来最好的，整个项目的测试期只有几天，而交付后一年中客户没有发觉过缺陷，只在更换硬件平台后发觉一个水土不服的时序问题。

这两个软件，是我自己亲自或近距离参与的项目中质量最好的两个，但惊奇的是他们都没有专业测试人员。

编程人员的降低缺陷的方法
这里先不分析编程人员与测试人员的分工、合作问题，先看看编程人员除了被“测试”之外，自己有哪些方法可以提高质量。

•第一个项目的经验
在第一个团队中，由于团队很年轻扩张又很快，所以推
行了代码审查的方法，简洁而言，就是高手/老手要看新手的代码，后期的制度则是每个人的代码必需有人看过之后，才能提交。

在这些提交过程中，许多可能带来日后维护困难或缺陷的代码都被踢了回去。

在这个团队扩张的后期，这种审查制度被凝聚在师徒制度中，以把原来“帮忙”做审查变成“审查义务”。

这一变化的原因是中间曾经发生过一次“不负责任”的审查，造成一大段两个月的代码未经充分审查就进入代码库，酿成后来的一次现场故障。

这种“不负责任”来自于原来就没有设定责任，只是帮忙，所以才发生了组织结构的变化。

在建立师徒制度后，师傅们将对小组的成败包括质量负责。

实际上，新人的流淌率很高，假如留下垃圾代码，还是要师傅来维护，所以师傅“被迫”很尽责。

师傅们普遍的做法是不只在最终才审查代码——因为那时候确定面临一个烂摊子——而是在前期就指导徒弟编出良好的代码，乃至在更早的时间点介入，做出良好的设计。

这些制度后来演化成松结对编程方法。

•第二个项目的经验
第二个项目则是本人做度量最认真的一个项目。

原因是在离开上一家公司后，我去了一个测试人员众多的企业，但其产品质量却奇差无比，甚至导致后来一个产品被放弃，40人因此离职。

所以萌生了一个念头，就是认真度量一下缺陷是怎么来的，又是怎样被发觉的。

针对这个项目有一个100多个检查项的代码检查表，每
天对代码进行30～60分钟的代码检查。

在整个项目过程中一共有240多个缺陷，不过只有6个发觉于系统测试期，9个发觉于与硬件的集成测试，63个来自于调试(就是完成编译到按下F5调试成功中发觉的问题，一般大家都是不记录的，但这个项目中也被记录下来)，剩下的有112+53个来自于“看代码”(有自查和后查两种形式)，这个项目没有单元测试活动。

大致结论是只有微乎其微的缺陷是由测试活动发觉的，而剩下的缺陷则是由开发活动发觉的。

这个项目的数据还揭示出一些有价值的信息：
1. 开发人员可以有效地降低总缺陷率
在为期27天的编码期(这个项目是瀑布式开发)中，千行代码的总缺陷率趋势从第一天的130/千行降低到最终一天的60/千行，说明若开发人员能潜心消退缺陷，那么在很短的时间里就能大幅降低自己代码的总缺陷率;极少有测试活动能做到类似的效果。

2. “全部缺陷无需测试活动即可消退”
下面是当时的“过程效益”分析，所谓过程效益，就是某个过程对消退缺陷的能力。

比如假如说“调试”的过程效益是40%，就是说假如有100个缺陷到达调试环节，调试中会发觉其中40个，而60个会被漏到后面去。

图中的蓝线就是“调试”的过程效益，留意前期的调试缺陷经常很低，表明“调试起来一切正常，但是一测试就发觉许多问题”;后期的调试效益经常是100%，这个意思是说在完成调试(就
是F5)后，之后再也没有任何人、任何活动从这天编写的代码中发觉任何缺陷。

准确说系统测试的6个缺陷，全部发觉于前13天的代码中;换一种说法：假如全程都能像后13天一样编写代码，系统测试的缺陷将为0。

“全部缺陷无需测试活动即可消退”这句话被打上引号，是因为它是一种很抱负的状态。

但是与“全部缺陷可以被某种测试活动消退”相比，我更相信前者。

3. 编程人员可以训练出行之有效的排解缺陷的手段
“自查”的过程效益始终没有达到100%，但是它与调试的作用越来越互补。

比如在初期自查+调试后，还有大量缺陷被发觉(所以调试的效益很低);但假如每天认真分析自己自查发觉的缺陷和调试发觉的缺陷，就可能在短短一个半月的时间内大幅度提升自身发觉缺陷的能力，乃至于到达不把缺陷留给测试环节，更不会留给客户的程度。

从上面图中的数据可以看出来，这个项目的质量不是由一个“能力很强的人”保证的，因为刚开头调试后还是有许多缺陷会留给测试活动发觉，只是后来的训练导致了能力的增加。

因此人的因素有，但是不是肯定的。

总结
这些项目揭示出来的规律是：程序员应当负责产品质量，他们有能力，也有时间。

第一个项目并没有因为“程序员还要负责质量”而耽搁进度或造成功能“太少”影响到市场竞争力;第二个项目甲方
后来坦然说“原定计划一年，没想到三个半月就结束了”(此前他们自己曾经尝试2个人研发过一年，此外也了解另外两家竞争对手投入的状况)。

许多人一定认为上述经验有很大的局限性，比如对个人能力的要求很高，其实不然。

第一个项目中，那些刚毕业的本科生和研究生与今日动辄工作5、6年乃至10年的程序员的水平不可同日而语;第二个项目中我本人当时工作经验也只有8年，其中做职业程序员的时间则只有4～5年左右，编码量仅在2万行左右。

所以关键还是方法，而不是人;或者说是“使用正确方法的人”就足够了，“使用正确方法的正确的人”不是一个强制条件。

来源：机敏开发实践
动身点：结果导向
机敏开发团队的外在行为是“结果导向”，而内在支撑则是“团队工作”(TeamWork)。

所谓结果导向，就是直指结果，而不拘泥于形式。

可以被拘泥的“形式”各式各样，比如方式、方法、流程、文档、部门、分工、职责……都是形式。

这些形式原来是设立来帮助实现更好的结果的，但是假如拘泥于此，则可能起到反作用。

假如认真端详机敏宣言中右侧的内容，就会发觉他们都
属于形式，而非结果：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
这些形式曾经保证了众多早期军工、航天、航空项目的成功，但若在任何行业任何项目——比如机敏开发出现时的互联网行业——拘泥于此，就可能导致失败。

可怕的是，左侧的4条，也是形式而非结果。

所以对机敏宣言的正确理解是：在现今的多数行业中，假如以结果导向为动身点，则左侧的形式赛过右侧的形式。

支撑点：团队工作
为什么说团队工作利于结果导向的实现?
有一个兄弟射雁的例子可以说明：三个兄弟看着大雁飞过，一个说要射下来烤着吃，一个说要炖着吃，另外一个则要炒着吃，三人争吵不下，大雁都飞走了。

比如有一个Bug，人们不去分析怎样改正怎样预防，而是争论是谁的责任;比如有一个任务，人们不去分析怎样做最快，而是争论应当谁做;比如有一个变更，人们不去分析变更前后甲乙方是否有利，而是争论应当哪些部门走怎样的流程;比如有一个产品，人们不去分析怎样做才能成功，而是争论成功后应当怎样考核……就很难直指结果，而陷入部门和个人的纷争之中。

这里倒不是说后者不需要考虑，而是说动身点问题。

假
如思索问题的第一念头是“我”“我们”“他”“他们”，那么团队协作就建立不起来，机敏开发也做不好。

几个真实案例
这几个团队都是我自己亲身经历的团队，从质量的角度来分析机敏团队的工作方式。

•第一个是一个较为大型的团队，约有25～30人，研发一个单一产品。

这个团队在一年半的时间里边，从5个人成长为25人，其中有一半人员来自刚毕业不到半年的本科或硕士(在20XX 年，还很难找到“有10年经验的编程人员”);在这个团队拥有25名成员的时候，只有1～2个测试人员。

按一般的常理而言，这个产品应当面临很大的质量问题，因为这些新来者应当编写大量的缺陷，而测试人员又严重不足，不足以发觉这些缺陷。

但实际状况是，这个产品是我后来经历的全部大型团队中最好的一个，包括后来拥有众多测试人员的团队;此产品运行于CCTV，属于高度实时性和牢靠性的产品;此产品在上市7年左右的时候占有市场的60%份额(之后数据不详)……
•第二个团队可以说是个团队，也可以说是个个人，是我之后为某家军工企业开发的一个小软件。

“无损检测系统”项目历时3.5个月，涉及步进电机、超声波扫描卡等各种软硬件，尽管就这么多人工，最终甲方说做了个“国内领先的无损检测系统”(只能说可见国内行业底子之差)。