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.小结
*对于你和你的团队，没有特定的在制品限制方式
*限制在制品不是目的，改善流程才是。在制品限制只是一个工具，能够帮助你发现阻碍流动性被改善的问题
*在制品限制越低，工作流动越快，问题也能被越早地发现。虽然需要较低的在制品限制，但请不要将它设置得过低
*当开始设置在制品限制时，一切从简——也许仅仅是一个口号“停止启动，聚焦完成”
*可以为团队/工作流设置整体在制品限制
*可以按类设置制品限制。
*绝大多数团队都会针对工作项而不是任务限制在制品数目。