研发度量DORA+SPACE+OST 影响模型

目录

• 总结
• DORA 指标
• Space指标
• 传统指标
  • 效率
  • 质量
    • 概念解说
• 参考资料

总结

作为研发总监，建议您建立一个三层指标仪表盘：

1. 顶层（DORA + 业务结果）： 关注结果和对业务的贡献。这是您向 CEO 或董事会汇报的指标。

   • 核心 DORA 4 指标。
   • 功能发布后的业务指标 (如用户转化率/留存率提升)。

2. 中层（SPACE P, A, E）： 关注过程和效率。这是您与团队和技术负责人一起改进的指标。

   • 代码评审时长。
   • 技术债务工时比例。

3. 底层（SPACE S, C）： 关注组织健康度。这是您与 HR 和工程经理一起关注的指标。

   • 开发者满意度/NPS。
   • 团队心流状态时间。

DORA 指标

‌DevOps Research and Assessment‌
DORA指标是DevOps Research and Assessment团队提炼的，用于评估软件交付与组织绩效的核心指标，涵盖交付速度和系统稳定性两大维度，四大核心指标具体如下：

1. 部署频率（Deployment Frequency）
   该指标衡量团队向生产环境成功发布代码的频率，比如每日数次或每周数次。它体现了研发团队价值交付的节奏，高频率部署通常意味着单次发布风险更低，组织响应市场变化的能力更强。

2. 变更前置时间（Lead Time for Changes）
   指从代码提交到主干分支，再到其在生产环境中成功运行的时长。这个指标能反映代码审查、测试、部署等流程的效率，指标耗时越短，说明团队响应需求、交付功能的敏捷性越高。

3. 变更失败率（Change Failure Rate）
   即部署到生产环境的变更中，引发服务降级、中断等故障且需紧急修复（如回滚、紧急补丁）的比例。该指标直接体现团队交付代码的质量，低失败率代表研发团队能稳定输出高质量的软件服务。

4. 服务恢复时间（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）的缩写；其中每个维度都包含若干个适用于个人、团队或系统级别的不同指标。

维度	英文名称	关注重点	关键指标（结合DORA和过程）
S - 满意度与幸福感	Satisfaction and Well-being	开发者对工具、文化和工作本身的感受。	* 开发者敬业度/NPS： 通过问卷衡量对工具、流程、文化和工作负载的满意度。* 心流状态时间： 每天不受打扰的深度工作时间百分比。* 倦怠（Burnout）率/离职率： 衡量团队健康度。
P - 绩效与效能	Performance and Productivity	软件交付的结果指标。	* DORA 四指标： 部署频率、变更前置时间、变更失败率、恢复服务时间（MTTR）。* 吞吐量： 完成的用户故事数/功能点数（需标准化）。
A - 活动与流量	Activity and Flow	开发者在工作流中的行为，如代码、测试、评审等活动。	* 代码评审时长/周转率： Pull Request 从创建到合并的平均时间。* 代码提交频率： 衡量持续集成习惯和工作颗粒度。* CI/CD 失败率/构建时长： 反映反馈回路的速度。
C - 沟通与协作	Communication and Collaboration	团队间和跨团队间的协作质量。	* 会议时长/比例： 非深度工作时间占用比例。* 跨团队依赖解决时长： 解决阻塞性依赖的平均时间。* 代码拥有者（Code Ownership）健康度： 衡量知识孤岛和 bus factor。
E - 效率与控制	Efficiency and Control	开发者对工具和流程的掌控程度，减少认知负荷。	* 技术债务比例： 用于维护和重构的工时占总工时的比例。* 工具链满意度： 开发者对 IDE、CI/CD、监控工具的使用满意度。* 代码复杂度： 如圈复杂度（Cyclomatic Complexity）的平均值。

传统指标

效率

需求吞吐量

质量

• 线上缺陷密度：生产环境确认的有效缺陷数 ÷ 软件规模（常用千行代码 KLOC、功能点 FP）
• 测试缺陷密度：测试阶段发现的有效缺陷数 ÷ 软件规模（千行代码 KLOC、功能点 FP）
• 缺陷逃逸率（生产环境）： 生产环境发现的缺陷数/（测试环境发现缺陷数+生产环境缺陷数）×100% 。 阿里指标。 评估测试有效性，金融系统要求<5% 。 OPPO是5-8%
• 单元测试覆盖率
• 自动化测试覆盖率
• 单元测试覆盖率

概念解说

功能点（FP）因复杂度差异存在大小之分（如简单查询功能与复杂交易功能的 FP 值不同），直接作为缺陷密度的分母可能导致评估偏差。平衡的核心是对功能点按复杂度分级加权，让 “单位功能点” 的缺陷密度更具可比性，具体方法如下：

1. 按功能点复杂度分级定义权重
   参考国际功能点计数标准（如 IFPUG），将功能点按复杂度分为 “简单、中等、复杂” 三级，赋予不同权重（权重基于复杂度对开发 / 测试工作量的影响设定）：
   简单功能点（如基础数据查询、静态页面展示）：权重 = 1
   中等功能点（如带校验的表单提交、简单业务逻辑处理）：权重 = 2
   复杂功能点（如分布式交易、高并发数据处理）：权重 = 3

参考资料