如何在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指出：“在产品开发中，问题的关键几乎从来不是停滞的资源，而是停滞的需求。”这是什么意思呢?产品开发的最终目的是交付价值，那我们就必须让价值交付的过程顺畅起来，也就是让价值流动顺畅起来。计划、管理、协调活动，以及资源的配置等等，都应该服务于价值的流动。价值流动是目的，资源忙起来不是。

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

为什么我们往往对需求的积压很少关注?因为它很难看到，不是光照亮的地方。我们很难觉察(至少很难即时察觉)需求的停滞、积压和返工，而那才是改进价值交付的关键所在。

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

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

我们单独看“开发中”这个阶段，在这里需求被分解成为任务——图中黄色纸条。任务与其所属于的需求处于同一行中，我们把这样的行称为泳道。泳道的首列(蓝色纸条)是需求，下属任务(黄色卡片)按模块组织在一起，如前端、后端或其他依赖的外部模块，其中任务的最后一列代表完成状态，所有任务完成后，需求进入下一阶段——待测试。