研发效能度量不要“你觉得”，而要这样的度量指标体系！

我们熟知的敏捷开发方法已经诞生了二十年，DevOps 也已经发展了十多年，很多企业对其进行了引入、落地和实践。

有些组织或者团队在消耗了大量的“变革”时间、投入了大量的人力资源和成本后，却无法有效回答一些看似非常基本的问题，比如：

• 你们的研发效能到底怎么样？可否量化？

• 你们比所在行业的平均水平、别的公司、别的团队好还是差？

• 研发效能的瓶颈点和问题是什么？

• 在采纳了敏捷或 DevOps 实践之后，有没有效果？有没有实质上的提升？

• 你们下一步应该采取什么样的行动，以继续优化效能？

这就是我们需要进行研发效能度量的原因。

研发效能度量可以让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能，而不是总凭直觉感性地说“我觉得……”。

“度量”这件事情操作起来不仅困难，而且稍不留神就可能会跑偏，结果经常是不但没有带来所预期的、对效能提升的正面引导作用，反而带来严重的副作用，让企业在消耗大量时间和资源的情况下，进行了一场看似轰轰烈烈却没有价值的数字游戏，或者进行了一场看似决策正确却让员工变得更加“内卷”的无效运动。

我们可以通过设计一套能够客观量化研发效能的指标体系，对各个指标数据进行采集与综合分析，从而客观反映研发团队“更高效、更高质量、更可靠、可持续地交付更优的业务价值”的能力，发现研发过程中的改进项并指导团队进行改进。

1

度量框架

在由中关村智联软件服务业质量创新联盟、中国软件协会过程改进分会发起的《软件研发效能度量规范》标准中提出了如下框架。

其中最重要的三个要素：对目标的共识、对现状的认知和从现状到目标的路径分别用三个“E”、一个“C”和一个“I”来代表。

E3CI 框架可以被抽象为简洁的公式：效能=认知+改进。

为了达到研发效能的目标，需要对团队研发效能的现状有清楚的认识，并提升团队对研发效能的认知。我们总结了研发效能度量包含的五个认知域：

• 交付价值：认知软件研发交付需求对用户或业务带来的效果。

• 交付速率：认知软件研发交付需求的快慢。

• 交付质量：认知软件研发交付需求的好坏。

• 交付能力：认知软件研发交付需求的可持续性。

• 交付成本：认知软件研发交付需求的开销。

在认知的基础上，需要通过改进达成效能目标。改进的过程可以总结为 MARI 循环，即度量（Measure）-分析（Analyze）-回顾（Review）-改进（Improve），如下图。

上述步骤共同组成一轮完整的优化迭代。在大部分情况下，问题改进需要经历多个迭代，持续度量改进效果，不断校准改进的方向和方法。

2

度量指标体系

▊ 指标设计原则

• 全局最优，而不是局部最优。

• 指标服务于度量目标：OKR（Objectives and Key Results，目标与关键结果）-指标定义（逐步拆解）。

• 如果指标不反映问题或无法指导改进，那就没必要存在。

• 分层级从三个层面设计：结果指标（高层关注）- 过程指标（中层关注）- 操作指标（一线团队关注）。

▊ 指标设计思路与建议

重点讨论 3 个关键维度：交付价值、交付质量与交付速率，效能指标体系架构图如下。

▊ 某互联网企业的效能指标体系

如下为该企业效能指标体系图，其包括 12 个维度的 100 多个指标。

设计思路：遵循持续交付的理念，对组织管理机制、软件系统架构与软件基础设施建设三个方面进行度量，针对需求、代码、环境、制品等提出了详细的度量指标，改进对象包括产品团队、开发团队、测试团队及运维团队。

优势：覆盖维度特别广，几乎涵盖了软件研发的各个层面，可以全方位推动研发底层能力的改革。此外，其不仅对最终结果指标有要求，同时也聚焦一线操作，用于指导一线人员实践。

不足：部分维度指标选择不合理，如自动化测试维度追求代码覆盖率，但未综合考虑自动化拦截问题的能力。因此，在实践上可能会出现“为了追求覆盖率，对非活跃但很好写测试用例的代码进行自动化补充”“代码覆盖率很高但实际拦截问题很弱的自动化手段”，这样违背初衷的情况。

