第一章：Kanbaneros 團隊啟程#

本章透過一個虛構但貼近現實的故事，介紹 kanban 的基礎概念。故事中，兩位教練 Marcus 和 Joakim 在一場研討會結束後，臨時受邀為一個軟體開發團隊進行兩小時的 kanban 入門指導。這個團隊面臨許多常見的軟體開發問題，而 kanban 提供了一套從「現狀出發」的改善方法。

本章是整本書的快速導覽。即使你只讀了這一章，也能掌握足夠的知識來開始實踐 kanban。後續章節會深入探討這裡介紹的每一個概念。

1.1 團隊介紹（Introductions）#

背景與挑戰#

故事的主角是一個小型軟體開發團隊，他們負責一家大型保險公司的行動銀行應用程式。團隊成員包括：

團隊面臨的挑戰#

Marcus 在翻頁紙上記下了團隊的核心問題：

Kanban 與 Scrum 或 RUP 等方法不同，它不會規定你應該有哪些角色、開什麼會議。Kanban 的起點是「從你目前的狀態開始」（start where you are），幫助你理解現狀，再找出下一步的改善方向。

1.2 看板（The Board）#

讓工作被看見#

Joakim 問團隊：「你們怎麼知道團隊正在做什麼？如果連你們自己都不確定，利害關係人又怎麼可能知道？」

團隊使用 JIRA 作為專案追蹤工具，Beth 負責在裡面登記和分類所有需求，Frank 則盡量維護優先順序。表面上看起來系統運作良好，但 Marcus 請大家把「目前正在做的工作」都寫在便利貼上，貼到白板上。

第一輪，團隊從 JIRA 中找出了 6 個項目。但當 Marcus 追問「還有其他的嗎？」時，Adam 坦承有很多工作根本沒有登記在 JIRA 裡：額外的需求、小型支援任務、替其他部門幫忙、系統維護等等。這些任務通常是組織裡的資深人員在走廊上直接交辦的。

第二輪，又多出了 8 個項目 – 比 JIRA 裡登記的還多。

Frank 驚呼：「天啊，這是真的嗎？」

資訊散熱器 vs. 資訊冰箱（Information Radiator vs. Information Fridge）：

• 大型可見的看板是「資訊散熱器」– 經過的人一眼就能看到資訊
• 電子工具有時更像「冰箱」– 你得打開它、翻找才能找到你要的東西

把工作貼在牆上，讓所有人隨時可見，這個簡單的動作就能帶來巨大的改變。

視覺化工作的價值#

透過將每個工作項目寫成便利貼並貼上牆，團隊達成了幾件事：

• 讓隱藏的工作浮出水面 – 那些沒被追蹤的額外任務終於被看見了
• 可以看到誰在做什麼
• 可以看到正在進行多少工作
• 可見的工作會向看到它的人「輻射」（radiate）資訊

1.3 對應工作流程（Mapping the Workflow）#

建立欄位#

Joakim 引導團隊將工作流程對應到看板上。工作項目會從「構想」或「客戶請求」流經整個系統，直到成為「上線的功能」為客戶產生價值。

團隊決定從「工作登記進 JIRA」開始，到「工作上線到生產環境」結束，逐步建立了以下欄位：

flowchart LR
A[Todo] --> B[Analyze]
B --> C[Development]
C --> D[Testing]
D --> E[Accept]
E --> F[Waiting\nfor Ops]
F --> G[In Production]
style F fill:#f96,stroke:#333

Marcus 建議用白板筆而非膠帶來畫欄位，因為用膠帶做成的永久性版面會讓人不願意改動它。而看板是需要隨著學習不斷演進的。

發現瓶頸：Waiting for Ops#

當團隊討論到「Accept 之後怎麼辦？」時，浮現了一個重要問題：營運部門（Ops）已經外包給另一家公司，部署只有一年六次，而且團隊失去了對生產伺服器的存取權限。

Eric 建議加一個「Waiting for Ops」欄位。Frank 一開始覺得這等同於「Done」，因為「到這裡我們就做不了什麼了」。

但 Joakim 追問：「你們的客戶是誰？」經過思考，團隊認同真正的客戶是網路銀行的使用者。對使用者而言，「完成」意味著他們可以使用這個功能 – 而東西卡在 Waiting for Ops 裡，對客戶毫無價值。

