摘要

看板1是丰田生产方式（Toyota Production System，TPS）中用来支持非集中“拉动式”生产控制（non-centralized "pull" production control）而使用的卡片。作为精益生产的工具，它现在已经应用于世界各地的制造企业之中。如今在敏捷软件开发中，项目的可视化（例如在墙壁上放置任务卡片就是常见的实践）往往被叫做“软件看板”，或者“任务看板”。我们甚至可以看到一些产品维护团队在类似瀑布过程模型中使用看板系统。那么，看板到底是什么呢？为什么它会被用于软件开发环境之中呢？

在本文中，我首先解释一下在精益生产中，尤其是TPS中的看板是什么样子的，来理解下这个成熟行业中的实践和法则，并圈定可以应用于软件开发的概念。其次，我将环顾我们的软件开发项目并指出看板应用的例子。然后，我会分析生产环境中的看板系统与软件开发中的看板系统有何异同，并尝试提出观点来有效地在软件开发中应用看板系统，其中还介绍了新近在kanbandev2讨论列表中萌芽的“KSSE——持续工程的看板系统（Kanban System for Sustaining Engineering）”运动。最后，我给出TPS的一个全景视图，也就是看板这种工具的原始背景，软件开发仍可从中有所借鉴。

TPS中的看板

在“拉动式”生产系统中，看板是指示移动或者制造零部件的信号装置（通常是放在透明塑料封套中的卡片），它是在丰田生产系统（TPS）中发明和发展起来的。在介绍软件开发中的看板之前，我来详细的介绍下看板最初的用法，也就是TPS中的看板。

看板的目的是通过确保只有当下游工序需要时上游工序才生产零部件，进而最大限度地减少工序（process）之间的在制品（Work-In-Process，WIP）或者库存。“拉动式”是指下游工人从他们的上游工序中领取或者“拉”出所需要的零部件。

图1 看板和拉动式生产

图1是看板系统的抽象模型。图中以两个工序，上游工序和下游工序为例，其中上游工序为下游工序供应零部件。为了给最终用户提供产品，这一工序需要生产零部件并将其流向下游，但是不能生产太多，因为生产过剩被认为是最糟糕的浪费。为了避免生产过剩，上游工序不是将成品零部件“推”给下游工序，反而是下游工序主动地从上游工序中拉出（拿）零部件。零部件存放的地方叫做“仓库”（或者“超市3”——Taiichi Ohno首次提出看板的思想，是在他参观了某个美国超市之后，在那里不是由商店售货员而是由顾客自己去获取他们想要的东西）。仓库位于上游工序，作为在制品的“缓冲区”或者“队列”。当一名来自下游工序的工人——叫做“物料管理员”——来到仓库并拿到新近完成的零部件，同时他也反馈一个生产信号——也就是，下游从上游中获取东西并在同时通过看板卡将信息推给上游。这是必须的，因为没有来自下游工序的信号上游工序决不会生产零部件。

那么在图1中有两种类型的看板一同工作：

·领取看板（Withdraw Kanban）——是由物料管理员递交给仓库的购物清单。

·生产看板（Production Kanban）——指示上游工序为其下游工序生产零部件。

如图1所示，领取看板循环于两道工序之间，而生产看板循环于工序内部，并且两者在仓库内发生交换。让我们稍微仔细的了解下这个交换细节。图2显示了在仓库中是如何进行“看板交换”。

图2 仓库中的看板交换

1.位于下游的物料管理员收到领取零部件的信号。此信号由下游工序定义，为下面两种情况之一：

（a） 由收集到的领取看板的数量触发信号

（b） 由定时时间间隔触发信号

物料管理员带着空托盘（pallet）和收集到的领取看板访问上游仓库，并将他收集的领取看板当作购物清单——其中标明了下游工序需要什么，需要多少。

2.由上游工序完成的零部件用托盘装着，并附上生产看板放入仓库。（这些发生在一个单独的线程中，和（1）是独立的。）

3.物料管理员拿取领取看板（购物清单）中指定的零部件，检查是否与附在零部件上的生产看板相匹配，然后交换两个看板。

