开发者学堂课程【阿里巴巴研发效能提升实践系列公开课：需求持续、快速地流动和交付】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/608/detail/8871
需求持续、快速地流动和交付
内容介绍
一、课程回顾
二、具体内容
三、控制在制品数目
四、总结
一、课程回顾
研发效能最终服务于组织效能，研发效能目的是提升企业或团队持续快速交付价值的能力，具体体现为响应力、吞吐量、质量等。研发效能的提升必须落实到实践中，比如协作实践、需求管理实践、持续交付实践等。本节讲解团队、项目协作实践。
上节课提到看板，它必须以用户价值为驱动，可视化端到端的流程，还要做到前后职能拉通，也就是从产品到开发到测试等职能在一个看板上能拉通。左右模块对齐，比如前后端算法等模块的对齐。为持续、快速地价值流动和交付打下基础。
如何才能让价值持续快速地流动和交付，或者让价值真正的流动起来。这是本节课的重点内容。
二、具体内容
1、举例：束水攻沙
潘季驯，明朝治理黄河的水利专家，被誉为“千古治黄第一人”。治理黄河难的原因是黄河中有很多泥沙，泥沙会泛滥，治理的办法一般是在冬天疏浚黄河的泥沙，但是黄河还会淤积，年复一年，劳民伤财。潘季驯提出了束水攻沙的策略。束水攻沙就是在大堤中建了一座更窄的堤，类似于下图，外面的堤叫遥堤，里面的堤叫缕堤。遥堤用于防溃，缕堤用于束水。束水就是将水流变窄，水流变窄的好处是可以让水流流速变快把泥沙冲到下游，就起到了疏浚黄河的作用。
2、束水攻沙和看板或者价值顺畅流动的关系
下图是天猫精灵的实体看板
这里有一个概念：甬道，即图中横向的道。每条道中只有一个需求。但是甬道数是有限的。图中有六个甬道，意味着并行开发中只能有六个需求。当六条甬道都被占满后，就无法进入新的需求，这意味着团队必须把已经开始的需求快速完成才能开始更多的需求。这会迫使团队解决问题，紧密协作。总之带来的结果就是快速完成已经开始的需求。它起到的作用与束水攻沙很相像，甬道数就相当于束水攻沙中的缕堤。
3、Aone (云效):控制并行(在制品）数目
(1)、在制品是并行的需求在特定阶段的数目。如图：
在每一个状态下都可以设置卡片的数量限制，设置的形式是卡片数量不超过多少，具体的数目由团队设置。还提供了一个选项，如果超过卡片的数量限制，可以选择不让新的需求从上游拉入，也就是要求团队必须把已经开始的需求开发完测试完才能拉入新的需求。或者是更加柔性的选择，当超过卡片的数量限制时出现警告提示，但是仍然可以拉入新的需求，出现警告的目的是引导团队解决问题，该选项由团队进行选择。
(2)、控制并行(在制品)的数目的作用
示意图：
在示意看板中，每一列上标有一个数字：八，四，四，六。数字表示在这列中最多并行的数目是几，比如在测试中最多并行的是六个。
假设接受了控制在制品的数目的限制，会出现什么情况。在图中，测试有五个需求，其中两个有 bug 或者处于有问题的状态。实现完成中有两个需求，把其中一个需求拉入测试中，另外一个需求拉不进来，因为数目限制是六。实现中一共有两个需求，最大限制是四，将分析完成中的一个需求拉入实现中。分析中有一个需求，最大允许的是四，最多可以拉入就绪中的三个需求。在实现中有一个需求处于完成状态，按照规则这个需求不允许进入测试。因为测试中已经有六个需求处于并行状态，称之为 work in process 或者在制品已经达到了设定的上限。
限制数目的作用是：先解决测试的瓶颈问题，因为测试已经达到了上限，这时会出现很多问题，不一定是测试的问题，有可能是开发没有及时解决 bug，也有可能测试环境不好或者测试本身的效率，人员数目有问题。但是需求的吞吐量取决于瓶颈环节的效率，所以必须让团队暂缓开始更多的测试，而是快速完成已经在测试的需求。如果问题是开发没有解决 bug，就要及时解决bug。如果是测试环境的问题，就要解决如何改善测试环境。以上称之为暂缓开始，聚焦完成。决定开发效率的不是能开始多少，而是能完成多少，尤其是已经形成队列的瓶颈的环节。
三、控制在制品数目
左边的图是一个任务的看板，所有的卡片都是任务，对进行中的需求做了控制，但是这样的控制并没有意义，因为任务完成不代表价值已经交付。而最主要的目的是更顺畅更快速的交付价值，以及发现价值交付过程中的问题。单个任务的完成有可能会隐藏问题，比如问题可能处于任务的协作中。
具体的做法如右图：控制在制品的前提是要控制需求的并行数量，基于用户价值限制在制品，才能促进团队更好协作，暴露问题和快速交付价值，这是核心的部分。
1、举例
第一幅图是一个迭代，迭代长度为一个月比较长，前半个月甚至前二十天所有的需求都处于开发中，二十天之后，需求逐渐进入待测试，但测试并没有开始。因为卡片即使进入待测试，却并不能测试，这些卡片只是任务，单个卡片不能测试，需要等待所有的卡片一起进入待测试进行集中的集成，才能够进入测试中，这显然没有起到控制在制品数目的作用。比如迭代的早期开发中的产品较多，接近结束时，在制品也全部集中于测试中或者待测试，这其实是问题。
团队引入了在制品控制，但是需要进行一系列实践，比如需求的拆分，持续的集成等方法，让需求顺畅地流动起来。图中右边部分，需求开始被均匀地分布。开发中有三个需求，待测试中有两个需求，测试中没有需求，可能有一些需求处于待发布或者已发布。
这样一方面控制住了在制品的数量，另一方面让需求真正顺畅地流动起来，快速的交付这些需求。
潘季驯有言急则沙随水流，缓则水漫沙停。这句话的意思是如果水流急，沙就会被冲走，如果水流慢，沙就会停滞。这里隐喻的是需求交付过程中的问题：如果需求流动速度慢，需求就会积压，问题也会隐藏和累积。限制在制品数目让需求流动速度变快，这时如果需求交付有问题，很快就能凸显问题，因为达到了在制品的上限。或者并行并不多，需求有问题就更容易及时的发现，引导团队及时的解决问题。
所以限制并行的数目好处不仅是更快的交付，还可以更快的发现问题，引导团队解决问题，从而提高长期价值交付能力。
2、控制在制品的不同方法
之前所讲的控制在制品的数目是比较简单的方法，就是在每一列中限制可以允许的并行的数目。理解方法背后的意义，才能够更好的控制在制品的数目。
控制在制品的数目的目的是为了让需求更加顺畅地流动，同时也是为了让问题更快的暴露。理解这两条原则之后，会发现控制在制品数目的方法还有其他很多不同的实践。
(1)、比如对于正在进行中的需求，应该聚焦于协作完成需求，而非单独的任务，看板的任务要向需求对齐。作为一个团队，主要的任务是协作交付需求，不是为了更多的交付任务和完成任务，而是真正的交付需求。所以团队应该通过看板让任务向需求对齐，也引导团队聚焦与协作完成需求，能更快的把需求交付。
(2)、如果需求发生阻碍，看板的卡片上有可能对于阻碍会标志一个禁止项，表示发生了阻碍，卡片本身也会变红。团队应该及时发现并处理阻碍事项，而不是把阻碍放在一边开始新的需求。
(3)、对于开发中，如果有完成的需求应该尽快递交到测试环节进行测试和验收。在这里有一个单独的待测实例，让开发把完成的需求放入待测实例测试，使测试可以尽快的开始。
(4)、优先解决 bug(看板中的小昆虫图标表示需求中有bug)而非开始更多的任务。
(5)、在需求开始的部分中对于就绪的需求，应该分批的开始，而非集中的开始。分批开始可以让需求更加顺畅的流动以便控制好并行的数目。分批开始的意思：比如一个迭代中有三十个需求，如果在第一天全部铺开一起测试，往往就会导致需求集中到最后完成，不能实现真正的持续交付。也会让需求中的问题，比如一些协作问题，技术问题被隐藏，集中在最后才爆发。
(6)、限制在制品的数目，图中数字六表示允许最大的在制品的数目，三表示事实上的在制品数目。
控制在制品的方法有很多，不一定是通过简单的数值的限制。但目的一样，都是让需求更加持续顺畅地流动，需求流动过程中的问题能够及时暴露，引导团队及时解决问题。
3、举例
在十字路口发生了拥，。交警在指挥交通时要做两件事：未进来的车停止前行，已经进来的车快速行驶。这就是暂缓开始和聚焦完成。
同样对于产品开发，也需要做到暂缓开始和聚焦完成，决定开发效率的是完成的效率而不是开始的效率，要提高开发效率就要引导团队尽快完成已经开始的需求，而不是让需求在中间拥堵让问题被隐藏。
四、总结
1、束水攻沙，控制在制品(并行的需求)的数目，让需求更加持续和快速的流动，缩短交付周期。
2、控制在制品数目，可以更即时地暴露问题、阻碍和瓶颈，促进团队系统性的改进，从而让价值顺畅流动。
3、控制在制品数目应该围绕价值交付，以需求而不是任务为线索，设计看板并运作看板，这是有效控制在制品的基础。
4、“暂缓开始、聚焦完成”—尽快交付已经开始的需求，而不是开始更多的任务甚至是更多的需求，因为最终的目标是顺畅快速的交付需求，尤其是已经完成的需求。
