06.看板实践——限制在制品

Posted 2021-02-04 aixiaoxiaoyu

00.找一个合适的在制品限制不仅仅取决于上下文，而且依赖于你想要达到的目标，并且是一个移动的目标。

 

01.实际情况的确如此

　　*所在组织持续改进的动力有多大

　　*团队的规模以及团队可投入工作的时间

　　*正在处理的工作项的类型和规模

　　*更低比更高好

　　*人员闲置或者工作闲置

　　*没有限制是不对的

 

02.通常更低的在制品限制比更高的好，因为你希望尽可能地限制并行工作项的数目。这样做将缩短前置时间，提供更快速的反馈，强迫你移除各种阻碍因素。而这些都有助于改善工作项的流动。

 

03.一定注意不要落入完全不设定在制品限制这个陷阱！这是许多团队导入看板方法时最常犯的错误。

 

04.没有了在制品，就没有了督促团队变得更好的力量。如果你允许无限的工作项出现在你在看板上，就没什么动力逼迫你在开始一项新工作之前完成旧的工作项。

 

05.简单的原则：停止启动，聚焦完成

 

06.限制在制品的一个简单而有力的出发点，就是同意在开始任何新工作之前，尽力完成当前手头的工作。这将让你的在制品保持在较低的水平，因为只有完成了手头的事情，新的工作项才会开始。

 

07.不是“你开始的越多，就完成的更多”而是“你结束的越多，才完成的越多”

 

08.团队编程（mob programming）是一个新奇而有趣的系统开发方法，它是由Woody Zuill辅导的一致团队首创的。团队编程的基本概念很简单：整个团队同时进行一项任务。者意味着：一支团队，一个键盘，一块屏幕。这就像是整个团队一起在进行结对编程。

 

09.设置在制品限制的原则

　　*一个简单口号就足够了

　　*停止启动，聚焦完成

　　*确保不增加在制品

　　*尽可能降低在制品

　　*但也许不能设置为1个

　　*除非你在做团伙编程

 

10.“真正的”在制品是不存在的。在制品限制是种改进工具。设置在制品限制是为了驱动你解决问题，而不是让你忽视它们。

 

11.整个团队的在制品限制

　　*整个团队使用一个数字

　　*例子中提到的策略

　　*根据需要调整限制

　　*通过减少在制品缩短前置时间

 

12.我们只设置了单个在制品限制，也就是整个系统只有一个常量在制品限制(也称为CON在制品)

 

13.从瓶颈开始

　　*瓶颈是工作流中使整个留宿变慢的那个步骤

　　*控制瓶颈之前那个步骤的填充，防止瓶颈处工作泛滥

　　*推动团队解决瓶颈。

 

14.故事点是一种使用相对估算方式来预估团队工作量的方法，它应用于许多敏捷实践(如Scrum和极限编程)中。

 

15.通过估算大小来确定限制

　　*给一列中的故事点数设置一个在制品

　　*也许梅列都有最适合的在制品

　　*在工作项完成过程中，预估可能会发生变化。

 

16.如何做取决于你的想象力以及你的团队更适应什么。要勇于做试验，宁可尝试新事物而不成功，也不要满足于某个次优方案。

 

17.按列设置在制品

　　*关注于看板上工作项的流动

　　*尽早识别排队和阻碍

　　*在列的上方写数字，或者采用其他物理方式

　　*观察流动，按需调整

 

18.请牢记这些策略的目的是侧重于确保每个人都有足够多的工作可做，但对工作流动到完成状态的帮助不大。你可以以此为起点，但用这种方法限制在制品的效果值得商圈。要知道，客户并不关注你是否保持忙碌，他们只希望你能够交付成果。

 

19.按人设置在制品

　　*避免多任务并行

　　*减少“囤货”

　　*常用的可视化方法：限制没人的头像数量、没人一个泳道，给每个泳道设置在制品

 

20.许多团队都采用对工作项进行制品限制的方式。任务只用于追踪为了完成工作项所需要做的事情，这些事情通常不交付客户价值。只要客户在等待有用的东西被交付出来，任务在看板中流动的快慢就是无关紧要的。

 

21.小结

　　*对于你和你的团队，没有特定的在制品限制方式

　　*限制在制品不是目的，改善流程才是。在制品限制只是一个工具，能够帮助你发现阻碍流动性被改善的问题

　　*在制品限制越低，工作流动越快，问题也能被越早地发现。虽然需要较低的在制品限制，但请不要将它设置得过低

　　*当开始设置在制品限制时，一切从简——也许仅仅是一个口号“停止启动，聚焦完成”

　　*可以为团队/工作流设置整体在制品限制

　　*可以按类设置制品限制。

　　*绝大多数团队都会针对工作项而不是任务限制在制品数目。