关于持续交付:从持续交付到业务创新上互联网时代研发效能的核心

本期的分享嘉宾是阿里巴巴阿拉丁团队的资深技术专家何勉老师，何老师也是国内最早的精益产品开发实践者之一，专一于产品开发和产品设计及翻新两方面的摸索和实际，帮忙组织晋升效力，使其顺畅、高质量交付有用价值。

本期课程将围绕着麻利产品开发维度，从麻利开发的指标、定义和进步继续交付能力、麻利在继续交付的根底上的翻新实际和全栈麻利四个维度，带咱们摸索麻利研发的冰山一角。

大家好，明天咱们分享的主题是：《从继续交付到业务翻新》，我将从麻利产品开发讲起。

从实质上讲麻利开发的一个重要指标是建设继续价值交付的能力。这种能力最终必须服务于业务的翻新，促成业务的胜利。绝对应的，明天分享的内容，蕴含两个方面，第一：什么是继续交付以及如何建设继续交付能力；第二：以继续交付能力为根底，落实业务翻新的实际，造成无效的翻新闭环。这是明天分享题目——“从继续交付到业务翻新”的由来。具体蕴含以下 4 个局部：

第一：麻利开发的指标；

第二：定义和进步继续交付能力；

第三：在继续交付的根底上落实翻新实际；

最初是一个总结，咱们会提出全栈麻利 Full Stack Agile 的概念，它是技术和治理的综合，也是交付和翻新的综合。

第一局部：麻利开发业务指标

咱们常常会说麻利模式，那什么开发模式是不麻利呢？对，咱们通常说“瀑布”是不麻利的。

瀑布开发模式把开发分成一系列阶段，如需要、设计、开发、测试，就像上图它画进去的，看起来很像瀑布，所以叫瀑布开发。问题是需要的交付难道不都是要经验这些阶段吗？

瀑布开发的实质问题并不是阶段，而是批量。需要批量地在一起进行设计，而后是批量地开发，批量地测试、交付等等。批量有什么问题? 首先，批量让价值交付提早，所有需要在最初的阶段能力交付，价值交付比拟晚。

价值交付比拟晚又怎么样？看这幅图。右边是 Intel 的创始人摩尔，摩尔定律的提出者。摩尔定律通知咱们，18 个月之后，用同样的钱能买到多一倍的货色，比方计算能力、存储量、晶元数等等。而左边这位是 Google 执行董事长施密特，他提出了反摩尔定律，表述为：“如果 18 个月之后咱们只能卖出跟明天一样的货色，咱们就只能失去一半的支出”。

反摩尔定律是摩尔定律的一个简略推论，它通知咱们，越迟交付的价值也是越低的价值。对硬件公司这很要害，甚至决定它们的的宿命——技术提高必须跟得上摩尔定律，否则利润就会被摩尔定律吞噬，让产品或公司走向灭亡。

软件或互联网服务又怎么呢? IBM 在上世纪 90 年代，意识到不能做一家硬件公司，转而主攻服务和软件行业，它确实过了一段好日子。然而，很快互联网时代到来了，软件和服务行业的翻新一下子减速了。这时，绝对硬件公司，反摩尔定律在软件和互联网服务公司的作用是有过之而无不及的，工夫的迟早可能不仅仅决定价值的多少，有时错过整工夫窗，可能会满载而归。

反摩尔定律通知咱们，越迟交付的价值也是越低的价值。所以对于软件开发来说，瀑布模式提早了价值交付，失去的价值也更少。绝对瀑布，咱们提出了迭代交付，咱们把开发分成迭代，每个迭代交付一部分价值，更早交付的价值往往意味着更多的价值。就这一点来说，迭代绝对瀑布的实质是，更小批量的疾速交付，从而更早获取更多价值，和获取市场竞争的先机。

所以麻利开发有第一个指标就是更快的交付价值，这里的快指的不是绝对速度，而是更早的交付。

