被遗漏的度量指标

开发
度量软件开发生产力的指标维度和数量,需要取得平衡,既要少到能恰好代表软件开发生产力关键要素,也要多到恰好能提供用于持续改进的上下文。

作者 | 吾真本

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) 指标1:开发者对于工作的幸福指数。

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

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

维度2:协作佳(沟通协作)

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

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

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

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

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

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

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

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

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

维度3:价值准(价值成效)

(5) 指标5:用户对产品的满意度

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

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

维度4:流速快(价值流速)

(6) 指标6:生产环境业务系统部署频率

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

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

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

(7) 指标7:生产环境用户故事交货时长

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

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

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

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

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

(9) 指标9:并行工作数(Work-In-Progress, WIP)

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

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

维度5:质量好(过程产出)

(10) 指标10:业务系统严重故障修复时长

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

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

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

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

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

(12) 指标12:通过代码评审的commit比例

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

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

(13) 指标13:迭代回归测试案例执行率

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

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

(14) 指标14:迭代回归测试执行时长

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

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

总结

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

责任编辑:赵宁宁 来源: Thoughtworks洞见
相关推荐

2022-02-18 14:41:49

Aerakiistio指标

2015-10-08 16:23:17

2023-08-02 18:40:42

2021-09-18 16:10:48

Spring BootJava微服务

2013-07-01 09:50:24

Windows 8.1

2023-07-12 15:43:01

DevSecOps软件安全

2013-07-11 15:21:04

Windows 8.1

2022-07-08 08:47:48

CIOKPIIT

2010-08-05 16:49:09

RIP路由协议

2016-04-28 10:32:47

2010-06-22 10:05:36

Linux监控

2011-07-04 09:43:05

Office 365云计算微软

2009-02-09 14:04:01

2021-01-05 18:46:45

物联网物联网安全

2021-12-29 17:24:16

Kubernetes集群事件

2022-12-09 11:23:21

2021-06-25 15:53:25

Kubernetes程序技巧

2009-03-16 10:11:16

度量基线自我监控设置

2016-11-04 23:45:12

云安全信息安全

2023-06-08 14:46:39

点赞
收藏

51CTO技术栈公众号