在开始主题之前，有必要先声明一下： 这篇文章里会讲到的看板和WIP控制，和现在行业里普遍使用方法有些不同，这些不同可能会引起不同的观点和争议。这些东西还未经过充分的实践验证，仅仅是出于自己的实践，反思，总结，再推理得出的结论。所以第一，请同学们不要无条件认同，一定请你们仔细的和自己的实践去印证，即使你觉得有道理，也需通过实践才能证明其有效性。第二，也请持不同观点的同学，不要拿当下书本或者行业里的标准做法来评判我总结的东西是否正确合理(BGM:我们不一样~~~)，如果以当前标准来评判的话，那这里的内容怎么都是不对的，不看也罢。现在，就进入主题吧。
看一下Toyota Production System（TPS）
同学们知道TPS是来自于丰田的生产制造系统，制造系统通常是长成这样的：
一条生产线，上面有一道道的工序，最前端是原始的生产物料，最后一道工序生产出来的就是完成品。在TPS里，有一个非常重要的概念，叫在制品，英文是WIP(Work In Progress)，WIP是指什么呢？见下图：
WIP的定义是：已经开始但是还未完成的工作。从采购进的原始物料开始，一直到成品之前，中间所有的物料，零部件，组装件，不管是放在缓冲区等待加工的，还是正在工序中加工生产的，全都是WIP。WIP是TPS中一个极其重要的概念，精益体系认为WIP是浪费的来源。原因很简单，因为对企业来说，WIP就是已经投入资金，但是还没获得有效产出的东西，WIP越多，意味着投入产出比越低，这显然是企业需要避免的现象。所以在TPS中，控制WIP是一个最重要的精益手段。
那怎么才能有效的控制WIP呢？无非是2个方法，1. 加速流动，让WIP快速的变成成品；2. 减少WIP的投入，让WIP恰好满足生产需要。
接着，我们来看一下另一个概念，缓冲区：
在TPS里，各个工序之前都设有缓冲区，用来存放工序生产所需要的物料，可以把缓冲区理解为一个待办清单。知道了缓冲区这个东西之后，我们就来看一下TPS的作业原理：
缓冲区的每一个物料格子里，都放了下道工序生产所需的物料和一块小板，这块小板在TPS里就叫做看板（KANBAN）。看板上记录了和这个板同处一个格子里的零件的生产所需物料和生产工艺等信息。事实上，TPS里的看板非常复杂，种类也很多，有生产看板，取件看板，控制看板，每种看板都起到不同的作用，并需要配套不同的使用规则。软件交付领域借鉴了TPS的理念和部分方法，但并没有套用TPS所有的管理方法。
上图的例子中，工序4的工人如果手上的工作做完了之后，他们就会到工序4的缓冲区里去拿他们生产所需的物料，这个动作叫做拉动。拉动了之后会怎么样呢？
工人根据生产需要，从缓冲区里拿走了物料，但是留下了看板，所以在那个物料格子里，物料没有了，看板还在那儿。这时候会发生什么事情？
工序3的工人发现工序3和工序4之间的缓冲区里，有物料格子里的物料被取走了，但是看板被留下了，他们就知道他们需要去生产新的物料去把这个格子给填上。所以他们会看着看板上的信息，到工序2和工序3之间的缓冲区去拉动他们生产所需要的物料。工序2和工序1也是如此的操作过程，这就是TPS最简单的模型。
现在，在这请同学们思考一个问题，WIP的控制，应该在哪里进行？
在生产工序上控制WIP有意义么？又怎么控制呢？大部分情况下，工厂当然是希望生产工序上的机器和工人一直都是有活干的，工序停工意味着产能浪费，意味着WIP的流动变慢。所以工序上的工人或者机器，在闲的时候，他们会去缓冲区拉动物料继续生产，在忙的时候，也没办法给他们增加更多的工作。因此，WIP控制应该发生在缓冲区，在工序上控制WIP的数量是没有意义的，这是我第一个观点。
WIP控制应该发生在缓冲区
注意，上面我在说到工厂希望工序上的机器和工人都是一直在工作这句话的时候，有这么一句前置语：大部分情况下。那么什么情况下，工序上的机器和工人可以不工作了呢？就是在看到自己这道工序和下道工序之间的缓冲区里的物料，达到了WIP上限的时候。
在上面的例子里，假设工序3和工序4之间的缓冲区的WIP上限是10，当工序3生产完了一个零件，放进了物料格之后，发现这个缓冲区里的物料已经到达10个了，那么他们就不需要再工作了，因为再工作也不会加速有效产出，缓冲区到达上限意味着它的下游工序已经饱和，这时候上游工序即使生产的再多，也只是在增加WIP，却不能增加产出。同理，当工序3停工了，工序2和工序3之间的物料格就会只增不减，当到达了它的WIP上限时，工序2也应该停工了，以此类推，整条生产线都是按照这样的规则来操作。所以，这里我有第二个观点：WIP限制的作用域是上游工序，而不是下游工序。
再来看一下Theory of Constraint（TOC）
和TOC理论结合在一起，让我更好的理解应该在哪里，和如何去设置WIP。首先，TOC理论有一个很重要的前提：必须是基于一个稳定的系统，TOC的改进五步法才能有效。所以这也是为什么第四式 别忙打，先磨下剑对我们而言，最重要的作用是让团队快速进入稳定的状态。
TOC理论有一个重要观点：一个稳定系统中瓶颈环节的产能，就等于整个系统的产能，这个瓶颈环节，在TOC被称作制约因素。怎么理解这个观点呢？请看下图:
还是基于刚才的例子，我们假设每个工序的产能分别是
工序1：5件/天
工序2：8件/天
工序3：6件/天
工序4：4件/天
那么在这个生产系统中，很容易看到工序4就是瓶颈环节，即制约因素。它的产能是4件/天，那是不是整个系统的产能也只能是4件/天，不可能大于这个数字？这里就引出了一个令人崩溃的事实：如果瓶颈环节损失了1小时，就等于整个系统损失了1小时，其他工序的生产效率再高也都是浮云一片。所以，根据TOC理论，要优化一个系统，首先得让它稳定，然后要找到它的制约因素去优化，不围绕制约因素优化的行为都是耍流氓。
对TOC有兴趣的同学可以去读一下高德拉特的《目标》三部曲，TOC五步法这里也就不介绍了，网上一搜一大堆。
如何根据TPS TOC来设计看板
根据刚才我第一个观点：WIP控制应该只发生在缓冲区，那么基于上面这个板，我首先需要加入缓冲区（见下图灰色的列）。
WIP控制应该只发生在缓冲区这个观点对于软件开发同样有效，同学们可以设想，就拿测试团队来说，假如我们测试团队有3个人，他们一天平均可以处理5个故事的测试。目前的一些书里，针对这种情况会在测试这个工作队里上设置一个5作为WIP上限，意思是当测试团队的正在处理的工作到达5了之后，就不能再给他们更多的任务了。
但是我对于这一点始终心存疑惑，因为我无法理解这个上限数值在这里如何发挥作用。对于测试团队来说，不管他们当前手上在处理多少个故事，哪怕是6个，超过WIP上限了，只要有人空闲了，他就应该去拉动新的故事来测试，如果他们都在忙，那就算只有1个故事在测试，他们也无法拉动新的故事。
缓冲区设置的思路很简单，参考TPS里缓冲区的设置，就是放置在工序和工序之间。但对于软件开发的过程来说，有一个很特殊的存在，就是bug fix。因为通常来说，负责开发和负责bug fix的，都会是开发工程师。当bug fix修复完了之后，也还是要回到测试环节去在此验证bug 的修复情况。所以从流动角度来说，回流是真实发生的事情，再次流向测试环节，也是真实发生的事情，所以我就把这些事实也体现在看板布局上。
然后，配合这样一个看板布局，我们需要设置一些规则，以便团队去聚焦完成。我们的规则如下：
1. 测试人员测出bug之后，放入bug fix的最下方。
2. 开发人员完成bug修复之后，放入待测试列的上方，根据故事的优先级排列，且不受WIP上限约束。
3. bug fix是最优先去处理的工作，当出现开发工作和bug fix并存的时候，优先进行bug fix。
同学们可以理解这3条规则背后的原因么？
第一条规则的原因，是因为我们的流动单元是故事，所以理论上来说，先测到的故事优先级总是较高，先测出bug的故事会在bug fix列的上方，那么后测出bug的故事，自然就放在bug fix列的下方了。
第二条规则的原因，是因为修复完了bug之后，我们并不希望去打断测试同学手头的工作，但是修完bug的故事优先级又相对更高，所以我们会放在待测试队列的上方。对测试同学而言，不管是bug fix再验证，还是新过来故事的第一次测试，都是待办工作，所以他们只要在手头工作完成之后，从待测试列去拉动卡片就可以。
第三条规则应该更容易理解，尽快完成bug fix，不理解的同学可以去看一下 第七式 嚎尤根~~~
接下来，我们就来聊一聊我们是怎么设置WIP的了。假设我们的项目团队刚刚达到的稳定状态是这样的:
需求分析
由PO和BA负责，共有2个人，平均每天可以完成4个故事的分析。所以我们需求分析的产能是4个/天。
设计
由开发团队的成员共同负责，共有7人，他们每周会找时间一起讨论待设计队列里故事的设计方案，平均下来每天能设计3个故事。能够同时进行设计的平均并发数是3个故事。
开发&用例&bug fix
这个环节比较特殊，因为会有多个工作并存，同学们可以理解，通常情况下，一个故事要能满足可以被测试的条件的话，至少是功能都已经开发完了，且它的测试用例也写完了，否则是没法测试的，所以我们是把开发和用例放在一列里面。然后如上面所介绍，开发工程师又经常要同时面对开发和bugfix的工作，bugfix完了之后还是会进入待测试，所以我们就把这两列放在一起。
我们有7个工程师，去掉bugfix和做设计的时间，他们平均可以并发支持5个新故事开发，平均每天可以向待测试列流入4个故事。
测试
由测试人员负责，只有2个测试，既要负责写用例，又要负责测试，还得负责验证，非常苦逼，算上由于bug回流的因素，再加上他们需要花时间去做测试用例，他们平均每天能测完1个故事并流动到发布环节，平均并发是2个故事。
发布
由1个工程师负责，由于使用了发布流水线，效率奇高，没算过这个环节的极限。所以这个环节的平均并发是无穷大，产能也是无穷大，吼嗨森！
（至于上述这些环节之间的流转规则，我在第四式 别忙打，先磨下剑里也讲过，有兴趣的同学可以移步阅读。）
于是，我们就有这样一个表格
很明显，目前测试环节的产能最低，它就是整个系统的制约因素，所以我们先来设置它的WIP。
在开始设置WIP之前，有必要再回顾一下WIP的概念：从原始物料到完成成品之前，所有的物料，零件，组装件，不管是在缓冲区还是在加工中的，全都是WIP，所以WIP不仅仅存在于缓冲区。
首先，WIP应该有下限，由于是设置在缓冲区里的，所以对于工序来说，WIP没有下限的话，就有可能造成停工——无料可拉了，那自然是停工了。如果这发生在瓶颈环节前的缓冲区里，那就会造成瓶颈产能浪费，同学们一定还记得，瓶颈的产能=整个系统的产能，如果瓶颈环节停工1个小时，无论其他同学多努力多高效，整个系统里所有人都浪费了1个小时。
因此TOC理论反复强调，要喂饱瓶颈环节，千万不要让瓶颈环节停工。而在缓冲区里设置WIP下限，就是为了不让瓶颈环节停工。那WIP的下限应该设置多少呢？设置成这个环节的平均并发就可以了（也可以再乘上个安全系数），这样生产工序就总是会有活干。
接着，设置WIP的上限。关于WIP上限的设置，网上有很多文章都介绍了可以使用利特尔法则来计算，那我们来看一下利特尔法则又是什么鬼。它的公式是：
WIP=前置时间*产能
利特尔法则也有一个很重要的前提：一个稳定的系统。它认为的稳定系统是流入速率和流出速录是相等的（这里的稳定TOC里要求的稳定是两码事，别弄混了）。关于利特尔法则，请同学们自行谷歌一下，我比较笨，花了点功夫才弄明白利特尔法则。
理解了利特尔法则，我们就知道，如果我们想减少前置时间，而前置时间 = WIP/产能。所以我们在暂时无法提高产能的情况下，只有减少WIP，这就是WIP控制的数学原理。
BUT，我们再来看一下利特尔法则对于稳定的这个要求，流入速率=流出速率，在我们的例子里满足么？流入待测试列的速率是4个/天，而流出测试列的速率是1个/天，显然是不满足这个稳定的要求的。而且我相信大多数软件项目都做不到利特尔法则要求的稳定。所以我们不能直接套用利特尔法则，因为它的前提都已经不成立了。那怎么办呢？WIP上限不设睡不着觉啊！
后来我想，如果做到了持续交付，那交付周期一般来说都是可以相对稳定的，如果交付周期稳定，产能也稳定的话，那么在这个交付周期里，整个团队能交付的上限就是交付周期和产能的乘积：
周期交付上限=交付周期*产能
这个公式的逻辑是，在产能稳定，交付周期固定的情况下，这个团队在这个周期内最多能完成这点数量的交付，再给更多的任务是没有意义的，只会增加WIP，但是不能增加有效产出，所以，WIP的上限应该等于周期交付的上限。
在我们的例子里，我们假设交付周期是10天，那么根据这个公式，瓶颈环节（测试）的WIP=10*1=10（个故事）。那对测试环节来说，在一个交付周期里，只能完成10个故事的测试，给测试团队更多的测试任务非但不能提高产出，还会产生浪费。
那我们的缓冲区上限就是10 了么？并不是！WIP不仅仅存在于缓冲区，所以在缓冲区里设置的上限应该要减去测试团队的平均并发，在我们的例子中，就是10-2=8。
所以我们会把待测试这个缓冲区的下限设置成2，上限设置成8。
现在瓶颈环节的WIP设置好了，别的环节的上限怎么控制呢？同样的思路，周期交付上限减去平均并发就可以了，但是注意，这个周期交付上限并不是这个环节自己的产能和交付周期的乘积，而应该是瓶颈环节的产能和交付周期的乘积。
那么根据我们上面的那个表，就可以逐个计算出每个缓冲区的上下限：
待测试下限 = 2，待测试上限 = 10*1-2 = 8
待开发下限 = 5，待开发上限 = 10-5 = 5
待设计下限 = 3，待设计上限 = 10-3 = 7
待开发这列有点特殊，它的上限等于下限，这种情况说明在这个项目里，开发团队的人员配置过剩了，同时能开始5个故事的开发，但是总产能却只有每天1个，可以考虑调整人员配置方案了。如果算出来下限还大于上限，那说明人员配置不平衡的问题更严重了，需要立即调整。
前面说过，WIP控制的作用域是上游，所以待测试的2~8这个范围就是在告诉开发的同学们，最好能把待测试列里的故事数量控制在4~5这个区间，这样既能保证测试的产能不被浪费，也不会有太多的WIP浪费。以下说明应该会更直观：
0~1 要造成产能浪费了，程序猿们加班吧
2~3 接近下限了，要加油了
4~5 不错的状态，保持下去
6~7 快接近上限了，可以放缓一下速度
>= 8 别再给测试的兄弟们添堵了，除了bugfix之外，不要再开发新的故事了，去拉测试的兄弟一把，如果帮不上测试兄弟的忙，就去干点别的事情，如说看看待设计，待开发栏里有没有达到下限，如果已经达到了，那就去学点新的知识，如果一时没有心思学新的知识，打几盘王者农药，玩几盘狼人杀也行，就是别去开发新的故事了。
这一式写了辣么多，感谢同学们有耐心读到这里。这一式确实也是我花费比较多时间去思考和推演，可以预见会引起非常多的探讨，期待中......
最后总结一下吧：
1. WIP控制应该放在缓冲区，而不是工作区
2. WIP控制的作用域是上游，而不是下游
3. 缓冲区的下限可以设置为平均并发
4. 在交付节奏稳定，但各环节产能不一致的情况下，瓶颈环节的WIP的上限可以用 交付周期*瓶颈产能-平均并发 来计算
本文由@合气大蒜 原创发布于管理圈，未经许可禁止转载。
粤公网安备 44010602010970