第二点，咱们再看一个坐标图，这个坐标是我的项目的工夫历程，最左是我的项目开始，最右是我的项目完结。纵坐标是团队领有的这个我的项目和产品的常识，比如说用户要什么，采取什么样的产品计划，应该做什么样的性能，以怎么的模式来合作，抉择什么样的技术计划等等。

咱们想问一下团队（包含产品也包含开发、业务）什么时候对于产品和我的项目的常识最充沛、最多？大家的答案都很统一，我的项目完结的时候。这不言而喻，咱们在我的项目过程中积攒了常识，特地是当向用户交付产品后，用户反馈：“我要的不是这个啊，我说的明明是…”，这时候你霎时狂涨常识，并感叹道“你怎么不早说呢？”。这两头可能有沟通问题，但更多可能的是，用户这时才分明或可能形容他们要的是啥，更有甚者，咱们可能一开始连用户是谁也未必能精确的定义。产品和业务开发原本就是一个摸索的过程，开始时肯定是最无知的时刻。

再问一个问题。我的项目中的大部分决策，是什么工夫做出的呢？大家的答案也很明确——我的项目开始的时刻。这里埋藏了一个重大的悖论，咱们在最无知的时刻，做出了最重要而且是绝大部分的决策，并把它作为随后执行的根据。面对不确定的技术、市场环境，传统开发模式已无奈适应要求，悖论越发突出。

对于这一悖论，麻利的对策还是迭代。开始时，咱们会做出一些初始的决策，比如说总体目标是什么，大略的策略和打法是什么，从哪里开始，怎么测验等等。但这些只是初始决策，定义了大抵的方向。在整个开发过程，咱们迭代交付需要，获取市场的反馈和最新的信息，并基于这些反馈和信息，积攒和修改对产品的认知，增量地决策和调整。

产品开发过程中，技术环境、市场环境、竞品策略、团队认知都会发生变化。面对变动的环境，咱们必须抵赖本人的无知，在开发过程被动无效地学习，一直地吸取反馈，灵便地调整。这也是麻利的第二个业务指标，无效学习和灵便响应变动。

综合下面提到的麻利开发的两个业务指标，咱们就能够给麻利开发下一个定义了。麻利指的是创立一个组织更快（早）的交付价值，和更无效学习和灵活应变的能力。

从能力的角度，麻利的外围是继续交付价值的能力，以及以继续交付为根底的疾速反馈学习能力。为了具备这样的能力，产品的开发和交付形式须要做出根本变化。这幅图从概念上体现了，传统批量式的开发方式到麻利的继续交付形式的转变。

传统开发方式下，需要成批量的流经各个阶段和组织部门，如产品、UED、开发、测试、经营等直至交付，各个职能各自优化本人的工作，造成效率竖井。因为批量的起因，需要期待整个批量实现，能力集中进入下一阶段。从单个需要的角度看，需要大部分工夫都处于期待状态。

上图的右半局部表白了这一过程，单个需要的理论解决的工夫很短（图中折线中下面绿色的短线），它们大部分工夫都处于期待状态（图中折线上面红色的长线），最终体现出的理论交付周期很长。

通过麻利施行，咱们心愿整个组织协调一致，更严密合作，缩短交付周期。图中左半局部是现实的麻利开发模式，它体现了麻利开发的根本指标——继续价值交付和疾速反馈、学习，这其中继续价值交付是根底。

问题是如何能力建设和改良继续价值交付能力呢？

第二局部：定义和晋升继续交付能力

管理学之父德鲁克说：“如果你不能度量它，你就无奈改良它”。对于继续交付能力，这同样实用。

无效的度量体系应该围绕外围问题开展。在这里，这个基本问题就是团队的继续价值交付能力如何？咱们将用五组指标来答复这一问题，它们别离是：

第一：公布能力，具体蕴含两个细分指标，别离是：1）公布频率，也就是团队均匀多长时间公布一次需要。它束缚了团队对外响应的最大可能；2）公布前置工夫，也就是从代码提交，到性能上线所须要破费的工夫。如果工夫开销很大，团队就不太可能去加大发版的频率。

