將看板應用于軟件開發：從敏捷到精益(2)

目前為止，我已經講述了看板是如何在制造業中工作的。注意以上是對真實看板系統的簡化模型。這里沒有明確提及的另一件事是看板形象地向每一個工人展示了信息和產品的流程，并激勵在現場（Gemba，指工作場所）的改善（Kaizen，指工序改進）。改善源于對現場中發生事件的關注。通過看板，每個工人（不是管理人員）都可以看到生產流程，進而有機會發現其中的浪費，并建議改進他們所在的工序。

看板的特性

根據前一節的詳細介紹，這里列出了從TPS最初的看板概念中總結的特性和作用。

• 實體的：看板是實體的卡片?？梢阅迷谑种?，可以移動，可以放在某些東西上面或者里面。
• 限制在制品數量：看板限制在制品的數量，也就是防止生產過剩。
• 連續流通：它會在倉庫耗盡庫存之前通知生產的需求。
• 拉動式：下游工序從上游工序中抽取零部件。
• 自導向（Self-Directing）：它有要完成的工作的所有信息，能以一種非集中的方式實行生產自治，并且不需要微管理（micro-management）。
• 可視化：堆放或者張貼著的看板直觀地展示了當前的狀態和進度。
• 信號：看板的可視化狀態為下一步的領取操作或者生產操作作出指示。
• 改善（Kaizen）：可視化的流程觸發并刺激改善。
• 附著的（Attached）：看板附在所供給的零部件之上并隨其一同移動。

圖3為以上9個特性之間的相互影響，它顯示了如何將這些組成一個因果效應網絡。你從中可以看到看板的兩種含義，一是“在維持連續流通的同時限制在制品數量”，而另一種是“改善”。

圖3 看板的特性和作用

圖表右側說明了如何在維持連續流通的同時，最大限度地減少在制品。如果倉庫中的在制品太少的話，下游工序不得不等待所需的零部件準備就緒，但是在制品還應該保證最小化以防止生產過剩。這樣看來這兩個目標是相矛盾的，而看板正被看作是解決這個難題的策略。

看板附著于零部件，并且可以被收集和重用，因此看板的數量是固定的。而且看板還可以直觀地指示下游工序僅當需要時才獲取零部件。這里有兩種限定在制品數量的機制。

第一個機制“附著的看板”工作機制同“能量守恒定律”類似。一旦根據產品市場銷售的速度和當前工序的內在變化規律確定了看板的數量，那么不管零部件的流入和流出如何，在制品的數量都被限制為看板數量的一定比例。在任何時候，看板（相當于系統中的“能量”）的最大數量都與在制品的上限保持守恒。在圖4中，你可以看到“系統”指的是上游工序和下游工序之間的庫存，也就是“倉庫”中的在制品。

圖4 限定在制品數量的看板機制

第二個機制——“拉動式”——通過依據下游消耗速度來確定上游工序的生產速度，這種機制也限制了在制品的數量。第一個機制僅僅涉及到在制品的數量，而第二個則涉及到流程——流程的方向和速度。

“方向”——僅由下游工序來驅動生產。

“速度”——通過看板傳達下次生產的時機和數量。

通過確保上游工序的生產以下游工序首次衍生訂單中的消耗為依據，“拉動式”限制了在制品的數量。通過在倉庫中交換看板，將生產控制信息從下游推到上游，這種依賴性便得以實現。

回到圖3：圖表左側說明了如何促使工作自導向并促進改善。通過查看張貼在面板上的看板卡，每個人都可以了解到發生了什么事，以及工序運轉的健康狀態。改善起始于對現場（Gemba）工作流的觀測。放置于面板之上的看板卡直觀地幫助工作在沒有中央控制管理之下自導向。為了支持改善，這種自治的工序向外提供其性能數據，并將管理重點從對具體工作的指派或者調度上轉移到改善活動。

圖3中的箭頭最終都指向了三個結果，如其所示，看板的終極目標可以表示為“限制在制品數量”、“連續流通”和“改善”?？窗逑到y在維持“連續流通”的同時“限制在制品數量”。它緩沖由普通變因引起的變化情況，并暴露特殊變因引起的變化情況，以備改善。

軟件開發中的看板

現在，讓我們將視線回到我們自己的工作領域——軟件開發。在敏捷軟件開發中，通過在項目工作場所的墻上張貼卡片來呈現和分享項目狀態已經成為一種常見的實踐。我已經在我的上一篇InfoQ文章《用“看板圖”實現敏捷項目的可視化》[Hiranabe07]給出了很多例子。特別是，貼在墻上用來展示當前項目狀態的任務卡片有時也被稱作“任務看板”或者“軟件看板”[Poppendieck03]。圖5是Change Vision公司的JUDE6開發團隊所用的任務看板。

圖5 敏捷看板

在面板上，工程任務用卡片（即時貼）來代表，并通過把卡片貼在在面板中的不同區域來象征任務的狀態，這些區域被標注為“ToDo”、“Doing”和“Done”（標注的名稱可能因地而異，比如“進行中（In Progress）”、“已測試（Tested）”、“已驗收（Accepted）”、“停滯中（Blocking）”等等。）。這樣的看板面板有利于可視化地通知任務并限制在制品（處理中的任務）數量。不過在這里并沒有出現“工序”（上游或者下游），新出現的概念是“迭代”。對于每一次迭代，通過分解用戶故事識別出任務，并且將其張貼在面板的ToDo區域中。

原文轉自：http://www.anti-gravitydesign.com