4.他将生产看板放入“生产板（Production Board）”中——稍后当看板累计到一定的阀值时，它将直观地触发上游生产。

5.物料管理员将所需的零部件附带着领取看板一同从仓库搬运至下游车间。

你可以看到仓库是由一个单独的线程控制的、位于两个工序之间的队列（queue），它通过看板来交换物品和信息。看板卡上面写明了像零部件号码、名称、数量、托盘类型、仓库位置这样的信息，这样物料管理员拿到卡片就知道去做什么了。

对于看板的运转有着严格的规定——被称作“看板六准则”：

1.客户（下游）工序精确按照看板上指示的数量领取产品。

2.供应者（上游）精确按照看板上指定的数量和顺序生产产品。

3.没有任何产品在看板之外制造或者流动。

4.每件产品每时每刻都要与看板相伴。

5.质量残次和数量有误的产品决不能发往下游工序。

6.谨慎地减少看板的数量来降低库存并揭露问题。

正如我们所了解到的，仓库用作零部件的队列，托盘用作零部件的载体，而看板卡用作客户之所需的信息载体。通过维持“连续流通（continuous

flow）”（消除等待带来的浪费）和“最小化在制品（minizing

WIP）”（消除生产过剩带来的浪费）之间的平衡，它们共同形成了“拉动式”系统。在超市中也是用同样的机制来把从采购到销售之间的流程中的在制品维持在“适当”数量，做好这一步是提高商店盈利率的关键。

目前为止，我已经讲述了看板是如何在制造业中工作的。注意以上是对真实看板系统的简化模型。这里没有明确提及的另一件事是看板形象地向每一个工人展示了信息和产品的流程，并激励在现场5（Gemba，指工作场所）的改善4（Kaizen，指工序改进）。改善源于对现场中发生事件的关注。通过看板，每个工人（不是管理人员）都可以看到生产流程，进而有机会发现其中的浪费，并建议改进他们所在的工序。

看板的特性

根据前一节的详细介绍，这里列出了从TPS最初的看板概念中总结的特性和作用。

·实体的：看板是实体的卡片。可以拿在手中，可以移动，可以放在某些东西上面或者里面。

·限制在制品数量：看板限制在制品的数量，也就是防止生产过剩。

·连续流通：它会在仓库耗尽库存之前通知生产的需求。

·拉动式：下游工序从上游工序中抽取零部件。

·自导向（Self-Directing）：它有要完成的工作的所有信息，能以一种非集中的方式实行生产自治，并且不需要微管理（micro-management）。

·可视化：堆放或者张贴着的看板直观地展示了当前的状态和进度。

·信号：看板的可视化状态为下一步的领取操作或者生产操作作出指示。

·改善（Kaizen）：可视化的流程触发并刺激改善。

·附着的（Attached）：看板附在所供给的零部件之上并随其一同移动。

图3为以上9个特性之间的相互影响，它显示了如何将这些组成一个因果效应网络。你从中可以看到看板的两种含义，一是“在维持连续流通的同时限制在制品数量”，而另一种是“改善”。

图3 看板的特性和作用

图表右侧说明了如何在维持连续流通的同时，最大限度地减少在制品。如果仓库中的在制品太少的话，下游工序不得不等待所需的零部件准备就绪，但是在制品还应该保证最小化以防止生产过剩。这样看来这两个目标是相矛盾的，而看板正被看作是解决这个难题的策略。

看板附着于零部件，并且可以被收集和重用，因此看板的数量是固定的。而且看板还可以直观地指示下游工序仅当需要时才获取零部件。这里有两种限定在制品数量的机制。

第一个机制“附着的看板”工作机制同“能量守恒定律”类似。一旦根据产品市场销售的速度和当前工序的内在变化规律确定了看板的数量，那么不管零部件的流入和流出如何，在制品的数量都被限制为看板数量的一定比例。在任何时候，看板（相当于系统中的“能量”）的最大数量都与在制品的上限保持守恒。在图4中，你可以看到“系统”指的是上游工序和下游工序之间的库存，也就是“仓库”中的在制品。

图4 限定在制品数量的看板机制