第二：需要响应周期，它蕴含两个细分的指标，别离是：1）交付周期时间，也就是从用户提出需要并被确认，到需要上线所要经验的时长。它反映团队（蕴含业务、开发、经营等职能）对客户问题或业务机会的整体响应速度；2）开发周期工夫：从开发团队了解并确认需要，到需要能够上线所经验的时长。它反映研发的响应能力。前面咱们还会更具体解读两个周期。

第三：交付的吞吐率，也就是单位工夫内交付的需要的个数。

第四：内建品质的能力，也就是整个交付过程的品质。它蕴含两个细分的指标，别离是：1) 开发过程中缺点的创立和修复工夫的散布。咱们心愿缺点可能及时且继续的发现，并且在发现后尽快修复；2）缺点库存，咱们心愿能在整个开发过程中管制缺点库存量，让产品始终处于靠近可公布状态，奠定继续交付的根底。对于内建品质的能力的具体度量办法，咱们前面还会具体介绍。

第五：对外交付品质。它蕴含两个细分的指标，别离是：1) 单位工夫（线上）问题数目；2）（线上）问题均匀解决时长。

好的度量体系应该答复一个基本问题，并为此讲述残缺的故事。为答复团队交付能力如何这一问题，下面 5 组指标，别离从响应能力、效率和品质三个方面提供一个残缺的故事。其中，继续公布能力和需要响应周期这两组指标反映的是响应能力，也就是价值的流动效率；交付吞吐率这一指标反映的是团队效率，也就是资源的产出效率；内建品质的能力和对外交付品质这两组指标是质量指标。这些指标综合起来，让咱们能够全面理解以后交付等能力，与指标的差距，以及改良的机会。

以上是度量体系的总体设计，咱们把周期时间作为掂量团队响应能力的外围指标。这幅图更直观地展现了两个周期时间的计算形式，以看板的工作流为根底，客户周期时间的终点是从需要被抉择开始，到需要公布完结；开发周期工夫则从待开发开始，到待发布完结。

基于下面的度量指标体系，咱们抉择和设计了相干的图表，来出现这些度量。上面咱们介绍其中的一些例子。

第一是累积流图。累积流图再现了团队合作交付价值的过程，它的横坐标为日期，纵坐标为各阶段累积实现的需要数目。从左至右的各条线，反映各个阶段累积解决实现的需要数量。例如：图中最下面这条线是曾经就绪的需要的个数，最上面这条线是曾经上线的需要的个数，两头这条线别离是曾经开发的、开发完结的、曾经测试的、测试完结的等等。

累积流图综合反映了均匀交付周期、在制品数量、达到和交付速率三类指标。

第一：均匀交付工夫。交付工夫指需要交付之前从开始到完结所经验的工夫。图中，到 3 月 26 日这一天累积打算了 40 个需要，而到 5 月 15 日这一天累积交付了 40 个需要。假如需要合乎先入先出（先打算的先交付）的法则，那么第 40 个需要的交付周期时间就是 5 月 15 日 – 3 月 26 日 = 50（天）。之所以要在交付工夫之前加上“均匀”，是因为并非所有的需要都是先进先出。从累积流图上还能够进一步看出交付工夫在各个阶段的散布。

第二：在制品的数量。在制品（Work in Process）指正在解决的需要的数目，也就是所有开始但还没有实现的需要的数目。如：上图中 4 月 15 日这一天，累积开始的需要有 61 个，累积上线的需要是 8 个。在制品数量 = 61- 8 = 53（个），它们曾经开始，但还没有交付。从累积流图上还能够进一步看出在制品在各个阶段的散布，如开发中的，待测试的，测试中的等。

第三：需要的达到和交付速率。指单位工夫内达到和交付需要的数目。图中，从 3 月 1 日到 3 月 30 日，4 周工夫交付需要数目从 10 个减少到 50 个，共交付 40 个需要，达到速率 = 40 / 4 = 10（个 / 周）。从 4 月 1 日到 4 月 30 日，4 周工夫交付需要数目从 10 个减少到 30 个，共交付 20 个需要，达到速率 = 20 / 4 = 5（个 / 周）。从累积流图上还能够看出不同阶段的产出速率，以及它们的变化趋势。

