开发者学堂课程【研发效能提升和敏捷实施36计：束水攻沙——持续加快产品交付速度】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/615/detail/9378
束水攻沙——持续加快产品交付速度
一、 回顾可视化
二、 管理价值流动过程
三、 课程总结
四、 如何在Teambition上束水攻沙，持续加速产品交付
一、回顾可视化
对于研发交付的问题，我们需要先找到问题所在，在研发过程中，需要可视化端的交付流程，因为一般不同的问题分布在各个局部，往往需要去观察整个系统和整体的交付过程，需要关注需求的过程。可视化也是可视化需求的交付过程。
1.4步可视化价值流
STEP1:用户价值驱动：识别有效的流动单元
注意：可视化的主体是需求的交付，而不是每个人的任务
STEP2:左右模块对齐：反应环节内任务协作
如果一个需求的交付是一个不同的团队，要让他们的任务向需求对齐，因为团队的目标是交付需求，而不是完成任务
STEP3:前后拉通职能：定义端到端的价值流
包含各个职能，可能是业务，整体，开发，运维等等
STEP4:定义流动规则：赋能团队本地决策内建质量
让更多的决策在本地发生，所以需要定义流动规则，让团队可以自己去改正流程
2.检验可视化效果的3个标准：
能反映需求端到端的交付过程吗？
能即时体现影响价值流动的瓶颈和问题吗？
能依据可视化的信息协作和做决定吗？
可视化是一个手段，而目的是高质量交付有效价值，为了保证价值更顺畅的交付出去。可视化奠定了基础，要以此基础管理数据流，让价值顺畅流动。
二、管理价值流动过程
目的：如何管理数据流，让价值顺畅流动
1.束水攻沙—限制在制品数量
束水攻沙是关于黄河治理的一个法则
黄河入海水道的变迁
问题：黄河为什么治理起来非常困难？
原因：因为黄河堆积了大量的泥沙，需要经常进行改造。
潘季驯（1521-1595）
明朝治理黄河的水利专家，被誉为“千古治黄第一人”
中国古代最伟大的水利专家
潘季驯曾四次治理黄河，提出了最有效的方法，叫做“束水攻沙”
束水攻沙
重点：束水就是将大地变得更加狭窄，在河道上建立一条更加狭窄的缕堤，而遥堤目的是为了防止溃坝。束水的目的是让水的流量变小，流速变快。当修建好一个更狭窄的堤坝时，水会在同样的流量下，流速加快，会让黄河中的泥沙流动到下游，再在下游利用其他湖水，将泥沙冲入入海口。
引用束水攻沙案例，讲解产品开发
开发任务
图中有很多蓝色的线，每条蓝色的线都表示一条泳道，也就是对应的一个需求，交付的一条道，它所对应的黄色的纸片是对应的需求中的开发任务。在开发中，泳道是有限的，在开发中最多并行8个需求，如果这8个需求满了，也不可以进入第9个需求，它其实是约束了并行的需求的数目。约束并行需求的作用是，当并行的数目变少时，执行速度和交付速度会变快，交付的速度变快就意味着从进去到出来的速度变快，它响应的周期会变得更短。例如，限制在制品数量，并行的工作的数目，在制品就是同时在开发中的需求的个数，要限制在制品的数量就是要限制在开发过程中需求的数量，在制品的数量越少，那么交付的速度就越快。
需要交付的累计流图
此图中横坐标为时间，纵坐标为需求数，红色的曲线代表已经开始的需求的数目，绿色的曲线表示已经交付的需求的数目。在不同的时间段，比如具体的某一天，可以知晓它的需求数。在制品，从红色曲线的纵坐标开始，表示这一天有很多的需求开始，绿色曲线的纵坐标就代表，需求的结束，两个纵坐标相减就是在制品的数目，就是并行的需求的数目，也是已经开始还没有完成的数目。前置时间代表的横线的横坐标，表示在某一天有n个需求的开始，达到绿色的曲线的横坐标，表示有n个需求的结束，两个横坐标相减，就是需求从进入到出去的时间被称之为前置时间。如果并行得越多，那么前置时间就会越长，前提是交付速率不变。例如，每个月可以交付5个需求，并行有10个需求，则前置时间为5除以10，时间为两个月，如果将在制品减半，将需求变为5个，则前置时间就会变短。利特尔法则中，降低在制品的数目，也会降低前置时间，提高响应能力。通过控制在制品的数量，就会降低前置时间，就会提高敏捷响应能力。
利特尔法则：
前置时间=在制品/交付速率
控制在制品的不同方法：
1.聚焦于协作完成需求，而非单独任务 完成需求，从而将需求的数目降低
2.即时发现并处理阻碍事项 快速解决问题，才可以完成需求
3.尽快移交测试验收
4.优先解决bug，而非开始更多的任务
5.需求分批进入，而非集中开始 如果发现已经有很多需求存于系统当中了，也不用急于将需求放进去，可以让需求分批进入
6.限制并行需求的数目，集中完成已开始的需求 例如通过泳道数，来限制并行开发的需求，通过控制在制品的数目，减少需求的数目，让需求可以尽快的移交，直至交付
总结：通过控制在制品数目，起到束水攻沙的作用，让需求更快的进行流动。
2.湖水岩石—暴露问题，促进改进
目的：提高吞吐量
急则沙随水流
缓则水慢沙停 --潘季驯
束水攻沙仅仅是让需求进行的速度变快了，而不是绝对的速度变快。
需求流动速度快，则能及时发现问题和解决问题。反之：需求积压，问题也会隐藏和累积
实例：
阿里市场例子
迭代早期
问题：蓝色的纸片代表需求，黄色的纸片代表任务，而图中的问题主要是需求和任务全部同时开始。
迭代中期：
所有的需求都即将开发完成，还剩一小部分
迭代结束前两天：
问题：迭代结束前，没有一个需求在任务中。需求全部都在进行待测试，最后的时间，需要解决很多问题，质量很难保证。此开发过程中需求的流动是不顺畅的。
迭代过程中的看板变化：
迭代早期时，所有的需求和任务同时进行，最后导致在迭代后期的时候，所有的东西都在等待测试，对质量造成很大影响。
最后的变化：
在经过迭代后，需求最终有一部分处于已排期，还有部分处于已就绪中，在开发中的需求很少，整个需求是持续的进行流动。
湖水岩石效应：
将湖水的水面的高度比喻为在制品数量和周期时间，湖底有很多岩石，当湖水很深时，看不到岩石的存在
降低需求的时候，水面也会降低，此时问题就暴露出来。
暴露问题的顺序：
1.协作和交付模式
2.需求拆分和管理问题
3.测试和回归问题
4.环境稳定性的问题
5.组织和沟通问题
6.目标管理和同步问题
7.基础技术架构
以阿里某某基础产品团队实施过程中暴露问题先后解决顺序为例
解决问题的步骤：减小批量-暴露问题-解决问题
理念：
例子：背景为在十字路口里堵车，交通会出现状况，警察来会阻止侧方位的车继续进入车流中，让拥堵中的车，尽快驶出车流。
暂缓开始（Stop Starting）
聚焦完成（Start Finishing）
在研发过程中就要做到暂缓开始，聚焦完成两个操作
3.建立节奏—管理价值流动
目的：如何有效的管理价值流动
建立节奏管理价值流动，例子：
输入：定义了需求的规划，有时被称为队列的填充，排期队列填充会议（或活动）
避免大批量的填充：
在进行需求计划的时候，就会出现一个问题，多长时间计划一次，这就是需求填充，填充间隔时间会很长，填充时间长会导致许多问题：
一次必须填入更多的需求，从需求确认到开始实现的时间长
出现的问题：降低了响应需求的敏捷性，也降低了需求的质量，对信息掌握不充分，无法获取市场的反馈，也无法在市场开发过程中了解到后续需求的反馈和输入。还会产生猜测性和实际无效的需求。
1.降低了决策的是质量
2.猜测但实际无效的需求
3.影响需求确认质量
从需求确认到完成的时间长，造成
1.不能很好的支持有效的学习和创新
2.降低团队响应变化的能力（敏捷性）
倡导更频繁填充：
越频繁地填充，带来越大的敏捷性（业务员响应能力），并提高决策的质量和团队的关注度
从敏捷的角度来讲，我们可以更加频繁的填充，但是还是需要考虑开发的合理性
最频繁的是每天按照需求填充，但是每天填充而不做周期性的规划的话，就无法达到好的效果，需要一个整体的规划。
合理的填充频率还取决于
1必要性—新信息到达的频度
2.召开填充会议的协调成本
形成了填充的机制：
产品规划：每月一次，由团队业务方和开发团队代表共同完成里程碑的规划。确定本月的主题和主题需求
可以和业务部每个月进行一次产品规划，此时对需求还没进行详细的分析和设计，还可以在月规划的基础上进行周排期。
需求排期：每周一次，开发和业务进一步澄清本周开发的需求。需要时，可以调整里程碑规划中尚未开始的需求，并及时响应紧急的日常需求。
两级填充（规划/排期）带来的好处： 第一级填充为产品规划，第二级需求为需求排期
产品规划是产品与业务之间的内容，排期最主要的是开发团队的内部，需要产品参与
1.维持了业务的承诺模式
2.让团队聚焦整体阶段性主题
3.避免小瀑布带来的危害 小瀑布指需求过多，且同时开始和结束
4.带来更灵活的响应能力 即使已经做好了规划，如果开发发生变化，也可以更加灵活的进行处理
5.更加专注和高效的需求沟通 可以更好的去澄清一个时间段内的需求
拥有一个规划对于整个团队来说，可以更好的合理去规划自己的技能，比如前后端等角度，另外，规划过后的东西可以按照优先级逐步去澄清来进行排期。
过程：每日站立会议
每日站会会与传统站会有所区别，对于站会也有很多新的模式以及问题，例如站会应该是一个人对应一个人，还是应该一个需求对应一个需求。在传统站位中的表现就是，人们围成一圈，相互讨论，进行计划事项。
站会的核心：促进价值的顺畅流动
观察管理需求是否顺畅
此时的站会会取决于图中需求的状态，获取需求的状态有两种方式，第一个是从左向右的顺序来进行了解，第二个是从右向左了解需求的状态。实际上从右向左检视每一列的顺序更为合理，因为我们的目标是尽快的完成需求，这样才能更快的开始前面部分的需求。
站会的内容是从右向左检视每一列的需求，观察是否有流动不通畅的情况，使其回复顺畅的流动
问题：站会上应该关注什么？（什么会影响和阻碍价值的顺畅流动）
阻碍价值顺畅流动的因素：
1.瓶颈和队列
2.关键缺陷
3.重点关注的需求
4.阻碍和问题
5.到期或即将到期的需求
6.中断
站会步骤：
会前：更新了看板上的内容
过程：瓶颈-中断-重点关注的需求-被阻碍的需求-已经或快超期的需求-长时间不动的需求-未反应在看板上的问题
（从右至左走读看板，关注和处理阻碍价值顺畅流动的问题）
会后：小范围讨论需要较长时间才能解决问题
团队
1.确保看板反应最新状态
2.确保流程顺畅流动的问题
3.识别影响顺畅流动的问题
4.现场处理或提出限进方案
个人
1.了解项目的整体状态
2.清楚个人的优先级
3.提出问题和需要
输出：发布评审会议（可选）
总体流程：
建立一个规划，来管理价值的流动。每个月进行一次产品规划，每周进行一次开发排期，每天进行一次站会，发布部分，可以根据产品的不同情况来进行持续发布，对于价值的管理，融入到各个活动中建立一个节奏。
三、课程总结
1. 束水攻沙：限制在制品数量，加速价值流动
通过控制在制品的数量，加速价值的流动，提高响应力
2. 湖水岩石：暴露问题，促进改进
3. 站会6+1：关注和处理阻碍价值流动的问题
4. 建立节奏：月规划，周排期，日站会
思考：
你看到过多的在制品数量给你们团队带来了什么影响？尝试过哪些办法来减少在制品数量？
四、如何在Teambition上束水攻沙，持续加速产品交付
实际操作：
首先可以看到 Teambition 上的一个看板，包括就绪（待开发）、开发中、待测试、测试中四个部分，还可以观察到四个部分的上方包含的数字，例如，开发中的数字4代表，在开发中包含了4个需求卡片，有4个需求卡片同时在开发中，4就代表在制品数量，此数量不可无限制地放大，我们需要根据团队情况去进行一个限定。
站会问题：传统的站会中会让工作人员回答3个问题，而站会中的主要部分为从右向左关注价值流动，也就是进行从右向左检视每一列的操作。看板中进行站会，需要关注6+1个点。第一个点是需要关注瓶颈和队列，例如测试中这5项中已经有成为瓶颈的部分，成为瓶颈的原因也许是因为测试资源不够，还有可能因为开发部门的问题，还有可能是因为缺陷导致需求无法流动。第二个点是需要关注关键缺陷，例如测试中的有两个缺陷需要去关注，然后缺陷移除掉，如果过程中出现需求和缺陷共同需要解决的时候，我们应该先解决缺陷，再继续去进行前面部分的需求，让此部分需求尽快交付，使其产生价值。第三部分是，我们需要去关注重点的需求，例如在开发中，出现了重点的需求需要我们去进行关注，还有优先级较高的需求需要我们去关注。第四个部分是需求会存在阻碍和问题，例如含有依赖方的我们需要去关注，要进行推动并将问题解决。第五个部分是卡片中有不同的颜色进行表示，过期的为红色卡片，到期的为橙色卡片，快到期的为蓝色卡片，没到期的是灰色部分，我们需要去关注到期或者即将到期的需求，来判断是否能够按时完成。第六个部分是，在分析中部分是没有需求卡片，出现了中断的情况，中断的情况是我们需要关注的地方，如果中断的情况过多就会造成价值无法进行流动，需要及时将其补好。最后一点是，在站会即将结束时，管理人员会问工作人员，自己手上是否还有工作部分没有体现到看板上，这时，团队就需要将这些没有体现到看板上的内容增加到看板上。站会前还需要注意，更新状态。
建立节奏：
实例：
此规划包括了月规划，研发排期，每日站会和发布窗口以及阅读研发效能回顾
此团队在七月下半旬进行八月份的月规划，然后在八月份第一周为七月对八月份的规划需求进行研发排期，然后每天早上进行站会，此团队每周会有两次发布窗口，最后到下个月出进行月度研发效能反馈。团队在刚开始的时候，进行的研发效能反馈可以更加的频繁。
在 Teambition 上进行建立节奏操作：
在 Teambition 中会有日程项目，点击进去就可以看到每日的安排事项，时间以及参与人员
同时还可以观察日历，日历中也会反映出各种排期、规划等
此日历还可以被订阅到本地的日程
