衡量交付系统

从需要作出的决定开始

团队想知道 AI 是否改善交付。计算生成行数回答的是另一个问题。选择指标前，先定义有用结果和质量条件。

对于虚构导出服务，目标是以更少总投入，可靠交付已接受的修改。记录准备、实现、审查、修正和等待，也纳入失败或放弃的变更。

选择边界清楚的单个服务。把实验网站与关键付款服务混在一起，可能得到一个对两者都没有解释力的数字。比较不同时期或团队前，先描述背景。

使用当前定义

DORA 当前交付模型包含五项指标。它们衡量交付表现，不是每项功能的价值，也不是个人贡献。参见 DORA 指标定义。

仪表板可能采用其他定义，解读结果前应先阅读。Taiga 当前部署文档说明了基于提供方部署记录报告的四项指标。其中恢复指标使用后续成功部署作为依据，并不是所有生产事件的完整记录。参见 Taiga 定义。

检查虚构变更序列

假设某服务一个月部署十二次，其中八次交付计划变更，四次修复早期发布的问题。总数是十二次，但组成也很重要。

下个月，团队部署十次，其中九次是计划变更，一次是修复。部署减少，也可能伴随更多有用工作。这些数字用于说明如何解读，不是绩效基准。

也要检查分布。一次很长的审查等待，可能被平均值掩盖。单次故障的恢复指标，不足以有力预测未来可靠性。报告观察次数和重要例外。

将流程与后果一起衡量

用服务信号检查交付变化是否影响用户。如果导出更频繁地失败，流水线更快并不够。采用合适的 SLO，或其他定义清楚的结果指标。参见 SLO 指南。

审查投入和返工有助于解释结果。如果 AI 缩短实现，却生成庞大 diff，审查可能成为瓶颈。如果获取环境需要数天，编码更快可能对交付总历时影响很小。

针对观察到的约束选择一项改进，例如提供受支持的测试环境，或缩小修改规模。定义质量制衡指标，让团队能够发现因检查变弱而产生的表面提速。

让测量有用

避免根据 PR 数量或生成代码给个人排名。这些指标可能鼓励人为拆分工作、回避困难维护，或把审查投入转移给同事。

与负责完整服务的人一起复核结果。记录工具、工作组成、团队和环境发生了什么变化。将前后比较视为有局限的证据，不要自动当作因果证明。

目的是作出更好的下一步决定。能够促成已验证改进的小规模可信测量，比没有共同定义的大型仪表板更有用。

用十项变更练习

下面是另一份独立的虚构数据集，记录十项计划变更。所有时间均为所示日期的 UTC 时间。修正字段为空，表示该数据集中没有记录修正。

比较代码就绪到开始审查的时间，再比较接受到发布的时间。找出最长的可见等待。认定它可以避免之前，先调查原因。这些时间戳不衡量实际工作投入，也不说明事件何时开始。仅凭修复版本发布，不能确定失败部署恢复时间。

下载虚构数据集（CSV）