在制品与前置时间（又叫交付时间）

转自：http://www.jianshu.com/p/bbc652391e45

在制品与前置时间基本为线性关系，减少在制品数量就能减少前置时间。

利特尔法则（Little’s Law）作为一个非常朴素的原理，为看板方法奠定了一个理论基础，看似简单的公式背后却有其复杂的一面。

一、利特尔法则

利特尔法则的公式是这样的：

平均吞吐率=在制品数量/平均前置时间

举个例子，假设你正在排队买快餐，在你前面有19个人在排队，你是第20个，已知收银窗口每分钟能处理一个人的点餐需求，求解你的等待时间。

如果你已经决定要排队，并且站到了队尾，那么在制品数量就是20（个），平均吞吐率是1（人/分钟）。
从你站到队尾的时候开始，一直到你点完餐，这个时间就是你的“前置时间”。
即使我们没有学习过利特尔法则，也可以轻易地算出来：

    1 = 20 / xx = 20（分钟）

因为在一段时间之内，保持工作量饱满的话，我们每天能做多少工作基本是一定的，所以吞吐率基本上不会发生太大变化。
如果这个时候我们想缩短平均前置时间，也就是等待的时间，利特尔法则告诉我们：可以通过减少在制品数量来达成这个目标。
在这个例子中，就是减少排队者的数量。

这也很好理解，10个人的队列和20个人的队列，前者需要等待的时间会更短。 [1]

二、限制在制品的意义

如上面所说，在制品数量和前置时间是成正比的，缩短前置时间的最有效手段就是减少在制品数量。

前置时间的增长会导致交付周期变长，这一点基本毋庸置疑。

前置时间的增长会导致交付的可预测性下降，俗话说“夜长梦多”，长时间停留在某一个阶段会带来一些额外的风险。

如果我们的交付周期比需求变化周期更长，那么会有更多的紧急任务，所以交付周期变长会导致更多的紧急任务。

如果我们管理不好紧急任务的插入，会增大我们的在制品数量。

如果交付团队的可预测性很低的话，那么会影响到IT研发组织和业务部门的信任关系，当业务部门无法预测一个需求提交给研发部门什么时候能交付的时候，那么唯一可行的手段就是一次性把要做的事情全部都压给研发部门，直接增大了研发部门的在制品数量。

同时在制品数量的增长会带来的另外一个后果就是故障发现得很晚，这一点在过去三四十年的软件工程方法论中都得到了验证。

发现的故障需要资源和时间来进行修复，带来的就是在制品数量的上升和前置时间的增长。