第十二章：Kanban 陷阱#

本章探討 Kanban 常見的批評與陷阱，幫助你了解如何避免這些問題。Kanban 採取「從現狀開始，逐步改善」的變革管理方式，大多數團隊與組織不會對其產生太大抗拒。但一些批評確實值得正視——這些批評往往指向實踐中容易掉入的陷阱。了解這些批評，是改進自身實踐的絕佳方式。

12.1 只有工作、沒有樂趣（All Work and No Play）#

Kanban 可能變成一條無止盡的工作流水線——一個接一個的工作項目排隊等候，沒有自然的中斷、慶祝或節奏（cadence）。

這段批評來自 Scrum 的共同創始人 Ken Schwaber。他曾評論道：

God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause. — Ken Schwaber

Ken Schwaber 指的是 Kanban 缺乏迭代（iteration）的問題。在他看來，Kanban 只是一長串排列好的工作，看不到盡頭：只有不停地工作、工作、再工作。

Kanban 從未說過要移除迭代。但它確實給了你自由，可以將不同方法中的「儀式」（ceremony）——例如計劃、審查、回顧——彼此解耦，不必綁定在同一個節奏上。

解決之道：

  • Kanban 不規定迭代、審查和演示的節奏，但你可以自行安排
  • 在需要的時候進行儀式，而不是因為固定時間到了才做——Just in Time 而非 Just in Case
  • 使用 WIP 限制會驅動協作，也可能為團隊創造「休息與創造」的空間
  • 參考第九章關於 cadence（節奏）的討論來規劃合適的活動

12.1.1 為慶祝建立節奏#

為了對抗「只有工作」的風險，你應該建立慶祝的節奏。這對提升士氣和團隊樂趣非常重要。以下是兩種實用的慶祝方式：

飛行常客里程（Frequent Flyer Miles）#

團隊可以為完成的工作累積點數，然後用點數來做一些有趣的事情：

  • 團隊與利害關係人共同設定點數追蹤方式與獎勵門檻
  • 例如：完成 50 個 story point 或 20 個工作項目後，舉辦披薩與遊戲之夜
  • 可以設計多層獎勵：50 點是辦公室披薩之夜，100 點是外出聚餐或雷射槍戰

注意不要過度依賴外在獎勵。Dan Pink 在《Drive》一書中引用多項研究指出，對於知識工作，更高的報酬和獎金反而可能導致更差的結果。真正驅動我們的是自主性（autonomy）、精通（mastery）和目的（purpose），而不是更多的金錢或披薩。將慶祝視為團隊共度美好時光的方式，而非工作的唯一動力。

蛋糕限制（Working to the Cake Limit）#

另一種建立慶祝節奏的方式，是在看板的「完成」（Done）欄位設定 WIP 限制。這個做法來自 Spotify 的團隊：

  • 在 Done 欄位設定 WIP 限制（例如 15 個項目）
  • 當 Done 欄位被填滿後，無法再完成更多項目
  • 工作開始在流程中堆積，產生越來越大的壓力要求清空 Done 欄位
  • 清空 Done 欄位的唯一方式：由利害關係人帶蛋糕來，感謝團隊的辛勤工作

Figure 12.1: Board with items piling up in Done without releasing

蛋糕限制既有趣又巧妙——它利用佇列（queue）和瓶頸（bottleneck）的原理，以拉動（pull）機制來觸發慶祝。這是 Kanban 機制在非工作領域的創意延伸。

12.2 時間盒（Timeboxing）對你有好處#

Kanban 沒有內建的時間盒機制。然而，時間盒能幫助你設定優先順序，並在範圍、時間和成本之間做出必要的取捨。

鐵三角（Iron Triangle）#

時間盒的核心概念可以用「鐵三角」或「三重約束」（triple constraints）來理解：

  • 範圍（Scope）：利害關係人想要完成的功能
  • 時間（Time）：需要多長時間？何時需要完成？
  • 成本（Cost）：這會花多少錢？

在三角形的中心是第四個面向——品質（Quality）。雖然可以拿品質做取捨，但這通常會以技術債（technical debt）的形式在日後造成問題。

技術債（Technical Debt） 是 Ward Cunningham 提出的比喻。就像金融債務一樣，技術債也有利息——如果不處理，利息會隨時間增長（需要額外努力維持程式碼的運作狀態），最終你會發現所有資源都在「還利息」，無法開發新功能。

三種取捨策略#

