研发效能提高 36 计第三课：束水攻沙，持续加快产品交付速度

摘要： 互联网时代，业务与协做复杂度与日俱增，竞争日趋激烈，提高研发效能已成为软件行业的共同挑战。《研发效能提高和敏捷实施 36 计》是阿里云联合 Teambition 精心打造的系列课程，课程由何勉、张刚、张燎原等国内多位在研发效能领域拥有数十年经验的精益敏捷资深专家担任讲师；将从敏捷项目协做、敏捷需求管理、持续交付与工程实践、设计及代码实践、业务创新 5 大方面，首次系统分享阿里巴巴研发效能提高方法、解析阿里巴巴及业界优秀实践案例，并经过工具的直观演示，帮助企业研发管理者们突破研发效能瓶颈、通往业务成功之路。

没有度量的改进就是盲人骑瞎马，夜半临深池。好的度量，必须直指本质，并指导行为改变。本次课程，是研发效能提高 36 计系列课程第三课，两位讲师将介绍一套行之有效的研发效能的度量指标，帮助团队设定研发效能改进的愿景和目标；经过有效反馈，持续提高研发效能。

注：如下内容是演讲视频的精要整理，点击文末连接可前往课程信息合集页面查看往期视频、PPT 以及最新直播预告。

上一课介绍了可视化交付过程。以下图所示，我将其总结为：4个步骤和3个检查项。可视化奠基了研发效能提高的基础。仍而，必须谨记的是：“可视化是手段，而不是目的”。让价值顺畅高质量地流动才是目的，这也是本次课程分享内容的目的。

本次课程将在可视化价值流的基础上，介绍：有效管理价值流动，提高持续交付能力。咱们将从一个故事——束水攻沙——讲起。

一. 束水攻沙 —— 限制在制品数量，加速价值流动

故事的主人公叫潘季驯，他是治理黄河的水利专家，被称为“千古治黄第一人”。

治理黄河难，难在泥沙不断淤积，上图中黄河入海水道的大范围变迁，就是不断淤积、溃坝的结果，背后的灾难深重则难以言表。

清淤是治理黄河的传统办法，问题是清了又会淤，年复一年。大批的河工汇集，又为造反提供条件，元朝的覆灭就与之关系甚大。不治则生灵涂炭，治则劳民伤财，这是摆在历代统治者面前的两难决定，明朝也不例外。

嘉靖到万历年间潘季驯四次临危受命治理黄河，取得史无前例的成效，并总结了切实可行的方略，其中最为重要的思想就是：“束水攻沙”。

什么是“束水攻沙”呢？潘季驯在治理黄河时没有蛮力清淤，也没有一味地加高、加宽河堤。他反其道而行，收窄河堤——在大堤（称为遥堤）内再修筑一道更窄的堤（称为缕堤），“遥堤用以防溃，缕堤用以束水”。河堤收窄了，水流的速度就会加快，并将沉积的泥沙带走，这就是所谓"束水攻沙"。

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

上图的看板，咱们前面介绍过。其中提到了泳道（图中横向的需求泳道）的概念。泳道数约束了并行需求的数目，目的是尽快完成已开始需求，加速需求的流动。就像缕堤约束了黄河水，加快了水流。

更重要的是，限制并行能更快暴露问题。因为泳道数有限，需求发生阻塞，很容易被发现。团队必须尽快解决阻塞的问题，不然会影响需求的开始。这里面的基本原则是：“聚焦完成，暂缓开始”。

并行的需求又被称为“在制品” （Work In Progress）。看板上，全部已经开始，但尚未完成的需求（或其余工做）都是在制品。通常而言，在制品数量越少，交付速度越快。源自“精益思想”的“利特尔法则”解释了背后的原理。

什么是李特尔法则？上图被称为累积流图，其中，横坐标表明日期，纵坐标表示需求个数。红色线表示已经开始的需求的数目，绿色线则表示已经交付的需求的数目。

