被遗漏的度量指标

DevOps的4个关键指标，似乎已经成为能解释一切软件开发生产力（或研发效能）问题的“北极星”指标。

我们知道，收集每个指标的数据，都需要投入成本，所以指标不是多多益善，需要识别关键的北极星指标。另外，当北极星指标没有符合预期目标时，也需要参考其他群星指标，以便为团队提供当时的上下文，识别合理的改进时机（后文“识别度量数据发出的改进信号”会详细讨论如如何通过度量数据，识别改进时机）。比如，当生产环境某个用户故事交货时长这个北极星指标很长时，可以看看该“用户故事所经历的SIT测试次数”是否多，来了解这是否因为返工多导致的。如果不是，那么再看看是否用户故事拆分粒度可以优化，等等。所以，指标数量和维度需要取得平衡，既要少到能恰好代表软件开发生产力关键要素，也要多到恰好能提供用于持续改进的上下文。为了更好地用度量驱动改进，我们需要平衡式的指标。

如果把DevOps的4个关键指标当作北极星指标，那么这4个指标属于哪些维度？这些维度是否恰好能满足为度量驱动改进提供上下文，从而设计群星指标？

DevOps的4个关键指标，在一定程度上，体现了“流速快”和“质量好”这两个维度。即“生产环境业务系统部署频率”和“生产环境用户故事交货时长”，体现了价值端到端流速是否快。因为前者越高，流速越快；后者越短，流速越快。而“业务系统严重故障修复时长”和“业务系统发布用户故事的严重故障率”，则体现了所交付的软件产品质量是否好。因为前者越短，用户感知的故障时长越短，质量越好；后者越低，质量越好。

为了找到用于提供改进上下文的群星指标，有些团队会将DevOps的4个关键指标所涵盖的“流速快”和“质量好”这两个维度的指标进行扩充，增加了诸如“迭代完成率”（流速快）、“构建时长”（流速快）、“代码重复率”（质量好）、“测试覆盖率”（质量好）等指标，作为群星指标。但增加了这些群星指标后，能否恰好代表软件开发生产力的关键要素？是否有遗漏？

我们知道，“个体与互动，高于流程和工具”，被放到了敏捷宣言的第一条。在敏捷项目中，“个体”与“互动”，能否作为代表软件开发生产力的关键要素呢？当度量软件开发生产力时，有些团队是否遗漏了这两个关键要素？

研究显示，软件开发生产力与开发者对于工作的满意度和幸福指数高度相关（参见参考资料2和3）。

如何度量“个体”与“互动”呢？我们可以粗略地用开发者（本文所说的开发者，包括Dev、QA、BA、UX、Ops等各个角色）的工作幸福指数来度量“个体”，用会议成效、知识获取和工具便利这些有关沟通协作的指标来度量“互动”。

另外，软件开发生产力的终极目标，是满足用户价值。那么用户对产品的满意度，是不是就是有些团队所遗漏的第三个关键要素？

上面谈到的被有些团队遗漏的3个关键要素，在GitHub、加拿大维多利亚大学和微软研究院于2021年所联合撰写的文章The SPACE of Developer Productivity（八叉推荐，参见参考资料1）中获得了印证。

这篇文章中所提到的SPACE，代表度量软件开发生产力的5个维度——Satisfaction & well-being, Performance, Activity, Communication & collaboration, Efficiency & flow。这5个维度，大致可以一一对应到本文所提到的下面5个度量维度——工作爽（幸福指数，Satisfaction & well-being）、协作佳（沟通协作，Communication & collaboration）、价值准（价值成效，Performance）、流速快（价值流速，Efficiency & flow）、质量好（过程产出，Activity）。

从下图中能够看出，如果仅局限于DevOps的4个关键指标所涉及的那2个维度，来设计群星指标，那么就会将“工作爽、协作佳和价值准”这3个重要的维度遗漏掉。为什么这3个维度很重要？因为团队所交付的软件产品，是要靠人这个“个体”，以及个体之间的“互动”来交付的。如果把DevOps的4个关键指标所涉及的“流速快”和“质量好”看作某种中间状态的“果”，那么“个体”所对应的“工作爽”，以及“互动”所对应的“协作佳”这两个维度，就是“因”。没有“因”，哪来“果”呢？虽然在项目的中后期，“工作爽、协作佳”可以与“流速快、质量好”互为因果，但在项目的初期，我们是可以通过规划，让“工作爽、协作佳”成为“因”的。最后那个“价值准”维度，是所有4个维度的最终状态的“果”，更值得我们关注。本着以终为始的原则，我们应该在关注“流速快、质量好”这两个维度之前，先关注“价值准”。

软件开发生产力平衡式度量维度之间的关系

本文的目的，就是要找回这3个被遗漏的度量维度，并补充其他维度的一些重要的度量指标，从而获得一份平衡式的度量维度和指标，进而便于敏捷团队通过度量驱动改进。注意，下面的5个指标维度，相对完整。但每个维度下的指标，并没有包括全部指标，团队需要根据自身实际情况，进行取舍。