累积流图再现了团队合作和交付过程，从中咱们可能解读出团队的开发模式，演变趋势和改良机会等。例如：从图中上边线阶梯能够看到批量打算模式，而 4 月开始打算的批量变得更小，公布频率加大，相应的并行的在制品的数目也变少了，周期时间随之变短了，交付的效率（交付线的斜率）也有所提高。

咱们再看另一幅图表——缺点趋势图，它反映了团队引入、发现及移除缺点的行为模式。图形的横坐标是日期，横坐标上方红色竖条代表当天发现缺点的数量；横坐标下方绿色竖条代表当天解决的缺点的数量；橙色曲线代表缺点存量。通过缺点趋势图心愿疏导用户的行为是：继续且尽早发现缺点并及时移除它们，从而管制缺点库存，保证系统随时处于靠近可公布状态，奠定继续交付的根底。上图的左右两个局部比拟了两种交付模式下的缺点趋势图。

左半局部：“迭代”后期团队集中设计、编码引入缺点，但因为并未即时的集成和验证，缺点未被即时发现。到了我的项目前期团队开始集成和测试，缺点集中暴发。小瀑布模式过程品质差，带来大量的返工、延期、赶工和交付品质问题。该模式下，产品的交付工夫依赖于何时缺点被充沛移除，无奈做到继续交付，升高了团队对外的响应能力。

右半局部：在整个迭代过程中，团队以小粒度的需要为单位开发、集成、测试，即时发现并解决问题。这样，缺点库存失去管制，零碎始终处于靠近可公布状态，做到继续公布，进步团队对外的响应能力。缺点趋势图能够从一个侧面反映团队的开发及交付模式，掂量团队的继续交付能力，疏导团队向继续交付演进。

好的度量应该为答复一个基本问题，讲述残缺的故事。咱们答复的问题是团队继续交付能力及其改良机会，并针对这个问题讲述了残缺的故事。也正是基于以上的体系，云效我的项目域对度量体系做了一次重构。下面的图是一个概念阐明，大家能够去应用，咱们也会依据大家的反馈，继续优化度量体系的设计。

基于这样的度量体系，咱们应该设定怎么的指标呢？最近咱们在阿里外部做团队效力改良时，提出了称之为“2-1-1”的愿景，失去了不少部门的认可。什么是 211 呢？“2”指的是交付周期 2 周——85% 以上的需要能够在 2 周内交付；第一个“1”指的是开发周期 1 周——85% 以上的需要能够在 1 周内开发实现；第二个“1”指的是公布前置工夫 1 小时——提交代码后能够在 1 小时内实现公布。

明天，很多团队离“211”还是有间隔的，特地是这个“2”，它波及到整个组织各职能，和部门的协调一致，严密合作。一小时的公布前置工夫，则须要继续交付流水线，产品架构体系和自动化测试、部署等无力保障。达成“211”并不容易，但它体现了组织晋升继续交付和疾速响应能力的指标，建立了继续改良的方向，因而咱们才把它作为愿景。

备注：以上理念也将落地到研发工具云效（阿里外部叫 Aone）中，从交付流程、交付后果、交付品质等数据也可在云效的度量性能中查看。

以上咱们定义了什么是继续交付能力，并制订了愿景性的指标，问题是咱们如何能力达成这一指标呢？让咱们先看一幅漫画。

这是一个酒吧，路灯下醉汉在找什么货色，很长时间过来了，警察始终看着他，终于忍不住走上前，问道：“你在找啥？”。醉汉说：“找我的钥匙”。警察看了一下钥匙如同不在这，就问：“钥匙是丢在这吗？”醉汉说：“不是”。警察奇怪的问道：“那你为什么在这找？”。“只有这儿能看到啊”醉汉答复道。

