學習了近兩年的敏捷開發，也跑了近兩年的 Scrum，但對於 Kanban（看板方法）卻仍是一知半解。這次利用了 228 連假，給自己出了一道習題：好好的閱讀 Ruddy 老師的《精實開發與看板方法》，並於本週主動分享給公司內各單位同仁關於 Kanban 的資訊，就在今天完成了這項習題！
以下重新歸納了一些我對 Kanban 的最基本認識，希望對於初學者有一點點幫助。若有錯誤還請不要客氣的糾正我～！
Kanban 是什麼？能吃嗎？
或許有些人對 Kanban 這個字完全沒有畫面。所以我先用一個淺白的句子描述一下 Kanban 的輪廓：「一群人透過一塊板子一起協作的方式，試圖從看版上得到更多的資訊。」有畫面了嗎？對，這描述聽起來很像下圖：
但通常這個板子會在牆上，並且貼滿滿的便利貼，並且有一些狀態欄位：
（圖片出處：Getting started with Kanban）
Kanban 的由來
在 1940 年代後期豐田公司對超市的研究中找到一個絕佳的流程設計，可以達到「零庫存管理」，之後將之應用在工廠生產中，建構出 TPS（Toyota Production System，豐田生產系統）。接著於 2005 年間由看板之父 David J. Anderson 首次成功的應用在軟體開發上，並一直到 2007年才正式命名為「看板方法（Kanban Method）」。
然而當今的敏捷開發中，Kanban 與 Scrum 成為了敏捷開發最火紅的兩個主流框架。說到這就要談談最常被誤解的「看板」這兩個字：
| Board (n.) | 看板 |
| Kanban | 看板（方法） |
在 Scrum 中，牆上也有一塊板子（Scrum Board），中文也稱為看板；Kanban 中牆上的板子也是看板。所以一般會用「看板方法」來稱呼 Kanban。
Kanban Method
看板是一種透過漸進、演化過程來改變組織系統的方法。
-- David J. Anderson
相較於 Scrum，Kanban 是一種漸進式的改善。尊重團隊的現況，尊重當前所有人的位階、職稱與關係，並不會進行大刀闊斧的改革。在這聽起來好像有一種無為而治的味道，但凡事都有一個 but，這個 but 就是：
看板的本質是一個很單純的想法，那就是半成品（work-in-progress，WIP）必須被限制。
-- David J. Anderson
換言之，沒有限制 WIP，那跑的就不是 Kanban，只能被稱為一個 Board。 限制 WIP 是 Kanban 最核心的信條與概念。那為何 WIP 如此重要呢？以下聊聊 WIP。
WIP ( Work-In-Process）
用個例子來說明，以下是速食餐廳免下車點餐車道範例（來源：WIP: why limiting work in progress makes sense (Kanban)）：
1. 當 WIP 設為 1（車道同時間只允許一台車進入）：
2. 當 WIP 設為 3（車道同時間只允許三台車進入）：
3. 當 WIP 設為 5（車道同時間只允許五台車進入）：
上述圖中所需時間表示運行一陣子後，一台車從點餐後到取餐離開總花費時間；而單位時間產出率，表示每單位時間的出貨量。這個例子整理為圖表就是：
| 排隊車輛 （WIP） |
單台車總時間 |
產出率 |
| 1 | 90 | 1.11% |
| 2 | 90 | 2.22% |
| 3 | 120 | 2.5% |
| 4 | 160 | 2.5% |
| 5 | 200 | 2.5% |
從此表可以看出，WIP 大於 3 之後，產出率並沒有因此而提昇。簡單的說，當車道裡頭的有三台車，負責點餐的員工，繼續點餐並不會帶來幫助，大可去忙別的，最好還能夠協助出餐作業。所以從這個例子可以看出：
限制 WIP 的主要目的是避免出現瞎忙的狀況，讓團隊集中火力關注實際產出。而不是製造一堆半成品，徒增不必要的成本。
這還可以用 Ruddy 老師書中的另一個故事 — 「看板一日遊」來作更生動的詮釋，這就是 Kanban 追求的價值。
更可用「束水攻沙」來形容這種感覺。傳統治水方式就是很直覺的清挖淤泥、拓寬河道、加高提防等，但明朝潘季馴提出了一個全新的主張，利用縮減河道寬度，增強水流的力道，自然的帶走淤泥，免除水患。（這貼切的意境是出自 David Ko 老師的分享）
Kanban 的最高境界
想像一下束水攻沙滾滾洪流的畫面，當這流速拉高，產能趨於穩定之時，便能夠更準確的預測產出效率，進而轉守為攻，主導需求，這個境界在《目標》一書中描述的相當到位，不是單憑三言兩語可以言喻的境界。
後記
Kanban 和限制理論真的是高度相關，不喜歡看書的朋友，建議可以從《目標》這本經典企管小說開始下手。