第二个机制——“拉动式”——通过依据下游消耗速度来确定上游工序的生产速度，这种机制也限制了在制品的数量。第一个机制仅仅涉及到在制品的数量，而第二个则涉及到流程——流程的方向和速度。

“方向”——仅由下游工序来驱动生产。

“速度”——通过看板传达下次生产的时机和数量。

通过确保上游工序的生产以下游工序首次衍生订单中的消耗为依据，“拉动式”限制了在制品的数量。通过在仓库中交换看板，将生产控制信息从下游推到上游，这种依赖性便得以实现。

回到图3：图表左侧说明了如何促使工作自导向并促进改善。通过查看张贴在面板上的看板卡，每个人都可以了解到发生了什么事，以及工序运转的健康状态。改善起始于对现场（Gemba）工作流的观测。放置于面板之上的看板卡直观地帮助工作在没有中央控制管理之下自导向。为了支持改善，这种自治的工序向外提供其性能数据，并将管理重点从对具体工作的指派或者调度上转移到改善活动。

图3中的箭头最终都指向了三个结果，如其所示，看板的终极目标可以表示为“限制在制品数量”、“连续流通”和“改善”。看板系统在维持“连续流通”的同时“限制在制品数量”。它缓冲由普通变因引起的变化情况，并暴露特殊变因引起的变化情况，以备改善。

软件开发中的看板

现在，让我们将视线回到我们自己的工作领域——软件开发。在敏捷软件开发中，通过在项目工作场所的墙上张贴卡片来呈现和分享项目状态已经成为一种常见的实践。我已经在我的上一篇InfoQ文章《用“看板图”实现敏捷项目的可视化》[Hiranabe07]给出了很多例子。特别是，贴在墙上用来展示当前项目状态的任务卡片有时也被称作“任务看板”或者“软件看板”[Poppendieck03]。图5是Change Vision公司的JUDE6开发团队所用的任务看板。

图5 敏捷看板

在面板上，工程任务用卡片（即时贴）来代表，并通过把卡片贴在在面板中的不同区域来象征任务的状态，这些区域被标注为“ToDo”、“Doing”和“Done”（标注的名称可能因地而异，比如“进行中（In

Progress）”、“已测试（Tested）”、“已验收（Accepted）”、“停滞中（Blocking）”等等。）。这样的看板面板有利于可视化地通知任务并限制在制品（处理中的任务）数量。不过在这里并没有出现“工序”（上游或者下游），新出现的概念是“迭代”。对于每一次迭代，通过分解用户故事识别出任务，并且将其张贴在面板的ToDo区域中。

这是一个拉动式系统吗？在制造业中，零部件由上游工序传递至下游工序。而在图5所示的敏捷开发中，并没有看到“移交物”。一个看板卡片对应一个任务，上面写明了如下信息：任务编号、任务名称、估计时间以及任务领取人的名字。任务有状态，可以是“ToDo”、“Doing”或者“Done”，状态信息被分享给整个团队。敏捷开发重视在一起工作，并趋向于减少团队内部的移交物。我称此为“敏捷看板”。

图6是另一个看板面板实例，由Yamaha Motor Solution有限公司7所采用。

图6 持续看板（Sustaining Kanban）

在这里，看板系统被用于带有流程的传统瀑布开发模型。项目被分解成“设计”、“开发”、“验证”等连续的工序，而看板卡就在这些工序之间移动。每张卡片代表需要修改或者添加的系统需求，也代表给下游工序的移交物。注意这不是一个标准的瀑布流程——标准瀑布流程中所有的需求在同一时间内完成“设计”，而“开发”和“验证”则在另一时间，这将使得所有的卡片作为一个整体进行移动。与标准的瀑布流程不同的是，这个项目中的卡片是一个接一个地移动，就像制造业中的单件流（one-piece-flow）一样。这里表现的是产品生命周期里稳定的“持续（sustaining）”阶段，处在带有流程的瀑布状态转换模型的管理之下。在这里，你可以清楚地看到“工作流程”的概念，而不同于敏捷中的“迭代”概念。它比敏捷看板看起来更像工厂中的看板，而且通过制定规则只允许下游工序移动卡片8，可以使其成为拉动式系统。我称其为“持续看板”，这与稍后章节中讨论的David Anderson的“持续工程的看板系统”是类似的。

