看板与利特尔法则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上所有的事情我们放到同一张图中，可以看到下面的情况，实线表示两者之间存在因果关系，同时还是正比的，因增大，果也会增大。虚线表示两者之间存在的因果关系是反比的，因增大，果会减小。

而在这众多因素之中，只有在制品数量是我们能够最有效的直接加以干预的。 而只有前置时间我们是可以直接观测的。

就像我们正在开车一样，我们踩油门的时候，速度表会发生变化，从60迈到100迈，但我们真正关心的并不是仪表盘的变化，而是真正汽车行驶的速度。

所以我们采用控制在制品数量的手段，通过观测前置时间的变化来观察我们的改进是否有效，但更重要的是整个系统是否正在向着更好的方向迈进。

我们用直觉感受一下，在制品数量如果越低越好，那限制到1怎么样？限制到0怎么样呢？

很显然，在制品数量如果过低的话，团队成员可能会产生空闲的现象，很大一部分产能会被浪费掉，那在制品数量限制到多少是最合适的呢？

我们都知道，一个任务如果2周能完成，两件任务串行，需要的时间是4周，但两件任务并行，绝不是2周能完成，有可能5周的时间都完成不了，所以直觉上在制品数量过高也不能带来产能的上升。

所以一个朴素的原则就是： 团队中每个人在任意时刻，手中只有一件事的时候，效率是最高的。团队的在制品数量低于这个值，会造成产能的浪费，如果高于这个值，会造成前置时间的变长。

那我们再用定量的方式模拟一下吧。

假设我们有一个三阶段的开发流程：分析、开发、测试，平均每张卡片需要4天时间分析、5天时间开发、6天时间测试。

为了简化计算，我们把分析、开发、测试三个阶段设一个总的在制品数量限制。[2]

当我们有1个分析人员、1个开发人员、1个测试人员的时候，会得到下面这个结果：

这个实验可以重复，有兴趣的同学可以自己写代码重复一下。

道理看似很简单，但放在软件研发领域就变得非常复杂，我们需要平衡需求和产能之间的关系，控制队列长度实际上就是在控制期望和承诺。在尊重事实的前提下，我们尽量让队列的长度变短，不去承诺不切实际的东西。 ↩

所谓“排队”，实际上软件开发真正的“收银窗口”就是最终交付的环节，在这个环节之前的所有需求其实都是一个队列，队列的末尾就是我们最近承诺的一个需求。所以一旦我们承诺了无法立刻着手的需求，那么就会产生极大的浪费。 ↩