DevOps 的 4 个关键指标（4 key metrics），似乎已经成为能解释一切软件开发生产力（或研发效能）问题的“北极星”指标。
我们知道，收集每个指标的数据，都需要投入成本，所以指标不是多多益善，需要识别关键的北极星指标。另外，当北极星指标没有符合预期目标时，也需要参考其他群星指标，以便为团队提供当时的上下文，识别合理的改进时机。
比如，当生产环境某个用户故事交货时长这个北极星指标很长时，可以看看该“用户故事所经历的 SIT 测试次数”是否多，来了解这是否因为返工多导致的。如果不是，那么再看看是否用户故事拆分粒度可以优化，等等。
所以，指标数量和维度需要取得平衡，既要少到能恰好代表软件开发生产力关键要素，也要多到恰好能提供用于持续改进的上下文。为了更好地用度量驱动改进，我们需要平衡式的指标。
要设计平衡式的指标，首先要确定平衡式的指标所应涵盖的维度。
DevOps 4 个关键指标的维度
可以先看看 DevOps 的 4 个关键指标属于哪些维度，然后思考这些维度是否恰好能满足为度量驱动改进提供上下文。如果不能完全满足，再寻找被遗漏的度量维度，并设计对应的群星指标。
DevOps 的 4 个关键指标，在一定程度上，体现了“流速快”和“质量好”这两个维度。
“生产环境业务系统部署频率”和“生产环境用户故事交货时长”，体现了价值端到端流速是否快。因为前者越高，流速越快；后者越短，流速越快。
“业务系统严重故障修复时长”和“业务系统发布用户故事的严重故障率”，则体现了所交付的软件产品质量是否好。因为前者越短，用户感知的故障时长越短，质量越好；后者越低，质量越好。
被遗漏的群星指标的维度
为了找到用于提供改进上下文的群星指标，有些团队会将 DevOps 的 4 个关键指标所涵盖的“流速快”和“质量好”这两个维度的指标进行扩充，增加了诸如“迭代完成率”（流速快）、“构建时长”（流速快）、“代码重复率”（质量好）、“测试覆盖率”（质量好）等指标，作为群星指标。但增加了这些群星指标后，能否恰好代表软件开发生产力的关键要素？是否有遗漏？
我们知道，“个体与互动，高于流程和工具”，被放到了敏捷宣言的第一条。在敏捷项目中，反映个人自身的“个体”，与反映团队成员之间协作的“互动”，能否作为代表软件开发生产力的关键要素呢？当度量软件开发生产力时，有些团队是否遗漏了这两个要素及其所对应的维度？
研究显示，软件开发生产力与开发者对于工作的满意度和幸福指数高度相关（参见参考资料 2 和3）。
如果团队忽视其成员的工作“幸福感”，不仅有损生产力，还会使人离心离德，导致背叛。当下热门动漫《中国奇谭》第一集“小妖怪的夏天“钟所讲述的故事，就生动地描绘了这一场景。在“大王洞”打工的小猪妖，用伙伴乌鸦怪的羽毛制作弓箭搞技术革新，但却被熊教头看作是“无视上级”而罚去重做；被熊教头当作猪鬃刷子刷锅，导致毛发变秃；目睹了伙伴乌鸦怪因为偷看了大王布置的捉拿唐僧的陷阱，而惨遭大王毒手。这些遭遇让他完全丧失了工作的“幸福感”，最后冒着生命危险，弃暗投明，阻止了唐僧师徒四人落入大王设下的陷阱。
如何度量“个体”与“互动”呢？我们可以粗略地用开发者（本文所说的开发者，包括 Dev、QA、BA、UX、Ops 等各个角色）的工作幸福指数来度量“个体”，用会议成效、知识获取和工具便利这些有关沟通协作的指标来度量“互动”。
另外，软件开发生产力的终极目标，是满足用户价值。那么用户对产品的满意度，是不是就是有些团队所遗漏的第三个关键要素及其所对应的维度？
平衡式度量指标的 5 个维度
上面谈到的被有些团队遗漏的 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 个维度，会导致团队仅关注“流速快”和“质量好”这两个中间状态的“果”，而失去对“幸福感、协作佳”这两个“因”的关注，且失去对用户满意度这样的最终状态的“果”的关注，无法看到软件开发生产力的全貌，也就难以用度量驱动改进。
相关参考资料
-
The SPACE of Developer Productivity; March 6, 2021; https://queue.acm.org/detail.cfm?id=3454124
-
Graziotin, D.， Fagerholm, F. 2019. Happiness and the productivity of software engineers. In Rethinking Productivity in Software Engineering, ed. C. Sadowski and T. Zimmermann, 109-124. Berkeley， CA: Apress; https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_10.
-
Storey， M. A.， Zimmermann, T.， Bird, C.， Czerwonka, J.， Murphy， B.， Kalliamvakou, E. 2019. Towards a theory of software developer job satisfaction and perceived productivity. IEEE Transactions on Software Engineering; https://ieeexplore.ieee.org/document/8851296.
