《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（一） 概念篇

《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（一） 概念篇

为什么要持续交付？

当前互联网变化非常迅速，在这个背景下，提升产品研发运营效率，快速发现新的机会并快速试错，降低试错成本已经变得非常重要。由此，带来几个问题：

1. 如何平衡软件的质量与交付速度？
2. 如何让产品创新快速交付部署，并让团队得到反馈？

我们都知道，要快速发现新机会并快速试错，就必须加快产品迭代速度，而加快迭代速度必然使得一些常规事务性占比增大，诸如测试成本，发布成本等。持续交互，即是这些问题的解决之道。

软件工程的发展历史

让我们先搁置问题本身，先来回顾软件工程的发展历史。

1. 瀑布软件开发模型
   1970年，Dr.Winston W.Rovce 首次提出瀑布软件开发模型，它将软件开发定义为多个阶段，每个阶段都有严格的输入和输出标准，很多人将这种开发方法称为“重型软件开发方法”。但这种方法会需在写第一行代码前，甲乙双方花费大量精力确定需求范围，编辑并审核软件需求说明书，即便如此，还是避免不了互相扯皮。
   
2. 敏捷软件开发
   2001年，敏捷软件开发方法出现，敏捷方法强调发挥人的主观能动性，提倡面对面沟通，拥抱变化，通过迭代和增量开发尽早交付有价值的软件。和瀑布软件开发方法对比，敏捷能更快的看到可运行的软件，而不是到交付后期才能看到。此间，持续集成作为敏捷开发中的工程实践，率先被广泛的it组织所接受，它能减少大量重复性劳动，并排除某些沟通障碍。但敏捷方法并没有解决发布间隔长的问题，以及业务与研发团队关于需求变更和研发效率的矛盾。无论是瀑布或者敏捷开发，关注的都是如何快速将需求变为可交付的软件包。
   
3. DevOps
   2008年，DevOps萌芽，起初的想法是将敏捷实践应用于运维领域。DevOps概念本身也在不断的变化中，如下是曾经的定义

DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。 DevOps的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。

DevOps并非一个标准、一种模式或者一套固定方法，而是一种IT组织管理的发展趋势，也就是说，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快。这种发展趋势将会引起IT组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强关联，因此顺应这一发展趋势的动力更加明显和迫切。

4. 持续交付
   2010年，Jez Humble 和 Dave Farley 合著了《持续交付》一书，可以称之为“持续交付1.0”。持续交付1.0提供的原则和方法是DevOps运动的具体实操指引，事实上，敏捷开发更多的是涉及产品需求方，开发工程师，测试工程师。DevOps更多的是开发、测试和运维工程师。而持续交付1.0则涉及产品需求方，研发团队，运维团队。
   持续交付2.0是1.0的升级版，它将精益创业的最小化可行产品和持续交付1.0相结合，强调业务与IT间的快速闭环。

持续交付2.0核心概念与原则

概念

企业开发软件产品的目标是创造客户价值，为此，它必须不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，简称为持续交付“8”字环。
它由两个相连的环组成:第一个环为“探索环，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。

探索环包含4个可持续循环步骤，分别是提问、锚定、共创和精炼。

1. 提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。
2. 锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。
3. 共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。
4. 精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。

验证环也包含4个可持续循环的步骤，分别是构建、运行、监测和决策。

1. 构建，是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。
2. 运行，是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
3. 监测，是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
4. 决策，是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。

探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。它们之间相互促进，探索环产生的可行性方案规模越小，越能够提高验证环的运转速度；如果价值验证环能够提高运转速度，则有利于探索环尽早得到真实反馈，有利于快速决策，及时对前进方向进行验证或调整。

4个核心原则

持续交付2.0可以使得企业以可持续发展的方式，在高质量、低成本及无风险的前提下，不断缩短持续交付“8”字环周期，从而与企业外部频繁互动，获得及时且真实的反馈，最终创造更多客户价值的能力。持续交付2.0有如下4个核心原则：

1. 坚持少做
   在咨询的过程中，最常听到的一句话就是:我们最大的问题是人力不足。”无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证。
2. 持续分解问题
   复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法并各自独立发布给用户。
