摘要：
互联网时代，业务与协作复杂度与日俱增，竞争日趋激烈，提升研发效能已成为软件行业的共同挑战。《研发效能提升和敏捷实施 36 计》是阿里云联合 Teambition 精心打造的系列课程，课程由何勉、张刚、张燎原等国内多位在研发效能领域拥有数十年经验的精益敏捷资深专家担任讲师；将从敏捷项目协作、敏捷需求管理、持续交付与工程实践、设计及代码实践、业务创新 5 大方面，首次系统分享阿里巴巴研发效能提升方法、解析阿里巴巴及业界优秀实践案例，并通过工具的直观演示，帮助企业研发管理者们突破研发效能瓶颈、通往业务成功之路。
没有度量的改进就是盲人骑瞎马，夜半临深池。好的度量，必须直指本质，并指导行为改变。本次课程，是研发效能提升 36 计系列课程第三课，两位讲师将介绍一套行之有效的研发效能的度量指标，帮助团队设定研发效能改进的愿景和目标；通过有效反馈，持续提升研发效能。
注：以下内容是演讲视频的精要整理，点击文末链接可前往课程信息合集页面查看往期视频、PPT 以及最新直播预告。
上一课介绍了可视化交付过程。如下图所示，我将其总结为：4个步骤和3个检查项。可视化奠定了研发效能提升的基础。仍而，必须谨记的是：“可视化是手段，而不是目的”。让价值顺畅高质量地流动才是目的，这也是本次课程分享内容的目的。
本次课程将在可视化价值流的基础上，介绍：有效管理价值流动，提升持续交付能力。我们将从一个故事——束水攻沙——讲起。
一. 束水攻沙 —— 限制在制品数量，加速价值流动
故事的主人公叫潘季驯，他是治理黄河的水利专家，被称为“千古治黄第一人”。
治理黄河难，难在泥沙不断淤积，上图中黄河入海水道的大范围变迁，就是不断淤积、溃坝的结果，背后的灾难深重则难以言表。
清淤是治理黄河的传统办法，问题是清了又会淤，年复一年。大批的河工聚集，又为*提供条件，元朝的覆灭就与之关系甚大。不治则生灵涂炭，治则劳民伤财，这是摆在历代统治者面前的两难决定，明朝也不例外。
嘉靖到万历年间潘季驯四次临危受命治理黄河，取得前所未有的成效，并总结了切实可行的方略，其中最为重要的思想就是：“束水攻沙”。
什么是“束水攻沙”呢？潘季驯在治理黄河时没有蛮力清淤，也没有一味地加高、加宽河堤。他反其道而行，收窄河堤——在大堤（称为遥堤）内再修筑一道更窄的堤（称为缕堤），“遥堤用以防溃，缕堤用以束水”。河堤收窄了，水流的速度就会加快，并将沉积的泥沙带走，这就是所谓"束水攻沙"。
“束水攻沙”与产品开发有什么关系呢？“束水”加快了水的流速，并带走了泥沙。对应的，产品开发中我们限制并行需求的数量，也是为了加快流速——缩短需求从开始到完成的交付周期，并即时发现和处理交付过程中的问题。我们来看具体的例子。
上图的看板，我们前面介绍过。其中提到了泳道（图中横向的需求泳道）的概念。泳道数约束了并行需求的数目，目的是尽快完成已开始需求，加速需求的流动。就像缕堤约束了黄河水，加快了水流。
更重要的是，限制并行能更快暴露问题。由于泳道数有限，需求发生阻塞，很容易被发现。团队必须尽快解决阻塞的问题，否则会影响需求的开始。这里面的基本原则是：“聚焦完成，暂缓开始”。
并行的需求又被称为“在制品” （Work In Progress）。看板上，所有已经开始，但还没有完成的需求（或其他工作）都是在制品。一般而言，在制品数量越少，交付速度越快。源自“精益思想”的“利特尔法则”解释了背后的原理。
什么是李特尔法则？上图被称为累积流图，其中，横坐标代表日期，纵坐标表示需求个数。红色线表示已经开始的需求的数目，绿色线则表示已经交付的需求的数目。
红色和绿色之间竖线的长度表示在制品的数目——已经开始，但还没有完成的需求的数目；红色和绿色之间横向线的长度表示前置时间——需求从开始到完成要花费的时间；图中斜线的斜率表示交付速率（吞吐率）——单位时间交付需求数。
这三条线构成的三角形，直观的表达了利特尔法则：
前置时间 = 在制品/交付速率。
在交付速率相对稳定的情况下，在制品越少，前置时间越短，也就是响应速度越快。例如：团队每月可以交付 5 个需求，并行开发 10 个需求，那么平均前置时间是：10 除以 5 ,也就是两个月。如果将在制品数量减半，变为 5 个，前置时间就会变成: 5 除以 5，也就是 1 个月。这就是产品开发中的利特尔法则，约束在制品数目，交付的时间变短，响应变快。这与束水攻沙的思想不谋而合。
控制在制品数目，让团队更加敏捷的响应用户需求。控制的方法则是多元的，如：聚焦于需求的完成而不是任务，让任务向需求对齐，尽快地完成（而不是开始）需求；及时发现阻碍，集中精力解决它们；即时向测试移交，并尽快开始测试；优先解决缺陷而不是开始更多的需求等。
上图表示了常见的控制在制品的方法。控制在制品数目，让团队聚焦需求的快速流动和交付，提高了团队的响应能力和敏捷性。不过，团队效能的本质提升需要更深层次的改进。如何发现并落实这些改进呢？这是我们接下来要分享的内容。
二. 湖水岩石——暴露问题，促进改进
潘季驯在解释“束水攻沙”时，曾说过：“急则沙随水流，缓则水漫沙停”。 “束水攻沙”不仅仅是要让水流地更快，更重要的是把沙给冲走。
这里我们想用沙来隐喻产品交付过程中的问题，也就是说需求流动速度快，则能够及时发现和解决问题；反之，当需求产生积压，问题也会隐藏和积累。
下面是阿里某个基础产品团队的实例。我们看他们是如何通过“束水攻沙”发现和解决问题，提高效率的。
这个团队早期使用了物理看板，可视化了交付过程。其中蓝色卡片代表需求，黄色卡片代表需求分解出的任务。当时，这个团队的迭代周期是一个月，每个月发布一次对基础产品来说并不算太差。问题是迭代过程并不顺畅，质量也有很大的问题。
第一幅图拍的是迭代的前几天，几乎所有需求都同时开始了。
第二幅图是迭代中期，所有的需求都做了一半，看上去还不错，至少有进展。但没有一个需求进入了测试，这其实是有问题的。
问题出现在迭代的后期，上图是迭代结束前两天的状况，开发完成了一堆需求，但却没有一个需求真正进入了测试。这显然不是一个号的状态，要在最后两天完成所有测试，这对进度和质量都是极大的挑战，尤其是这种 “code then fix” 的模式对产品的长期质量伤害很大。事实上，这个团队的进度和质量一直有问题，可视化更好地暴露了问题，问题背后的原因也更清楚了。
回头看团队迭代的过程，这是典型的“缓则水漫沙停”，过程中需求没有向下流动，问题也被积累到了最后，比如需求拆分、测试环境以及需求之间相互依赖等问题，在前期都被有意无意的忽略了。这其实是团队效率和质量问题的重要和根本的原因。
可视化让团队看到了问题和影响，接下来他们开始有意识的控制在制品。以此为基础，开启了他们的改进之旅，在协作过程、需求管理、工程能力都做了很大的改进。
上图的右边是改进后的状态。我们看到，需求开发的交付流畅起来，每个阶段的需求（在制品）都不多，需求的分布更加均匀，需求持续进入测试及发布状态，团队从集中批量交付转变为了持续交付。在这个过程中，效率、质量、敏捷性都得到了很大的提升。
当然改进的过程是需要付出艰辛的努力的，涉及到技术、管理、需求、环境等多个方面。4 个迭代后，质量、效率都得到了大幅提升。我的同事蔡春华用一篇文章（集体通宵发版怎么破？阿里敏捷教练开出四道“药方” ）真实记录了团队转变的过程和效果，非常值得参考。
在上面的团队中，我们用“湖水岩石”来比喻并指导了改进过程。
什么是“湖水岩石”呢？如上图所示，湖水比较深时，石头都隐藏在湖面之下；只有水位降下来，石头才会渐次暴露出来。我们用石头隐喻的产品开发中的问题，而湖水的水位则隐喻交付周期（或并行需求的数目）。当需求的交付周期长时，问题被隐藏，我们看到的是平整的水面。只有水位降低，问题才会暴露。
上图中，岩石所处的深度表达了这个团队问题暴露的先后顺序。比如：为了控制在制品数目，最早暴露的是协作模式的问题，因为产品、开发、测试团队之间习惯了大批量的移交，这是首先要解决的问题。
接下来暴露的是需求拆分和管理的问题，为此我们引入了故事地图、实例化需求等实践，比较顺利的解决了这个问题。关于这两个实践，在敏捷需求的课程中，我们会详细介绍。
其后，又陆续暴露和解决了测试回归、测试环境、团队沟通机制、目标管理等问题。在这个过程中水位不断降低，深层次的问题不断显露和解决。而团队的效率和质量也在解决问题中不断提升。过程并不容易，但没有这些问题的解决就不会有研发效能的根本提升。
三. 建立节奏，管理价值流动
“束水攻沙”是为了限制在制品的数量，让价值顺畅流动； “湖水岩石”是为了持续暴露问题，改进交付能力。这为研发效能的改进提供了可操作的理念支撑，这当然是有巨大意义的。
然而，如果离开有效的落地，再先进的理论和原则都没有意义。接下来要讨论的就是如何落地上面的原则——建立节奏，管理价值流动。
有效地管理价值流动需要从三个方面入手，价值的输入、流动过程以及输出。其中，关于输出，它的最终的目标是持续交付和发布。因此接下来的讨论将关注两个方面：
- 价值的输入：它对应需求的规划和排期；
- 价值的流动过程：我们将介绍每日站会;
月规划，周排期——建立管理价值流动的节奏;
应该建立怎样的计划节奏，多长时间做一次计划呢？这是我们首先要回答的问题。传统瀑布开发模式下，计划是大批量进行的——一次计划很多内容，并且要很长时间后才完成交付。这是瀑布开发与敏捷开发本质的区别之一。它带来一系列问题：
- 降低决策的质量：一次要准备很多需求，其中包含当前还不清晰的需求。缺乏足够的信息，却不得不做出决策，决策的质量很难保证;
- 导致范围蔓延：填充间隔过长时，业务方倾向将那些只是可能有用的需求也计划进来，因为此时不计划，下一次就要等到很久以后了。这样就会产生很多猜测的需求，导致需求范围蔓延;
- 降低需求澄清的关注度和效果：填充的需求要等很久之后才做，团队关注度就会大打折扣，难以保证需求澄清的效果;
- 不能很好地支持有效学习和创新：计划时做出假设，交付后得到反馈，验证假设并作出调整，这是互联网产品试错和创新的重要模式。一次填充过多需求，反馈速度慢，极大降低学习和创新的机会;
- 降低团队灵活响应市场变化的能力（敏捷性）：一次填入很多需求，发生变化或出现新需求时，就只能等很久以后的下一次填充了，这对组织响应变化的能力显然是不利的，损害了组织的敏捷性。
计划的频率越高，批量越小，则敏捷性越好。同时决策时信息越充分，决策质量也越高。但是频繁计划也带来额外的成本。相关的人在一起进行会议，业务人员要提前准备好需求，这都带来协调成本。
除了成本外，还要考虑频繁填充的必要性。两次填充之间产生了足够多的支持更好决策的新信息，分开进行需求填充才是有意义的。否则，必要性就很低。
基于对以上两点的考虑和阿里自身的一些实践经验，我们形成了“月规划，周排期”的机制。
如上图所示，看板中选择（规划）这一列，对应需求规划，规划好的需求放入选择列。第四列则是需求排期，排期好的需求放入该列。团队每个月会进行一次产品规划，和产品或者业务方确认本月的主题是什么，围绕这些主题需要做哪些需求。月规划的基础上再做周排期，决定本周要做什么。如此形成的机制就是:
- 月规划：每月进行一次。由业务方和开发团队的代表参加，共同计划和确认接下来的一个月要做的需求，初步的沟通和确认后，放入“选择”队列；
- 周排期：每周进行一次。在开发团队内部进行，团队从计划队列中选择接下来要做的需求，详细澄清后，放入就绪“排期”队列。团队决定填充什么需求时，一方面会考虑需求的优先级，也会结合上一周开发实际完成情况做调整。
对于规划排期这部分更加详细的内容，可以参见之前的文章（精益看板方法从理论到实战 （9）—— 计划会议，就绪队列填充）。
“非常6+1”——站会的正确姿势
站会应该聚焦于价值的流动，而非个人工作。它的目的是：检视价值流动的状态，促进价值顺畅流动。站会的组织形式也要服务于这一目的。
典型的看板站会，发生在每个工作日、同一时间、同一地点（看板前）。站会上，团队从右至左走读看板。之所以从右往左，一方面是为了体现价值拉动的方向；另一方面是为了贯彻“暂缓开始，聚焦完成”的原则，比如 Bug 一般在看板墙上偏右的测试列，从右往左更方便安排优先解决 Bug，快速完成需求交付，而不是开始更多的需求开发。
影响和阻碍价值顺畅流动的因素有很多，比如瓶颈和队列、关键缺陷、重点需求、阻碍和问题、已经到期或者即将到期的需求、中断以及未反映在看板上的问题。
站会上不需要检视每一张卡片。本着“检视价值流动的状态，促进价值顺畅流动”的目的，我们应该重点关注影响价值流动的问题。如上图所示，它们中的绝大部分都可以很清晰地体现在看板墙上，典型的包括以下 6 个方面，加上未反映在看板上的问题（+1）。我们称之为 “ 6+1 ” 站会。这里只是一个简单的介绍，关于如何组织站会，可以参考之前的文章（精益看板方法从理论到实战 （8）—— 看板站会）。
以上我们介绍了规划、排期以及站会的节奏。我们，在实施过程中逐渐形成了：月规划、周排期、日站会的节奏。如上图所示，这些节奏帮团队落地相关的精益和敏捷实践，并在此基础上形成改进闭环，在不同的场景中得到了应用，在新零售、大文娱、云基础设施都得到过验证，效果不错，具有较广泛的适应性。
总结
本次课程我们从“束水攻沙”的故事讲起，通过主动的控制在制品，加速价值的流动； “湖水岩石”，则通过不断降低水位，让团队尽早暴露问题，并直面和解决它们。为了让价值顺畅、高质量地流动，团队还必须建立节奏，落地相关原则和实践，并形成效能改进和业务反馈闭环，切实提升组织的“研发效能”。
下一次课程将分享研发效能的度量和改进闭环。我们将了解到如何通过度量，来了解研发效能的现状和问题，发现系统和深层次为题，和指导持续改进。
最新课程直播预告
直播时间：10 月 8 日 20:00 - 21:30
直播主题：第 6 课：【敏捷需求篇】为什么「雇佣」奶昔，从用户问题出发设计需求
直播内容：
用户为什么要 “雇佣” 你的产品？这个问题为产品设计打开了一个全新的视角。本次课程将介绍如何分析产品的价值主张，设计真正能够解决用户问题，并且被用户接受的产品方案。
讲师阵容：
阿里云研发效能部资深技术专家、Teambition 客户成功首席顾问 何勉
阿里云研发效能部高级技术专家、Teambition 客户成功资深专家 张燎原
观看方式：
点击此处链接，预约本次网页版直播。
更多课程信息
点击此处链接获取更多课程信息、查看往期课程回放、PPT 以及最新直播预告。