- 总结
- DORA 指标
- Space指标
- 传统指标
- 参考资料
总结
作为研发总监，建议您建立一个三层指标仪表盘：
-
顶层（DORA + 业务结果）： 关注结果和对业务的贡献。这是您向 CEO 或董事会汇报的指标。
- 核心 DORA 4 指标。
- 功能发布后的业务指标 (如用户转化率/留存率提升)。
-
中层（SPACE P, A, E）： 关注过程和效率。这是您与团队和技术负责人一起改进的指标。
- 代码评审时长。
- 技术债务工时比例。
-
底层（SPACE S, C）： 关注组织健康度。这是您与 HR 和工程经理一起关注的指标。
- 开发者满意度/NPS。
- 团队心流状态时间。
DORA 指标
DevOps Research and Assessment
DORA指标是DevOps Research and Assessment团队提炼的，用于评估软件交付与组织绩效的核心指标，涵盖交付速度和系统稳定性两大维度，四大核心指标具体如下：
-
部署频率（Deployment Frequency）
该指标衡量团队向生产环境成功发布代码的频率，比如每日数次或每周数次。它体现了研发团队价值交付的节奏，高频率部署通常意味着单次发布风险更低，组织响应市场变化的能力更强。 -
变更前置时间（Lead Time for Changes）
指从代码提交到主干分支，再到其在生产环境中成功运行的时长。这个指标能反映代码审查、测试、部署等流程的效率，指标耗时越短，说明团队响应需求、交付功能的敏捷性越高。 -
变更失败率（Change Failure Rate）
即部署到生产环境的变更中，引发服务降级、中断等故障且需紧急修复（如回滚、紧急补丁）的比例。该指标直接体现团队交付代码的质量，低失败率代表研发团队能稳定输出高质量的软件服务。 -
服务恢复时间（Mean Time to Restore Service，MTTR）
指生产环境出现故障后，服务恢复至正常状态的平均时间。它考验团队对故障的监控、定位、诊断和解决能力，较短的恢复时间可有效降低故障对业务和用户的影响，保障业务连续性。
| 指标 | 精英（Elite） | 高效能（High） | 中等效能（Medium） | 低效能（Low） |
|---|---|---|---|---|
| 部署频率（Deployment Frequency） | 按需部署或每日多次 | 每日一次至每周一次 | 每周一次至每月一次 | 每月少于一次 |
| 变更前置时间（Lead Time for Changes） | 少于1小时 | 1天至1周 | 1周至1个月 | 超过1个月（部分标准为超过6个月） |
| 变更失败率（Change Failure Rate） | 0%-15% | 16%-30% | 31%-45% | 46%-60% |
| 服务恢复时间（MTTR） | 少于1小时 | 少于1天 | 1天至1周 | 超过6个月 |
Space指标
SPACE 指标由 GitHub 和 Microsoft Research 提出，用于增强 DORA 指标。SPACE 是满意度（Satisfaction）、绩效（Performance）、活动（Activity）、沟通（Communication）和效率（Efficiency）的缩写；其中每个维度都包含若干个适用于个人、团队或系统级别的不同指标。
传统指标
单元测试覆盖率