混乱（Chaos）
研发过程不可见，质量不可控，结果不可测：代码上线不受控、增量手工发布、工作过程和工作量不透明、流程复杂。
Agilean 方法论 / 研发效能成熟度
DEER 研发效能提升路线图
定义
DEER（Digital Efficacy Elevation Roadmap，研发效能提升数字化路线图）是 Agilean 基于 FLEET 框架提出的研发效能提升模型。它从研发过程不可见、质量不可控、结果不可测的起点“混乱（Chaos）”出发，把效能提升分为“发布受控、基线建立、协作优化、自动守护、挑战卓越”五个关键步骤，并为每一步给出可数字化评估的核心指标和出口条件，用于评定团队研发效能成熟度、确定改进次序。
出处：《DEER：研发效能提升路线图》（）
- 英文全称
- Digital Efficacy Elevation Roadmap
- 中文名
- 研发效能提升数字化路线图
- 框架类型
- 研发效能成熟度模型 / 改进路线图
- 理论基础
- FLEET 精益效能提升思维框架
- 五个级别
- 发布受控、基线建立、协作优化、自动守护、挑战卓越
解决的问题
DEER 要解决什么问题
- FLEET 作为思考指引提出后，团队需要知道如何落地：是否存在通用的改进次序、有哪些里程碑、如何评估进展。
- 很多研发组织处于效能提升的起点，在有大量外包的项目中尤其明显：代码上线不受控、增量手工发布、工作过程和工作量不透明。
- 立项、规模评估、需求澄清、变更等流程复杂，大量时间耗费在各种沟通会上，交易成本居高不下。
组成要素
DEER 的起点与五个级别
发布受控（Versioned）
以 Git 作为唯一发布数据源，建设统一编译平台和构建、部署、分析流水线。策略“以堵为主”，堵住不经代码库发布生产的通道。
基线建立（Baselined）
代码提交写明变更编号，用看板“点亮”卡片自动计算工时；先收紧代码、再收紧变更，再用 DEF 建立时效、质量、吞吐量和流动效率基线。
协作优化（Optimized）
结合 FLEET 的整流、细粒、润滑、小批原则，细化需求颗粒度、建立需求层级，推行开发 showcase、每日代码评审和每日缺陷清零。
自动守护（Automated）
需求双向澄清与实例化需求，构建稳定的自动化回归能力，采用主干开发和全量自动发布，团队开启基于数据的自我改进。
挑战卓越（Challenged）
大多数组织目前很难达到的愿景级别：小步提交并实时评审，提升设计水平、控制质量债务，为核心代码编写单元测试。
速查
DEER 各级代表性指标（原文建议值）
| 级别 | 代表性指标 | 出口条件 / 目标 |
|---|---|---|
| 第一级 发布受控 | 服务构建自动化率；平均构建时长控制在 5 分钟内；构建成功率约 98%；85% 的构建失败在 15–30 分钟内修复 | 服务可从代码库自动构建出发布包 |
| 第二级 基线建立 | 分段需求前置时间；每天无工作任务点亮人数、无变更号代码提交数等守护指标 | 对时效、质量、吞吐量、流动效率建立基线 |
| 第三级 协作优化 | 系统任务约 10 人天、个人任务 2–3 人天；开发冒烟通过率高于 80%；每次提交平均 50 行内；代码评审率 50% | 响应速度提升 30%，质量提升 50% |
| 第四级 自动守护 | 复杂需求澄清率、架构复杂需求评审率 100%；测试案例误报率低于 2‰；核心测试案例执行时间低于 10 分钟；接口测试代码覆盖率 40% | 响应时效提升 50%，质量提升 70%，吞吐率在第三级基础上再提升 10% |
| 第五级 挑战卓越 | 每次提交 25 行内并实时评审；单元测试覆盖率 10%，综合测试覆盖率 50% | 生产质量提升 90%，吞吐率进一步提升 20% |
以上数值均为 DEER 原文给出的参考建议。原文强调，指标统计的意义在于透明瓶颈、指明改进方向，而不是成为组织的负担。
适用场景
什么时候适合使用 DEER
适合的情况
- 研发组织存在代码上线不受控、增量手工发布、外包工作量不透明等“起点”特征
- 需要评估各团队的研发效能成熟度，并确定先做什么、后做什么
- 建设 DevOps 流水线、自动化测试和效能度量时，需要分阶段的目标和出口条件
- 已用 FLEET 统一了改进思路，需要可评估的落地路线
使用边界与注意事项
- 第五级“挑战卓越”是一种愿景，大部分研发组织目前很难达到，可视为努力方向。
- 不应要求构建成功率 100%，也不应提出 100% 甚至 80% 代码覆盖率这类不切实际的要求，否则弊大于利。
- 工时不可能绝对准确，代码行也不能完全代表工作量；这些数据的价值在于为管理者的直觉提供佐证，而不是紧盯每个变化、横向对比每个团队。
框架关系
与其他 Agilean 方法框架的关系
延伸阅读
相关服务、产品、案例与延伸阅读
相关咨询与培训
- 研发效能度量体系建设指标体系与度量成熟度模型
- 精益研发流程优化
- AI 原生研发工具体系咨询DevOps 与研发协同工具链
相关工具
- 知微原文提出由知微支持 DEER 的指标统计与应用
常见问题
关于 DEER 的常见问题
DEER 是什么？
DEER（Digital Efficacy Elevation Roadmap，研发效能提升数字化路线图）是 Agilean 基于 FLEET 框架提出的研发效能提升模型，包含发布受控、基线建立、协作优化、自动守护、挑战卓越五个关键步骤，以及每个步骤的数字化评估方式。
DEER 有哪几个级别？
起点是混乱（Chaos），之后依次是第一级发布受控（Versioned）、第二级基线建立（Baselined）、第三级协作优化（Optimized）、第四级自动守护（Automated）和第五级挑战卓越（Challenged）。
为什么第一级要先做“发布受控”？
发布受控让管理者“看见”研发最重要的产出——代码，为建立基线打下基础。这一级以“堵”为主要策略，堵住不经代码库直接发布生产的通道；如果做不好，就可能出现流程摆在那里却没人执行的“两张皮”现象。
为什么 DEER 不要求构建成功率和代码覆盖率达到 100%？
构建失败并不可怕，关键是能否快速修复；要求 100% 成功反而可能让团队绕开受监控的流水线。代码覆盖率方面，100% 甚至 80% 成本过高、不可能达到，DEER 在第四级要求接口测试覆盖率 40%，第五级才提出较低的单元测试覆盖率要求。
DEER 与 FLEET、DEF 是什么关系？
FLEET 是思维框架，DEER 是基于 FLEET 的落地路线图，DEF 是 DEER 第二级用来建立时效、质量、吞吐量等数据基线的指标框架。
工时和代码行数据应该怎么用？
DEER 建议用看板“点亮”卡片自动计算工时，并结合代码行视图透视团队工作。但工时不可能绝对准确，代码行也不能完全代表工作量，这些数据应为管理者的直觉提供佐证，而不是用来紧盯每个变化或横向排名。
想判断 DEER 是否适合你们的组织？可以从一个真实问题开始讨论。