你無法同時固定三個面向。你的選擇是：

  • 固定時間和範圍，讓成本浮動：「我們會在 5 月 14 日完成這個確切功能，但不知道要花多少錢。」——大多數公司不喜歡，而且在軟體開發中，增加人力很難加速進度。打字不是軟體開發中最大的瓶頸，學習和理解才是。
  • 固定範圍和成本，讓時間浮動：「我們會完成這些功能，花費 $47,343，但不知道何時完成。」——比讓成本浮動更糟。公司需要可預測性，而且「固定範圍」很少真的能固定，因為在開始前你通常無法完全了解範圍。
  • 固定成本和時間，讓範圍浮動：「我們會在 5 月 12 日完成，成本是這六個人在此期間的薪資，但我們不知道能完成多少。」——雖然聽起來可怕，但這其實是一個商業機會。你可以按業務價值排序工作項目，先做最有價值的。
flowchart TD
A{鐵三角取捨} -->|方案 1| B[固定時間+範圍\n 成本浮動 ❌]
A -->|方案 2| C[固定範圍+成本\n 時間浮動 ❌]
A -->|方案 3 ✅| D[固定時間+成本\n 範圍浮動]
D --> E[時間盒 Timeboxing]

最後一種方式就是時間盒（Timeboxing）——固定時間（和成本），根據情況調整範圍。這是 Scrum 中 Sprint 背後的核心概念。

固定所有面向的問題#

如果你試圖同時固定範圍、成本和時間，唯一能妥協的就是品質——這會導致技術債。更糟的是，當所有面向都固定時，團隊往往會在估算中加上 30% 的風險緩衝，而業務方收到估算後又會再加 30%。這延遲了反饋，推遲了決策，直到為時已晚。

Kanban 中的時間盒#

在像 Scrum 這樣的迭代式流程中，時間盒是內建的（Sprint）。而基於流程的 Kanban 沒有內建時間盒，但你可以：

  • 使用截止日期（deadline dates） 標註在工作項目卡片上
  • 使用 SLA（服務等級協議）和不同的服務類別（classes of service）（參見第八章）
  • 為單一工作項目、一組工作項目或流程中的欄位創建時間盒

迭代式流程鼓勵你裁剪能塞進迭代的工作量；基於流程的做法則是裁剪每個故事本身。例如，將一個進階功能（如精美的下拉選單）拆分為獨立的工作項目，先用簡單的文字輸入框代替——說不定使用者反而更喜歡直接輸入數值。

12.3 必要的革命（The Necessary Revolution）#

Kanban 採取演進式（evolutionary）的變革管理方法，鼓勵你從現狀開始、追求漸進式改變、尊重現有流程和角色。但如果你需要的是一場革命呢？如果組織或團隊需要被大力搖醒呢？

Kanban 的優勢在於可以從現狀開始，不需要改變任何東西——只需視覺化你的工作方式並限制同時進行的項目數量。然而，有時候你確實需要一場革命：

  • 為了生存或把握新的商業機會，你可能需要大量且快速地改變
  • 如果需要這樣做，可以考慮先採用成熟的方法（如 Scrum 或 XP），再加上 Kanban 原則來驅動改進

如何思考這個問題： 以風險評估的角度來看：

  • 一個小型、靈活、願意嘗試新事物且有優秀教練的團隊，可以承受較大的變革而不會冒太大風險
  • 但如果你是大型保守銀行組織中的 Cobol 團隊，改變的風險就更大

你可以控制改進的速度。更積極、更低的 WIP 限制會帶來更多改進機會。更頻繁地將東西推上生產環境會更快地提供反饋，進而給你更多改變和改進的理由。如果同時出現太多問題，隨時可以放寬 WIP 限制，先處理最大的問題。

你也可以根據需要加入其他方法的實踐：

  • 從 XP 借用 Pair Programming（配對程式設計）或 TDD（測試驅動開發）來提升程式碼品質
  • 引入 Impact Mapping（影響地圖）和 Specification by Example（實例化需求）來確保你在建造正確的東西
  • 採用 Continuous Delivery（持續交付）和 Lean Startup 的理念來縮短反饋迴路

確保以你和組織能承受的速度進行改進。但也不要太慢——有時候你確實需要一場革命。

12.4 不要讓 Kanban 成為偷懶的藉口#

由於 Kanban 只有幾個簡單的原則，它幾乎不規定什麼。這有時會成為停止做那些目前對你有幫助的事情的藉口。你可能會變得懶惰。

