几个真实案例

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

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

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

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

　　但实际情况是，这个产品是我后来经历的所有大型团队中最好的一个，包括后来拥有众多测试人员的团队；此产品运行于CCTV，属于高度实时性和可靠性的产品；此产品在上市7年左右的时候占有市场的60%份额（之后数据不详）……

　　第二团队个可以说是个团队，也可以说是个个人，是我之后为某家军工企业开发的一个小软件。

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

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

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

　　编程人员的降低缺陷的方法

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

　　第一个项目的经验

　　在第一个团队中，由于团队很年轻扩张又很快，所以推行了代码审查的方法，简单而言，就是高手/老手要看新手的代码，后期的制度则是每个人的代码必须有人看过之后，才能提交。在这些提交过程中，很多可能带来日后维护困难或缺陷的代码都被踢了回去。

　　在这个团队扩张的后期，这种审查制度被凝结在师徒制度中，以把原来“帮忙”做审查变成“审查义务”。这一变化的原因是中间曾经发生过一次“不负责任”的审查，造成一大段两个月的代码未经充分审查就进入代码库，酿成后来的一次现场故障。这种“不负责任”来自于本来就没有设定责任，只是帮忙，所以才发生了组织结构的变化。

　　在建立师徒制度后，师傅们将对小组的成败包括质量负责。实际上，新人的流动率很高，如果留下垃圾代码，还是要师傅来维护，所以师傅“被迫”很尽责。师傅们普遍的做法是不只在最后才审查代码——因为那时候肯定面临一个烂摊子——而是在前期就指导徒弟编出良好的代码，乃至在更早的时间点介入，做出良好的设计。

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

　　第二个项目的经验

　　第二个项目则是本人做度量最仔细的一个项目。

　　原因是在离开上一家公司后，我去了一个测试人员众多的企业，但其产品质量却奇差无比，甚至导致后来一个产品被放弃，40人因此离职。所以萌生了一个念头，就是仔细度量一下缺陷是怎么来的，又是怎样被发现的。

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

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