你的leader还在考核你的千行代码Bug率吗？

管理学大师德鲁克说：你若是你没法度量它，就没法管理它。要想作有效的管理，就很难绕开度量的问题。

软件开发的过程或者技术团队的管理也存在着如何去合理的度量效率的问题。而度量是把双刃剑，度量具备极强的引导性。度量指标会激励团队重视并改善可以度量元素，也会致使你忽视没法度量的元素，并使得问题进一步恶化。因此，选择合适的度量指标考核技术团队成员，须要慎重考虑。例如，代码行数和千行代码Bug率指标就值得商榷。

什么是千行代码Bug率

首先咱们来看一下，千行代码Bug率是怎么定义的：

千行代码Bug率 = Bug数量/ (代码行数/1000)

度量的标准：千行代码Bug率数值越小质量越好。

关于CMMI级别中和BUG率相关的信息以下：

CMMI级别	BUG率
CMM1级	11.95‰
CMM2级	5.52‰
CMM3级	2.39‰
CMM4级	0.92‰
CMM5级	0.32‰

考核千行代码Bug率的问题

从考核千行代码Bug率来看，主要存在两个方面的问题： 
首先，从考核标准上来讲，Bug率数值越小就说明越好，基于这个结果，会引导团队成员作出一些对长远和总体效率无益的行为，例如： 
1. 增大基数，增长无心义代码 
2. 把定长循环分开写，写成顺序方法 
3. 把可配置信息写死到代码中 
4. 大量的复制、粘贴代码 
5. 从新发明各类轮子

统计“千行代码Bug率”和“每日生产代码行数”同样，都是没通过大脑思考，而直接打算把优秀员工踢出团队的懒人式管理方式。特别是对从事智力型工做工程师来讲，是很不合适的考量指标。

由于优秀的程序员是经过减小代码行数来增长功能的。

千行代码Bug率，虽然没有明确鼓励增长代码行数，可是这个计算结果对于优秀的员工来讲是至关的不公平。它隐含的推广了“尽可能增大代码行数”这个意思。

其次，从考核阶段看，Bug率的数据主要产出在研发阶段的后期，及提交测试后产出bug数。从项目的研发阶段和效率价值金字塔来看，其对项目的总体质量方面更多的聚焦在微观层面问题，总体的质量的影响范围会较小。而前面几个阶段的缺陷，会影响整个项目的进度，甚至致使项目失败，管理者和团队更应该将风险控制和度量指标向前移。 

    

 

研发阶段和效率价值金字塔

 

 

如何更合理的度量质量

若是考核千行代码Bug率不能很好的解决质量核心问题，那咱们还有那些方法和方案来提升项目的总体质量呢？ 
我的以为，咱们仍是从项目的研发阶段和效率价值金字塔出发，重总体上去把控质量，上下游一体，从源头开始：

1. 需求的评审 
2. 架构设计方案评审 
3. 代码模块设计，包的依赖的规划，接口的设计的review
4. 代码的review的机制 
5. 测试用例评审
6. 使用代码检测工具，自动发现问题

 

过程评审是最有效也是成本最低的质量和效率保证和提高的手段。另外，过程评审仍是迅速提升新人能力及其成果物的规范性的一个有效手段。 
可是过程评审，也存在一些问题： 
1. 前期过分依赖于团队的人员素质 
2. 规则的定义也比较难，产出很差量化 
3. 评审耗时多 
4. 团队的意识不一致

对于过程评审的实施，最核心的统一团队意识，团队意识不一致时，效果必定很差。 意识意识不一致，在资源的投入上就会缩手缩脚；只有把过程评审作到位，才能体会到评审活动的高效，避免那种蜻蜓点水式的“评审”，是浪费时间，不是真正的评审。到位地完成评审后，会有那种对系统质量“踏实了”的感受，过程当中辅以严密的变动管理和风险控制手段，系统质量出大问题可行性会很小或者近乎为零。

系统质量是要靠上游工程作出来的，并且上游的工做质量会更为重要，上游的问题的影响范围将更广，对效率和价值的影响更大，应该是咱们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关，是十分低效，并且代价是很是昂贵的。

 

总结

想作有效的管理，就很难绕开度量的问题。在选择度量指标上，大部分管理者老是倾向于关注容易度量的指标，而忽略难以度量的指标。可是容易度量的指标不必定是重要的，难以度量的反而多是重要的。 
软件开发产出最直观的结论就是一行行代码，实际上代码行数的多少并不表明价值的多少。当考核不合理致使出现大量的复制，不合理的设计，大量的冗余，不但难以理解和维护，甚至没有实际运行起来。这样就形成大量的时间浪费，同时也形成质量的严重腐化。 
而基于全过程的评审机制和持续改进方法，能够很好的改善质量。但持续改进须要一个过程，需全团队从认知达成一致，并共享问题，统一步调和规范，持续的执行和改进。

另外，从工程师自身来讲，千行代码Bug率用来自我评估和改进，仍是颇有价值的。