聊聊研发效能治理方案的理论框架

最近几年，国内业界越来越常提及“研发效能”这个词，追其根源大部分是始于“DevOps”运动的活跃。
知道 DevOps 发展历史的，基本都了解 DevOps 是受敏捷的影响，是敏捷原则在软件研发到运维运营层面的延伸。
很多云厂商在推广自己 DevOps 平台服务的时候，也会提及对“研发效能”的大幅度影响，比如 AWS 对 DevOps 的描述：

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

那么，研发效能 == DevOps 吗？
答案自然是否定 。

研发效能 明显是“问题域”。
DevOps 是一种解决方案，且是一种已经被验证、非常成熟的、可以提升软件研发效能的解决方案。
但就像人感冒发烧一样，吃 A 药可以痊愈，吃 B 药也可以痊愈，打针也可以痊愈，甚至有时候发现吃药效果不理想，最后还是去打了针。
研发效能低，就像人感冒发烧一样，是个 “问题” 。DevOps, 是解决这个问题的一种 “药”。

因此，弄清楚了问题域和解空间的关系之后，我们来看看研发效能和它的解空间，并且主要聊一聊解空间（研发效能治理）。

1. 研发效能的定义

研发效能，即持续快速交付价值的能力。
将其拆解一下：研发效能 = 效率 + 质量+ 有效价值，还有这三项可重复和稳定发生的持续性。

展开来讲，就是

• 要在保证系统可靠性、不降低交付质量的情况下，尽量缩短从业务构想到功能上线的时间 （质量 + 效率）
• 从而使“最小化可行需求”能快速被验证，确保有效价值，减少浪费 （有效价值）
• 且整个过程效果可重复发生（持续性）

2. 研发效能的治理

有了定义之后，就来看看如何对研发效能进行治理。
根据市面上大部分公司的软件工程能力状况，针对研发效能治理，这里提炼了一条“研发效能治理成熟度模型”。

从左至右，研发效能治理分为5个阶段，每个阶段也必须包含它左边所有阶段的成果。
举个例子：某IT部门采购了一个 DevOps 平台服务，但日常仅仅当做 CI/CD流水线 甚至是“发布工具”来使用，对效能治理没什么概念，这时候该IT部门的治理成熟度自然是低的，可能只在“度量和评估”的位置。

接着，展开来看看效能治理成熟度每一个阶段。

2.1. 度量和评估

管理学之父彼得德鲁克曾经说过：“如果你无法度量它，就无法管理它”。
对管理如此，对效能治理亦是如此。因此，度量和评估，对于研发效能的治理必不可少。

那么，再来看看为何把“度量和评估”放在治理的第一步呢：

• 首先，想要对研发效能进行治理，必须知道当前效能处于一个什么阶段，对现状有了度量评估和自我认知之后，才能明确之后治理的方向和力度。
• 同时，度量和评估模型在持续治理的过程中，可以阶段性地重复使用，用以呈现治理成果的效果和进行快速反馈。

因此，度量和评估，作为研发效能治理的第一步不可或缺。

接着，来看看如何做度量和评估？
从 “健康度指标” 和 “局部诊断性指标” 分两层来看。

健康度指标

首先，借鉴于DORA(DevOps研究和评估组织) 的2021年报告中的Four Key Metrics，将其作为研发效能的4个关键 健康度指标:

• 研发效率：
  • 部署频率
  • 前置时间（Lead time）
• 研发质量：
  • 故障恢复时间 （MTTR）
  • 部署失败率

特别注意：区别于 DevOps 只关注于“从代码提交到功能发布”这个区间的前置时间，研发效能中的“前置时间”延伸了覆盖范围 —— 从业务构想到功能发布，涉及研发运营的整个研发周期。
其他三项，与 DevOps 报告相同。

至于，研发效能中的__有效价值__，其与业务关系紧密，度量数据模型需要根据具体业务来设计，因此目前仅给予该项 健康度评估模型：

Measurement involves collecting factual information about the value of a deployed feature and evaluating it against the original hypothesis statement.
Rate your team’s ability to collect objective information about the actual value realized by deployed features so that it can inform strategic financial decisions.
Sit (1-2): We don’t define or measure the value of Features.
Crawl (3-4): We’ve defined what “value” is but don’t know how to measure it.
Walk (5-6): We capture qualitative feedback from the business about the value of our Features.
Run (7-8): We capture qualitative and quantitative feedback from the business and our monitoring systems about the value of our features.
Fly (9-10): We aggregate the quantitative and qualitative feedback to objectively validate the original hypothesis and inform pivot-or-persevere decisions.