3. 坚持快速反馈
   当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。
4. 持续改进并衡量
   无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。

价值探索环

意义

探索环的目标是持续识别和定义三个有价值的假设：

1. 用户假设，即我们提供的产品服务是针对某类潜在用户人群的需求的假设；
2. 问题假设，即目标用户群之所以有这种需求，是因为他们的确存在某些痛点（或问题）需要解决的假设；
3. 解决方案假设，即我们提供的解决方案可以解决这些痛点或问题，而且比其他现存的解决方案都有效且高效。

这3类假设中，任何一个假设不成立，都会导致我们事倍功半，甚至前尽弃。因此，我们需要选择并验证其中风险最高或最易验证的价值假设，并借助价值验证环得到数据反馈，以便深入理解用户需求，把握业务前进方向。

4个关键环节

为了达成探索环的目标，我们需要经历4个关键环节：

1. 提问
   该环节是持续交付“8”字环的起点。其目的在于通过不断地提问，澄清客户需求背后要实现的真正目标，以便找寻更多解决问题的方法，同时也有助于团队成员从业务问题出发，充分理解业务问题。

2. 锚定
   “锚定”是设定目标以及目标分解的讨论过程，其目的是确定要达成的目标以及可以衡量它的指标，并能够指导后续的共创与精炼活动。对于目标的选择，应该遵循两点:一是识别价值指标，而非虚荣指标；二是指标应该可衡量且可获取，易于客观对比。

3. 共创
   共创是指:当我们制订了想要达到的目标后，团队为设法验证或达成目标而找出多种可行性解决方案的过程。

共创分析方法有很多，书中列举了两个：

• 量化式影响地图
  它是用Why-who-how-What的分析法，通过结构化的显示方式，让团队寻找达成业务目标的方法。还应该了解当前的影响程度，以及对实施后达到效果的预期。也就是，从业务问题域出发，按“角色一影响一方案一量化”的顺序进行讨论，从而尽可能多地发掘出可行性解决方案。我们可以称它为“量化式影响地图”。我们有时无法马上对所有指标进行量化。此时可临时性地收集一部分数据，并进行相应的推断，通过一段时间的运行，进行指标量化的校准即可。另一种可能是希望衡量的指标较难直接量化。此时可通过一些过程指标或相近指标来替代。需要注意的是，这两种情况都存在一定的偏差，因此在数据的应用过程中，应该格外注意。

• 用户旅行地图
  用户旅行地图（user journey map）是指以可视化方式，将用户与产品或服务之间的互动，按业务流分阶段呈现出来。

在“共创”这一环节中，需要注意两个陷阱，分别是分析瘫痪（paralysis by analysis）和直觉决策（extinct by instinct）。分析瘫痪是指因为过度分析（或过度思考）而无法决策或采取行动，最终影响结果产出的一种状态。通常是由于有太多的细节选项，或者过于寻求最佳或“完美”的解决方案，并担心做出任何可能导致错误结果的决定。而直觉决策是指不做分析，基于匆忙的判断或直觉反应而做出致命的决定。它是与分析瘫痪相反的另一个极端。

4. 精炼
   精炼环节就是对共创环节中得出的众多方案进行评估，从中筛选出团队认为最小可行性解决方案的过程。评估因素包括备选方案的实施成本、时间与人力、效果反馈周期，以及该方案对业务目标的影响程度。在VUCA环境中，时间是最大的隐形成本。精炼的目标并不是为了删除在共创阶段得出的解决方案，而是将它们按优先级排列，并让团队将解决方案进一步分解，顺序选出共同认可的最重要改进项，并确保它能够尽早被验证。

工作原则

在探索环的工作中应该遵循“分解并快速试错”“一次只验证一点”“允许失败”原则。

1. 分解并快速试错
   “一次到位式”解决方案通常需要较高的实施成本，而其带来的实际效果具有较高的不确定性。由于前期投入的成本较高（即沉没成本），一旦这个解决方案未能带来预期效果，团队不愿意放弃这一方案，决策者通常选择保留它，或者仍会持续优化，使其慢慢“死去”，而这会带来不必要的产品复杂度和维护成本。