图7显示的是另外一个例子——在整个产品开发流程的价值流中使用看板的思想实验（thought experiment）[Poppendieck 07]。

图7 精益+敏捷看板

假设在一个产品开发流中有客户团队、产品所有人、开发团队和QA团队，他们使用队列传递移交物来协调工作，以使得团队之间能异步工作，并维持工作速度。每一个“DONE”空间是一个队列，其工作方式就像制造工厂中的“仓库”那样，并且看起来非常像TPS看板系统。同时，它看起来就像每条工序内同步地使用敏捷看板，而在贯穿各个工序的整个价值流上异步地使用持续看板。我认为看板系统可以扩展至覆盖整个价值流，在这种情况下，它是价值流的一个活生生的视觉表现。

在这里例子中，通过设定每一个区域的大小可以限制在制品的数量。而为了使其变成拉动式系统，还需要一种机制来使下游工序以某种信号通知上游工序开始工作。其中一种方法是制定一个规则只允许下游移动DONE区域中的卡片来通知上游。另一种方法是定期召开“迭代会议”，来同步团队和团队之间传递（通讯）的信息。这两种通讯方式可能对应于我们在第一章节中讨论的零部件领取的两种信号，即领取看板的数量（a）和时间间隔（b）的可视信号。一次迭代中的一组用户故事对应于迭代中托盘里的零部件，而零部件的数量对应于迭代中的项目“生产率”（昨日天气[Beck00]）。我叫它为“精益+敏捷看板”，如下一个例子展示的那样它可以与“敏捷看板”相结合。

图8中是一个小型的“便携式”看板系统，这是我在CENTRAL COMPUTER

SERVICES有限公司的某个项目里发现的。在这个项目中，团队被分为了几个小型子团队（通常是一对人）。整个团队有一个与图7概念相似的工作流，还有图8所示的小型敏捷看板面板（ToDo、Doing、DONE）。

当一个子团队选取了一个用户故事，他们将其分解到任务并张贴在便携式看板面板上。在这种情况下，看板系统由两个层面组成，在项目层面一张卡片代表一个用户故事，而在团队（或者结对）层面一张卡片代表一个任务。

他们很喜欢这个便携式小型看板系统，并命名为“看板nano”。

图8 便携式敏捷看板（“看板nano”）

如你所见，将看板的概念应用于软件开发有许多方式。“敏捷看板”用来在团队中分享信息并使工作自导向，但它不支持流程。“持续看板”是另一种类型的看板，能够让小批量的维护工作在几个状态之间流转。这种结合便是“精益+敏捷看板”，使用“持续看板”贯穿价值流，同时在子流（sub-stream）中使用“敏捷看板”。

注意，图5中的“敏捷看板”（在当今敏捷项目中随处可见）仅仅可以看到价值流中的一个子流。当你考虑从客户到客户的完整价值流，经常由处于同一流中的某个团队递交给你需求，而另一个团队则交付你的工作结果给客户。这篇文章的目的之一，就是要设法让看板的应用超越“敏捷看板”，扩大看板在价值流中的应用范围。

生产与开发

软件开发是不同于生产活动或者制造活动的。软件工程师每次创造的产物都是不同的，而制造业总是周而复始的生产相同的东西。所以直接将两者等同起来是危险的。可是，让我们研究一下如何在软件开发看板中找到TPS看板中的特性。表1显示了我们在章节1中总结的看板特性在我们已经提及的两种软件看板中是否仍然有效。

图5所示的敏捷看板例子本身并没有实现“限制在制品的数量”、“连续流通”和“拉动式”特性。敏捷看板更关注于实现任务、“可视化”和“自导向”，以便帮助团队自治并改进其工序。为了使工序连续流通并限制在制品的数量，需要召开“迭代会议”交流信息。