钥匙（key）英文的也是要害的意思。光照亮的中央却不是关键所在。我讲这个故事，是为了阐明研发中一个常见的问题——在光照亮的中央，而不是关键所在的中央寻找答案，当然不会有后果。那研发过程的关键所在到底在哪里呢？

《The Principles of product development flow》一书的作者 Don 指出：“在产品开发中，问题的要害简直从来不是停滞的资源，而是停滞的需要”。这是什么意思呢？产品开发的最终目标是交付价值，那咱们就必须让价值交付的过程顺畅起来，也就是让价值流动顺畅起来。打算、治理、协调流动，以及资源的配置等等，都应该服务于价值的流动。价值流动是目标，资源忙起来不是。

事实中咱们更多关注资源是否停滞，人是否闲着，但真正的问题并不在这儿。真正的问题是需要的停滞，需要在各个阶段的积压——如分析阶段、测试阶段、公布阶段等等。需要不能顺畅流动才是真正的问题所在，也就是咱们所说的关键所在。

为什么咱们往往对需要的积压很少关注？因为它很难看到，不是光照亮的中央。咱们很难发觉（至多很难即时的觉察）需要的停滞、积压和返工，而那才是改良价值交付的关键所在。

要改良端到端的流程，咱们必须看到价值端到端的流动过程，在哪里呈现了积压和停滞。为此，改良的第一步，就是要让光照亮关键所在——可视化端到端的价值流动过程，基于价值流发现流动过程中的问题。

看一个例子，它是来自某个产品团队看板。看板中蓝色卡片的是需要。让光照亮关键所在，就是要让需要流动的端到端过程可视化。需要从“抉择”开始，所谓抉择是指从泛滥的市场机会中抉择这些需要开始开发。抉择之后是流程中的其余阶段，比方需要的设计、开发、测试、验收等，直至公布，这是一个端到端的过程。

咱们独自看“开发中”这个阶段，在这里需要被合成成为工作——图中黄色纸条。工作与其所属于的需要处于同一行中，咱们把这样的行成为泳道。泳道的首列（蓝色纸条）是需要，上司工作（黄色卡片 ) 按模块组织在一起，如前端、后端或其余依赖的内部模块，其中工作的最初一列代表实现状态，所有工作实现后，需要进入下一阶段——待测试。

端到端可视化需要的流动过程，从需要被抉择开始，直到公布完结。这让咱们能即时看到问题，如：需要是否顺畅流动，是否产生了停滞和积压，是否有瓶颈。这就是所谓：光照亮了问题所在。

除此之外，咱们还要保障价值流动的过程品质，把交付品质内建到开发过程中，而不是依赖最初环节的测试。为了做到内建品质，咱们须要明确定义需要流动的规范，上图显示了需要进入开发环节要满足的输出规范，在这个例子中，它被定义为：1）需要的用户应用流程和验收规定清晰定义；2）依赖方可能被辨认；3）大的需要拆分成在两周以内或者一周以内的小需要，等等。咱们还能够定义其它阶段的规定，如开发输入（也就是转测试）的规定。这也是照亮关键所在一部分。

照亮关键所在，看到需要端到端流动的过程，以及流动中的问题和瓶颈是第一步。更要害是看到问题后要怎么做？以可视化端到端的价值流动为根底，咱们心愿价值可能顺畅流动，从左到右，不要产生停滞和积压。如何做到呢？让咱们再看一个故事。

图中这位叫潘季驯，他是明朝治理黄河的水利专家，被称为“千古治黄第一人”，咱们明天要讲的就是他治理黄河的故事。治黄河难，难在泥沙一直淤积。清淤是治理黄河的传统方法，问题是清了又会淤，年复一年。少量的河工汇集，又为造反提供条件，元朝的覆灭就与之关系甚大。不治则民不聊生，治则劳民伤财，这是摆在历代统治者背后的两难决定，明朝也不例外。

