在以往工作经历中，总是遇到各种各样的问题

产品需求过于简单，漏洞百出，线上处处留坑，异常场景考虑欠缺

技术架构复杂不统一，不同团队维护多种架构，开发风格多样，开发质量无检测，无review code

测试耗时，业务场景不熟悉，测试难点问题重复出现，不能自动化测试

产品，研发，测试不是一个整体，项目串联无质无序

1 DevOps核心理念

DevOps是以快速交付价值，给与开发最大自由度，负责开发和运维的全部过程。在监控、故障防控工具，功能开关的配合下，可以在保障用户体验和快速交付价值之间找到平衡点。

1.1 DevOps核心理念之松管控和强卡点

松管控：应用 Owner可以完整定义这个应用的各种规则，比如如何发布，如何测试，如何进行资源、环境 配置等。我们有通用构建和自定义构建，可以给开发最大自由度。最后是“轻发布，重恢复”。在每一个应用维度，开发可以随时使用流水线来交付代码，而并不需要特别的限制，仅仅需要思考的是如果出问题，我们应该如何快速恢复。

强卡点：代码审核和质量红线；代码安全检查、规约检查；发布、封网窗口等。还有所谓“变更三板斧”：可灰度、可监控、可回滚。这些卡点是为了保障所有开发工程师步调统一，交付合格的产品。

1.2 DevOps核心理念之应用中心

DevOps是应用为中心。应用信息其实可以归纳为CMDB(Configuration Management Database配置管理数据库)中的一种数据。它对于研发人员天然是亲切的，它可以直接对应一个服务，一个代码库。以代码为起点，我们又可以串联流水线、环境、测试、资源。最外围是工具链：监控、DB、运维、中间件等等。

2 DevOps实践之敏捷开发

随着5G、人工智能、IOT等新技术的迅猛发展，企业的业务都将构架在软件和互联网之上。软件交付能力成为企业的核心竞争力，随着市场竞争的加剧，企业对研发效能的期望越来越高。然而新技术、新业态的不断涌现，又使企业的业务变得越来越复杂，各个团队之

间的协作也越来越困难，企业的研发效能呈现降低趋势。“期望”与“现实”之间产生了巨大的“Gap”，正是我们要努力的方向。

2.1 敏捷开发之效能问题

局部效率 ≠ 高效交付 ≠ 持续高效  

高效交付 ≠ 业务成功

精益和敏捷的方案是需要解决上面的三个问题：

● 从局部效率到高效交付，我们需要做到：顺畅高质量交付。

● 从高效交付到持续高效，我们需要做到：持续地顺畅高质量地交付。对于代码设计和质量的长期维护和提高，持续工程能力的积累，持续交付实践的实施等。

● 从高效交付到业务成功，我们需要做到：持续地顺畅高质量交付有效价值。

2.2 精益敏捷实践之实践框架

精益敏捷研发实践框架分为三层，

第一层是战略和目标，主要包含用户诉求、愿景目标和战略规划。第二层是产品规划层，这里需要业务、产品、技术之间的敏捷协

作，将战略和目标层的业务诉求形成业务诉求条目后录入业务需求池，然后通过业务设计、产品设计、产品交付等环节，交付有效价值，并根据业务验证结果，建立业务反馈进行调整，最终达成业务结果。
    第三层是团队交付层，在这一层需要产品和技术团队高效协作，持续澄清，开发和验证需求，并通过自动化交付流水线和持续交付机

制实现快速交付需求。

实现精益敏捷研发，需要做到以下四步

2.2.1 第一步需要打通端到端的业务价值流

从用户的需求到用户问题解决这一全过程，而不是中间的某一个阶段。这就需要我们的业务、产品、技术进行协作。

业务、产品、开发、测试和运维在内的端到端交付过程。打通端到端的业务价值流必须做到：用户价值驱动，即每一个流动单元体现的都是具有用户价值的业务需求；前后职能拉通，即拉通业务、产品、开发、测试等各个职能一起来看整个链路，始于用户问题的提出，终于用户问题的解决

产品规划层：需要聚焦端到端的流动效率，并形成价值反馈闭环。而在团队交付层：需要聚焦快速交付业务需求，并保证交付质量

团队交付层：需求从“产品规划层”流转到“等待开发”这个阶段的时候，需要“指派”给开发团队。需求进入开发团队后，开发同

学会把它拆分为“任务”，比如说按照“前后端”会拆分为“前端任务”“后端任务”；只有当所有“任务”开发完成后，满足“提交测试”要求了，才“提测”。

2.2.2 第二步快速高质量交付

从阶段“业务讨论”开始到“已发布”都需要有明确的准入规则。

举两个具体的例子，

第一个是从“产品”流转到“开发”的规则：

● 开发、测试和产品达成一致，定义明确的验收标准。

● 大需求，需拆分为工作量在两周以内的需求卡片。

● 与关联方确认相关计划；识别大的技术风险并定义应对方案。

