摘要

看板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把軟件開發看作是一種溝通游戲，并一直在尋求提高軟件開發的生產效率、合作程度以及樂趣的途徑。

小李日課