【读书笔记-002】持续交付2.0之双环模型

软件行业的VUCA特性：V（volatility，易变性），U（uncertainty，不确定性），C（complexity，复杂性）和A(ambiguity，模糊性)

软件工程的发展

瀑布软件开发方法

将软件开发过程定义为多个阶段，每个阶段具有严格的输入和输出，希望以重计划、重流程和重文档的方式来解决软件危机。这种开发模式每个阶段需要耗费数月的时间，软件交付的失败率仍然很高。

瀑布开发模式

敏捷软件开发方法

针对瀑布开发模式的缺陷，软件开发者开始尝试新的轻量级的软件开发方法，随着“敏捷宣言”的发布，提出软件开发的十二开发原则，提倡面对面沟通、拥抱变化、通过迭代增量开发尽早交付和验证的软件。一个迭代交付计划被划分为多个迭代，强调在每个迭代结束时得到可运行的交付件。

敏捷开发方法

缺点：交付周期依旧很长，需求变更和研发效率之间的矛盾依然是主要矛盾，部署活动通常由专门的运维团队执行。

DevOps运动

DevOps是一组概念的集合，是一种运维工程师和开发工程人员参与整个服务生命周期的一组时间，它是一种软件工程的文化和实践，旨在统一整合软件开发和软件运维，倡导对构建软件的所有环节，包括继承、测试、发布、部署和基础架构管理，进行自动化和监控。目标在于缩短开发周期，提供部署频率和更可靠地发布。

持续交付1.0

部署流水线模式的四条指导原则：

1）每个构建阶段都应该交付可运行的软件；

2）用同一个制品部署在不同的环境，将制品和运行时配置分离；

3）自动化的测试和部署；

4）部署生产线设计需要随着应用程序的发展而不断变化。

持续交付1.0提供的很多原则及方法是DevOps的具体实操指南，可以为企业将DevOps落地提供具体的指导。

持续交付1.0

敏捷开发方法：更多地涉及产品需求方、软件开发工程师和软件测试工程师

DevOps：更多地涉及软件开发工程师、软件测试工程师和运维工程师

持续交付1.0：涉及点涵盖以上两个开发方法

不同软件开发方法的涉及点

持续交付1.0关注“从代码提交到产品发布”的流程，如下图：

持续交付1.0的关注点

缺点：难以评估一些软件需求开发完成之后是否对用户和业务的影响，难以验证功能是否对用户有用，存在着无形的浪费。

持续交付2.0

精益思想：开发新产品时，先做出简单的最小化可行性产品（MVP），用于验证自己心中的商业假设。得到用户的真实反馈之后，在每次实验中学习，通过敏捷的快速迭代持续优化以适应市场的需求。精益的过程是一个“开发-测量-认知”的验证学习的过程，识别和消除整个生产过程中的浪费。

持续交付2.0的双环模型：为了在VUCA环境中更加了解用户，快速验证大量的业务假设和解决方案，逐步形成了互联网软件产品研发管理的双环模式。

持续交付2.0

持续交付2.0是一种产品研发管理思维框架，将精益思想和持续交付1.0思想相结合，强调业务和IT间的快速闭环，以“精益”为知道思想，识别和消除一切浪费，通过一系列工作原则和实践，帮助企业以一种可持续方式高质量、低成本、无风险地交付客户价值。

第一环：探索环

识别和定义业务问题，制定出最小可行解决方案，包含四个循环步骤，分别为提问、锚定、共创和精炼。

1）提问：定义问题，针对性提问找出客户的真实需求和其背后的原因，形成团队需求达成的业务目标或者想要解决的业务问题

2）锚定：定义结果目标指示器，根据问题经过分析和过滤之后，识别问题假设，得到适当的衡量指标项，描述当前的状况和期望达成的结果

3）共创：共同探索和创造解决或验证该问题的多种觉有可行性的解决方案

4）精炼：对所有的可行试验方案进行选择，找到最小可行性解决方案。

第二环：验证环

以最快的速度交付最小可行方案，可靠地收集真实反馈。包括四个可持续循环的步骤，即构建、运行、监测和决策。

1）构建：将最小可行性解决方案转化成可运行的软件包

2）运行：将达到满足质量要求的软件包部署到生产环境或交付到用户手中

3）监测：收集生产中的数据并展示出来，并对系统进行监控，保证其正常运行

4）决策：根据收集到的数据与探索环的目标进行对比分析，做出决策指导下一步的方向

双环的四个核心原则

1）坚持少做

需求永远做不完，需求并不是做得越多越好，坚持少做，想办法对新创意尽早验证。Netfilx认为，他们想做的事情中，可能有90%是错误的。微软统计指出，那些旨在改进关键指标而精心设计和开发的功能中，只有1/3左右成功改进了关键指标。

2）持续分解问题

复杂的业务系统中一定存在着大量的不确定因素，通过对问题的层层分解，使更加深入业务，更早地识别出风险。即使再大的课题和变更，都可以将其分解为一系列小变更，快速解决并得到反馈，将一次持续数月的一次性发布，分解为不断地尝试新想法并各自独立交付给用户。

3）坚持快速反馈

通过对需求分解之后的小变更的快速反馈，确认风险降低和解除，尽早了解完成工作的质量和效果。

4）持续改进并衡量

找到适当的衡量方式，并将之放在与需求同等重要的位置，只有通过数据的衡量才能分析出需求是否能够满足用户的需求，以及确认下一步的着手方向。

持续交付七巧板

持续交付双环模型涉及企业内的多个部门和不同角色，无法由某个部门独立实施，必须在整个组织范围内贯彻执行持续交付2.0的思想、原则和理念。企业需要在组织管理机制、基础设施以及软件架构等多个方面行动，如下图：

持续交付七巧板

每个企业的实施路径可能存在着不一致，所需的周期也不一样，需要根据每个企业自己的意愿和诉求，实事求是，拼出属于自己的持续交付实践地图。