深入解读“看板方法” - 看板管理知识

看板方法，一般认为是由大卫安德森（David J. Anderson)发明创造的，于2004年诞生在微软的XIT项目，并于06年至07年之间在Corbis公司得到大规模运用，紧接着在全球迅速推广。

大卫在发明看板方法之初，便深受了大野耐一的丰田生产方法（TPS），高德拉特的约束理论（TOC），戴明的质量管理，以及敏捷开发的影响。因此，看板方法中的很多概念，都可以从上述理论中找到影子。下面我们就来详细的谈一谈：

拉动(Pull)、瓶颈(Bottleneck)

约束理论诞生于上世纪八十年代，曾大量应用于耐克，福特，英特尔，宝洁等大型企业。其理念是，通过对产品在企业各生产环节之间流动的长期观察，建立拉动系统，进一步识别并消除生产过程的瓶颈，并通过后续的持续改进，消除一个又一个新出现的瓶颈，从而让企业的各个生产环节协同一致，提高生产效率。

这里不得不提一个经典的“鼓-缓冲-绳（D-B-R）”的拉动系统：

在上图中，我们把每一个生产环节比作一个纸片人，那么产品在每个生产环节的流动速度，就相当于每个纸片人的前进速度。
现在，我们给一条绳子，一端由走在最前面的纸片人牵着，另外一端由走在最后的纸片人牵着，并且由前面的纸片人通过绳子，“拉动”后面的纸片人前进。
在所有纸片人前进的过程中，我们可以通过观察绳子是否“紧绷”来判断后面一个纸片人是否为“瓶颈”。如果绳子没有“紧绷”，那么将绳子的一端，由最后一个纸片人，交给倒数第二个纸片人，再次观察绳子的状态。以此类推。

上图中，我们发现到了第四个纸片人的时候，绳子变得“紧绷”了，那么我们断定这第四人就是我们要找的“瓶颈”，是进行重点改进的对象。
当然，当改进结束以后，我们会再次运用这一拉动系统，去发现和解决系统中新的瓶颈，以达到持续改进的目的。

批量规模（Batch size)、在制品（WIP)

丰田生产方法的产生要追溯到上世纪70年代，大野耐一及其团队通过长达20多年的探索和完善，形成了丰田公司独有的生产体系，通过对物流，库存，组织等一系列管理的强化控制，极大的提高了丰田汽车的竞争力。

凭借这套生产方法，丰田汽车在进入美国市场后，仅仅通过短短几年时间，便迅速的击败了美国三大汽车公司，在美国本土的汽车占有率上独占鳖头。

与高德拉特的约束理论相比，丰田生产方法更强调了“批量规模（Batch size）”的重要性。丰田正是通过降低批量规模，进而降低在制品库存，达到节约成本的目的，实现了效能的飞跃。另一方面，小规模的生产方式，也让企业能够更加聚焦于减少浪费，通过降低协调成本和事务成本来提高交付效率。

（2012年冬，拍摄于美国麻省的Wrentham Village Premium Outlets的Coach工厂店。该店为了保证服务质量，提高成交率，对店内购物人数进行了限制，因此在店外排起了长龙。）

看板方法借鉴丰田生产方法的另一个重要思想就是对在制品数量（WIP）的限制。通过对每一个生产环节在制品数量的限制，一方面，减少了产品在各个生产环节之间的排队等待，缩短了产品从开始生产到交付的时间，加速了价值流动；另一方面，由此产生湖水岩石效应，暴露了生产环节中的团队协作，资源分配等各类问题，为进一步改进提供了着力点。

看板方法对于WIP的最佳实践是对每一个生产环节都分别定义一个最大在制品数，以充分发挥看板在挖掘问题，协同改进方面的作用。
对于WIP，通常有两类错误的应用：

先不设置WIP，等到看板运用成熟以后，逐步加入WIP

一个典型的例子就是雅虎公司。早期的时候，他们选择不设置WIP限制，理由是因为他们认为团队对于看板应用还不够成熟，希望首先利用看板的可视化来提升组织的成熟度，然后再引入WIP。然而，事实证明这种方法是有问题的。离开了WIP这一看板的核心方法，团队在协同改进上进展缓慢，最终在还没看到改善之前，团队就被解散，或者放弃了看板方法。

