dora-metrics

name	dora-metrics
description	度量项目交付效能时使用。适用于团队效能分析、季度复盘、改进决策。优先使用 Google DORA 四大指标（部署频率、前置时间、失败率、恢复时间）。

DORA 交付效能度量

参考来源：Google DORA、Accelerate

适用场景

• 团队/工作流效能度量
• 季度/年度交付能力评估
• 改进决策的数据支持
• 项目复盘时的客观指标

不适用场景

• 单个任务的成败（用 milestone-gate）
• 短期波动判断（DORA 是趋势指标）

核心原则

不只看"是否按时完成"，要看"持续交付能力"

DORA 四指标是一组：
  - 速度指标（部署频率 / 前置时间）
  - 稳定性指标（失败率 / 恢复时间）

只看速度会忽略质量
只看稳定会牺牲速度
两者必须平衡

四大核心指标

1. 部署频率（Deployment Frequency）

含义：多频繁可以把变更部署到生产环境
AI 工作流场景：每个功能模块从完成到可部署的频率

测量：
  - 每天/每周/每月部署次数
  - 单位：次/天

效能等级：
  Elite：每天多次（按需部署）
  High：每周一次到每天一次
  Medium：每月一次到每周一次
  Low：每几个月一次

目标：每个模块完成即可部署，不积压

2. 变更前置时间（Lead Time for Changes）

含义：从代码提交到部署到生产的时间
AI 工作流场景：从任务开始到交付完成的总耗时

测量：
  - commit → production 的时间分布
  - 取 median 或 p90

效能等级：
  Elite：< 1 天
  High：1 天到 1 周
  Medium：1 周到 1 个月
  Low：> 1 个月

AI 工作流目标：
  - M 级项目 < 3 小时
  - L 级 < 8 小时
  - XL 级 < 1 天

3. 变更失败率（Change Failure Rate）

含义：部署后导致问题需要紧急修复/回滚的比例
AI 工作流场景：交付后需要返工/回滚的比例

测量：
  - 失败部署数 / 总部署数 × 100%
  - 失败定义：服务降级、回滚、紧急修复

效能等级：
  Elite：0~15%
  High：16~30%
  Medium：31~45%
  Low：> 45%

目标：< 15%（门禁机制应该拦住大部分问题）

4. 恢复时间（Mean Time to Recovery / MTTR）

含义：服务出现故障到恢复正常的时间
AI 工作流场景：发现问题到修复完成的时间

测量：
  - 从故障开始到完全恢复
  - 取 median

效能等级：
  Elite：< 1 小时
  High：< 1 天
  Medium：< 1 周
  Low：> 1 周

AI 工作流目标：< 30 分钟
（AI 修复速度快，瓶颈在定位）

效能等级综合

所有 4 个指标都达标的层级：

Elite（精英）：
  部署频率：按需多次
  前置时间：< 1 天
  失败率：0~15%
  恢复时间：< 1 小时

High（高效）：
  部署频率：日均到周均
  前置时间：1 天~1 周
  失败率：16~30%
  恢复时间：< 1 天

Medium（中等）：
  部署频率：周均到月均
  前置时间：1 周~1 月
  失败率：31~45%
  恢复时间：< 1 周

Low（待改进）：
  任一指标长期处于最低层

商业影响（来自 Accelerate）：
  Elite 团队比 Low 团队：
    - 50% 高的市场资本增长
    - 2.5x 快的市场上市

数据收集

部署频率

来源：
  - CI/CD 系统（GitHub Actions / Jenkins）的部署日志
  - 容器/Kubernetes 的滚动更新记录
  - Tag/Release 记录

AI 工作流：
  - 每个功能模块完成的时间戳
  - 工作流自动汇报"我完成了 X"的时间

前置时间

来源：
  - Git commit 时间
  - PR 合并时间
  - 部署时间

AI 工作流：
  - 任务进入 in_progress 的时间
  - 任务进入 done 的时间
  - 计算差值

失败率

来源：
  - 部署失败的告警
  - 回滚记录
  - 紧急修复 commit

AI 工作流：
  - 任务进入 rework 的次数
  - 上线后的紧急修复次数

恢复时间

来源：
  - 监控告警的开始/结束时间
  - 故障单的处理时间

AI 工作流：
  - 阻塞开始/解除时间
  - 验收失败到修复完成

工作流程

1. 项目启动时：
   - 确认要追踪的指标范围
   - 设置基线（项目开始前的数据）
   - 设置目标值
   ↓
2. 项目执行中：
   - 自动收集每个事件的时间戳
   - 不打扰执行流程
   ↓
3. 项目结束：
   - 计算四大指标
   - 与基线和目标对比
   - 输出 DORA 报告
   ↓
4. 定期（季度）复盘：
   - 对比多个项目的 DORA
   - 识别改进方向
   - 制定改进措施

DORA 报告模板

## DORA 效能报告 [项目名]

### 测量周期：[开始时间] ~ [结束时间]

### 四大指标

| 指标 | 当前值 | 基线 | 目标 | 等级 | 趋势 |
|------|--------|------|------|------|------|
| 部署频率 | 5 次/天 | 1 次/天 | 5+ 次/天 | Elite | ↑↑↑ |
| 前置时间 | 2.5 小时 | 8 小时 | < 3 小时 | Elite | ↑↑ |
| 失败率 | 12% | 25% | < 15% | Elite | ↑↑ |
| 恢复时间 | 25 分钟 | 2 小时 | < 30 分钟 | Elite | ↑↑↑ |

### 整体等级：Elite

### 关键发现

- 部署频率提升 5x（自动化 CI/CD 见效）
- 前置时间从 8h 降到 2.5h（并发编排起作用）
- 失败率减半（门禁机制有效）
- 恢复时间显著下降（监控告警完善）

### 改进建议

- 部署频率已 Elite，保持
- 前置时间还有空间，可以进一步优化联调环节
- 失败率从 12% 到 < 10% 是下个目标
- 恢复时间已优秀，不需要专门优化

### 下季度目标

- 部署频率：保持 5+ 次/天
- 前置时间：< 2 小时
- 失败率：< 10%
- 恢复时间：< 20 分钟

质量自检

□ 是否四个指标都测了（不能只看部署频率）
□ 是否设置了基线（不能凭空对比）
□ 是否设置了目标值（不能"越好越好"）
□ 数据来源是否客观（不是自己估算）
□ 报告是否有趋势分析（一次数据没意义）
□ 是否提出了具体改进建议

常见坑

1. 只看速度指标——部署频率高但失败率也高，不是真效能
2. 只看稳定性指标——失败率 0% 但一年才部署一次，不是好事
3. 测量周期太短——一周数据不能下结论
4. 没有基线——不知道是进步还是退步
5. 指标 gaming——为了好看的数字牺牲实际质量
6. 不行动——测了不改进，等于没测
7. 指标用作 KPI 考核——会扭曲行为，DORA 是诊断工具不是 KPI

配套模板

• templates/dora-report-template.md — DORA 报告模板
• templates/dora-tracking-template.md — 数据追踪表模板

与其他 skill 的协作

上游：
  progress-tracking → 提供执行数据
  milestone-gate → 提供门禁通过率

平行：
  retrospective → 复盘时引用 DORA 数据

下游：
  改进决策 → 影响下个项目的 wbs / orchestration / risk