一次搞懂Kanban看板管理法—最容易上手的敏捷工作法【敏捷管理手札】

自敏捷的概念被推出以來，各種不同的敏捷應用方法一直被推出，在相互競爭下，常見的敏捷方法及目前的市佔率大致如下：Scrum（58％）、Scrum/Kanban混合型（10％）、Scrum/XP混合型（8％）、Kanban（7％）、其他迭代方法（4％）、精實生產（1％）、Extreme Programming（1%）。

從以上市佔率來看，如果公司要推動敏捷，當然不會去選那些較為冷門的方法，而會投資在最具有成長性的方法。這也導致目前才開始要導入敏捷的公司，幾乎都會選擇「彎道超車」，直接以Scrum為主要的敏捷方法。

Scrum在所有敏捷方法中算是比較「輕量級的」，意思就是架構簡單，應用廣泛，容易上手。即使如此，由於Scrum對團隊成員的角色、職責與工作流程都有詳細的規範，即便是在公司裡小範圍實施，也會牽涉到組織的變革，與流程的調整，對某些行業或工作而言，可能還是稍嫌複雜。

這時，更「輕量級的」Kanban法可能更合適，這也就是在豐田製造系統中，大家耳熟能詳的「看板」。

讓我們一起來探討Kanban法是如何工作的。

延伸閱讀：高效生產力的6大敏捷工作方法，用敏捷管理取代時間管理

---

Kanban看板管理法的起源

---

Kanban法的起源可以追溯到20世紀40年代，一位名叫大野耐一（Taiichi Ohno）的豐田工程師（後來成為豐田汽車的副社長）創建了一個系統。

他注意到在「及時生產系統」JIT（Just In Time）的要求下，他們的庫存供應量僅剛好夠滿足需求，一旦工廠裡有空貨架，就需要馬上訂購更多庫存以補充貨架。慢慢地，貨架被一塊看板及上面的紙片所取代，就成為最早的看板雛形。

2004年，微軟的David J. Anderson將Kanban法應用於IT軟體開發，從此，Kanban法大量普及。

Kanban法強調保持連續的任務流和持續的交付，同時，團隊的工作量永遠不會超過它所能處理的工作量。

延伸閱讀：敏捷開發：從特斯拉看導入敏捷概念的硬體製造趨勢與10大挑戰

---

Kanban看板管理法的六大原則

---

Kanban法經過這幾年的不斷演進，現在已經形成了六大原則：

原則1：將工作視覺化（Visualize）  

首先，每個工作任務都記錄在「看板卡」上。

看板被分為「待完成To do」、「進行中 In Progress」和「已完成Done」的欄位，團隊可以根據需要添加更多類別，以更好地視覺化其過程。

隨著每張「看板卡」的重新定址，它將進入下一個階段，直到所有「看板卡」完全通過工作流移動。

原則2：限制工作量（Limit Work In Progress）

Kanban法的重點是保持連續的任務流並持續交付，團隊永遠不會被賦予超出其能力範圍的工作。這是透過看板的第二個原則實現的，即限制工作量WIP（Work In Progress）。

原則3：管理工作流（Manage Flow）

透過觀察當前的工作流看板，有助於團隊瞭解與溝通工作任務的進展情况。

原則4：明確化規則（Make Policy Explicit）

透過看板，讓所有人知道工作是如何被完成的，彼此間的依賴關係，以及明確團隊的規則。

原則5：建立回饋迴路（Establish Feedback Loops）

團隊能在持續的交付過程中，透過團隊的力量，持續優化流程。

原則6： 協同改進，試驗性發展（Improve collaboratively, Evolve experimentally）

當一份工作持續在「進行中」（In Progress）超過預期時間，或消耗過多資源，或形成工作瓶頸時，就需要透過團隊透過合作或試驗新方法一起來解決問題。

---

比較Kanban與Scrum的差異

---

Kanban與Scrum的相同點

簡單來說，Kanban法與Scrum有四個相同點：

第一，使用Pull System

需求導向，依需求來完成所需工作。簡單的說，兩者都會有待辦事項清單的存在，在看板上逐步移動位置至完成狀態。Scrum下稱為「Backlog」，Kanban法下稱為「To Do List」。

第二，限制工作量

兩者都有「產能」的限制。Scrum透過每個Sprint的工作量來確保團隊集中資源在當前最重要的工作；而Kanban法透過限制工作量（Work In Progress），避免團隊超負荷，協助團隊穩定地產出。

第三，化繁為簡

兩種工作方式都會先將大型或複雜的工作，切分成小型工作，以方便後續的工作安排。

第四，強調持續改善

Scrum下有Sprint回顧會議來持續改善；Kanban法以持續進行流程優化，來改善瓶頸。

---

Kanban與Scrum的差異點

Kanban法與Scrum法有10個主要差異點：

	Scrum法	Kanban法