设置整体WIP，取代各个环节的WIP

即使是看板方法的发源地，Corbis公司，也在这一问题上栽过跟头。为简化WIP，几个重点项目团队选择了粗粒度的整体WIP限制。结果因为无法识别具体环节上的瓶颈来加以改进，实际效果大打折扣。

（上图中，我们以典型的软件开发流程为例，根据实际产能，对每个开发阶段都分别设置了WIP，这是一种比较推荐的做法。）

质量（Quality)

作为质量管理之父，戴明提出了“质量是一种以最经济的手段，制造出市场上最有用的产品。一旦改进了产品质量，生产率就会自动提高。” 其思想更是对二战后迅速崛起的日本起了重大作用，并且在随后的几十年中影响了许多世界上最具创新精神的经理人。

因此，大卫在看板方法的推广过程中，也极其强调了內建质量的重要性。经过研究发现，专注质量，能够让高缺陷率团队的生产力和交付速率获得2-4倍的提升。

在软件生产过程中，提高质量通常有以下几种实践：

代码检查（Code Review）
单元测试（UT）
测试驱动开发（TDD）
验收测试驱动开发（ATDD）
使用设计模式（Design pattern）

前置时间（Lead Time)

众所周知，敏捷开发非常重视对用户反馈的快速响应，强调以最短的时间，交付最大的用户价值，以获得市场竞争力。

因此，任务完成的“前置时间”，是衡量敏捷团队成熟度的一个重要标志，而看板方法也将这个“前置时间”看作是度量与改进的一项非常重要的指标。

服务分类（Class of Service)

在看板的实际应用中，对于不同的任务类型，往往需要区别处理，因此看板方法引入了服务分类（CoS）这一重要机制。常见的服务分类有：

1.加急类（Expedite）

常见于一些时效性特别强的需求，或者对产品重大缺陷的修复。
这一类任务将被视为最高优先级，因此可以无视最大在制品数(WIP)的限制，直接进行作业。
然而这样的任务，很容易对看板的正常工作造成冲击，因此加急类的任务个数，通常都仅设置为1。

2.固定交付日期类（Fixed Delivery Date）

看板方法推荐安排一定的产能，来处理一些固定交付日期的任务。
对于这一类的任务，需要在开发之前对任务的工作量进行估算，并在开发过程中定期的确认进度。一旦发现进度落后到有可能无法完成的情况，则需要对任务重新进行评估。如有必要，这类任务可以升级为加急类。

3.标准类（Standard）

顾名思义，就是最普通的任务。看板方法推荐大部分的产能都应用于此类任务。无需对任务的工作量进行估算，直接按照先进先出的顺序进行处理。但对于超过两周工作量的任务，建议先进行拆分。

4.无形类（Intangible）

主要针对一些用户价值有限的附加功能。看板方法推荐安排在此类任务上的产能应该低于标准类。

上图为软件开发看板中，针对不同服务类型的产能分配。值得注意的是，该产能分配在实际过程中，可根据具体的情况，适当的动态调整。比如，由于业务季节性的原因，预计后续一段时间的固定交付日期任务会比较少，这个时候可以将一部分的产能暂时交给标准类的任务。

需要强调的是，看板的服务分类是一项非常强大的机制。它能够确保团队在合适的时间做着合适的事情，即使在整体按时交付率比较低的情况下，团队依然能够获得较高的客户满意度。

看板仪式（Ceremony)

下面简单介绍一下Kanban实施的几项重要会议：

1.每日站会

必开。在每日固定时间召开，全员参加，每人1-3分钟各自介绍任务状态，计划，以及障碍。此外，每日站会还可能需要根据实际情况，对看板输入队列（To Do List）进行填充。

2.回顾会

建议两周开一次。用于讨论上一阶段的工作成果，检视上一期行动方案的落实情况，以及集体思考如何改进，并制定下一期的行动方案。

3.发布计划会

根据实际情况，在版本发布前召开。主要用来明确即将发布的内容，以及部署计划等等。具体内容和瀑布流程的Release notes内容非常类似。

4.需求讨论会

可选会议。如果需求可以在日常工作交流中完成，可以选择不开。

联系人：	阿道
电话：	17762006160
地址：	青岛市黄岛区长江西路118号青铁广场18楼