管理学大师德鲁克说：你如果你无法度量它，就无法管理它。要想做有效的管理，就很难绕开度量的问题。所以，选择合适的度量指标考核技术团队成员，需要慎重考虑。
例如，代码行数和千行代码Bug率指标就值得商榷。
什么是千行代码Bug率？
千行代码Bug率= Bug数量/ (代码行数/1000) ，千行代码Bug率数值越小质量越好。
CMMI级别对应的BUG率：CMMI1~5 →11.95‰ 、5.52‰、 2.39‰ 、0.92‰、0.32‰
千行代码Bug率的无效性体现在哪里？
首先，统计“千行代码Bug率”和“每日生产代码行数”一样，都是没经过大脑思考，而直接打算把优秀员工踢出团队的懒人式管理方式。特别是对从事智力型工作工程师来说，是很不合适的考量指标。因为优秀的程序员是通过减少代码行数来增加功能的。千行代码Bug率，虽然没有明确鼓励增加代码行数，但是这个计算结果对于优秀的员工来说是相当的不公平。它隐含的推广了“尽量增大代码行数”这个意思。
其次，系统质量是要靠上游工程做出来的，而且上游的工作质量会更为重要，上游的问题的影响范围将更广，对效率和价值的影响更大，应该是我们重点关注的地方。仅仅依赖下游工程(研发阶段的后期的种种测试)来把质量关，是十分低效，而且代价是非常昂贵的。从项目的研发阶段和效率价值金字塔来看，前面几个阶段的缺陷，会影响整个项目的进度，甚至导致项目失败，管理者和团队更应该将风险控制和度量指标向前移。
研发阶段和效率价值金字塔
如何更合理的把控软件质量？
软件开发产出最直观的结论就是一行行代码，实际上代码行数的多少并不代表价值的多少。当考核不合理导致出现大量的复制，不合理的设计，大量的冗余，不但难以理解和维护，甚至没有实际运行起来。这样就造成大量的时间浪费，同时也造成质量的严重腐化。
如果考核千行代码Bug率不能很好的解决质量核心问题，那我们还有那些方法和方案来提高项目的整体质量呢？个人觉得，我们还是从项目的研发阶段和效率价值金字塔出发，重整体上去把控质量，上下游一体，从源头开始：
1. 需求的评审
2. 架构设计方案评审
3. 代码模块设计，包的依赖的规划，接口的设计的review
4. 代码的review的机制
5. 测试用例评审
6. 使用代码检测工具，自动发现问题
磨合的过程，存在哪些问题？
过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外，过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。 但是过程评审，也存在一些问题：
1. 前期过度依赖于团队的人员素质
2. 规则的定义也比较难，产出不好量化
3. 评审耗时多
4. 团队的意识不一致
而基于全过程的评审机制和持续改进方法，可以很好的改善质量。但持续改进需要一个过程，需全团队从认知达成一致，并共享问题，统一步调和规范，持续的执行和改进。
引自：http://www.cnblogs.com/peida/p/8315677.html
网友评论