時間期限	團隊依照固定長度的Sprint來進行每一次工作迭代，有明確的時間期限。	沒有固定時間框架的安排，任務依照工作的進行，依序完成，不需事先承諾明確的結束時間。
交付方式	每個Sprint結束時一次性交付預期成果。	持續交付成果。
角色與職責	有明確的工作角色（產品負責人、Scrum Master、開發團隊），甚至還有與利益關係人及客戶（使用者）間明確的工作關係。 Scrum團隊中沒有管理者的角色，團隊自主管理。透過Scrum Master的角色，來協助團隊解決問題、促進運作順暢，並鼓勵全員參與。	沒有預先規定的角色，更強調團隊協同合作來完成任務。 雖然可能存在敏捷教練的角色，但沒有類似Kanban Master的角色，來協助團隊解決問題、促進運作順暢，並鼓勵全員參與。
團隊組成	必須是跨職能的（Cross- Functional）	可以是專業的（Specialized）
工作承諾	團隊成員承諾他們在當個Sprint中要完成特定數量的工作。 如果預測不準或出現突發狀況，會無法達成工作承諾。	不需要明確的工作量承諾。每個人在承接新工作前都要先完成既有的工作。 只有工作量有餘，才能承接新工作。
工作規劃	在每個Sprint之前進行工作規劃，有助於團隊設立該Sprint或迭代要完成的目標與期望，同步大家的作法。	通常以過去的工作流程數據進行規劃，預估後續的工作進度。
工作量限制（WIP Limit）	限制每個Sprint中的故事點點數（Story Point），以防止團隊超負荷。	限制工作中（Work In Progress）的工作數量，當進行中的工作量達到滿載時，不能承接新工作。
修改或改變	一旦Sprint開始進行，不允許添加新的需求。	有高度的修改彈性，工作可以隨時新增到待辦清單中，工作優先順序可以隨時調整。 只要工作量不超過限制，就可以持續承接新的工作。
主要衡量指標	以速度（Velocity），也就是一個Sprint中所能完成的故事點來評估。速度也就是Scrum團隊的績效衡量指標。	前置時間（Lead Time）與週期時間（Cycle Time）可用來計算任務從開始到完成所需的平均時間。 完成任務的平均時間可視為團隊的績效衡量指標。
Scrum 看板 vs. Kanban 看板	Sprint剛開始時，所有該Sprint預計完成的故事都會列入「Scrum 看板」最左列，目標是在Sprint結束前完成所有的故事。 如果Sprint結束時，所有工作沒有移到最右邊那一列，代表Sprint的任務未完成。 不管Sprint任務是否全部完成，在Sprint回顧會議結束後，「Scrum 看板」上的內容會全部清空重置。	「Kanban 看板」上，分欄位來顯示工作狀態，每個欄位都有明確的WIP限制，不能超量工作。 Kanban法沒有時間限制，所以不會重置。只要專案繼續，「Kanban 看板」就會持續運作，或新增工作項目。

延伸閱讀：敏捷專案管理手法：讓「使用者故事」替你聚焦工作任務

---

Kanban與Scrum的適用情境

---

Scrum適用情境

總結來說，在Scrum架構下，每個Sprint的進行過程中優先順序不能改變，所以Scrum適合優先順序較為固定的專案。團隊尚未運作成熟時，運用Scrum也是很好的選擇，因為Scrum有明確的工作角色及運作規範以提供團隊指導。軟體開發、廣告、建築等專案活動都很適合。

Scrum更加結構化，是一種全新的工作框架，在導入Scrum的同時，也意味著組織運作方式的調整，甚至是組織上的變革，公司需要較大的決心來進行組織調整，與辦公室座位的重新改造。

Kanban適用情境

Kanban法不是一個框架，所以與Scrum或其他敏捷框架間，不是競爭關係，而是可以同時存在。Kanban法對既有的敏捷作法提供一個額外的工具，來持續改善現有的作法。

相對上，導入Kanban法可以很靈活，它是一個視覺化系統，用於管理日常工作。作為一個視覺輔助工具，它很容易可以嵌入日常運作之中，以流程化的角度促進團隊合作與溝通，完全不需改變既有運作，所有的投資僅有一塊大型白板而已。

當任務優先順序不斷變化時，Kanban法更為合適。尤其是引入Kanban法並不需要改變既有的流程或架構，對於改變既有運作模式較為困難的情況下（例如：工廠流水線、餐廳廚房等），Kanban法提供一個可視化的工具，讓我們以工作流的角度來管理工作、找出瓶頸、促進團隊溝通，並持續改善效率。

Kanban法更適合成熟的團隊，或對運作十分順暢的現有流程進行管控。因為當你熟悉組織文化並且已經養成可靠的工作習慣時，你不需要嚴格的規則。傳統製造業的生產線、市場行銷活動、內容創建、餐廳的廚房、各種服務業、部門日常工作管理等都很合適，甚至個人的時間管理也能派上用場。