當被問到 Waiting for Ops 裡有多少項目時，Frank 估計大約有 25 到 40 個。

「完成」不等於「離開團隊的手」。工作只有在為客戶產生價值時才算真正完成。如果大量項目堆積在等待區，這代表你的流程中有一個嚴重的瓶頸。

Daphne 指出，如果看板上有一個 Waiting for Ops 欄位，裡面堆滿了便利貼，而唯一阻止這些項目完成的就是 Ops 團隊，這就成為了一個有力的「對話啟動器」。Marcus 總結道：「當你視覺化你的痛點並收集資料，就更容易獲得利害關係人和其他團隊的理解。這不是你在抱怨，這是數據。」

最終團隊加入了 In Production 作為最後一個欄位，取代簡單的「Done」，因為這更能反映真實狀態（上線後可能還會有 bug 回報）。

對應工作流程的要點#

• 辨識工作從進入到離開團隊的所有階段
• 不要追求完美 – 持續檢視與調整（inspect and adapt）
• 工作要到為客戶產生價值時才算完成
• 透過視覺化的工作流程，你可以看到：
  • 工作的狀態
  • 潛在的問題，例如工作在某個階段堆積、沒有進展

1.4 工作項目（Work Items）#

便利貼上該寫什麼？#

團隊已經有了帶有簡短標題的便利貼，但這些標題有時太簡略，只有開發者本人才看得懂。經過討論，團隊設計了工作項目卡片的格式：

工作類型的區分#

Adam 提出需要區分 bug 和一般工作。bug 有更高的優先順序，可能可以跳過 Analyze 等步驟。團隊決定：

• 黃色便利貼 = 一般工作（Normal）
• 紅色便利貼 = Bug

用顏色區分工作類型是 kanban 社群中常見的做法。當看板上開始出現大量紅色便利貼時，就是該坐下來好好討論品質問題的時候了。看板正在向你「說話」。

工作項目的設計原則#

從卡片上你應該能夠：

• 看到工作項目的狀態
• 做出關於下一步行動的決定

常見的屬性包括：

• 工作項目的描述
• 在電子系統中的 ID
• 截止日期
• 誰在負責
• 工作類型（如 bug 或一般功能）

你無法改善你看不見的東西（You can’t improve what you don’t see）。這是 kanban 的一個基本且重要的原則：讓工作可見。視覺化的真正收益不僅僅是看到每個工作項目的狀態，而是幫助我們做決策、從流程的運作中學習、進而改善流程。

1.5 傳遞硬幣遊戲（Pass the Pennies）#

為了解釋「限制在製品」（Limit WIP）的概念，Marcus 和 Joakim 帶領團隊進行了一個經典的模擬遊戲。

遊戲設置#

• 4 位「工人」坐在桌子四邊，每人輪流翻轉硬幣後傳給下一位
• 4 位「經理」站在工人背後計時
• Joakim 扮演「客戶」，記錄第一枚硬幣到達的時間和全部完成的時間
• 共 20 枚硬幣

三輪實驗與結果#

關鍵發現#

結果令團隊大為震驚：

1. 第一次交付時間大幅縮短：從 50 秒降至 4 秒，不到原來的十分之一
2. 總完成時間也縮短：從 50 秒降至 20 秒，做的工作量完全一樣
3. 個人工作時間反而增加：每個工人在小批次時工作時間更長（個人效率降低），但團隊整體效能提升
4. 錯誤成本降低：如果翻幣方式有誤，小批次只需重做少量工作

在製品（WIP, Work in Process） 是你同時進行中的工作項目數量。減少在製品數量 = 更快的流動速度 = 更短的前置時間（Lead Time）。

這裡有一個反直覺的取捨：優化流程以加快流動，可能會導致個別資源使用率下降。在大批次模式中，每個工人很「高效」地一次做完所有工作，但後面的工人必須等待。在小批次模式中，工人的個人效率看起來較低，但團隊整體更有效。

Adam 提出了合理的質疑：現實中的工作不像硬幣那樣均勻，項目大小不一，且常常需要在不同階段之間來回。Joakim 承認這是簡化的模擬，但基本原則仍然成立：減少在製品數量會降低前置時間。