嘉靖到万历年间潘季驯四次临危受命治理黄河，获得前所未有的功效，并总结了切实可行的方略，其中最为重要的思维就是“束水攻沙”。什么是“束水攻沙”呢？潘季驯在治理黄河时既没有蛮力清淤，也不是一味地加高、加宽河堤。他反其道而行，收窄河堤——在大堤（称为遥堤）内再修筑一道更窄的堤（称为缕堤），遥堤用以防溃，缕堤用以束水。河堤收窄了，水流的速度就会放慢，将沉积的泥沙带走，这就是所谓 ” 束水攻沙 ”。

“束水攻沙”与产品开发有什么关系呢？“束水”放慢了水的流速，也带走了泥沙。对应的，产品开发中咱们也要限度并行需要的数量，同样是为了缩短需要从开始到实现的均匀交付周期——放慢流速，并即时发现和解决交付过程中的问题——带走泥沙。咱们来看具体的例子。

在上图中，泳道数束缚了并行需要的数目。并行需要缩小，需要流动的速度随之放慢, 从而缩短开发和交付周期。更重要的是，限度并行能更快裸露问题。无限泳道中的需要产生阻塞，很容易被发现。团队必须尽快解决阻塞的问题，能力开始新的需要。而即时解决问题又促成了价值的顺畅流动。

基于端到端的价值流，团队能够更好的治理价值流动。以站会为例，团队在站会上，会去扫视需要的状态。这外面有两个策略，一种是从左向右扫视，还有一个从右往左扫视，大家认为哪个适合？对，大家都说从右往左。为什么呢？因为咱们应该聚焦于实现而不是开始，咱们应该聚焦于尽快的交付，比方测试中的需要是不是有缺点，并优先解决这些缺点，好让需要尽快上线；开发中的需要，有没有妨碍，并即时解决这些妨碍，实现它们。只有这样，新的期待开发的需要才可能开始。

站会的外围是通过扫视价值流动，关注需要流动中的缺点、妨碍、停滞、期待和瓶颈，即时发现和解决这些问题，促成需要更晦涩流动。站会只是一个例子，围绕看板的其余流动，比如说度量数据分析和改良口头的制订，都是为了促成价值流动，而价值的顺畅流动是响应能力、品质和效率的保障。

此电子看板截图来自阿里云云效

下面举例用的都是物理看板，是为了让大家更有体感。当初绝大部分团队，不论是阿里云，技术中台还是闲鱼，用的都是云效电子看板。通过继续的优化，电子看板操作体验曾经与物理看板靠近。并且具备物理看板不具备的劣势，比方：后面讲到的数据度量都能够主动生成，这对于发现问题和改良很有意义，还有就是与其余零碎如文档和公布工具的无缝集成。这是优酷电子看板的截图。

看板帮忙团队裸露问题，具体的改良口头还是要落实到不同方面的。咱们能够用湖水岩石效应来形容这一过程。这是一个湖，湖里有一些石头。湖水比拟深时，石头都暗藏在湖面之下，但其影响是在的；当湖面升高，石头就会渐次裸露进去。

在产品开发中，石头暗喻的是问题，而湖水的深度暗喻交付周期长短（或并行需要的数目）。当需要的交付周期长时，问题被暗藏，咱们看到的是平坦的水面。只有水位升高，问题才会裸露。

以某个中间件团队的效力改良过程为例。他们原先采纳小瀑布的模式，没有继续集成和无效自动化，以月度为周期交付产品，需要在月初集中开始，在月底集中转测试和公布，对外交付品质和效率始终不让人称心，外部的合作也有很多问题，每次公布都异样苦楚，延期的状况时有发生, 但大家对问题本源和解决方案却各执一词。

在精益和麻利开发施行过程中，咱们首先做的是可视化价值流动，并以此为根底逐渐减小并行需要的数目，力求需要的继续流动——继续小批量的输出、开发、转测试和交付。在减小批量的过程中，问题逐步裸露。

在这个案例中，为了做到小批量的流动，首先裸露的是需要剖析和拆分的问题，也就是如何将需要拆分成能够独立测试、验证和交付的小的单元。通过引入“实例化需要”（一种需要廓清、剖析和拆分的办法）等办法，这一问题失去了解决，开发和测试移交的批量显著减小了。

