《持续交付》读书笔记

读乔梁先生《持续交付2.0》摘要，仅供学习交流

---

一、持续交付2.0

1.1 软件工程发展

1、瀑布软件开发

传统的瀑布软件开发模型每个阶段都花费属于的实际那，需要花费大量的经历确定需求的范围，审核繁杂的需求规格说明书，确定需求范围复杂。

2、敏捷软件开发

提倡面对面沟通，拥抱变化，提倡通过迭代和增量开发今早交付有价值的软件，软件开发实际是一个不断迭代学习的阶段。

• 瀑布只有在项目交付后期才可以看到软件的实际运行。
• 敏捷开发采用迭代模型，但是软件发布之间的间隔较长。需求变更&研发效率是主要矛盾，部署发布&运维矛盾较小。

3、DevOps发展

DevOps目前没有统一的定义，正如每个人理解敏捷是不一样的。目标是缩短开发周期，提高部署频率和刚可靠的发布，与业务目标一致。

4、持续交付1.0

部署流水线：

1. 每个隔间阶段都应该交付可工作的软件，中间产物的生成不应该是独立的阶段。
2. 同一个制品向不同类型的环境部署，且运行时的配置分开管理。（Apollo）
3. 自动化测试和部署，根据测试的目的，分为几个独立的质量关卡。（流水线测试卡点）
4. 部署生产线设计应随着应用程序的发展而不断演进。

组织角色触达：

5、持续交付与持续部署。部署是技术领域的，交付是业务决策。交付可理解为上线、发布，部署可能有多次，而在业务需要时，才会交付。

1.2 持续交付2.0

1、精益思想

《精益创业》线产生最小化的可行性产品，而非玩么牛的产品，在经过快速迭代与持续修正，资源耗尽前实现市场需求。

• 精益创业是“开发–测量–认知”的验证学习过程。
• 按照价值流来组织全部生产活动是价值在生产活动之间流动，需求拉动产品的生产，识别生产过程中不经意间的浪费产生。
• 业务生产活动分为增加价值的活动和不增加价值的活动，后者归为“浪费”活动中，浪费活动分为必要的增值活动和纯粹的浪费。{有价值，无价值[必要浪费，不必要浪费]}。EG：流水线上的装配工作是增值活动，质量检查是非增值活动，因材料不足而生产等待和质量缺陷的返工都是不必要的浪费。

2、双环模型【★】

1. 产品研发管理思维框架，是产品与研发的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念。有可持续方式、高质量、低成本、无风险的快速交付客户价值。

2. ”8“字环，第一个为**“探索环”，目标为识别和定义业务问题，制定最小可行解决方案；第二个为“验证环”**，目标为一最快速度交付最小可行环，可靠的收集真实反馈，并分析和验证业务问题的解决效果。，以确定下一步的行动。

   探索环：

   1. 提问，即定义问题。通过有针对性行的提问，找出用户具体需求，并找出具体需求后的原因，即要解决的根本问题。
   2. 锚定，即定义结果目标指示器。经过分析，去除干扰信息，得到适当的衡量指标，并表述现在的状况和行动预期的结果。
   3. 共创，制定目标后，团队设法验证或者达成目标，而探索多种可行性解决方案。
   4. 精炼，即对所有的可行方案进行选择，找到最小可行性解决方案（单个或者多个混合）。

   验证环：

   1. 构建，最小可行性解决方案转化为符合质量需求的软件包。
   2. 运行，部署到生产环境或者交到用户手中，并使之为用户提供服务。
   3. 检测，生产系统的系统和数据监控，保证运行，并将业务数据以适当的形式展示。
   4. 决策，数据分析与目标对比，决策下一步方向。

   3、四个核心原则：

   1. 坚持少做。想做的事情永远超出自己的交付能力，即使在微软，也只有1/3的新特性成功改进了关键指标。
   2. 持续分解问题。
   3. 坚持快速反馈。快速反馈工作的结果。
   4. 持续改进并衡量。

补充：VUCA模型