红色和绿色之间竖线的长度表示在制品的数目——已经开始，但尚未完成的需求的数目；红色和绿色之间横向线的长度表示前置时间——需求从开始到完成要花费的时间；图中斜线的斜率表示交付速率（吞吐率）——单位时间交付需求数。

这三条线构成的三角形，直观的表达了利特尔法则：

前置时间 = 在制品/交付速率。

在交付速率相对稳定的状况下，在制品越少，前置时间越短，也就是响应速度越快。例如：团队每个月能够交付 5 个需求，并行开发 10 个需求，那么平均前置时间是：10 除以 5 ,也就是两个月。若是将在制品数量减半，变为 5 个，前置时间就会变成: 5 除以 5，也就是 1 个月。这就是产品开发中的利特尔法则，约束在制品数目，交付的时间变短，响应变快。这与束水攻沙的思想不谋而合。

控制在制品数目，让团队更加敏捷的响应用户需求。控制的方法则是多元的，如：聚焦于需求的完成而不是任务，让任务向需求对齐，尽快地完成（而不是开始）需求；及时发现阻碍，集中精力解决它们；即时向测试移交，并尽快开始测试；优先解决缺陷而不是开始更多的需求等。

上图表示了常见的控制在制品的方法。控制在制品数目，让团队聚焦需求的快速流动和交付，提升了团队的响应能力和敏捷性。不过，团队效能的本质提高须要更深层次的改进。如何发现并落实这些改进呢？这是咱们接下来要分享的内容。

二. 湖水岩石——暴露问题，促进改进

潘季驯在解释“束水攻沙”时，曾说过：“急则沙随水流，缓则水漫沙停”。 “束水攻沙”不只仅是要让水流地更快，更重要的是把沙给冲走。

这里咱们想用沙来隐喻产品交付过程当中的问题，也就是说需求流动速度快，则可以及时发现和解决问题；反之，当需求产生积压，问题也会隐藏和积累。

下面是阿里某个基础产品团队的实例。咱们看他们是如何经过“束水攻沙”发现和解决问题，提升效率的。

这个团队早期使用了物理看板，可视化了交付过程。其中蓝色卡片表明需求，黄色卡片表明需求分解出的任务。当时，这个团队的迭代周期是一个月，每月发布一次对基础产品来讲并不算太差。问题是迭代过程并不畅，质量也有很大的问题。

第一幅图拍的是迭代的前几天，几乎全部需求都同时开始了。

第二幅图是迭代中期，全部的需求都作了一半，看上去还不错，至少有进展。但没有一个需求进入了测试，这实际上是有问题的。

问题出如今迭代的后期，上图是迭代结束前两天的情况，开发完成了一堆需求，但却没有一个需求真正进入了测试。这显然不是一个号的状态，要在最后两天完成全部测试，这对进度和质量都是极大的挑战，尤为是这种 “code then fix” 的模式对产品的长期质量伤害很大。事实上，这个团队的进度和质量一直有问题，可视化更好地暴露了问题，问题背后的缘由也更清楚了。

回头看团队迭代的过程，这是典型的“缓则水漫沙停”，过程当中需求没有向下流动，问题也被积累到了最后，好比需求拆分、测试环境以及需求之间相互依赖等问题，在前期都被有意无心的忽略了。这实际上是团队效率和质量问题的重要和根本的缘由。

可视化让团队看到了问题和影响，接下来他们开始有意识的控制在制品。以此为基础，开启了他们的改进之旅，在协做过程、需求管理、工程能力都作了很大的改进。

上图的右边是改进后的状态。咱们看到，需求开发的交付流畅起来，每一个阶段的需求（在制品）都很少，需求的分布更加均匀，需求持续进入测试及发布状态，团队从集中批量交付转变为了持续交付。在这个过程当中，效率、质量、敏捷性都获得了很大的提高。

固然改进的过程是须要付出艰辛的努力的，涉及到技术、管理、需求、环境等多个方面。4 个迭代后，质量、效率都获得了大幅提高。个人同事蔡春华用一篇文章（ 集体通宵发版怎么破？阿里敏捷教练开出四道“药方” ）真实记录了团队转变的过程和效果，很是值得参考。

