如何在2周内交付超过85%的需求？阿里工程师在什么是真正的敏捷开发？在文章中，我们描述了什么是真正的敏捷开发以及如何衡量它。今天，阿里资深技术专家何冕先生继续带领我们探讨如何通过关注流效率来提升持续交付能力。提升持续交付能力最近，我们在阿里内部提升团队绩效的时候，提出了一个叫“2-1-1”的愿景，得到了很多部门的认可。什么是211？“2”指的是2周的交付周期——85%以上的需求可以在2周内交付；第一个“1”指的是1周的开发周期——85%以上的需求可以在1周内开发完成；第二个“1”指的是1小时的releaseleadtime——代码提交后，1小时内可以完成发布。今天，很多团队离“211”还有很远的距离，尤其是这个“2”，涉及到整个组织的各个职能，各个部门的协调和密切配合。一小时的发布提前期需要持续的交付流水线、产品架构体系以及自动化测试和部署的有力保障。实现“211”并不容易，但它体现了组织提高持续交付和快速响应能力的目标，确定了持续改进的方向，所以我们把它作为愿景。注：以上概念同样适用于研发工具云霄（阿里内部称为Aone），交付过程、交付结果、交付质量等数据也可在云霄的度量功能中查看。问题是我们如何实现这一目标？让我们从卡通开始。这是一个酒吧。一个醉汉在路灯下找东西。良久，警察一直看着他，终于忍不住上前问道：“你找什么？””醉汉道：“找东西。我的钥匙。”警察看着钥匙，好像不在这儿似的，就问：“钥匙在这儿吗？”醉鬼说：“没有。”警察奇怪地问：“那你为什么在这里找？？”韩回答：“只有这里才能看到。”Key（钥匙）在英文中也有关键的意思，光照射到哪里不是重点。灯光照耀着，而不是钥匙所在的地方，当然会让你无处可去。那么研发过程的症结在哪里呢？《The Principles of product development flow》一书的作者唐指出：“在产品开发中，问题的症结几乎从来都不是停滞的资源，而是停滞的需求。”这是什么意思？产品开发的最终目的是交付价值，所以我们必须让价值交付的过程顺畅，也就是让价值顺畅流动。规划、管理、协调活动、资源配置等，都应该为价值流服务。价值流转是目的，资源忙却不是目的。现实中，我们更关注资源是否停滞，人是否闲置，但真正的问题不在这里。真正的问题是需求的停滞，各个阶段需求的积压——比如分析阶段、测试阶段、发布阶段等等。真正的问题是需求不能畅通，也就是我们所说的关键。为什么我们往往很少关注需求积压？因为很难看到，而不是光线照射的地方。需求的停滞、积压和返工难以发现（至少不能立即发现），这是提高价值交付的关键。为了改进端到端流程，我们必须看到端到端价值流动的地方以及积压和停滞的地方。为此，改进的第一步就是让光照亮重点——将端到端的价值流转过程可视化，根据价值流转发现流转过程中的问题。让我们看一个产品团队看板的例子。看板中的蓝色卡片是需求。让光芒闪耀的关键是可视化需求流的端到端过程。需求从“选”开始。所谓选择，就是从大量的市场机会中挑选出这些需求，开始开发。选型之后，还有需求设计、开发、测试、验收等其他流程，直到发布，这是一个端到端的流程。我们单看“underdevelopment”阶段，需求被分解成任务——图中黄色注释。任务与其所属的需求在同一行，我们称这样的行为泳道。泳道的第一列（蓝色纸条）是需求，从属任务（黄色卡片）按模块组织在一起，例如前端、后端或其他依赖的外部模块。任务的最后一列表示完成状态。所有任务完成后，需求进入下一阶段——待测。端到端的需求流程可视化，从需求选择开始，直到发布结束。这样一来，需求是否畅通，是否出现停滞和积压，是否存在瓶颈等问题，我们都能即时看到。这就是所谓的：灯照亮了问题。此外，我们还需要保证价值流的过程质量，将交付质量构建到开发过程中，而不是依赖于最后的测试环节。为了实现内在质量，我们需要明确定义需求流的标准。上图展示了需求进入开发流程时需要满足的输入标准。本例中定义为：1)明确需求的用户使用流程和验收规则；2)可以识别依赖方；3）大需求在两周内或一周内拆分成小需求等。我们还可以定义其他阶段的规则，比如开发输出（即测试）的规则。这也是点亮的关键部分。阐明关键点，看到端到端的需求流，以及流中的问题和瓶颈是第一步。更关键的是看到问题后怎么办？基于可视化的端到端价值流，我们希望价值能够顺畅地流动，从左到右，没有停滞和积压。如何？我们再看一个故事。照片中的人叫潘继勋。他是明代治理黄河的水利专家。治黄难，难在泥沙不断堆积。疏浚是治理黄河的传统方式。问题是它会年复一年地再次淤塞。大量河工的聚集为造反提供了条件，元朝的垮台与此有很大关系。不治则人丧命，治则伤人伤财。这是历代统治者都面临的困境，明朝也不例外。从嘉靖到万历，潘继勋临危受命四次治理黄河，取得了空前的战果。他还总结了实用策略，其中最重要的是“克水攻沙”。什么是“射水攻沙”？潘继勋在治理黄河时，既没有蛮力疏淤，也没有盲目加高拓宽堤岸。他反其道而行之，把河堤收窄——在大堤（叫尧堤）里面修了一个更窄的堤（叫线堤）。当路堤变窄时，水流速度会加快，沉积的泥沙会被带走。这就是所谓的“光束水攻击沙子”。“射水攻沙”与产品研发有什么关系？“光束水”加快水流速度，带走泥沙。相应的，在产品开发中，我们也需要限制并行需求的数量，也是为了缩短需求从开始到完成的平均交付周期——加快流程，发现和处理交付过程中的问题实时——带走沙子。让我们看一个具体的例子。在上图中，通道的数量限制了并行需求的数量。并行需求越少，需求流动越快，从而缩短开发和交付周期。更重要的是，限制并行度会更快地暴露问题。有限泳道的需求堵塞很容易发现。在开始新需求之前，团队必须尽快解决阻塞问题。立即解决问题有助于价值的顺畅流动。基于端到端的价值流，团队可以更好地管理价值流。以站会为例，团队会在站会上审核需求的状态。这里有两种策略，一种是从左往右考察，一种是从右往左考察，你觉得哪个合适？是的，每个人都说从右到左。为什么？因为我们应该关注完成而不是开始，我们应该关注尽快交付，比如测试中的需求是否有缺陷，优先解决这些缺陷，让需求尽快上线；开发中的需求是否有障碍，即时解决完成。只有这样，等待开发的新需求才能启动。站会的核心是审视价值流，关注需求流中的缺陷、障碍、停滞、等待和瓶颈，实时发现并解决这些问题，促进需求流更顺畅.站立会议只是一个例子。围绕看板的其他活动，如测量数据分析、改进行动的制定等，都是为了促进价值的流动，而价值的顺畅流动是响应性、质量和效率的保证。（电子看板截图来自阿里云云霄）上面的例子使用实体看板让大家看得更舒服。现在大部分团队，无论是阿里云、技术中心还是闲鱼，都在使用云效电子看板。经过不断优化，电子看板的操作体验接近实体看板。而且它具有物理看板所没有的优势。比如上面提到的数据指标可以自动生成，这对于发现问题和改进是非常有意义的，并且可以和文档、发布工具等其他系统无缝集成。这是优酷电子看板的截图。看板帮助团队暴露问题，具体的改进动作还是需要在不同的方面去落实。我们可以用湖水岩石效应来描述这个过程。这是一个湖，里面有一些石头。当湖水较深时，石头隐藏在湖面之下，但它的影响是存在的；当湖水位降低时，石头就会逐渐露出来。在产品开发中，石头比喻问题，湖的深度比喻提前期的长短（或并行需求的数量）。当需求的交付周期长了，问题就隐藏起来了，我们看到的是一帆风顺。只有当水位降低时，问题才会暴露出来。以一个中间件团队的绩效提升过程为例。他们最初采用的是小瀑布模型，没有持续集成和有效的自动化，按月交付产品。需求集中在月初，转入月末测试发布。对外交付质量和效率不尽如人意。内部协作也有很多问题，每次发布都异常痛苦，时有延迟，但每个人对问题的根源和解决方案都有不同的看法。在精益和敏捷开发的实施过程中，我们首先要做的是价值流的可视化，并在此基础上逐步减少并行需求的数量，力求需求的持续流动——持续的小批量输入、开发、测试和交付。在减小batchsize的过程中，问题逐渐暴露出来。在这种情况下，要实现小批量的流转，首先暴露的就是需求分析和拆分的问题，即如何将需求拆分成可以独立测试、验证和交付的小单元。通过引入“RequirementsbyExample”（一种需求厘清、分析、拆分的方法）等方法，解决了这个问题，开发和测试交接的批量也大大减少。很快又出现了新的问题。测试环境或者交到测试的版本总是不可用，需求还是不能顺畅流动。这时候，持续交付流水线建设的重要性就凸显出来了。当然，持续交付流水线的构建不是一步到位的。一开始我们只是打通了流水线，引入了最基本的自动验证，保证随时有可用的环境和版本可供测试。下一步是自动化关键功能的覆盖。之后逐渐暴露出组织协调、沟通、技术架构等问题。在这个过程中，我们感受到的最大的好处就是，虽然解决问题的过程还是比较痛苦的，但是我们可以集中精力去解决一个真实的一次性暴露出来的问题，而且解决起来也会带来立竿见影的收益，大大提高团队继续投入解决问题的动力。团队多年解决不了的问题，只用了三四个月就一一解决了。在不投入额外资源的情况下，研发效率得到根本提升，质量和响应能力也得到了质的提升。对此我也深有感触——研发效率提升实践的技术难度并不比我们平时做的业务系统难。但是为什么总是不执行呢？团队做了正确的事情。这里的根本问题不是能力的问题，也不是意识和态度的问题。更重要的是：让团队看到问题，并提供合适的路径，一次解决一个问题，解决问题后能够看到当下的想法。有两个核心：第一：“看”，它的关键是看到系统，看到端到端的价值流转，在此基础上看到问题和改进的机会；第二：“路径”，它的关键是小走快，但每一步都要有实效。图中岩石的高度在概念上反映了问题随着平行度降低而逐渐暴露的大致顺序。不同团队的问题和顺序会有所不同。但相同的是，通过水位的降低，问题逐渐暴露和解决，产品交付的响应速度、效率和质量也会得到提升。我们的目标不是把水位降到最低，而是发现问题，让需求以更小的粒度顺畅流动，实现顺畅、优质、持续的价值交付。总结持续交付的实践。它侧重于从需求到开发、测试到部署和运维的环节。它的目标可以概括为两个：第一：让价值畅通无阻，这个我们讲了很多。前面提到的实践可以促进价值的顺畅流动，比如看板、反馈改进等管理实践，以及故事地图、验收测试驱动开发等技术实践。第二：让流程更高效，这个我们前面没有强调。补充一下，核心是让团队成员只需要专注于带来真正价值的业务逻辑，而不用花太多时间在其他任务上。我们来看看除了业务逻辑之外，团队还会受到哪些工作的影响？如何减少这些工作？这里我们列出其中的一些：可靠的交付流水线：让团队不用担心验证和部署的环境、步骤和过程。容器技术（如Docker）：让团队不必过多考虑构建分发和运行环境。Kubernetes：让团队不必过多考虑容器应用的部署、运行、扩缩容。ServiceMesh：让团队不必过多考虑分布式服务的通信。Severless：让团队不必过多考虑服务器的物理资源。……持续交付价值的能力是互联网时代研发效率的核心。介绍了提升持续交付能力的衡量方法，以及以流程效率为切入点提升持续交付能力的实践与路径。问题是，构建持续交付能力是否能保证业务成功？很明显不是。持续交付能力是快速交付价值、获得反馈和灵活适应的基础。我们还必须通过将持续交付能力转化为有效的业务创新来带来真正的业务成功。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
