将看板应用于软件开发：从敏捷到精益讲义.docx

摘要  HYPERLINK /wiki/Kanban \o 看板 \t _blank 看板 HYPERLINK /cn/articles/hiranabe-lean-agile-kanban;jsessionid=1D055474950AB5A986B75700D6F054BA \l ftn.id1 1是丰田生产方式（Toyota Production System，TPS）中用来支持非集中“拉动式”生产控制（non-centralized pull production control）而使用的卡片。作为精益生产的工具，它现在已经应用于世界各地的制造企业之中。如今在敏捷软件开发中，项目的可视化（例如在墙壁上放置任务卡片就是常见的实践）往往被叫做“软件看板”，或者“任务看板”。我们甚至可以看到一些产品维护团队在类似瀑布过程模型中使用看板系统。那么，看板到底是什么呢？为什么它会被用于软件开发环境之中呢？ 在本文中，我首先解释一下在精益生产中，尤其是TPS中的看板是什么样子的，来理解下这个成熟行业中的实践和法则，并圈定可以应用于软件开发的概念。其次，我将环顾我们的软件开发项目并指出看板应用的例子。然后，我会分析生产环境中的看板系统与软件开发中的看板系统有何异同，并尝试提出观点来有效地在软件开发中应用看板系统，其中还介绍了新近在 HYPERLINK /group/kanbandev \t _blank kanbandev HYPERLINK /cn/articles/hiranabe-lean-agile-kanban;jsessionid=1D055474950AB5A986B75700D6F054BA \l ftn.id2 2讨论列表中萌芽的“KSSE——持续工程的看板系统（Kanban System for Sustaining Engineering）”运动。最后，我给出TPS的一个全景视图，也就是看板这种工具的原始背景，软件开发仍可从中有所借鉴。 TPS中的看板 在“拉动式”生产系统中，看板是指示移动或者制造零部件的信号装置（通常是放在透明塑料封套中的卡片），它是在丰田生产系统（TPS）中发明和发展起来的。在介绍软件开发中的看板之前，我来详细的介绍下看板最初的用法，也就是TPS中的看板。 看板的目的是通过确保只有当下游工序需要时上游工序才生产零部件，进而最大限度地减少工序（process）之间的在制品（Work-In-Process，WIP）或者库存。“拉动式”是指下游工人从他们的上游工序中领取或者“拉”??所需要的零部件。 图1 看板和拉动式生产 图1是看板系统的抽象模型。图中以两个工序，上游工序和下游工序为例，其中上游工序为下游工序供应零部件。为了给最终用户提供产品，这一工序需要生产零部件并将其流向下游，但是不能生产太多，因为生产过剩被认为是最糟糕的浪费。为了避免生产过剩，上游工序不是将成品零部件“推”给下游工序，反而是下游工序主动地从上游工序中拉出（拿）零部件。零部件存放的地方叫做“仓库”（或者“超市 HYPERLINK /cn/articles/hiranabe-lean-agile-kanban;jsessionid=1D055474950AB5A986B75700D6F054BA \l ftn.id3 3”—— HYPERLINK /wiki/Taiichi_Ohno \o Taiichi Ohno \t _blank Taiichi Ohno首次提出看板的思想，是在他参观了某个美国超市之后，在那里不是由商店售货员而是由顾客自己去获取他们想要的东西）。仓库位于上游工序，作为在制品的“缓冲区”或者“队列”。当一名来自下游工序的工人——叫做“物料管理员”——来到仓库并拿到新近完成的零部件，同时他也反馈一个生产信号——也就是，下游从上游中获取东西并在同时通过看板卡将信息推给上游。这是必须的，因为没有来自下游工序的信号上游工序决不会生产零部件。 那么在图1中有两种类型的看板一同工作： 领取看板（Withdraw Kanban）——是由物料管理员递交给仓库的购物清单。 生产看板（Production Kanban）——指示上游工序为其下游工序生产零部件。 如图1所示，领取看板循环于两道工序之间，而生产看板循环于工序内部，并且两者在仓库内发生交换。让我们稍微仔细的了解下这个交换细节。图2显示了在仓库中是如何进行“看板交换”。 图2 仓库中的看板交换 位于下游的物料管理员收到领取零部件的信号。此信号由下游工序定义，为下面两种情况之一：（a） 由收集到的领取看板的数量触发信号（b） 由定时时间间隔触发信号物料管理员带着空托盘（pallet）和收集到的领取看板访问上游