平衡式的度量指标

维度1：工作爽（幸福指数）

指标1：开发者对于工作的幸福指数。

工作幸福指数越高，软件开发生产力就越高。

可以每周问每位开发者：“如果从0到10打分，你向其他开发者推荐入职我司做开发工作的可能性有多大？”

维度2：协作佳（沟通协作）

指标2：开发者对于会议成效的满意度。

会议越有成效，沟通协作就越好，软件开发生产力就越高。

可以每周问每位开发者：“如果从0到10打分，你对本周所参与的所有会议的成效的综合满意度打几分？”

指标3：开发者对于知识获取的满意度

获取所需知识（包括文档质量和知识分享）越便利，软件开发生产力就越高。

可以每周问每位开发者：“如果从0到10打分，你对本周获取知识的便利情况（包括文档质量和知识分享）的综合满意度打几分？”

指标4：开发者对于工具及工具平台的满意度

工欲善其事，必先利其器。沟通协作所需工具越趁手，软件开发生产力就越高。

可以每周问每位开发者：“如果从0到10打分，你对本周使用工具及工具平台的便利情况的综合满意度打几分？”

维度3：价值准（价值成效）

指标5：用户对产品的满意度

用户对产品越满意，说明软件开发生产力成效就越高。

可以每月问用户代表：“如果从0到10打分，你向他人推荐使用这款产品的可能性有多大？”

维度4：流速快（价值流速）

指标6：生产环境业务系统部署频率

当部署与发布不分离时，生产环境业务系统部署频率越高，说明业务能更小批地部署上线，这样能更早地将业务价值交付给用户，软件开发生产力就越高。

当部署与发布分离时，生产环境业务系统部署频率越高，能间接反映自动化回归测试、特性开关、蓝绿部署等机制更强，软件开发生产力就越高。

可以每次生产环境部署时，问运维人员：“业务系统生产环境本次部署距上次部署之间的间隔时长有多长？”

指标7：生产环境用户故事交货时长

生产环境用户故事交货时长越短，说明用户故事拆分越合理，中间返工少，工序间等待少，软件开发生产力就越高。

可以每次投产上线后，请运维人员统计本次成功投产上线的所有用户故事的交货时长，即从提交第一行代码到代码库到成功投产上线之间的时长。

指标8：用户故事所经历的SIT测试次数

开发者在修复SIT测试阶段所发现的用户故事缺陷后，还应该再次提交给QA在SIT阶段验证。用户故事所经历的SIT测试次数越少，说明该故事开卡验卡等质量内建做得好，返工少，软件开发生产力就越高。

可以在每次用户故事通过了SIT测试后，请测试人员记录该故事所经历的SIT测试次数。

指标9：并行工作数（Work-In-Progress, WIP）

开发者每日并行的工作越少，工作切换所消耗的时间就越少，软件开发生产力就越高。

可以每日问每位开发者：“当天手中并行安排了几个工作？”

维度5：质量好（过程产出）

指标10：业务系统严重故障修复时长

业务系统严重故障修复时长越短，可以间接反映生产环境系统运行观测能力越强，故障响应、切换和回滚机制越强，软件开发生产力就越高。

可以每次解决完生产环境的严重故障后，请运维人员统计修复时长，即从故障出现（而非发现）到成功修复或回滚之间的时长。

指标11：业务系统发布用户故事的严重故障率

业务系统发布用户故事的严重故障率越低，说明所发布的用户故事质量越好，软件开发生产力就越高。

可以在每次投产上线后，请运维人员统计本次投产的用户故事中无法正常使用的比例。

指标12：通过代码评审的commit比例

通过代码评审的commit比例越高，或许能反映代码质量会更好（取决于开发者的整洁代码意识和代码评审质量）。

可以在每个迭代结束前，请每位开发者统计自己提交到主干的commit中，通过代码评审的比例。

指标13：迭代回归测试案例执行率

迭代回归测试案例执行率越高，或许能反映业务系统已有功能的缺陷就越少（取决于回归测试覆盖关键业务场景的质量）。

可以在每个迭代结束前，请测试人员统计迭代实际执行的回归测试案例，占本应执行的比例。

指标14：迭代回归测试执行时长

该指标需要与“迭代回归测试案例执行率”结合起来看，当“迭代回归测试案例执行率”为100%，且使用了自动化回归测试，那么迭代回归测试执行时长越短，能间接表明软件开发生产力就越高。

可以在每个迭代结束前，请测试人员统计本迭代回归测试执行时长。

总结

度量软件开发生产力的指标维度和数量，需要取得平衡，既要少到能恰好代表软件开发生产力关键要素，也要多到恰好能提供用于持续改进的上下文。只使用DevOps的4个关键指标，而忽视“工作爽、协作佳和价值准”这3个维度，会导致团队仅关注“流速快”和“质量好”这两个中间状态的“果”，而失去对“工作爽、协作佳”这两个“因”的关注，且失去对用户满意度这样的最终状态的“果”的关注，无法看到软件开发生产力的全貌，也就难以用度量驱动改进。