--- title: "DEER 研发效能提升路线图" url: https://www.agilean.cn/methodology/deer-rd-efficacy-roadmap/ updated: 2026-10-07 description: "DEER 是 Agilean 基于 FLEET 提出的研发效能提升数字化路线图，从混乱起点经发布受控、基线建立、协作优化、自动守护到挑战卓越五级进阶，每级给出核心指标和出口条件，用于评估团队成熟度、确定改进次序。" publisher: "Agilean（爱捷软件开发（深圳）有限公司）" language: zh-CN --- [Agilean 方法论](https://www.agilean.cn/methodology/) / 研发效能成熟度 # DEER 研发效能提升路线图 定义 DEER（Digital Efficacy Elevation Roadmap，研发效能提升数字化路线图）是 Agilean 基于 FLEET 框架提出的研发效能提升模型。它从研发过程不可见、质量不可控、结果不可测的起点“混乱（Chaos）”出发，把效能提升分为“发布受控、基线建立、协作优化、自动守护、挑战卓越”五个关键步骤，并为每一步给出可数字化评估的核心指标和出口条件，用于评定团队研发效能成熟度、确定改进次序。 更新于 2026-10-07 出处： [《DEER：研发效能提升路线图》](https://www.agilean.cn/insights-new/45/) （本站收录于 2022-04-19） **英文全称** Digital Efficacy Elevation Roadmap **中文名** 研发效能提升数字化路线图 **框架类型** 研发效能成熟度模型 / 改进路线图 **理论基础** FLEET 精益效能提升思维框架 **五个级别** 发布受控、基线建立、协作优化、自动守护、挑战卓越 解决的问题 ## DEER 要解决什么问题 - FLEET 作为思考指引提出后，团队需要知道如何落地：是否存在通用的改进次序、有哪些里程碑、如何评估进展。 - 很多研发组织处于效能提升的起点，在有大量外包的项目中尤其明显：代码上线不受控、增量手工发布、工作过程和工作量不透明。 - 立项、规模评估、需求澄清、变更等流程复杂，大量时间耗费在各种沟通会上，交易成本居高不下。 组成要素 ## DEER 的起点与五个级别 起点 ### 混乱（Chaos） 研发过程不可见，质量不可控，结果不可测：代码上线不受控、增量手工发布、工作过程和工作量不透明、流程复杂。 第一级 ### 发布受控（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 方法框架的关系 - [精益研发 / 研发效能](https://www.agilean.cn/methodology/fleet-lean-efficacy-framework/)：FLEET 精益效能提升思维框架；DEER 是 FLEET 的落地路线图：FLEET 给出改进思路，DEER 给出改进次序、里程碑和评估方式。 - [研发效能度量](https://www.agilean.cn/methodology/def-rd-performance-metrics/)：DEF 研发绩效指标框架（多快好赞）；DEER 第二级“基线建立”使用 DEF 研发效能框架建立数据基线，后续各级以这些指标衡量改进效果。 延伸阅读 ## 相关服务、产品、案例与延伸阅读 ### 相关咨询与培训 - [研发效能度量体系建设](https://www.agilean.cn/consulting-service/rd-effectiveness-measurement/) 指标体系与度量成熟度模型 - [精益研发流程优化](https://www.agilean.cn/consulting-service/lean-rd-process/) - [AI 原生研发工具体系咨询](https://www.agilean.cn/consulting-service/ai-rd-toolchain/) DevOps 与研发协同工具链 ### 相关工具 - [知微](https://www.agilean.cn/product/zhiwei/) 原文提出由知微支持 DEER 的指标统计与应用 ### 相关洞见 - [DEER：研发效能提升路线图（原文）](https://www.agilean.cn/insights-new/45/) - [研发效能度量的两大法宝、四大法门和七种武器](https://www.agilean.cn/insights-new/105/) - [提升代码质量：代码检查工具规模化使用实践](https://www.agilean.cn/insights-new/88/) - [9个从零开始的B端产品自动化测试实践](https://www.agilean.cn/insights-new/57/) - [从测试本质看质量](https://www.agilean.cn/insights-new/83/) 问答指南 ## 相关问答指南 - [研发效能怎么度量？](https://www.agilean.cn/guides/how-to-measure-rd-effectiveness/) - [金融行业研发效能咨询做什么？](https://www.agilean.cn/guides/financial-rd-effectiveness-consulting/) 常见问题 ## 关于 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 是否适合你们的组织？可以从一个真实问题开始讨论。 [联系 Agilean](https://www.agilean.cn/contact/) [查看全部方法框架](https://www.agilean.cn/methodology/) --- 来源：[DEER 研发效能提升路线图](https://www.agilean.cn/methodology/deer-rd-efficacy-roadmap/)（更新于 2026-10-07）