1.6 在製品限制（Work in Process）#

從遊戲回到看板#

回到白板前，團隊開始討論如何將 Pass the Pennies 的教訓應用到實際工作中。

Frank 總結道：「如果我們希望工作快速流過看板，就應該減少同時進行的項目數量。」

但 Eric 問了一個關鍵問題：「實際上我們要改變什麼？」

Joakim 提出了 kanban 的行動口號：

Stop starting, start finishing.（停止開始，開始完成。）

具體來說：

• 與其開始新的工作項目，不如幫團隊中的某人完成一個已在進行的項目
• 與其讓自己被阻塞（例如等待資訊或審核），不如嘗試解決阻塞或思考如何在未來避免它

設定 WIP 限制#

Marcus 引導團隊為每個欄位設定在製品限制。原則是：選定一個最大數量，作為該欄位同時進行中的工作項目上限。

如何找到合適的數字？

• 太高的限制 = 工作閒置、流動緩慢
• 太低的限制 = 人員閒置、等待工作
• 需要在「快速流動」和「人員有事做」之間取得平衡

團隊的初始設定過程：

1. Testing = 2 – Adam 一開始建議 1（因為只有他做測試），但 Beth 提到她也會做一些測試，所以改為 2
2. Development = 3 – Daphne 認為 2 太低（有時需要等人，會沒事做），Eric 建議 4，最後 Daphne 折中選了 3
3. Analyze = 2 – Beth 認為合理，無人反對
4. Accept = 4 – Cesar 解釋說，限制為 4 意味著當 Accept 欄填滿 4 個項目時，測試團隊就會被阻塞。這時 Cesar 和 Beth 就需要過來做驗收工作。限制太低（如 1）會要求他們隨時待命；太高則意味著團隊等太久才得到回饋

不是每個欄位都一定要有 WIP 限制。只在你認為限制能幫助加快流動的地方設限。Todo、Waiting for Ops 等欄位可以暫時不設限。

佇列與緩衝（Queue / Buffer）#

Daphne 問了一個好問題：Accept 欄位不就是在「等它填滿再開始做」嗎？

Marcus 在 Accept 欄位中畫了 Ready 和 Doing 兩個子欄位。這種「佇列」（queue）或「緩衝」（buffer）常見於有限資源前面 – 例如 Beth 和 Cesar 不能隨時在場，所以建立一個小緩衝區，等填滿了再通知他們過來。

在製品限制不是嚴格的規則，而是觸發討論的機制。當限制即將被突破時，團隊需要討論：

• 是否有人可以幫忙完成正在進行的工作？
• 是否需要移除某個優先順序較低的項目？
• 開發者是否可以暫時去幫忙測試？

如果你經常打破限制，可能需要提高限制。如果你從來不碰到限制，可能需要降低限制以促進這些有益的討論。

限制在製品的要點#

• 從「停止開始，開始完成」的心態開始
• 限制 WIP 會讓改善機會浮現，採取行動就能改善流動
• 沒有「唯一正確」的 WIP 限制
• 較低的 WIP 通常更好。經驗法則：
  • WIP 太高 = 工作閒置等待
  • WIP 太低 = 人員閒置等待
• WIP 限制不是規則 – 是觸發討論的機制

1.7 加急項目（Expedite Items）#

處理緊急工作#

Adam 提出了一個現實問題：「有時候生產環境出了問題，不管你正在做什麼、有多少東西在進行中，你就是得馬上修！」

Daphne 也確認：「我們總不能因為不想超出在製品限制就不處理緊急工作吧？」

Joakim 介紹了 加急通道（Expedite Lane）的概念 – 在看板頂部新增一個特殊的橫向泳道（lane），專門用來處理緊急項目。

加急通道的風險#

Eric 立刻提出警告：「你們（指 Frank、Beth、Cesar）會把這條通道塞滿的。這會變成你們把工作插隊的快速通道，讓我們不斷在項目之間切換。就像去年 Bank 2.0 大版本時一樣。」

這番話引起了一陣尷尬的沉默，也促成了團隊制定加急通道的使用政策：

• 加急項目只用於真正緊急的情況，不可作為「插隊快速通道」
• 設定每月允許的加急項目數量上限
• Cesar 承諾會尊重這個制度