指标太多且层次不明显，结果指标、过程指标与操作指标没有很好地区分。

在实际执行过程中，容易形成过于关注“操作层面达标”，而忽视“结果指标”。因为操作指标达标并不代表团队研发效能水平达标，前者并非后者的充分条件，也因此容易引发各角色之间的相互“甩锅”。

3

效能分析

▊ 效能分析模型

效能分析模型是如何对效能问题进行分析的一系列方法论的表达，如下。

定性分析——利用效能判定表，判定度量周期内效能是否有提升。

定量分析——如果效能有提升，则利用下面推荐的分析方法找到所采用措施的优化效果；如果效能有下降或者持平，则利用各类分析方法找到问题所在，规划下一步改进措施。

✸ 效能诊断分析

有效的研发效能提升可以被拆分为 3 个目标：

• 在不降低交付质量的前提下，增加单位研发成本的交付价值。在仅考虑人力成本的情况下，简单可以理解为“需求吞吐量/人力”。

• 在不降低交付质量和需求吞吐量的前提下，降低单位交付价值的交付时长，即降低需求交付周期和线上问题修复时长。

• 在保持单位研发成本交付价值不变的情况下，提升交付质量。

根据以上拆解，可以形成“研发效能提升是否有效”的简单判定表，如下。

✸ 趋势分析

如下是某业务线上缺陷修复时长在 2021 年 1 月～2021 年 10 月的趋势图。

从 2021 年 2 月～2021 年 6 月之间，线上缺陷修复时长随着时间的推移，持续处于上升趋势，即缺陷修复越来越慢。

其实，在进行度量分析之前，客服团队曾说过他们主观感觉到最近线上问题的解决速度变慢，因为他们需要不停地推进和询问问题解决进展，给客服工作带来了难度。还可以看出客观数据与客服团队的主观感受是一致的。最后经过系统的问题分析，团队从 7 月开始进行了干预与改进优化，也可以明显看到线上缺陷修复时长持续下降。

▊ 效能优化/问题分析

在做效能分析汇报时，我们常常遇到给出了效能提升目标达成或未达成的结论性判断，但无法非常自信地给出变化产生的具体原因的情况，这时就可以利用常见的效能优化/问题分析方法有逻辑树分析、下钻分析和相关性分析对数据进行深入挖掘。

✸ 逻辑树分析

我们常常使用“鱼骨图”来辅助进行逻辑树分析。如下是针对“需求交付周期上升”的一个拆解分析过程，将“需求交付周期”映射到相关联的各项过程指标中去。

✸ 下钻分析

常见的效能下钻分析包括以下几点。

（1）按时间维度下钻（针对价值类与质量类指标）。

（2）按研发阶段下钻（针对交付周期类指标）。

（3）按任务类型下钻（针对价值类与质量类指标）。

✸ 相关性分析

研发效能受到很多因素的影响，各个因素之间往往并不是因果关系。

例如，代码提交量、提交频率与部署频率之间的关系，部署频率与客户满意度之间的关系，代码行数和代码质量的关系大小，以及代码质量的好坏与团队稳定性是否存在着某种联系等，这些都是“相关性分析”需要回答的问题。

我们可以先针对大量的历史数据分析这种相关性，然后通过实验的方式进行探索，找到能够切实驱动效能提升的因素并进行持续干预。

除此之外，还要进行度量平台的建设、专项度量分析等，更多内容请参见《软件研发效能权威指南》一书，本书由茹炳晟和张乐领衔主编，48 位领域专家共同编写。

在数字化时代，每一家公司都是信息技术公司，研发效能已经成为它们的核心竞争力。通过正确的效能度量方法，坚持数据驱动和实验性的精神，可以让研发效能可量化、可分析、可提升。

软件研发效能二维码.png

扫码查看本书详情

软件研发效能二维码.png

比双 11 更便宜

不仅直接 5 折

现在预订尾款再减 5 块

史低千万别错过！

快快扫码抢购吧！