图6中的“持续看板”不仅可以限制在制品的数量，还可以以“单件（one-piece）”和“拉动式”的方式控制流程，而不需要召开迭代会议。在这种方法中，它的关注点是“限制在制品的数量”、“连续流通”和“拉动式”，同时允许团队（或者管理人员）借其改进工序。

回顾一下图3，我将看板的特性和作用分成图9所示的两个关键区域，以便上面提到的两类软件看板概念的用途各得其所。图10显示了生产和开发的频谱图。生产是成功几率很高（高于99%）的工序，而开发的成功几率要低。当成功几率在50%左右的时候敏捷是理想的开发方法，而当成功几率超过90%的时候瀑布式则是理想的开发方式（依据Shannon理论，一个具有50%成功几率的项目是最有价值的项目）。通常随着开发进入到支持维护状态，修改缺陷和添加新功能的成功几率逐步提高。

看板系统的“工序控制焦点（Process Control Focus）”适合在“高于90%”的成功率下工作，而“工序改进焦点（Process Improvement Focus）”既适合在50%成功率也适合在90%成功率下工作。

值得注意的是，敏捷方法在产品维护状态（sustaining mode ）下仍能工作良好，同样看板的“工序改进焦点”特性也在维护状态下工作良好。

图9 看板的特性和作用（2）

图10 使用看板的方法频谱

KSSE——持续工程的看板系统

接下来，我介绍最近出现的一种软件开发精益应用。Agile2007会议时，我参加了David Anderson主持的关于软件看板的一个会中会（Conference-Within-A-Conference，CWAC）。他在Corbis.com管理着一个“维护状态（maintenance mode）”类型的看板系统，并发表了一篇相关论文——持续工程的看板系统[Anderson 07]。他的方法首先关注于看板的“限制在制品数量”特性——就像在图4所示的抽象图表那样——也关注“自导向”特性以使得团队自组织，减少自上而下的（top-down）管理。然后，通过看板观察流程，找出整个工序流中的驻点（stagnation point）并调整人力资源，也就是在工序间调动成员。这意味着他的方法，像图3表现的那样，涵盖了看板特性中从“限制在制品数量”、“自导向”到“改善”。

会议之后，Anderson启动了一个看板开发邮件列表2，这里已经成为将看板应用于软件开发的一个新兴知识创新讨论社区，名为“KSSE”——持续工程的看板系统，读作Kiss-ee ;-)。Aaron Sanders还着手创建关于看板的知识体系，并已经开始构建KSSE词汇表。

KSSE对于通过队列在工序间传递移交物、连续相接的多个工序运作良好。请注意KSSE不一定需要纳入“迭代”的概念。使用KSSE的方式，我看到了另一种缩放（scaling）敏捷的可能性方式并且好过“scrum of scrums”。[Ladas07]

创造价值流

当通过看板从敏捷放大到精益时，一张看板卡应该代表什么东西呢？

 在敏捷看板系统中，一个卡片是一个从“用户故事”中分解出来的“任务”。在开发团队中，它作为工作的一个基本单元执行，因为团队中每个人都能明白它的意思。但是，在看板系统中它贯穿了价值流中的多个工序（多个团队），在其中流转之物应该带有客户认可的价值。既然这样，看板卡片就不是对应于“工作（work）”而是对应于“功能（feature）”，并且它不是WBS（任务分解结构，work

breakdown structure）的组成部分，而是FBS（功能分解结构，feature breakdown

structure）的组成部分。因此团队中的每个人，甚至是客户，都能够理解看板的含义和流转之物的价值。Jim Highsmith

在《敏捷项目管理（Agile Project Management）》[Highsmith04]书中所概述的原理也将FBS定位高于WBS。

“用户故事”，“Backlog事项”或者“用例”都被抽象为“MMF”（最小可市场化功能，minimum marketable features），用来明确地声明流转之物具有客户价值。于是精益开发就可以说成“使得MMF快速流过整个价值流。”

图5中“敏捷看板”的例子是一个工作的分解，它在团队内部工作良好。图6中“持续看板”的例子是一个功能的分解并且一张卡片代表一个MMF。图7中“精益+敏捷看板”的例子与图8一起展示了上级功能分解和下级工作分解的结合。

