|
一个人开发，当然只能自己开发自己测试，但是质量却是有史以来最好的，整个项目的测试期只有几天，而交付后一年中客户没有发现过缺陷，只在更换硬件平台后发现一个水土不服的时序问题。项目管理者联盟
这两个软件，是我自己亲自或近距离参与的项目中质量最好的两个，但奇怪的是他们都没有专业测试人员。项目管理者联盟文章
编程人员的降低缺陷的方法项目经理博客
这里先不分析编程人员与测试人员的分工、合作问题，先看看编程人员除了被“测试”之外，自己有哪些方法可以提高质量。项目管理者联盟
• 第一个项目的经验项目管理者联盟文章
在第一个团队中，由于团队很年轻扩张又很快，所以推行了代码审查的方法，简单而言，就是高手/老手要看新手的代码，后期的制度则是每个人的代码必须有人看过之后，才能提交。在这些提交过程中，很多可能带来日后维护困难或缺陷的代码都被踢了回去。blog.mypm.net
在这个团队扩张的后期，这种审查制度被凝结在师徒制度中，以把原来“帮忙”做审查变成“审查义务”。这一变化的原因是中间曾经发生过一次“不负责任”的审查，造成一大段两个月的代码未经充分审查就进入代码库，酿成后来的一次现场故障。这种“不负责任”来自于本来就没有设定责任，只是帮忙，所以才发生了组织结构的变化。项目管理者联盟
在建立师徒制度后，师傅们将对小组的成败包括质量负责。实际上，新人的流动率很高，如果留下垃圾代码，还是要师傅来维护，所以师傅“被迫”很尽责。师傅们普遍的做法是不只在最后才审查代码——因为那时候肯定面临一个烂摊子——而是在前期就指导徒弟编出良好的代码，乃至在更早的时间点介入，做出良好的设计。项目管理者联盟
这些制度后来演化成松结对编程方法。training.mypm.net
• 第二个项目的经验training.mypm.net
第二个项目则是本人做度量最仔细的一个项目。
原因是在离开上一家公司后，我去了一个测试人员众多的企业，但其产品质量却奇差无比，甚至导致后来一个产品被放弃，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。
“所有缺陷无需测试活动即可消除”这句话被打上引号，是因为它是一种很理想的状态。但是与“所有缺陷可以被某种测试活动消除”相比，我更相信前者。talent.mypm.net
转自项目管理者联盟
项目管理培训
3. 编程人员可以训练出行之有效的排除缺陷的手段blog.mypm.net
“自查”的过程效益始终没有达到100%，但是它与调试的作用越来越互补。比如在初期自查+调试后，还有大量缺陷被发现(所以调试的效益很低);但如果每天仔细分析自己自查发现的缺陷和调试发现的缺陷，就可能在短短一个半月的时间内大幅度提升自身发现缺陷的能力，乃至于到达不把缺陷留给测试环节，更不会留给客户的程度。club.mypm.net
|
