如何在2周内交付85%以上需求？阿里工程师这么作

提高持续交付能力

最近咱们在阿里内部作团队效能改进时，提出了称之为“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）大的需求拆分红在两周之内或者一周之内的小需求，等等。

咱们还能够定义其它阶段的规则，如开发输出（也就是转测试）的规则。这也是照亮关键所在一部分。

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

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

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

“束水攻沙”与产品开发有什么关系呢？“束水”加快了水的流速，也带走了泥沙。对应的，产品开发中咱们也要限制并行需求的数量，一样是为了缩短需求从开始到完成的平均交付周期——加快流速，并即时发现和处理交付过程当中的问题——带走泥沙。咱们来看具体的例子。

在上图中，泳道数约束了并行需求的数目。并行需求减小，需求流动的速度随之加快，从而缩短开发和交付周期。更重要的是，限制并行能更快暴露问题。有限泳道中的需求发生阻塞，很容易被发现。团队必须尽快解决阻塞的问题，才能开始新的需求。而即时解决问题又促进了价值的顺畅流动。

基于端到端的价值流，团队能够更好地管理价值流动。以站会为例，团队在站会上，会去审视需求的状态。这里面有两个策略，一种是从左向右审视，还有一个从右往左审视，你们认为哪一个合适？对，你们都说从右往左。为何呢？由于咱们应该聚焦于完成而不是开始，咱们应该聚焦于尽快地交付，好比测试中的需求是否是有缺陷，并优先解决这些缺陷，好让需求尽快上线；开发中的需求，有没有阻碍，并即时解决这些阻碍，完成它们。只有这样，新的等待开发的需求才可以开始。

站会的核心是经过审视价值流动，关注需求流动中的缺陷、阻碍、停滞、等待和瓶颈，即时发现和解决这些问题，促进需求更流畅流动。站会只是一个例子，围绕看板的其余活动，好比说度量数据分析和改进行动的制定，都是为了促进价值流动，而价值的顺畅流动是响应能力、质量和效率的保障。

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

上面举例用的都是物理看板，是为了让你们更有体感。如今绝大部分团队，不论是阿里云，技术中台仍是闲鱼，用的都是云效电子看板。通过持续的优化，电子看板操做体验已经与物理看板接近。而且具有物理看板不具有的优点，好比：前面讲到的数据度量均可以自动生成，这对于发现问题和改进颇有意义，还有就是与其余系统如文档和发布工具的无缝集成。这是优酷电子看板的截图。

看板帮助团队暴露问题，具体的改进行动仍是要落实到不一样方面的。咱们能够用湖水岩石效应来描述这一过程。这是一个湖，湖里有一些石头。湖水比较深时，石头都隐藏在湖面之下，但其影响是在的；当湖面下降，石头就会渐次暴露出来。

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

以某个中间件团队的效能改进过程为例。他们原先采用小瀑布的模式，没有持续集成和有效自动化，以月度为周期交付产品，需求在月初集中开始，在月底集中转测试和发布，对外交付质量和效率一直不让人满意，内部的协做也有不少问题，每次发布都异常痛苦，延期的状况时有发生，但你们对问题根源和解决方案却各执一词。

在精益和敏捷开发实施过程当中，咱们首先作的是可视化价值流动，并以此为基础逐步减少并行需求的数目，力求需求的持续流动——持续小批量的输入、开发、转测试和交付。在减少批量的过程当中，问题逐渐暴露。

在这个案例中，为了作到小批量的流动，首先暴露的是需求分析和拆分的问题，也就是如何将需求拆分红能够独立测试、验证和交付的小的单元。经过引入“实例化需求”（一种需求澄清、分析和拆分的方法）等方法，这一问题获得了解决，开发和测试移交的批量明显减少了。

很快新的问题又出现了，测试环境或移交给测试的版本老是不可用，需求仍是不能顺畅流动，这时持续交付流水线的建设的重要性就凸显出来。固然持续交付流水线的建设也并非一步实现的，一开始咱们只是打通了管道，并引入了最基本的自动验证，保证测试随时都有一个可用的环境和版本可用。接下来才是自动化对关键功能的覆盖。在其后组织协调沟通，技术架构等问题也渐次暴露。

过程当中，咱们感觉到最大的好处是，尽管解决问题的过程仍是比较痛苦，但咱们能够集中精力一个时间解决一个被暴露的真实问题，而解决它们也会带来当即可感知的受益，这大大提高了团队持续投入解决问题的动力。

这个团队，多年未能解决的问题，在短短3、四个月内被一一解决，在没有投入额外资源的状况下，研发效能获得根本改善，质量、响应能力都有了质的提高。我对此也深有感触——研发效能改进实践的技术难度，并不比咱们平时作的业务系统难。但为何老是得不到实施呢？这个团队有作对了什么。

这里面的根本问题不是能力问题，也不是意识和态度问题。更重要的是：要让团队看见问题，而且提供合适的路径，一个时间解决一个问题，而且解决问题后要能看到当即的想过。

核心有两个：

 ●  第一：“看见”，它的关键是看见系统，看见价值的端到端流动，以此为基础看到问题和改进机会；
 ●  第二：“路径”，它的关键是小步快走，但每一步都要有可感知的成果。

图中岩石的高低，从概念上反映了随着并行的下降，问题逐渐暴露的大体顺序。对不一样的团队，问题和次序会不一样。但相同的是，经过水位的下降，问题被渐次暴露和解决，产品交付的响应能力、效率和质量也会获得提高。咱们的目标并非要把水位降到最低，而是要发现问题，让需求能以较小的粒度顺畅流动，实现顺畅和高质量和持续的交付价值。

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

 ●  第一：让价值顺畅流动,这个咱们已经讲了不少。以前讲的实践都能促进价值的顺畅流动，如：看板、反馈改进这些管理实践，故事地图、验收测试驱动开发这类技术实践。
 ●  第二：让流动过程更加高效,这个咱们前面没有强调。补充一下，其核心是让团队成员只须要关注带来真正价值的业务逻辑，而不须要在其余工做上花费过多时间。

咱们看看除了业务逻辑，团队还会被那些工做影响？又如何减小这些工做？这里咱们列举了其中的一些：

 ●  可靠的交付流水线：让团队不用担忧验证和部署的环境，步骤及流程。
 ●  容器技术（如Docker）：让团队没必要过多考虑构建分发及运行环境的问题。
 ●  Kubernetes：让团队不用过多考虑容器应用的部署、运行、扩缩容等工做。
 ●  Sevice Mesh：让团队不用过多考虑分布式服务的通讯。
 ●  Severless：让团队不用过多考虑服务器的实体资源。
 ●  …

持续交付价值的能力是互联网时代研发效能的核心。咱们介绍了提高持续交付能力的度量，以及以流动效率为抓手提高持续交付能力的实践和路径。

问题是，创建了持续交付能力就能够保证业务的成功吗？显然不是。持续交付能力是快速交付价值、获取反馈并灵活调整的基础。咱们还必须以把持续交付能力转化为有效的业务创新，带来真正的业务成功。

阿里内部分享

 

做者： 何勉
原文连接
本文为云栖社区原创内容，未经容许不得转载。

双十一广告：阿里云双十一1折拼团活动:已满6人,都是最低折扣了 【满6人】1核2G云服务器99.5元一年298.5元三年 2核4G云服务器545元一年 1227元三年 【满6人】1核1G MySQL数据库 119.5元一年 【满6人】3000条国内短信包 60元每6月 参团地址：http://click.aliyun.com/m/1000020293/