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

创新互联公司长期为1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为双台子企业提供专业的网站制作、做网站，双台子网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。

本期课程将围绕着敏捷产品开发维度，从敏捷开发的目标、定义和提高持续交付能力、敏捷在持续交付的基础上的创新实践和全栈敏捷四个维度，带我们探索敏捷研发的冰山一角。

大家好，今天我们分享的主题是：《从持续交付到业务创新》，我将从敏捷产品开发讲起。

从本质上讲敏捷开发的一个重要目标是建立持续价值交付的能力。这种能力最终必须服务于业务的创新，促进业务的成功。相对应的，今天分享的内容，包含两个方面，第一：什么是持续交付以及如何建立持续交付能力；第二：以持续交付能力为基础，落实业务创新的实践，形成有效的创新闭环。这是今天分享题目——“从持续交付到业务创新”的由来。具体包含以下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 倍效能提升。

​​立即体验​​

网站标题：从持续交付到业务创新（上）：互联网时代研发效能的核心
文章位置：http://hbruida.cn/article/dscggis.html