如何从混乱到卓越：团队研发效能提升路线图

FLEET 效能提升框架提出后，引发了很多读者的共鸣。有朋友关心，作为思考指引，FLEET 框架该如何落地？是否存在通用的改进次序？有没有一些重要的里程碑节点？应用过程中，如何评估团队的进展？因此，本篇将分享 Agilean 基于 FLEET 框架的一套研发效能提升模型，我们将之称为 DEER 研发效能提升数字化路线图（Digital Efficacy Elevation Roadmap），里面包括5个关键步骤，以及每个步骤的数字化评估方式。

DEER 是一套可以实现自动打分、评定团队研发成熟度的智能模型，本篇将对该模型进行纲领性介绍 。您也可以关注 Agilean 公众号，回复 DEER 获得模型高清图解。为了便于其在企业落地，我们自研的数字化管理工具「知微」将实现对 DEER 应用侧的全面支持。

起点：混乱（Chaos）

不受控，不透明

混乱，失控，观察与真实状况之间萦绕着迷障——这是 DEER 框架描述的起点：研发过程不可见，质量不可控，结果不可测。

在十余年的咨询经历中，我们看到很多研发组织处于效能提升的起点状态，在有大量外包的项目或组织中尤其严重。

处于这种状态的研发组织，通常呈现以下特点：

• 代码上线不受控。没有统一代码库（git、svn 等）作为发布原点，缺乏统一的部署管理，开发就可以发布生产系统。这对小型创业公司是可接受的，但在大中型组织，往往就是混乱的起源。

• 增量手工发布。对流程质量没信心，不敢全量发布，只能手工发布本次修改过的代码。依赖开发判断被修改过与否，耗时且容易犯错，最终导致代码基线和生产版本不一致，使未来更不敢全量发布，问题越垒越高——这是刀尖上起舞，如果哪天生产环境出现问题，不可恢复，会引发严重的业务中断。

• 工作过程和工作量不透明。这点在有大量外包的研发组织中，往往体现更为明显。甲方对乙方进度、工作量和实际能力做不到心中有数，对乙方约束力较弱。甲方人员多扮演“二传手”角色，左手接需求、右手扔给外包，能力严重退化。长久下去，研发进度和质量全部受控于乙方，甲方失去主动权，只能仰人鼻息。

• 立项、规模评估、需求澄清、需求变更等流程复杂。大量时间和精力耗费在各种沟通会、澄清会上，交易成本居高不下。

起点状态可以用「管理混乱」以蔽之，总体表现为效能低下，团队甚至整个组织在失控的漩涡中挣扎。

第一级：发布受控（Versioned）

管住出口，建立流水线

离开混乱的起点，从 Chaos 提升到 Versioned ，需要建立一些制度。

首先，让代码受控。以 Git 库作为唯一发布数据源，建设统一编译平台，从Git中读取源文件，自动打包，运维只发布统一编译平台的输出。

补充说明：Git 已经成为代码版本管理的事实标准，被多个顶级组织广泛使用，安全稳定。放弃 SVN 或其他版本管理工具，全面迁移到 Git 上是理性选择。

讨论本阶段指标前，先澄清三个概念。研发组织中，代码管理单元可以分成三层：系统、服务、模块。系统是为了满足业务要求的一组能力的集合，一个系统由多个服务组成。服务是部署单元，由多个模块编译打包而成，可根据负载均衡、可用性等要求，在一个服务部署多套副本。模块则对应一种编程语言，一个代码路径。

为了把模块中的代码变成生产环境中运行的服务包，一般会建立多条自动化流水线（Pipeline），大致可以分成三种：构建流水线、部署流水线、分析流水线。「构建流水线」在给定时间产生一个质量满足初步要求、用于部署的包，「部署流水线」把包部署到特定环境，「分析流水线」对代码进行全面质量扫描，避免风险。

发布受控这一级的核心指标是服务构建自动化率，即有多少比例的服务可以从代码库中自动构建出服务发布包（增量包/全量包皆可），关键有两点：源头一定是代码仓库，构建打包过程一定是自动化的。

我们建议，不仅在组织级的统计服务构建自动化指标，也要为每个服务指定负责团队，这就可以统计出每个团队是否达到了发布受控这一状态。

