转自：http://www.jianshu.com/p/bbc652391e45学习
在制品与前置时间基本为线性关系，减小在制品数量就能减小前置时间。spa
利特尔法则（Little’s Law）做为一个很是朴素的原理，为看板方法奠基了一个理论基础，看似简单的公式背后却有其复杂的一面。code
利特尔法则的公式是这样的：队列
平均吞吐率=在制品数量/平均前置时间
举个例子，假设你正在排队买快餐，在你前面有19我的在排队，你是第20个，已知收银窗口每分钟能处理一我的的点餐需求，求解你的等待时间。资源
若是你已经决定要排队，而且站到了队尾，那么在制品数量就是20（个），平均吞吐率是1（人/分钟）。
从你站到队尾的时候开始，一直到你点完餐，这个时间就是你的“前置时间”。
即便咱们没有学习过利特尔法则，也能够轻易地算出来：get
1 = 20 / x
x = 20（分钟）
由于在一段时间以内，保持工做量饱满的话，咱们天天能作多少工做基本是必定的，因此吞吐率基本上不会发生太大变化。
若是这个时候咱们想缩短平均前置时间，也就是等待的时间，利特尔法则告诉咱们：能够经过减小在制品数量来达成这个目标。
在这个例子中，就是减小排队者的数量。string
这也很好理解，10我的的队列和20我的的队列，前者须要等待的时间会更短。 [1]
it
如上面所说，在制品数量和前置时间是成正比的，缩短前置时间的最有效手段就是减小在制品数量。io
前置时间的增加会致使交付周期变长，这一点基本毋庸置疑。class
前置时间的增加会致使交付的可预测性降低，俗话说“夜长梦多”，长时间停留在某一个阶段会带来一些额外的风险。
若是咱们的交付周期比需求变化周期更长，那么会有更多的紧急任务，因此交付周期变长会致使更多的紧急任务。
若是咱们管理很差紧急任务的插入，会增大咱们的在制品数量。
若是交付团队的可预测性很低的话，那么会影响到IT研发组织和业务部门的信任关系，当业务部门没法预测一个需求提交给研发部门何时能交付的时候，那么惟一可行的手段就是一次性把要作的事情所有都压给研发部门，直接增大了研发部门的在制品数量。
同时在制品数量的增加会带来的另一个后果就是故障发现得很晚，这一点在过去三四十年的软件工程方法论中都获得了验证。
发现的故障须要资源和时间来进行修复，带来的就是在制品数量的上升和前置时间的增加。