“看板方法”是一个制造业的术语，由David Anderson 引入到软件开发领域。David 在其的著作《看板方法》一书中这样描述看板方法与精益之间的关系：“看板方法带来了一套复杂的适应性系统，该系统的目的就是在一个组织中催生出精益的效果。”
1. 看板方法
正如David Anderson所说，看板方法本身并不是一种软件开发流程或者项目管理方法。使用看板方法之前，你必须已经具备某种流程或方法，而看板方法的作用就在于逐渐改变你已有的流程或方法。所以可以认为看板方法是敏捷团队用来改进流程的一个方法。事实上，我们也可以把看板方法看作和精益思想一样是一个消除浪费的方法，因为对于软件开发消除浪费就是流程改进的主要目的。从这点上，看板方法和Scrum有较大区别，因为Scrum主要提供的是过程管理框架，关注于需要做哪些工作，何时做以及谁来做等项目管理类问题。
看板方法为流程管理提供了最基本的工具就是看板，看板的作用在于把整个开发流程可视化。如图8-所示就是一张典型的看板（Kanban Board），看板上的栏目是：输入队列、分析（处理中）、分析（已完成）、可开发、开发（处理中）、开发（已完成）、可构建、测试和可发布。使用这个看板的团队的工作流程可能是这样的：每个特性都需要经过分析、开发、构建和测试这几个环节。所以，团队可能会从类似下图那样的一个看板开始，在各栏目中贴上贴纸来代表经过系统中的各个工作项。
我们知道Scrum中有任务板（Task Borad）的概念，看板与任务板表现形式非常相近，但有一个本质性的区别。看板中的每一个栏目中的工作量可以设限制，这点与管道理论有非常密切的关系，我们将在下一节中具体讨论。
1. 看板中的管道管理
我们先来看一个日常开发过程中的典型场景，一个迭代的开发过程由产品提出需求、需求分析、开发、测试、产品验收和发布等几个步骤组成，在某一个特定时期，下图是看板的一个快照。
如果某一段时间测试人员生病请假，显而易见，看板上在测试这一栏中很快就会堆积很多需要测试的开发任务（见下图）。现在我们有了团队工作流程的一个更加准确的可视化结果，也很容易就发现团队的瓶颈所在。团队中已经有人清楚问题的关键，接下去就是要做开发流程上的改进，为此我们引入一个重要概念，在制品。
在制品（Work In Progress，WIP）的意思就是当前某个环节中正在开发的任务，而限制在制品就是为这个开发任务数量设定一个上限。在制品是一个看板用语，但我们可以看到它与管道中的开发任务是一致的，而限制在制品就是要管理管道中的负载。管道不能长时间的超负荷运作，看板把工作流程可视化能够帮助团队清楚地看到这种超负荷的问题。在上图中，我们已经看到测试环节已经处于超负荷运转状态了，在这种情况下，马上开始该特性的开发工作就不合时宜了，因为开发完了之后它也不过是放在那里等着，因为没有多余的人手马上测试它。
当测试工作出现瓶颈，我们有很多选择。给某个环节的在制品设置一个上限意味着限制了可以进入该步骤的任务的数量。这样可以帮助限制团队的选项，从而让团队的选择变得更容易。针对例子中的这个测试环节，如果我们把测试在制品上限设为五（见下图），当第六个开发任务即将进入测试环境时，我们就会发现它已经超过了这个环节的在制品上限。通过在图8-中添加一栏“被测试推迟”的任务，就可以将这个问题充分暴露出来。同时，也就意味着我们需要停下来考虑一下如何解决测试资源不足的问题，解决的一种思路是从其他团队调用一个测试人员过来做短期支援，或者鼓励全民测试，或者其他任何有效的方法。从瓶颈被发现到被解决，整个过程可以在本文三张图的流转过程中得到可视化管理。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