除了服务构建自动化率这个核心指标之外，还应关注如下几个监控指标：

服务平均构建时长。针对一个团队的多个服务，每个服务构建时长的平均值，这个值会受服务复杂性、编程语言、构建服务器性能等多个因素影响。基本上，应将服务平均构建时长控制在 5 分钟内，太长的服务构建时长，会影响团队对持续集成、持续质量守护的应用。

理想上，构建流水线应包含初步的自动化质量守护，如单元测试、隔离外系统的接口测试等。但 DEER 模型的第一步，只要求实现编译打包自动化，暂不要求在构建流水线中包含测试动作。未来，当构建流水线包含自动化测试后，该指标可以放宽到 15 分钟。

服务构建平均成功率指标。针对一个团队的多个服务，每个服务都可能出现构建失败的情况，不应要求服务构建平均成功率达到 100% 。

笔者曾亲身经历，一家大型组织要求构建 100% 成功，开发团队只好在公司构建流水线之前，加一条不受监控的预构建流水线，这反而减慢了团队的交付速度。

在发布受控这一步，只要求实现编译打包自动化，因此可以对构建成功率提出较高的要求，如 98% 。未来随着自动化测试的引入，这个指标可以放宽到 90%  。

服务构建失败修复时效。构建失败并不可怕，关键是团队能否对构建失败进行快速响应。对于 85% 的构建失败，团队能在一定时间内完成修复，这才是最应该监控的指标。服务构建失败修复时效应该控制在15 - 30 分钟之内。

发布受控是研发效能提升的基础，其意义在于能够「看见」研发最重要的产出（代码），这为组织建立基线打下了坚实基础。该阶段以堵为主要策略：通过发布收口，堵住不经代码库发布生产环境的「偷懒」通道，使第二步基线建立成为可能。

如果第一步做不好，就可能出现管理两张皮的现象：私下潜规则成为常态，流程摆在那里，但没人认真执行。

第二级：基线建立（Baselined）

开启数字化研发管理

发布受控让管理者「看见」做了什么（代码），下一步要让管理者看到为什么做（变更），从而对变更建立管理基线。这里的变更是个泛化概念，只要对原系统进行修改（包括需求、缺陷、任务等），就是变更。研发人员在提交代码时，写明变更编号，明确每次变更是谁做的、为什么做、做了多少。

代码只是研发人员的工作产出之一，需求讨论、计划沟通、测试案例编写等工作该如何体现？项目经理、产品经理、测试人员的工作量该如何体现？这都是管理者要考虑的现实问题。

鉴于传统周/月工时表用于软件研发管理时的局限性（通常表现为信息失真），Agilean 发明了在看板上点亮卡片，每天自动计算工时的方法（如下图所示）。

在软件研发管理过程中，站会和看板是最基层的管理现场。点亮工时不需要成员花额外时间进行填写，同时为管理者重建了管理现场。让管理者看到团队需要做哪些事情，正在做哪些事情，有什么阻碍，需要什么帮助，上线优先级是否一致等等。

「点亮」机制还能展示组织当前的负荷状况。管理者可以及时调配团队资源，既防止有人无事可做，划水摸鱼；也防止有人负荷过高，出现大量工作积压。管理者的持续观察也有助于保证信息的真实性和准确性，实现「双眼紧盯」，才可能逐渐「双手放开」，适度授权。

有了代码量和工时数据之后，知微通过个人工时和代码行视图进行展现，帮助管理者透视研发团队的工作、产能和进展（如下图）。

以上只是初始数据。如果想产生有效的数据洞察，还需要关注一些守护性指标，保证数据的有效性。比如，为了保证工时的有效性，需要监控每天无工作任务点亮的人数，并和企业的考勤休假系统打通，保证每人每天至少点亮一张工作任务。另外，还要监控没有变更号的代码提交数量。

这些守护指标需要细化到每层组织、每个人，以保证工时和代码行数据的初步有效性。

诚然，在现实中，工时不可能绝对准确，代码行也不能完全代表工作量。但根据 Agilean 的实践经验，这些数据可以反映员工、团队的工作能力和工作态度。这些数据的价值，在于为管理者的直觉提供佐证，而不是让管理者去紧盯每个变化，横向对比每个团队的状态，就像买卖股票不能依赖于每天紧盯K线图一样。

