1.2　持续交付2.0

持续交付1.0关注于“从提交代码到产品发布”的过程，如图1-6所示，并且提供了一系列工作原则和优秀的实践方法，可以提升软件开发活动的效率。

图1-6　持续交付1.0的关注点

但是，我在实际咨询过程中发现，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。可是，这些功能的确花费了团队的很多精力才设计实现。这是一种巨大的浪费。这种“无用”的功能生产得越多，浪费就越大。我们是否可以找到一些方法，让我们付出的努力对业务改善更加有效，或者只用很少的成本就可以验证对业务无效呢？

1.2.1　精益思想

2011年出版的《精益创业》一书给了我一些启示。其核心思想是，开发新产品时，先做出一个简单的原型——最小化可行产品（Minimum Viable Product，MVP），这个原型的目标并不是马上生产出一个完美的产品，而是为了验证自己心中的商业假设。得到用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。

Eric Rise在书中强调，精益创业就是一个“开发—测量—认知”的验证学习过程，如图1-7所示。也就是说，把创意快速转化为产品，衡量顾客的反馈，然后再决定是改弦更张，还是坚守不移。

图1-7　“开发—测量—认知”环

该书主要关注于创业初始阶段，将精益思想贯穿于产品“从0到1”的过程。事实上，它也可以用于产品“从1到n”的过程中。

1996年，Womack、Jones和Roos在《精益思想》一书中指出：精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。

在精益管理理论中，“浪费”是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。并指出，业务生产中所有活动都可以归结为以下两种活动，也就是增加价值的活动和不增加价值的活动，而不增加价值的活动就是浪费。在被归类为“浪费”的活动中，又可以分为必要的非增值活动和纯粹的浪费。必要的非增值活动是指从客户的角度看虽没有价值，却可以避免（潜在的）更大的浪费或降低系统性风险的活动，如图1-8所示。

图1-8　软件产品开发中的活动浪费

例如，生产流水线上的装配工作是增值活动，质量检查是必要的非增值活动，而因材料供应不足产生的生产等待以及因质量缺陷导致的返工都被认为是浪费。在软件产品服务的全生命周期中，也同样包含多种“浪费”，例如，无效果的功能特性、各生产环节中的等待（如图1-9所示）、没人看的文档、软件缺陷、机械性的重复工作等。

图1-9　用户视角的增值活动与浪费

尽管“消除所有浪费”几乎是不可能的，但是，我们仍旧要全面贯彻“识别和消除一切浪费”的理念，持续不断地优化流程与工作方式，达到高质量、低成本、无风险地快速交付客户价值的目的。

1.2.2　双环模型

自2009年Flickr（一个聚合全球知名热门图片分享网站）声称其网站每天部署10次之时起，“主干开发+持续集成+持续发布”已成为硅谷知名互联网公司应对VUCA环境的一种主流软件研发管理模式。这种变化的原动力并不是来自技术团队本身，而是来自业务与产品方的诉求。为了在VUCA环境中更快地了解海量用户，快速验证大量业务假设和解决方案，他们改变了业务探索的模式，并催生了软件研发管理模式的改变，两种模式相互促进，从而形成了互联网软件产品研发管理的双环模式，即“持续交付2.0”，如图1-10所示。

图1-10　持续交付2.0的双环模型

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

对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有限的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，简称为持续交付“8”字环。

它由两个相连的环组成（见图1-10）：第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。

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

（1）提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。

（2）锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。

（3）共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。

（4）精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。

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

（1）构建，是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。

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

（3）监测，是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。

（4）决策，是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。

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

1.2.3　4个核心原则

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

1．坚持少做

在咨询的过程中，最常听到的一句话就是：“我们最大的问题是人力不足。”无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证。

Moran在Do It Wrong Quickly一书中写道：“Netflix认为，他们想做的事情中，可能有90%是错误的。”Ronny Kohavi等共同发布的文章“Online Experimentation at Microsoft”中也指出，在微软，“那些旨在改进关键指标而精心设计和开发的功能特性中，只有1/3左右成功地改进了关键指标”。

正如当年Mike Krieger（Instagram的联合创始人兼CTO）被问及“5个工程师如何支持4000万用户”时所说的那样——“少做，先做简单的事情”。

2．持续分解问题

复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法，并各自独立发布给用户。

3．坚持快速反馈

当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。

4．持续改进并衡量

无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。

某数据公司就曾因无度量数据，而无法提出有效改进方向的情况。该系统是一个数据标注志愿者招募考试系统。虽然它被分成多个迭代，每个迭代都发布了很多功能，但是，由于没有实现产品人员所关注的数据收集与统计分析功能，使得团队仅知道人们可以使用这个系统完成工作，却无法知道是否能够高效完成工作，也很难提出下一步的产品优化方向。

1.2.4　持续交付七巧板

我们讨论了“持续交付2.0”的指导思想、工作理念和核心原则。大家很容易意识到，它对适应快速变化的市场环境和激烈的市场竞争是非常有效的。那么，企业如何让“持续交付2.0”成为一种组织能力，成为组织的DNA，持续发挥作用，从而领先竞争对手，成为自己的一种竞争优势呢？

持续交付双环模型的实施与改进将涉及企业内的多个部门与不同的角色，无法由某个部门独立实施，必须在整个组织范围内贯彻执行“持续交付2.0”的思想、理念与原则。企业需要在组织管理机制、基础设施以及软件系统架构3个方面付诸行动，而每一个方面都包含多项内容，如图1-11所示。

图1-11　持续交付七巧板

条条大路通罗马，而且，罗马也不是一天建成的。每个企业的实施路径可能各不相同，所需要的周期也各有长短，对各方面的能力需求也不完全一致。正如中国传统玩具七巧板一样，每个企业都应根据自己的意愿和诉求，拼出属于自己的持续交付实践地图。