加急項目的代價#

Marcus 引用 Pass the Pennies 遊戲來說明：加急項目就像在翻幣過程中插入一枚必須優先處理的新硬幣。它會讓所有其他硬幣的流動變慢。

加急項目有其「通行費」（toll）：

• 它會增加在製品數量
• 這反過來會拖慢所有其他正在進行的工作
• 有時候讓一個重要項目快速通過是正確的決定，但你必須清楚知道你正在付出的代價

加急通道也可以用來處理「走廊上被交辦的工作」– 可以做，但值得為此付出代價嗎？這就成了一個有數據支撐的討論。

1.8 指標（Metrics）#

團隊對指標的抗拒#

當 Beth 提出「我們怎麼知道自己在改善？」時，「指標」這個詞立刻引起了團隊的強烈反感。原來團隊之前被迫採用過一套公司級的 KPI（關鍵績效指標），不但沒有幫助，反而傷害了生產力和士氣。

Joakim 澄清：「我們說的不是那種指標。這些是由你們自己制定、為你們自己服務的指標，幫助你們找到改善的方向。追蹤在看板上，如果你們願意，可以只給自己看。」

前置時間（Lead Time）#

前置時間是一個工作項目從第一個欄位（Todo）走到最後一個欄位（In Production）所需的時間。

追蹤方法非常簡單：

• 在便利貼進入 Todo 時寫上日期
• 在便利貼進入 In Production 時寫上日期
• 將結果繪製成簡單的散佈圖

從圖表中可以發現：

• 哪些項目花了特別長的時間？為什麼？
  • 可能與某個特定子系統有關
  • 可能是規格不夠明確
  • 可能是缺少測試人員的早期投入
• 將平均前置時間減半需要什麼條件？

產出量（Throughput）#

產出量是你在給定時間段內完成的工作項目數量，追蹤方式更簡單：

• 選定一個固定的統計週期（例如團隊每月第二個星期三的發佈日）
• 計算 In Production 欄位中的項目數量
• 然後將它們從看板上移除

追蹤產出量一段時間後，你可以：

• 驗證降低 WIP 是否真的加快了流動
• 開始做出可靠的預測和承諾
• 用數據而非直覺來說服他人

指標的關鍵原則：

• 指標是為了幫助團隊改善，不是用來做績效考核的
• 讓團隊自己選擇要追蹤什麼指標
• 簡單但有用的指標，勝過複雜但沒人使用的指標
• 前置時間和產出量是兩個最基本也最有力的 kanban 指標

1.9 臨別贈言（The Sendoff）#

兩小時的指導結束了。Joakim 和 Marcus 給團隊的最後建議是：

專注在縮短前置時間。 考慮整個流程，嘗試降低在製品數量來達成這個目標。

Cesar 代表團隊致謝，稱這次指導是他們需要的「維他命注射」。在離開前，他留下了一張寫著銀行帳號的便利貼 – 作為付費方式，也展現了對教練們的信任。

1.10 本章總結#

本章透過 Kanbaneros 團隊的故事，涵蓋了 kanban 的核心基礎：

視覺化（Visualize）#

• 為每個工作項目建立便利貼，讓隱藏的工作浮出水面
• 把工作貼在牆上（資訊散熱器），而非藏在電子工具裡（資訊冰箱）
• 將工作流程對應到看板欄位，從 Todo 到 In Production

限制在製品（Limit WIP）#

• 透過 Pass the Pennies 遊戲理解：減少同時進行的工作 = 更短的前置時間
• 為看板欄位設定 WIP 限制，作為觸發討論的機制
• Stop starting, start finishing

管理流動（Manage Flow）#

• 識別瓶頸（如 Waiting for Ops 的堆積）
• 用加急通道處理緊急工作，但要了解其代價
• 用佇列（Ready/Doing）來管理資源有限的階段

持續改善（Improve）#

• 追蹤前置時間和產出量作為基本指標
• 指標由團隊自己制定、為團隊自己服務
• 用數據而非直覺來驅動改善

你不需要做到故事中的每一件事。根據你自己的團隊、工作和情境，挑選適合你的做法，從明天就可以開始。Kanban 的精神就是：從現狀出發，持續改善。