• volatility （易变性）
• uncertainty （不确定性）
• complexity （复杂性）
• ambiguity（模糊性）
• VUCA这个术语源于军事用语，在20世纪90年代开始被普遍使用，用来描述冷战结束后的越发不稳定的、不确定的、复杂、模棱两可和多边的世界。随后， VUCA被战略性商业领袖们用来描述已成为“新常态”的、混乱的和快速变化的商业环境。

二、价值探索环

2.1 探索环的意义

1、探索环的目标与价值假设

就是持续事变和定义这些有价值的假设，选择并验证其中风险最高的或者最易验证的价值假设，并截止价值验证环得到数据反馈，以便深入理解用户需求，把我业务前进方向。假设来源：

1. 用户假设：潜在用户的需求假设
2. 问题假设：问题点痛点的需求假设
3. 解决方案假设：提供的方案可以解决这些痛点或问题点，且比其他方案高效

EG：持续交付工具GoDC，设计200多个功能特性，一半都废弃掉，说明假设的不成立。该产品实际一直秉承“持续交付2.0”，调整功能策略，实现成功。

2.2 探索环的四个关键

1、提问

不断提问，澄清客户需求背后真正要实现的目标。

EG：举办DevOps的沙龙，客户要咖啡。问了一堆要什么口味的咖啡、多热的咖啡、什么时间、中杯大杯。

其实问的都是“做什么”和“怎么做”，而没有去问及原因。客户真正的诉求是担心困意而错过听讲。此时，我们的解决方案有多种，比如录制视频，即使参与者中途离场，也可以回顾内容。

2、锚定

1. 避免模糊不清的目标，这样会影响团队的交流。清晰的描述目标让我们知道自己当前的位置，目标是：清晰、具体、可衡量的、有时间限定。若没有时间限定，则将会成为一个愿景，无法直接知道企业日常生产管理的活动。

• 清晰、具体、可衡量、有时间限制。

  EG：某App用户量当前为20万，年底愿景为200万。

  所以我们可以根据新闻信息流服务（Feed流），我们期望用户喜欢该App，那么可以推断：

  1. 用户会阅读更多的内容，花费更长的时间
  2. 用户会将该产品推荐给朋友，而朋友也会喜欢并成为该产品的用户。

2. 根据分析可以得出三个衡量指标：推荐朋友数、单位时间内的用户数、单个用户的平均使用时长。制定指标后，各个团队根据自身职责制定目标如：提高API的请求响应速度、后台稳定性等等。

3. 目标选择应该遵循：

   1. 识别价值目标而非虚荣目标。
   2. 指标应该是可衡量且可获取，易于客观对比。

3、共创

解决方案基于假定条件或者猜想，提供两种分析方法：

1. 量化式影响地图（目标–角色–影响–方案–量化、Why-Who-How-What）。

   EG：以20万到200万为例。涉及到的角色有App使用者、推广渠道、客服团队、产品研发和运营、内容提供商及更多角色。

   以推广渠道商为例

   • 角色：列出设计的人或者角色
   • 影响：App的展示位置、App的曝光量、App审核速度
   • 方案：购买展位、搜索优化、规范更新
   • 量化：App的下载指标

2. 用户陆行地图（可视化的方式，讲用户与产品或服务之间的活动按照业务流进行展示）

   四个部分：

   • 用户接触点
   • 接触阶段
   • 用户痛点
   • 用户情绪

   制作步骤：

   • 定义用户
   • 定义任务或阶段
   • 用户与服务接触点的互动行为
   • 用户的动机
   • 用户心理

共创的两个陷阱、两个极端：

• 分析瘫痪（过度分析，无法决策）、
• 直觉决策（匆忙判断，直觉反应）

4、精炼

筛选最小可行性方案。精炼的目标并不是为了删除在共创阶段得出的解决方案，而是将它们按优先级排列，并让团队将解决方案进一步分解，顺序选出共同认可的最重要改进项，并确保它能够尽早被验证。

2.3 工作原则

1、分解快速验试错

与“一次到位式”的解决方式不同。采用低成本的快速验证，多次尝试，多种方法，多种成功方式。

2、一次只验证一点</