如果代码行数不是一个好指标，应该用什么度量研发工作？

利用单一指标度量研发产出往往不是一个好主意，例如代码行数、提交数、缺陷数等等，它们往往存在容易注水、远离实际价值交付的问题（所谓的代理指标）。所以建立一套复合的指标是比较好的做法。

建立复合指标的第一步是找到基础的指标数据，包括以下几个类别：

• 基础的代码产出数据，这类数据可以从源代码管理协作平台中提取。在代码产出方面，代码行数的确不是一个好的指标——容易注水、稳定性差。这里极力推荐思码逸代码分析系统的代码当量，基于源代码的提交进行了代码工作量的提纯，有效克服了代码行数的缺点，能提供一个客观、稳定很多的基础指标。如果你有现有的基于代码行数的指标，可以将其替换为代码当量。

• 基础的交付产出数据，这类数据可以从需求管理系统（如 JIRA）中提取，包括故事点数、周期时间（故事从一个状态转移到另一个状态的时间开销）、燃尽图等。

• 基础的质量数据，这里数据从需求管理系统、测试管理系统、客户支持系统等获得，包括缺陷数量、测试覆盖率、测试成功率、缺陷逃逸数量、客户报告问题数量等。

• 基础的部署或发布数据，可以从变更系统、CI/CD 流水线系统中获得，例如构建时长、流水线执行时长等。

• 如果是线上系统的话，还需要从监控系统获取服务状态的数据。

接下来，在基础数据之上引入不同数据的关联。例如，将代码产出和缺陷数量关联计算出缺陷密度，将缺陷数量和客户报告的问题关联为缺陷逃逸率等等，通过这种方法来形成各种复合指标，可以涵盖以下几个类别：

• 代码产出：人均代码当量，代码审核时间等。

• 质量：测试通过率、缺陷密度、缺陷逃逸率、服务可用性、客户满意度等。

• 部署（适用于 Web/SaaS）：部署频率、部署前置时间、部署失败率、部署恢复时间等。

• 研发过程：需求前置时间、需求吞吐量、平均周期时间、按时交付率等。

随后，我们可以在不同层面进行数据聚合和观测，包括团队、版本、项目、部门、地域、工作年限等等。有几点建议：

• 研发产出的指标的作用是辅助决策，指标要稳定、可预测、可解释，要时刻关注指标的有效性，及时迭代；

• 尽量避免对个人的评估，最小以团队为单元；

• 勿盲目追求研发产出的增长，可持续发展最重要。

本文整理自《研发效能100问》，原作者：  管俊 戴尔中国 卓越研发集团 DevOps 架构师