2. 一次只验证一点
   一次只验证一个需求假设。在执行整个试验方案过程中，我们仍旧要保持开放心态，不断优化这些试验方案。时刻提醒自己，我们的目标是验证我们的假设，试验方案只是我们验证假设的手段，而不是我们的目标。

3. 允许失败
   尽管每个产品经理都希望所有方案都获得成功，但是我们却无法保证每个方案都会获得成功。但是，只要具有开放的心态，我们就可以从所有方案中都学到很多新的知识。

共创与精炼的常用方法

关于共创与精炼，书中花了大量篇幅介绍了6个常用方法，这里我只简单介绍2个。

• 装饰窗方法
  所谓装饰窗方法（Decorative Window），就是指为新功能预留一个“入口”，让用户能够看到，但实际上并没有真正实现其功能。这是一种了解用户喜好的方法，其目的是利用最小成本，来验证用户是否喜欢某个功能，以及其紧迫程度，为是否研发后续更全面的解决方案提供数据支持。

• 最小可行特性法
  最小可行特性法（Minimum Viable Feature）是指在产品从1到n的过程中，寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法，以尽可能少的成本快速增加或修改某个产品特性，让用户使用，收集真实反馈，专注于验证功能改进，同时也可提升用户使用体验。

快速验证环

当我们通过“探索环”对最小可行方案达成共识以后，要借助“验证环”的快速运转，才能将其交付到用户（客户）手中，从而得到真实且可靠的反馈，以验证之。快速验证环的运转速度由两部分决定:一是探索环中得出的最小可行性解决方案的大小和复杂性；二是验证环自身运转的速度。

验证环的目标

进入验证环的基本前提是“团队已达成共识，所选的方式是当前所处环境下，验证或解决业务领域问题的最佳方式“。验证环的目标就是借助各种方法与工具，让质量可靠的解决方案以最快的速度到达客户手中，从而收集并分析真实的反馈。

质量与速度是验证环的关键，它们却常常被认为是互斥的。然而， Puppet LabsDev发布的2017年DevOps现状调查报告结果显示，与低绩效IT组织相比，高绩效IT组织可以同时实现这两个目标，也就是说，发布质量好而且频率高。持续交付1.0在这方面发挥了巨大作用，如质量内建、小批量交付、自动化一切重复工作等。

验证环的4个关键环节

验证环的主要工作内容就是以最可靠的质量和最快的速度，将最小可行性解决方案从描述性语言转换成可运行的软件包，并将其部署到生产环境中运行，准确收集相关数据并呈现，以便团队根据相关数据做出判断和决策。与探索环一样，它也包含4个环节，分别是构建、运行、监测和决策。

1. 构建
   构建环节是将自然语言的描述转换成计算机可执行的软件，即“质量达标的软件包”。这一环节既要求相关人员能对业务问题及试验方案达成共识，又要求能够准确地将团队的意图转换成最终仅由0和1组成的数字程序。这一环节的参与角色最多，尤其当开发一个新产品或者产品有重大变更的时候，参与角色如业务人员、产品经理、开发工程师和测试工程师，以及运维工程师。每个角色的背景知识和技能优势各不相同，如何快速将人们头脑中的解决方案变成可以运行的高质量软件包，一直是软件工程领域的一个难题。这是验证环内不确定因素最多的一个环节。时间盒管理、工作任务分解和持续验证是应对这种不确定性的好方法。

2. 运行
   将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。

3. 监测
   监测环节收集数据，并统计展现结果、及时发现生产系统问题以及业务指标的异常波动，并做出适当的反应。它也是团队做出决策的最重要数据源之一。团队必须在验证环一开始就讨论并确定验证所需的数据需求，尽早讨论并定义数据需求规范制订日志记录标准，建立数据日志元数据，并与相对应的功能需求一并同时实现。

4. 决策
   决策是指收到真实的业务数据反馈结果后，根据探索环中已确定的相应衡量指标进行对比分析，从而验证是否符合最初的预期。下一步行动既可能是从精炼环节的最小可行方案列表中选择下一个试验方案，也可能是返回到持续交付“8”字环的起点，开始新问题的探索。

工作原则

验证环的工作原则主要包括质量内建、消除等待、尽量并行、监测一切。