看到这里，是不是有点眼熟，如果原本预想的解决方案是 “DevOps一体化” 的话，加上有效价值的度量，是不是方案就要考虑"BizDevOps"?! 是不是仅仅一个DevOps的方案就不够匹配了？（重新再正视一下问题域和解空间的区别 :P）

局部诊断性指标

也许有人会觉得，对比下其他类型的度量和评估报告上繁多的指标量，上面这几个指标未免有些简陋。
比如，连常见的评估应用架构维度的指标都没有。 其实，应用架构指标是有的，但并不属于效能“健康度指标”，而是“局部诊断性指标”。

• 当发现健康度不理想，需要分析、定位和形成改进建议时，这时就要借助于局部诊断性指标。
• 当实施了改进建议，对局部指标进行了优化，最终效果又会传导到健康度指标上。
  如果局部指标改进了，但健康度未提升，这时可能需要回过头来分析和反思一下：是诊断和改进建议的问题，还是本身局部指标需要调整。

有了这两层指标，整个研发效能的度量和评估模型才大体完整。
而在整个研发的过程中，可以常常阶段性的使用模型进行度量和评估一下，比如每次发布周期完成 或者 每次sprint完成的时候等等。
使用指标值的时候，也需要注意：指标值本身并不重要，重要的是通过数据驱动出洞见。而在持续改进的过程中，数据趋势比数据值更重要。

健康度指标中，有非常重要的一项 —— Lead Time。
Lead Time 的定义来源于传统制造业，指从受订到出货之间间隔的时间。
同时，与Lead Time 一同被提起的，还有"Cycle Time"。 而 DevOps 的度量指标，习惯称其为“Process time”。
Cycle Time 和 Process Time, 在软件研发和 DevOps 领域基本相互等同，主要指去掉排队等待时长，处于生产任务（增值活动）执行的时长。

一定要谈下区别的话，对 DevOps 工具自动化来说，基本每个环节的执行动作都是可重复的、标准的，因此“单件”的 Process time 基本可以代表当前任务的生产性能。
位于 DevOps 之前的研发环节，每件制品包含知识类的创造、不是标准件、无法准确重复，因此在统计任务时长时（比如：In Dev processing, in QA processing）, 只能通过“多件”运算出均值，亦就是 Cycle time.

Lead Time 和 Cycle Time 是精益制造中重要的衡量指标。
自从精益生产在制造业获得成功之后，为了改善产品开发流程，软件研发行业也将精益思想引入到了产品研发之中。

2.2. 价值流分析和改进建议

从研发效能来看，除了宏观的 lead time 的健康度之外，想要回答 lead time 为何会花费这么长时间、具体那些环节比较耗时、是否可以优化耗时时，就需要将研发工作流程打开来看一看。
想要理解和观察研发流程，有一个重要工具，就是 —— 价值流图（Value Stream Mapping， VSM）。

软件研发流程，是从需求构想到产品（或功能）发布上线的这个过程中，为了提供用户价值而采取的一系列研发活动。
价值流图，就是用来观察和分析价值在研发流程中流动的情况。
价值在整个流动的过程中，会经历增值活动、非增值但必要的活动（I型浪费）、以及非增值可以去掉的活动（II型浪费）。价值流图分析的目的，首先就是去掉 II 型浪费，然后再将 I 型浪费转化为 II 型浪费从而消除。

也许有人会认为，上图中 QA 进行测试、Ops 进行发布，这些怎么能看做是增值行为呢？这主要是因为，不能只是从代码即是生产的角度去看待软件研发。
软件研发，其实是一种知识型的创造活动，虽然这些知识最终是通过代码的形式固化下来的。这种知识性的创造活动，包括PO、BA、Dev、QA、Ops所有角色的知识汇总。
这也是为何敏捷测试总是强调测试左移的重要性 —— 在需求分析或者 Feature kick off 阶段，QA 尽早参与到知识汇集的阶段，也可以降低 Dev 的返工率。即使是处于“开发”下游的“功能测试”，也可以从提供自动化测试代码的视角，察觉到测试的增值贡献 —— 让代码制品拥有了自动化测试代码。

正如图中显示，黄色标签为 I 型浪费，红色为 II 型浪费，比如“等待型浪费” —— 等待联调， “返工型浪费” —— 改 Bug。
那如何实施消除浪费呢？比如上面的等待联调、联调后的bug返工修复。
没有标准答案，但大体有如下思路：