先收紧代码，再收紧变更，可以保证在系统中记录所有对组织有效的工作任务。这时，就可以利用 DEF 研发效能框架来建立数据基线了。

首先，要建立研发各阶段时效指标。如下图所示，知微可以对需求前置时间进行分段计算，既能统计展示研发整体时效，也能分需求、设计、开发、测试、验收等各段分别展示。具体的统计阶段，可以根据组织实际需要进行自定义。

有的团队没有及时拖卡的习惯，平时需求只有「to do」和「done」两个状态，过程完全不可见。建立了上述分段时效透明机制之后，这个问题迎刃而解：产品经理、设计师、开发、测试对不同阶段的前置时间负责，整个团队对需求前置时间这个整体时效负责。

除时效指标外，也可以对团队的质量（生产缺陷数、每人天测试/生产缺陷数）、吞吐量、流动效率等指标建立基线，以便衡量未来的改进效果。

第三级：协作优化（Optimized）

开展有效质量活动

基线建立后，FLEET 框架的「看见」已基本达成。协作优化，是结合 FLEET 框架整流、细粒、润滑、小批原则进行的实践，通过开展有效的质量活动，优化研发内部各角色之间的协作流程。

该阶段的主要改进点是细化需求颗粒度，以及建立需求层级体系。对于大型组织，可以采用「需求-系统任务-个人任务」三级体系；小型团队，采用「用户故事-开发任务」两级体系。建议系统任务或用户故事控制在 10 人天，个人任务控制在 2-3 人天。

通过整流、细粒、小批系列手段，团队吞吐量会提升，前置时间会缩短，每个需求、系统任务的代码量会下降。

需求开发完成后，我们建议开发先进行 showcase ，根据开发测试在需求澄清时约定的冒烟测试案例，由开发向测试验收完成的功能，帮助其更快速地获取质量反馈。观察开发冒烟透过率，监控开发初始移交的质量，本阶段此指标应高于 80% 。

代码质量方面，建议本阶段开始观测每次提交的平均代码行数，初始控制在 50 行内。

开发人员应该学会小步快跑，每次提交增加一部分代码能力，但不能破坏原有能力（never ruin原则）。同时，组织应开始推进每日代码评审机制，将代码评审流程线上化，达成 50% 代码评审率。

研发团队还应该确立缺陷优先的思维，强调每日缺陷清零（努力目标）。上图为知微研发团队缺陷修复的时效统计，可以看出自从今年 8 月执行缺陷日清后，缺陷修复时效出现了明显的优化，控制在了 3 天之内。

在该阶段，需要开始对缺陷进行必要的分析，区分需求缺陷占比，明确未来的预防手段，为后面两个阶段做准备。

经过上述改进手段和对合理的指标进行监控，大多数团队可以取得整体响应速度提升 30% ，质量提升 50% 的效果。我们建议把这两个指标的提升作为该阶段的出口条件。由于需求颗粒度的变化，吞吐率指标在三级要重新建立基线。

从「Baselined」到后面的「Optimized」，读者或许能感觉到，在 DEER 模型中，效能越是提升，对统计的要求就越高。指标统计的意义在于透明瓶颈，为效能提升指明方向，而不是成为组织的负担——这也是知微的愿望之一，融合 FLEET 、DEF和 DEER 等众多模型，实现指标的自动化统计和便利呈现。

第四级：自动守护（Automated）

整体自动化和自主优化

协作优化见到效果后，「自动守护」将是研发效能提升的主要改进方向，这也是 DEER 模型中对研发效能提升描述中的「升华」阶段。

在这一级，DEER 模型要求开始进一步降低需求缺陷密度——这里的需求缺陷主要指由于团队需求沟通不清楚造成的缺陷。

我们建议实现需求双向澄清和实例化需求，监控业务复杂需求澄清率。100% 进行需求双向澄清，尽可能地避免理解有误和传递失真的需求进入开发阶段。

同时，开始识别架构复杂需求，监控架构复杂需求评审率，建议达到 100% 。

