将看板应用于软件开发：从敏捷到精益(2)

目前为止，我已经讲述了看板是如何在制造业中工作的。注意以上是对真实看板系统的简化模型。这里没有明确提及的另一件事是看板形象地向每一个工人展示了信息和产品的流程，并激励在现场（Gemba，指工作场所）的改善（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区域中。

原文转自：http://www.ltesting.net