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

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

起点：混乱（Chaos）

不受控，不透明

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

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

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

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

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

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

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

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

第一级：发布受控（Versioned）

管住出口，建立流水线

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

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

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

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

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

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

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

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

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

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

第三级：协作优化（Optimized）

开展有效质量活动

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

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

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

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

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

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

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

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

总结

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

协议。

RECOMMEND

推荐阅读

FLEET 研发效能提升框架

DEF 研发效能度量体系