很快新的问题又呈现了，测试环境或移交给测试的版本总是不可用，需要还是不能顺畅流动，这时继续交付流水线的建设的重要性就凸显进去。当然继续交付流水线的建设也并不是一步实现的，一开始咱们只是买通了管道，并引入了最根本的主动验证，保障测试随时都有一个可用的环境和版本可用。接下来才是自动化对要害性能的笼罩。在其后组织协调沟通，技术架构等问题也渐次裸露。

过程中，咱们感触到最大的益处是，只管解决问题的过程还是比拟苦楚，但咱们能够集中精力一个工夫解决一个被裸露的实在问题，而解决它们也会带来立刻可感知的受害，这大大晋升了团队继续投入解决问题的能源。

这个团队，多年未能解决的问题，在短短三、四个月内被一一解决，在没有投入额定资源的状况下，研发效力失去基本改善，品质、响应能力都有了质的晋升。我对此也深有感触——研发效力改良实际的技术难度，并不比咱们平时做的业务零碎难。但为什么总是得不到施行呢？这个团队有做对了什么。

这外面的基本问题不是能力问题，也不是意识和态度问题。更重要的是：要让团队看见问题，并且提供适合的门路，一个工夫解决一个问题，并且解决问题后要能看到立刻的想过。外围有两个，第一:“看见”，它的要害是看见零碎，看见价值的端到端流动，以此为根底看到问题和改良机会；第二：“门路”，它的要害是小步快走，但每一步都要有可感知的成绩。

图中岩石的高下，从概念上反映了随着并行的升高，问题逐步裸露的大抵程序。对不同的团队，问题和秩序会不同。但雷同的是，通过水位的升高，问题被渐次裸露和解决，产品交付的响应能力、效率和品质也会失去晋升。咱们的指标并不是要把水位降到最低，而是要发现问题，让需要能以较小的粒度顺畅流动，实现顺畅和高质量和继续的交付价值。

总结一下继续交付实际。它关注从需要到开发、测试直至部署和运维这些环节。它的指标能够总结为两个。

第一：让价值顺畅流动, 这个咱们曾经讲了很多。之前讲的实际都能促成价值的顺畅流动，如：看板、反馈改良这些治理实际，故事地图、验收测试驱动开发这类技术实际。

第二：让流动过程更加高效, 这个咱们后面没有强调。补充一下，其外围是让团队成员只须要关注带来真正价值的业务逻辑，而不须要在其余工作上破费过多工夫。咱们看看除了业务逻辑，团队还会被那些工作影响？又如何缩小这些工作？这里咱们列举了其中的一些：

• 牢靠的交付流水线: 让团队不必放心验证和部署的环境，步骤及流程
• 容器技术（如 Docker）：让团队不用过多思考构建散发及运行环境的问题
• Kubernetes：让团队不必过多思考容器利用的部署，运行，扩缩容等工作
• Sevice Mesh：让团队不必过多思考分布式服务的通信
• Severless：让团队不必过多思考服务器的实体资源
• …

到此为止，咱们曾经分享完明天上半局部的内容。继续交付价值的能力是互联网时代研发效力的外围。咱们还介绍了晋升继续交付能力的度量，以及以流动效率为抓手晋升继续交付能力的实际和门路。

问题是，建设了继续交付能力就能够保障业务的胜利吗？显然不是。继续交付能力是疾速交付价值、获取反馈并灵便调整的根底。咱们还必须以把继续交付能力转化为无效的业务翻新，带来真正的业务胜利。这也是咱们下半局部要分享的内容：《从继续交付到业务翻新（下）：无效的业务翻新》

击下方链接体验麻利理念领导下的工具云效和学习更多企业麻利实际案例。

https://www.aliyun.com/product/yunxiao?channel=yy_yccb

【对于云效】

云效，云原生时代一站式 BizDevOps 平台，反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现 10 倍效力晋升。

立刻体验