一旦建立起工作流程，五个“精益思想”[Womack1996]的核心概念就可直接应用于整个工序。精益工序的管理可以简单地遵循以下原则。

·从客户的角度定义价值——确定和分类MMF

·明确价值流并消除浪费——找出驻点（停滞的任务）

·在客户的拉动下创造价值流——制定看板的拉动规则

·关注员工并给予一定的权力——授权给在现场的团队

·追求完美的持续改善——反省和改善

TPS全景视图

以下内容相当于附录，我在这一部分分享从TPS中学到，并发现可以适用于软件开发的知识。Mary和Tom

Poppendieck已经发现有效的软件开发方式和精益或者TPS方法有着很多的相同点——不是在实践层面，而是在原理层面上[Poppendieck03,

07]。让我们从更高的角度回过头来再看下TPS中的看板。

读者很容易假定看板是整个TPS的中心，但其实并不是。图11展示了TPS的概念结构，有时也叫做“TPS之屋（TPS House）”。它有好几种版本，图11是基于Toshiko Narusawa和John Shook的版本[Narusawa06]。在TPS中，看板仅仅是“拉动式系统”实现准时制（Just-In-Time9）的一种方法。准时制可以解释为“仅在需要的时候生产和交付所需要的东西，并且仅完成需要的数量”。它直接瞄准的是客户的需要：“尽快以最低的价格提供最高质量的产品。”注意，准时制是TPS的两大支柱之一，另一个是Jidoka10（译注：写作“自动化/自働化”，但其含义与对应于Automation的中文的“自动化”不同，详见注释）。制造业中的“Jidoka”即自动停机（Autonomation）与软件开发中的测试驱动开发类似。Mary和Tom Poppendieck把Jidoka解释为“停止流水线文化（Stop the Line Culture）”。丰田工厂的工人真正地可以停止流水线而不是把次品推到下一个工序——它不仅是一种规定，也是丰田公司的一种文化，它的萌芽可以追溯到（丰田集团创始人）丰田佐吉时期。

图11 TPS概念结构

准时制由以下三部分元素构成，“节拍时间（Takt time）”、“连续流通”和“拉动式系统”。

节拍时间基于销售率制定产品生产率。

连续流通与节拍时间相匹配，无停滞地在工序中生产部件。

拉动式系统在工序之间移动零部件并通知生产，同时限制库存数量。

也应该注意到两个支柱依赖于改善和人。丰田一年生产近千万辆汽车，同时，他们通过在现场（也就是车间）中近1百万次的改善来完善他们的工序。形象化地表示出团队正在做些什么，总是改善的出发点。

结论

文中，我分析了看板在制造业的实施，接着列出了看板的特性。看板系统用以达到以下目标：

更优的工序控制——在限制在制品数量的同时保持连续流通

更优的工序改进——使流程可视化并且激励改善

“敏捷看板”专注于#2，而“持续看板”专注于#1。我提出将两者结合，来拓展可视化和“拉动式系统”到整个价值流，以使得整个生产精益化。

感谢

Tom Poppendieck与Mary对本文进行了通篇审校，并给出了许多见解和建议，在此我表示非常感谢。感谢Yamaha Motor

Solution有限公司总裁Yasuharu Terai以及Ryuichi Sato允许本文中使用其看板系统的图片。另外David

Anderson也参与了本文的审校工作并且提出了一个更好的看板抽象层次来推进KSSE的发展。KSSE概念最初来源于Kanbandev

Yahoo团队的讨论。最后感谢Deborah Hartmann的最后校订工作，使得我的表达更清晰。

关于作者

Kenji HIRANABE是日本Change Vision公司的CEO。他是JUDE（一个集成了ERD、DFD和Mind Map的UML编辑器）和TRICHORD11（一个集成了Burndown图表和Parking Lots图的敏捷项目管理看板系统）的创始人。他还把《Lean Software Development》、《XP Installed》、《Agile Project Management》以及其他XP/Agile书籍翻译成日文。Kenji把软件开发看作是一种沟通游戏，并一直在寻求提高软件开发的生产效率、合作程度以及乐趣的途径。

小李日课