1. 当前后端等待联调，团队的Dev是否可以发展成全栈工程师，这样前后端一个Dev就直接完成了，不存在联调。既消除了联调等待，也降低了返工率。
2. 如果不发展全栈工程师，在story开始阶段，前后端是否可以一起设计和约定好契约（包括happy path、unhappy path、异常处理），由契约DSL上传到contract Mock server，这样可以降低联调成本和返工率。

2.3. 敏捷 & DevOps团队能力建设

有了前面两步治理成熟度的达成：度量评估和价值流分析，对研发效能有了不同维度整体的了解之后，接着就进入到治理动作的实施中。
建议使用带有整体优化能力的理论和实践框架 —— 敏捷 & DevOps。这些理论和实践已经被反复验证，并且非常成熟。

敏捷，鼓励创建研发的全功能团队，提升交流和互动，以尽早和持续的交付高价值的软件为目标。一些团队甚至还鼓励成员打破角色边界，比如身兼 QA 能力的 Dev、具备 ops 能力的 Dev 等等。在这个阶段，基于Scrum、Kanban软件研发模式的普及，持续交付理念（Continuous Delivery, Jez Humble 提到的宏观角度的持续交付）也越来越被重视。

到2009年，终于有人在借鉴敏捷和精益的基础上，创造了 DevOps 这个词，旨在强调将 Ops 加入到产品研发全功能团队的充分必要性，并且兼顾开发思维、实行 infra as code的运维方式和方法，旨在提升产品交付效率和可靠性。

随着 DevOps 运动的兴起和推广， DevOps 逐渐发展，包括和涵盖了方法论、流程、自动化工具，以及特别强调的 DevOps 文化，并且逐渐影响到了整个研发价值流的参与者们遵循 DevOps 精神进行群策群力。
比如：Sec、QA 将安全和测试脚本加入Pipeline —— 不需要等到环境验证，在build运行的过程中就可以快速反馈到Dev，进行代码修复。

《凤凰项目》在DevOps原则，总结了三步工作法：

• 流动原则。实现开发到运维的工作快速地从左往右流动。
• 反馈原则。从右往左的每个阶段中，应持续、快速地获得工作反馈。
• 持续学习和实验原则。团队建立持续学习和实践的文化。

因此，团队针对敏捷 & DevOps 进行能力建设，可以从整体优化的角度对效能进行治理和提升。
在具备了敏捷 & DevOps 能力下，再去探索局部优化和治理。

2.4. 交付和运营方式转变

在敏捷 & DevOps 团队具备稳定和高效地研发效率、高质量、降低了发布成本和发布风险后，让原本正确、但看起来不可实现地交付和运营方式变得可能：

• 系统3~6个月一次大批量发布上线 --> 每个月/甚至更短周期 小批量发布上线
• 由需求批量压入迭代的 Scrum 研发管理模式 --> 需求拉动的 Kanban 研发管理模式
• DevOps 2.0、持续交付2.0 逐渐实现。

研发效能被提及，其目标是快速验证产品、获取用户反馈的能力，位于行业前台的系统的快速推出，还能带来抢占市场的机会。
因此，交付和运营方式的转变，在完成治理成熟度3之后，必要、且可顺势而行。

2.5. 共享的、自助的研发运营XXX一体化平台

也许有人会奇怪，在达成前 4 步效能成熟度之后，第 5 阶次的成熟度居然是推出 研发运营XXX一体化平台？（XXX可能是业务运营等等，反正随着 DevOps 2.0、持续交付2.0、bizDevOps这些相似概念的提出，大家旨在将产品的从概念到投入用户群体，这其中正向、反向的活动都组成一个闭环的整体）
将研发运营XXX一体化平台放在效能治理成熟度最后一步的逻辑是：

• 即使不依托一体化平台，循序前四个成熟度治理，效能治理也可以在不同的企业和组织中开展。
• 当团队达成前四步治理成熟度，可以考虑将局部优化转化成全局优化。借助研发运营XXX一体化平台，对企业和组织内的全局优化事半功倍。
• 研发运营XXX一体化平台，说白了，只是一个工具，投入需要大成本。如果没有前四步成熟度的认知和达成，它也仅仅只是个工具。

3. 总结

研发效能治理方案的理论框架，基本到这里就阐述完了。 总结一下，就是：

• 先度量和评估，再价值流分析
• 敏捷 & DevOps 团队能力建设
• 交付和运营模式转变
• 推出 共享的、自助的研发运营XXX一体化平台