在 什么是真正的敏捷开发?文章里，我们讲述了什么是真正意义的敏捷开发，如何去衡量。今天，阿里资深技术专家何勉老师，继续带领我们探索，如何以流动效率为抓手，提升持续交付的能力。
提升持续交付能力
最近我们在阿里内部做团队效能改进时，提出了称之为“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：让团队不用过多考虑服务器的实体资源。
…
持续交付价值的能力是互联网时代研发效能的核心。我们介绍了提升持续交付能力的度量，以及以流动效率为抓手提升持续交付能力的实践和路径。
问题是，建立了持续交付能力就可以保证业务的成功吗?显然不是。持续交付能力是快速交付价值、获取反馈并灵活调整的基础。我们还必须以把持续交付能力转化为有效的业务创新，带来真正的业务成功。
【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件，转载请联系原作者】
