【每日一学 20260817】敏捷之道——被遗漏的度量指标

2026-08-17 16:08:00
蓉蓉
原创
3

一、平衡式的度量指标

1.维度1：幸福感（幸福指数）

指标1：开发者对于工作的幸福指数
工作幸福指数越高，软件开发生产力就越高。
可以每周问每位开发者：“如果从0到10打分，你向其他开发者推荐入职我司做开发工作的可能性有多大？”

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

指标2：开发者对于会议成效的满意度
会议越有成效，沟通协作就越好，软件开发生产力就越高。
可以每周问每位开发者：“如果从0到10打分，你对本周所参与的所有会议的成效的综合满意度打几分？”


指标3：开发者对于知识获取的满意度
获取所需知识越便利，文档和知识分享质量越高，软件开发生产力就越高。
可以每周问每位开发者：“如果从0到10打分，你对本周获取知识的便利情况，以及知识质量综合满意度，分别打几分？”


指标4：开发者对于工具及工具平台的满意度
工欲善其事，必先利其器。沟通协作所需工具越趁手，软件开发生产力就越高。
可以每周问每位开发者：“如果从0到10打分，你对本周使用工具及工具平台的便利情况的综合满意度打几分？”

3.维度3：价值高（价值成效）

指标5：用户对产品的满意度
用户对产品越满意，说明软件开发生产力成效就越高。
可以每月问用户：“如果从0到10打分，你向他人推荐使用这款产品的可能性有多大？”
注意，用户在给产品的满意度打分时，需要提醒她/他，要将产品所有模块和功能，作为一个有机的整体来看待并打分。而对于产品中每个模块和功能的满意度，用户很少有时间和耐心来打分。此时我们可以用访谈或A/B测试等方式，来寻找答案。

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

指标6：生产环境业务系统部署频率
当部署与发布不分离时，生产环境业务系统部署频率越高，说明业务能更小批地部署上线，这样能更早地将业务价值交付给用户，软件开发生产力就越高。
当部署与发布分离时，生产环境业务系统部署频率越高，能间接反映自动化回归测试、特性开关、蓝绿部署等机制更强，软件开发生产力就越高。
可以每次生产环境部署时，问运维人员：“业务系统生产环境本次部署距上次部署之间的间隔时长有多长？”


指标7：生产环境用户故事交货时长
生产环境用户故事交货时长越短，可能说明用户故事拆分越合理，中间返工少，工序间等待少，软件开发生产力就越高。
可以每次投产上线后，请运维人员统计本次成功投产上线的所有用户故事的交货时长，即从提交第一行代码到代码库到成功投产上线之间的时长。


指标8：用户故事所经历的SIT（System Integration Test，系统集成测试）测试次数
开发者在修复SIT测试阶段所发现的用户故事缺陷后，还应该再次提交给QA在SIT阶段验证。用户故事所经历的SIT测试次数越少，说明该故事开卡验卡等质量内建做得好，返工少，软件开发生产力就越高。
可以在每次用户故事通过了SIT测试后，请测试人员记录该故事所经历的SIT测试次数。


指标9：并行工作数（Work-In-Progress， WIP，在制品）
开发者每日并行的工作越少，工作切换所消耗的时间就越少，软件开发生产力就越高。
可以每日在开站会时，问每位开发者：“当天手中并行安排了几个工作？”也可以在看板上，可视化每个人当日需要并行完成的工作。

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

指标10：业务系统严重故障修复时长
业务系统严重故障修复时长越短，可以间接反映生产环境系统运行观测能力越强，故障响应、切换和回滚机制越强，软件开发生产力就越高。
可以每次解决完生产环境的严重故障后，请运维人员统计修复时长，即从故障出现（而非发现）到成功修复或回滚之间的时长。


指标11：业务系统发布用户故事的严重故障率
业务系统发布用户故事的严重故障率越低，说明所发布的用户故事质量越好，软件开发生产力就越高。
可以在每次投产上线后，请运维人员统计本次投产的用户故事中无法正常使用的比例。


指标12：通过代码评审的commit（提交）比例
通过代码评审的commit比例越高，或许能反映代码质量会更好（取决于开发者的整洁代码意识和代码评审质量）。
可以在每个迭代结束前，请每位开发者统计自己提交到主干的commit中，通过代码评审的比例。


指标13：迭代回归测试用例执行率
迭代回归测试用例执行率越高，或许能反映业务系统已有功能的缺陷就越少（取决于回归测试覆盖关键业务场景的质量）。
可以在每个迭代结束前，请测试人员统计迭代实际执行的回归测试用例，占本应执行的比例。


指标14：迭代回归测试执行时长
该指标需要与“迭代回归测试用例执行率”结合起来看，当“迭代回归测试用例执行率”为100%，且使用了自动化回归测试，那么迭代回归测试执行时长越短，能间接表明软件开发生产力就越高。
可以在每个迭代结束前，请测试人员统计本迭代回归测试执行时长。

二、总结

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


来源：《敏捷之道》——被遗漏的度量指标--文/伍斌

发表评论
通过审核后显示您的意见