在上面的团队中，咱们用“湖水岩石”来比喻并指导了改进过程。

什么是“湖水岩石”呢？如上图所示，湖水比较深时，石头都隐藏在湖面之下；只有水位降下来，石头才会渐次暴露出来。咱们用石头隐喻的产品开发中的问题，而湖水的水位则隐喻交付周期（或并行需求的数目）。当需求的交付周期长时，问题被隐藏，咱们看到的是平整的水面。只有水位下降，问题才会暴露。

上图中，岩石所处的深度表达了这个团队问题暴露的前后顺序。好比：为了控制在制品数目，最先暴露的是协做模式的问题，由于产品、开发、测试团队之间习惯了大批量的移交，这是首先要解决的问题。

接下来暴露的是需求拆分和管理的问题，为此咱们引入了故事地图、实例化需求等实践，比较顺利的解决了这个问题。关于这两个实践，在敏捷需求的课程中，咱们会详细介绍。

其后，又陆续暴露和解决了测试回归、测试环境、团队沟通机制、目标管理等问题。在这个过程当中水位不断下降，深层次的问题不断显露和解决。而团队的效率和质量也在解决问题中不断提高。过程并不容易，但没有这些问题的解决就不会有研发效能的根本提高。

三. 创建节奏，管理价值流动

“束水攻沙”是为了限制在制品的数量，让价值顺畅流动； “湖水岩石”是为了持续暴露问题，改进交付能力。这为研发效能的改进提供了可操做的理念支撑，这固然是有巨大意义的。

然而，若是离开有效的落地，再先进的理论和原则都没有意义。接下来要讨论的就是如何落地上面的原则——创建节奏，管理价值流动。

有效地管理价值流动须要从三个方面入手，价值的输入、流动过程以及输出。其中，关于输出，它的最终的目标是持续交付和发布。所以接下来的讨论将关注两个方面：

1. 价值的输入：它对应需求的规划和排期；
2. 价值的流动过程：咱们将介绍每日站会;

月规划，周排期——创建管理价值流动的节奏;

应该创建怎样的计划节奏，多长时间作一次计划呢？这是咱们首先要回答的问题。传统瀑布开发模式下，计划是大批量进行的——一次计划不少内容，而且要很长时间后才完成交付。这是瀑布开发与敏捷开发本质的区别之一。它带来一系列问题：

1. 下降决策的质量：一次要准备不少需求，其中包含当前还不清晰的需求。缺少足够的信息，却不得不作出决策，决策的质量很难保证;
2. 致使范围蔓延：填充间隔过长时，业务方倾向将那些只是可能有用的需求也计划进来，由于此时不计划，下一次就要等到好久之后了。这样就会产生不少猜想的需求，致使需求范围蔓延;
3. 下降需求澄清的关注度和效果：填充的需求要等好久以后才作，团队关注度就会大打折扣，难以保证需求澄清的效果;
4. 不能很好地支持有效学习和创新：计划时作出假设，交付后获得反馈，验证假设并做出调整，这是互联网产品试错和创新的重要模式。一次填充过多需求，反馈速度慢，极大下降学习和创新的机会;
5. 下降团队灵活响应市场变化的能力（敏捷性）：一次填入不少需求，发生变化或出现新需求时，就只能等好久之后的下一次填充了，这对组织响应变化的能力显然是不利的，损害了组织的敏捷性。

计划的频率越高，批量越小，则敏捷性越好。同时决策时信息越充分，决策质量也越高。可是频繁计划也带来额外的成本。相关的人在一块儿进行会议，业务人员要提早准备好需求，这都带来协调成本。

除了成本外，还要考虑频繁填充的必要性。两次填充之间产生了足够多的支持更好决策的新信息，分开进行需求填充才是有意义的。不然，必要性就很低。

基于对以上两点的考虑和阿里自身的一些实践经验，咱们造成了“月规划，周排期”的机制。