一些常見的錯誤態度：

  • 「我們以前會做工作計劃，但現在用了 Kanban，我們就停了。」
  • 「Scrum 對我們不適用！我們昨天試了一次計劃會議，很無聊。我們改用 Kanban——只需要站會（可能之後也會取消）和牆上的便利貼就夠了。」

Kanban 不是一個流程——而是元流程（Meta-Process）#

你不能「做 Kanban」（do kanban）。你不能「從 Scrum 切換到 Kanban」。你能做的是——將 Kanban 原則應用到你的流程中。Kanban 是一個元流程（meta-process）——一個用來改進流程的改進流程。

這是個好消息，因為這意味著你可以將 Kanban 應用到你目前使用的任何方法上，然後從那裡開始改進。

對於那些因為「開始用 Kanban」就停止其他好做法的團隊：

  • Kanban 沒有說要停止任何有助於工作流動或提升流程品質的實踐
  • 在你有充分理由停止之前，繼續做以下事情：回顧會議、審查、Sprint（包含計劃會議和審查）
  • Kanban 會逐漸顯示出什麼在拖慢你的流程——當工作項目開始堆積時，你就知道問題在哪裡
  • 你的指標和圖表會幫助你看到流程在哪裡被拖慢，這些觀察最終會引導你開始質疑和改進現有做法

開始使用 Kanban 的頭號錯誤：沒有 WIP 限制#

許多團隊在引入 Kanban 時，最常犯的錯誤就是不設定 WIP 限制。沒有 WIP 限制，就沒有驅動改進的張力——你只會在問題出現時不斷增加在製品，通常表現為看板上大量被阻塞（blocked）或等待中的工作項目。

沒有 WIP 限制就像一個可以無限延長的迭代——沒有動力按時完成範圍內的工作，你總是可以擴大範圍。

WIP 限制的真正本質：

  • 它不是規則（rule），而是指導方針（guideline）和討論觸發器（discussion trigger）
  • 沒有它，就沒有理由進行「我們是否應該這樣做」的討論
  • 你只會不斷增加工作，沒有任何機制來質疑這是否合適

如果覺得設定「正確」的 WIP 限制很困難，可以使用第六章介紹的「Drop Down and Give Me 20」方法：先選一個較大的數字，然後逐漸降低 WIP 限制，直到開始遇到問題，再稍微放寬。記住——不存在「正確」的 WIP 限制，它只是幫助你驅動改進的工具。

實例：第一次回顧會議#

書中分享了一個案例：一個合作了約 15 年的團隊，在開始視覺化工作並引入 Kanban 原則後，舉行了有史以來第一次回顧會議。和許多類似情況的團隊一樣，他們還沒有設定 WIP 限制。

在回顧會議中，最需要改進的事項是如何處理意外加入的工作。團隊意識到這些項目會干擾他們的流程。他們發現一個簡單的 WIP 限制就能在新項目要加入時觸發討論。產品負責人對三個升級層級感到滿意：

  • 放到待辦事項的末尾：「我們到時候再處理。」
  • 放到待辦事項的最前面：「我們完成手上的事情後立刻處理。」
  • 推入進行中欄位，以犧牲其他工作為代價：「我們立刻放下手上的事情，改做這個。」

在設定 WIP 限制之前，根本沒有理由進行這樣的對話。項目只是被塞進當前的工作量中，每個人都在新的負擔下掙扎應對。

12.5 本章總結#

本章檢視了 Kanban 面臨的常見陷阱與批評，並提供了避免這些問題的方法：

  • 只有工作、沒有樂趣：Kanban 可能變成一條看似永無止境的工作流。透過按需安排審查、回顧和計劃的節奏來避免這個問題。建立慶祝機制（如飛行常客里程或蛋糕限制）來提振士氣。

  • 缺乏時間盒：Kanban 不建議使用時間盒，但你可以為個別項目添加時間盒，使用截止日期、SLA 或服務類別來創造必要的約束。

  • 有時你需要一場革命：Kanban 的演進式方法很好，但有時你需要大幅度的改變。你可以控制改進的速度——降低 WIP 限制以創造更多改進機會，或引入其他方法的實踐。

  • 不要讓 Kanban 成為偷懶的藉口：Kanban 是一個元流程，用來改進你已有的流程。不要僅僅因為 Kanban 沒有提到就移除目前有效的做法。

  • 頭號錯誤——沒有 WIP 限制：沒有 WIP 限制就沒有驅動改進的約束。WIP 限制是指導方針和討論觸發器，是你控制來推動改進的工具。

Backward Using Metrics to Guide Improvements Teaching Kanban Through Games Forward