敏捷其实很简单--初识看板 - 看板管理知识

摘要：今天我们来介绍一下敏捷开发中常用的第二个实践，看板方法。其实，看板方法实际上可以说是精益产品开发的重要实践，与其他敏捷方法相比，它具有更强的可实施性，提升端到端价值交付能力，更好支持系统的改进。而且它也可以和很多其他敏捷方法无缝连结。

今天我们来介绍一下敏捷开发中常用的第二个实践，看板方法。其实，看板方法实际上可以说是精益产品开发的重要实践，与其他敏捷方法相比，它具有更强的可实施性，提升端到端价值交付能力，更好支持系统的改进。而且它也可以和很多其他敏捷方法无缝连结。

看板方法的起源

中文意思带来误解

看板方法的英文为kanban，和中文的看板正好音同，这个当然不是巧合了，看板起源于日本，它的日文注音也正好是'kanban'，在日文中它也可以写作汉字“看板”，当然也可以写成日本假名。但是这两个意思完全不同，写作看板时接近“可视化的板”，而日文假名则为“信号卡”。

软件开发中的看板应该更接近于信号卡，但是在国内，大家往往因名生义，把它看做可视化的板，所以往往忽略了其本质的意义，这也是看板系统在国内被普遍误解的一个重要原因。但是在国外，英语有对应的可视化的板---“kanban board”。所以我们称其为看板墙。

信号卡的概念来自于精益制造，最早出现于丰田生产系统（TPS），我们先可以从制造中的看板学起，

从而帮助我们理解本质，消除误解。

我们可以从上图中看到，丰田生产过程有多个工序构成，其中有加工站，前工程，后工程。

我们可以看到当后工程取件的时候，这个时候，前工程会有产品被拿走，导致空缺，然后加工站会根据前工程的产品空缺来进行生产，填补空缺。

看板时丰田生产方式的两个核心工具之一，看板向上传递的信息流拉大乡下的物流，一直到交付客户，这样就导致了实际上最终拉动生产的是客户的需求。而产品开发则是借鉴的这个思路。

这里我们就要讲一下什么是拉式开发和推式开发了。

传统的推式开发，各个工序按照预先计划生产，将完成的组件推向下游，最求每个工序的产能最大。

而拉式开发则是通过用户需求，从下游向上游传递信息，达到控制。

那么拉动生产方式到底有哪些优点呢：

1。控制库存：下游需要时上游才开始生产，有效控制库存

2。加速流动：进入生产环节的物料和半成品，很快就被拉入下一环节，实现了保证安全库存的前提下物料最快流动，提高工程的运转效率。

3。灵活响应：用户需求变化通过看板行程的信息流快速传递至各个环节，系统能够做出快的响应。

4。促进改善：库存降低和流动加速，能够使生产问题快速暴露，比如生产环节的质量问题很快就会被下个环境发现。

但是产品开发和生产制造有本质的区别，所以我们不能照搬看板方法，产品生产要有自己的看板方法。

David J. Anderson 最早在软件开发中借用了看板实践，并且形成为完整的方法体系。我们下面按照看板方法5个核心实践来介绍。

建立看板系统的3个实践：

1）可视化价值流：产品开发中的价值流是不可见的，这样也就很难管理和优化。为此，看板方法首先要让工作和工作流可视化。

从上图中我们可以看到可视化价值流的三个特点：

首先可视的是用户价值，产品开发的目标也是交付用户价值，工作也应该从用户的角度来组织，图片中每个蓝色的卡片代表一个用户的价值，典型的是一个可以验证，可以交付的用户需求。
接下来是用户价值端到端的流动过程，这里的端到端是指价值提出到价值交付的整个过程。
最后所有问题和瓶颈也都要可视化，问题指的是阻碍价值流动的因素，包括需求不明确，技术问题，外部依赖等。而瓶颈包括价值积压等。

2）显示化流程规则

价值流动过程也是团队协作交付价值的过程。为了更好的协作，团队还需要明确价值流转的规则。如下图所示，流转规则是价值从看板上一列到下一列必须达到的目标。

显示化指的是明确并达成共识，这点和可视化不能混为一谈。

所谓显示化流程规则只明确价值流转和团队协作的规则并达成共识。这个也是团队改进的基线，团队可以进行修正。

3）控制在制品

在制品（WIP）指的是在某一环节内所有的工作--包括进行和等待的。上图中红色数字就是在制品。

环节内在制品数目小于这个数目的，可以从上一个环节拉入新的工作，否则不允许拉入。

控制在制品数量可以是环节内并行工作降低，当个工作项的完成加等待时间缩短，工作项从进入看板到交付的时间也会缩短。因此，加入用户价值的流动。

而且更重要的是，控制在制品数量可以帮助团队暴露问题和瓶颈。举个例子，上图中如果测试的在制品数目达到上限，就不能在拉入新的工作了，团队应该聚焦于完成当前的工作，及时处理出现问题，如果测试这里长期积压，那么说明这个地方已经成为了团队工作的瓶颈，更早的暴露问题所在。

控制在制品实际上成为了一种拉动机制，下游工作顺畅的时候才能从上游拉动工作，这样最终拉动整个用户价值流的交付。控制在制品是整个看板方法的核心，也是很有争议的地方，因为它很难落地在实际开发环境中。这个问题如果有兴趣的读者我们可以进一步根据实际例子交流。

运作看板方法的2个实践：

1。管理价值的流动

管理工作流包括三个部分，

1）准备队列填充，准备队列是整个看板系统的输入和价值流动的源头，管理好准备队列非常重要

2）站会。站会是管理价值流动的活动，一个站会要发生每天的同一个时间看板前，团队成员更新并且根据看板上的卡片，关注出现的问题和阻碍，并且形成解决方案。

3）评审。评审是需求发布前的活动，决定上限哪些功能和相关的策略。

2。建立反馈，持续改进

其实现实中总会有各种问题让价值流动不畅或者阻碍，同时这也是我们的改进机会。当然这个前提是团队必须建立有效的反馈系统，从问题中发现根本原因。

反馈的目的是为了改善。团队根据反馈形成系统的认知必须最终落实到具体的改进行动，而这些行动也可以放到看板系统的调整中，而且其中一部分也可以放到看板外，比如说产品设计，团队调整，环境及工具的改进等。但是无论哪种改进，效果都要通过看板系统中价值流的状态的度量来考察，从而形成看板系统的改进闭环。

本文初步介绍了一些看板相关的知识，其中看板的核心方法是控制在制品数量的拉动系统，通过这个来暴露问题，团队能够根据问题进行反馈和改进，从而提高价值交付能力。