如上图所示，看板中选择（规划）这一列，对应需求规划，规划好的需求放入选择列。第四列则是需求排期，排期好的需求放入该列。团队每月会进行一次产品规划，和产品或者业务方确认本月的主题是什么，围绕这些主题须要作哪些需求。月规划的基础上再作周排期，决定本周要作什么。如此造成的机制就是:

1. 月规划：每个月进行一次。由业务方和开发团队的表明参加，共同计划和确认接下来的一个月要作的需求，初步的沟通和确认后，放入“选择”队列；
2. 周排期：每周进行一次。在开发团队内部进行，团队从计划队列中选择接下来要作的需求，详细澄清后，放入就绪“排期”队列。团队决定填充什么需求时，一方面会考虑需求的优先级，也会结合上一周开发实际完成状况作调整。

对于规划排期这部分更加详细的内容，能够参见以前的文章（ 精益看板方法从理论到实战 （9）—— 计划会议，就绪队列填充）。

“很是6+1”——站会的正确姿式

站会应该聚焦于价值的流动，而非我的工做。它的目的是：检视价值流动的状态，促进价值顺畅流动。站会的组织形式也要服务于这一目的。

典型的看板站会，发生在每一个工做日、同一时间、同一地点（看板前）。站会上，团队从右至左走读看板。之因此从右往左，一方面是为了体现价值拉动的方向；另外一方面是为了贯彻“暂缓开始，聚焦完成”的原则，好比 Bug 通常在看板墙上偏右的测试列，从右往左更方便安排优先解决 Bug，快速完成需求交付，而不是开始更多的需求开发。

影响和阻碍价值顺畅流动的因素有不少，好比瓶颈和队列、关键缺陷、重点需求、阻碍和问题、已经到期或者即将到期的需求、中断以及未反映在看板上的问题。

站会上不须要检视每一张卡片。本着“检视价值流动的状态，促进价值顺畅流动”的目的，咱们应该重点关注影响价值流动的问题。如上图所示，它们中的绝大部分均可以很清晰地体如今看板墙上，典型的包括如下 6 个方面，加上未反映在看板上的问题（+1）。咱们称之为 “ 6+1 ” 站会。这里只是一个简单的介绍，关于如何组织站会，能够参考以前的文章（ 精益看板方法从理论到实战 （8）—— 看板站会）。

以上咱们介绍了规划、排期以及站会的节奏。咱们，在实施过程当中逐渐造成了：月规划、周排期、日站会的节奏。如上图所示，这些节奏帮团队落地相关的精益和敏捷实践，并在此基础上造成改进闭环，在不一样的场景中获得了应用，在新零售、大文娱、云基础设施都获得过验证，效果不错，具备较普遍的适应性。

总结

本次课程咱们从“束水攻沙”的故事讲起，经过主动的控制在制品，加速价值的流动； “湖水岩石”，则经过不断下降水位，让团队尽早暴露问题，并直面和解决它们。为了让价值顺畅、高质量地流动，团队还必须创建节奏，落地相关原则和实践，并造成效能改进和业务反馈闭环，切实提高组织的“研发效能”。

下一次课程将分享研发效能的度量和改进闭环。咱们将了解到如何经过度量，来了解研发效能的现状和问题，发现系统和深层次为题，和指导持续改进。

最新课程直播预告

直播时间：10 月 8 日 20:00 - 21:30

直播主题：第 6 课：【敏捷需求篇】为何「雇佣」奶昔，从用户问题出发设计需求

直播内容： 用户为何要 “雇佣” 你的产品？这个问题为产品设计打开了一个全新的视角。本次课程将介绍如何分析产品的价值主张，设计真正可以解决用户问题，而且被用户接受的产品方案。

讲师阵容： 阿里云研发效能部资深技术专家、Teambition 客户成功首席顾问 何勉 阿里云研发效能部高级技术专家、Teambition 客户成功资深专家 张燎原

原文连接

本文为云栖社区原创内容，未经容许不得转载。