● 涉及三位及以上开发人员的需求，指定需求负责人，负责协调进度。

注：在软件研发过程中，大多数的时间浪费不是协作上的等待，而是做了很多无价值的需求，以及需求不停地返工。因此发生在软件开发之前的需求澄清工作至关重要。

其典型形式是：“在什么情况下，做什么操作，会得到什么结果”。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。

第二个是从“开发”流转到“测试”的规则。

● 通过持续集成开发完成后，部署在测试环境；

● 开发对照验收标准Case进行了自测。

● 通过 Show Case。

验收测试驱动开发，确保高质量的准入准出

需求进入开发团队的队列（等待开发）后，业务、开发和测试立即通过实例化,用结构化的方式生成需求的验收标准。

在开发实现这些需求的同时，QA团队会将这些需求实例会转化成测试用例，并把部分测试用例自动化，做到功能实现和自动化测试开发同步完成。

需求实现完成后，QA团队会用处理好的测试用例来验收这些需求。甚至可以将部分测试用例提前给到开发人员，让开发提前进行自测。

注：从“业务讨论”到“已发布”每个环节都需要有一个明确的准入准出规则，研发，产品，测试可以根据实际情况去定义自己的规则，这些规则不是一成不变的而是需要持续更新、持续迭代。

2.2.3 第三步度量反馈和持续改进

期望产品交付过程是可被度量的，同时可驱动交付团队持续改进。

根据产品规划时明确的业务目标和要解决的用户问题，去验证业务目标是否已达成，用户问题是否已被解决，然后做相应的优化和调整。

左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。

小瀑布模式下，交付质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且这一模式通常都导致后期的赶工，埋下交付质量隐患。

右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。

使用“周期时间控制图”来度量“交付效率”。如上图所示，横轴代表日期，竖轴是天数，一个一个蓝色的点代表已经发布的需求。期望这些蓝色的散点进行如下分布。

1. 纵向上向下集中——需求交付周期和开发周期越短，业务响应能力及其可预测性越高。

2. 散点密度提高——散点密度越高代表发布频率越高，发布的能力就越强。

3. 横向上更均匀分布——横向上的需求分布是均匀的，代表是持续交付的。在度量一个研发团队的交付效率时，看这些散点分布的趋势是否是往下走的，如果是往下走的，说明交付效率在变好。此外，还会看“控制线”，在上图中，看到这个研发团队的周期控制线是 13 天，这表示 85% 的需求周期时间都要小于13天，这也代表了该研发团队的交付效率。

2.2.3.1 可行动的效能度量体系

包含需求响应周期、持续发布能力、交付吞吐率、交付过程质量、交付质量等五组指标。这五组度量指标内容又被归纳为三个维度，即流动效率、资源效率和质量保障。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。用六个字 来概括这三个维度就是：又快、又多、又好。有了度量标准之后，还要建立效能反馈和改进闭环，才能更好地提升研发效能。

2.2.3.2 效能反馈和改进闭环

通过日常反馈，质量和交付效能的反馈，并定期进行复盘分析，形成流程操作、基础设施、代码与设计、交付及测试守护和人员技能等五个方面的改进行动，然后持续反馈、分析和改进。

2.2.4 第四步规模化实施

有了以上三步，其实还不够，我们需要赋能整个企业或组织，进行规模化实施。

2.2.4.1 单产品多交付团队场景

在产品规划层，具有一个产品线看板， 管理业务需求的端到端价值流，并将准备好的需求分配给负责任的开发团队（指派给交付团队 1 或交付团队 2）。在交付团队层，有两个独立的交付团队，他

们的操作其实跟单产品线单交付团队时并没有不同。只需要接受业务需求，分解开发任务，管理需求的开发和交付过程，快速交付。

2.2.4.2 多产品多交付团队场景

有三层看板。第一层是公司级业务运营看板，关注公司战略的落地，如各业务线的投资组合，各业务单元的目标和关键结果，跨业务线的协作和组合创新等。第二层是产品线看板，主要关注产品需求价值流，如端到端需求流动过程，目标反馈闭环等。第三层是交付团队层，主要关注团队快速交付需求，如高质量快速交付，效能反馈闭环等。

可以看到每条产品线都对应多个不同的交付团队，如果各个产品线之间没有任何“交叉”就比较简单了，操作方式类似前面提到的“单产品线多交付团队”模式。但是也可能出现“跨业务线协作”，这就需要在产品规划层进行拉通。比如在这个例子中“生活业务线产品” 的某个功能可能要依赖“中台业务线产品”的某个功能，生活业务线的产品经理就需要将开发需求“指派”到“交付团队 14”，让“交付团队 11”和“交付团队 14”协作完成需求的开发。

3 总结

敏捷研发实践的三层框架：目标层、产品规划层、团队交付层。最重要的是精益敏捷研发的四个步骤：打通端到端价值流；快速高质量交付；度量反馈和持续改进；规模化实施。