需要说明的是，这些评审澄清都是良心活，无论怎么加审批机制或要求上传文档，都不能让没有意愿的团队做好这件事情。因此，这两个指标更多是团队的监控改进指标，用于自我提示和优化。

本阶段的最大变化是提升自动化质量守护能力。我们希望团队可以利用测试金数据技术快速构建稳定的测试初始数据，利用挡板、Docker 等技术快速构建测试环境，从而快速执行稳定无噪音的回归测试案例。这里的重要指标是测试案例误报率 < 2‰ ，核心测试案例执行时间 < 10 分钟。

开发人员每次提交代码时，自动触发核心回归案例的执行，在 15 分钟内提供快速反馈。这种能力可以使团队放心使用主干开发模式，而不是采用每个任务开分支的模式。

使用每版本平均分支数指标来监控团队的分支模型。使用主干分支的团队，每版本平均分支数应该接近于 1 ，采用任务分支的团队，这个指标会远大于 1 ，区别非常明显。

自动化测试、测试金数据能力，也让全自动回归成为可能。该阶段要求全面实现接口测试自动化，降低交易成本，确保接口测试代码覆盖率达 40% 。

建议接口测试，是因为接口测试比单元测试经济，不容易受代码重构影响。接口测试也比界面测试经济稳定，界面测试无法达到 2‰ 误报率的要求，也容易受到界面重构的影响。

40% 覆盖率指标参考了谷歌的测试能力成熟度模型（下图）。领导者一定要意识到，100% 代码覆盖率是不可能达到的，成本太高，哪怕 80% 也不可能。在该指标上提出不切实际的要求，只会弊大于利。

有了全量自动化回归的守护，就可以放弃手工增量发布，采用全量自动发布机制了。增量发布有风险，有观点认为其是一种「冒险的策略」：

• 增量发布一般都是手工任务，完全依赖开发的判断，耗时且容易犯错；

• 增量让回滚变得麻烦，一旦选择了错误的增量包，极易导致难逆转的混乱和错误。

第四级的另一个要求是，团队应开启自我改进：

• 利用数字化手段来发现研发团队存在的问题；

• 不断对研发数据进行数据挖掘和分析；

• 根据分析结果制定改进目标，并不断将改进目标落地。

该阶段的出口指标要求为：响应时效提升 50% ，质量提升 70% ，吞吐率应在第三级基础上再提升 10% 。

下一步，就是挑战卓越了。

第五级：挑战卓越（Challenged）

顶层和未来

顾名思义，这是一种美好的愿景，是大部分研发组织目前很难达到的一个阶段。团队可以将本级视为挑战，或者努力的方向。

达到该级别的团队，可以将每次提交的代码行控制在 25 行之内，并按提交实时评审。冲击该级别的团队，应开始提升设计水平，控制质量债务，针对核心代码编写单元测试，并能够随着代码重构，不断维护这些测试案例。

目前大多数开发人员不具备编写单元测试所要求的设计能力，大多数代码仍处于低内聚，高耦合的状态。编写单元测试需要设计优化与重构，其前提是足够的开发时间和自动化测试的守护。因此，DEER 模型为第五级定义了一个较低的单元测试覆盖率要求，且未在第四级对单元测试覆盖率提出要求。

在Google的测试成熟度模型中，要求单元测试覆盖率 40%，综合覆盖率 60%（下图），现实中，该要求在绝大多数组织是难以企及的。

DEER 模型中，达成第五级的团队可利用单元测试守护核心业务逻辑，单元测试覆盖率 10% 、综合测试覆盖率达到 50% 。这可以帮助团队将生产质量提升 90% ，吞吐率进一步提升 20% 。

总结

DEER 是 Agilean 以多年来辅导敏捷团队提升研发效能的实战经验为基础，进行数字化提炼和总结的产物。该模型和路线图将内嵌到「知微」中，实时、智能、远程地帮助研发团队提升效能，实现「发布受控、基线建立、协作优化、自动守护、挑战卓越」的升级进阶之路。

本文篇幅较长。您可以关注 Agilean 公众号，回复 DEER 获得模型的高清图解，快速掌握 DEER 模型核心内容。

协议。

RECOMMEND

推荐阅读

FLEET 研发效能提升框架

DEF 研发效能度量体系