第六章：限制在製品 (Limiting Work in Process)#

本章涵蓋以下主題：

• 尋找合適 WIP 限制的原則
• 團隊限制 WIP 的常見方法
• WIP 限制的視覺化方式
• 關於 WIP 限制的常見問答

本章開頭就揭示了一個秘密：限制 WIP 本身並非目的。WIP 限制只是驅動你改善流程的手段。透過限制 WIP 來達成更好的流動 (flow)，才是真正的目標。

找到合適的 WIP 限制取決於情境，也像是在射擊移動靶——WIP 限制可以而且應該隨時調整。你會在本章看到很多「視情況而定」的說法，這不是因為作者不確定，而是因為你需要找到最適合你和團隊的方式。不過不用擔心，本章充滿了尋找合適 WIP 限制的指引和原則，以及許多團隊用來視覺化和設定 WIP 限制的實用方法。

6.1 尋找 WIP 限制 (The Search for WIP Limits)#

尋找合適的 WIP 限制並不容易。正確答案是顧問們最愛的回答：「視情況而定 (It depends)。」

影響 WIP 限制的因素包括：

• 組織對持續改善的壓力有多大
• 團隊人數及其可用性
• 工作項目 (work items) 的形狀與大小

以下是幾條基本的經驗法則：

• 越低越好，優於越高
• 人閒或工作閒——用這個信號來調整
• 沒有限制絕非答案

6.1.1 越低越好 (Lower Is Better Than Higher)#

較低的 WIP 限制通常優於較高的，因為你希望盡可能限制同時進行的項目數量。這將帶來：

• 更短的前置時間 (lead time)
• 更快的回饋 (feedback)
• 迫使你移除障礙 (impediments)

這些都是幫助你改善工作項目在流程中流動的因素。

然而，WIP 限制設得太低可能讓流程完全停擺，因為它會迅速暴露流程中的所有問題。想像整個團隊只做一個工作項目，突然需要等客戶回覆——因為那是唯一在做的事情，整個團隊就此完全停止。

問題是需要在流程中改變的事物的症狀。一次發現太多問題可能會迅速變成痛苦的經歷。

如果問題一次出現太多，而團隊又沒有能力處理，常見的反應不是受到鼓勵去改善和解決問題，而是放棄、不再在意 WIP 限制被持續違反。你要尋找一個低但不至於太低的 WIP 限制——下一節提供了引導你的信號。

6.1.2 人閒或工作閒 (People Idle or Work Idle)#

調整 WIP 限制可能變成一件永遠在討論的事情：追求找到「唯一正確的限制」可能導致大量討論而無人能決定什麼是最好的。這不是時間的好用途——最好是嘗試某個東西然後調整。

一個簡單的上下調整方法：

如果你的 WIP 限制太高，工作會變得閒置——會有沒人負責的工作項目。如果 WIP 限制太低，人會變得閒置——所有項目都被做著，但有人沒有工作。此時你可以選擇協作來完成項目，或者提高 WIP 限制。

與其花大量時間討論「唯一正確的 WIP 限制」，不如先試一個數字再調整。嘗試比辯論更有價值。

6.1.3 沒有限制絕非答案 (No Limits Is Not the Answer)#

不設 WIP 限制是團隊開始實施看板時最常見的錯誤之一。看板有三個簡單的原則，不要太早就移除其中一個。

不設限制的風險：

• 看板會被大量工作淹沒，顯示出你的低效率和無法將工作推過流程的失敗
• 最終看板會因為工作太多而無法看清工作項目，變得不再被使用
• 全世界辦公室裡有許多被廢棄的、貼滿便利貼的看板——不要讓你的看板加入那個可悲的行列；讓看板成為幫助你改善的工具
• 移除 WIP 限制就移除了改善的動力——沒有東西推動人們做得更好
• 允許無限量的項目上板，就不會有壓力去完成現有工作再開新工作

如果你記得第五章關於在製品的內容：同時進行的工作越多，所有工作的前置時間就越長。你需要一個約束 (constraint) 來推動你完成工作並改善流程。WIP 限制正是這個約束。

6.2 設定限制的原則 (Principles for Setting Limits)#

找到 WIP 限制取決於你的情境。在本節中，我們會看看一些作者輔導過和聽說過的團隊是如何約定他們的限制的。

記住，重要的是：與其說是「找到 WIP 限制」，不如說是「視覺化你目前的 WIP 限制」——它代表目前為止最好的數字。你應該在需要時隨時更改。擁抱變化，這對你有益。

6.2.1 停止開始，開始完成 (Stop Starting, Start Finishing)#

一個簡單但強大的起點：團隊約定在開始新工作之前，先努力完成目前的工作。這會保持你的 WIP 很低，因為你只在其他東西完成時才開始新工作。

一個簡單的開始方式是為你的團隊採用這個口號：

Stop starting, start finishing.

沒錯，前幾次說的時候需要用力想一下，但之後就會記住了。一個好主意是把這句話貼在看板上方（每天早會時會看到的地方），或者用它作為每日站會 (daily standup) 的開場或結語。

這個口號有巨大的力量，因為它推動你走向更低的 WIP，並且總結了看板的基本模式：

• 限制同時進行的工作項目數量
• 縮短前置時間
• 讓工作通過整個價值鏈 (value chain)
• 獲得回饋
• 改善流程

David P. Joyce 的名言完美地詮釋了這個原則： 「不是『你開始得越多，完成得越多』，而是『你完成得越多，完成得越多』。」

很快你可能需要更精細地控制 WIP 限制，到那時這個原則可能太粗糙。但作為強調原則的起點，它非常出色。

6.2.2 一不是答案 (One Is Not the Answer)#

追求低 WIP 限制是好事，但設為 1 對大多數團隊來說太具破壞性。例如，當 WIP 限制為 1 時，任何流動中的干擾——交接 (handoffs)、人員請假等——都會導致所有工作停止。大多數組織還沒準備好同時處理那麼多「改善機會」（你還記得我們把問題叫做改善機會吧？），所以你大概應該選擇一個高於 1 的 WIP 限制。

Mob Programming (群體程式設計) 是一個例外。由 Woody Zuill 指導的團隊首創了這種方法：整個團隊一起處理一個任務——一個團隊、一個鍵盤、一個螢幕。WIP 限制為 1 在這種情況下非常有效，因為任何問題都能立即被解決。但對大多數組織來說，這太極端了。

問題是：你賣的是按鍵次數，還是完成的功能？

6.3 全板全團隊方法 (Whole Board, Whole Team Approach)#

本節介紹幾種限制整個團隊在板上工作項目總數的方法。這可以是一個簡單的起步方式，而且對你的團隊來說可能已經足夠。

記住：沒有「真正的」WIP 限制可以被找到。WIP 限制是你用來改善的工具。你可能會問這樣的問題：

• 這個 WIP 限制會幫助工作更好地流動，還是讓流動變差？
• 這個 WIP 限制會讓很多人閒置嗎？
• 會有很多工作閒置嗎？那是個問題嗎？你能做什麼來解決它？

6.3.1 Take One! Take Two!#

許多作者輔導過的團隊都經歷了類似的旅程來找到合適的 WIP 限制。他們的經驗說明了我們認為在 WIP 限制方面必要的推理類型。從中學習，然後選擇一個適合你的限制。

以一個五人團隊為例，展示逐步推理的過程：

第一步：每人一個項目（WIP = 團隊人數 = 5）

你可以大膽地決定每人一個項目的 WIP 限制，使總 WIP 等於團隊人數。但很快你就會發現這帶來一些問題——例如，如果你被阻塞 (blocked)，就無法在不違反 WIP 限制的情況下拿新工作。

第二步：每人兩個項目（WIP = 團隊人數 x 2 = 10）

也許允許每人最多兩個項目更合理，這樣當一個項目被阻塞時還有事做。但這個設定也有問題：它允許每個人都可以被阻塞一個項目卻繼續做另一個而不違反 WIP 限制。在許多情況下，這不夠推動團隊去解決問題。你希望 WIP 限制推動你去解決問題，而不是允許你在不注意問題的情況下繼續工作。

第三步：降到 8

為了推動團隊，你可以從 10 降到 8。如果所有人都被阻塞一個項目，再各拿一個新的就會突破 WIP 限制。你比 WIP 為 10 時更早收到溫和的提醒 (gentle nudge) 去處理阻塞。如果你想更早收到這個警告，可以再降低一點。

重要的不是範例中的具體數字，而是尋找 WIP 限制時的推理過程（如果大家都被阻塞會怎樣？這能改善流動嗎？等等）。記住——沒有可以計算出來的正確 WIP 限制。你必須找到最適合你的團隊和情況的那個。最理性的做法是嘗試一個 WIP 限制，然後根據需要改變它。同時思考你希望 WIP 限制驅動什麼樣的行為——它是驅動改善的機制。

6.3.2 Come Together（走到一起）#

如果團隊使用協作實踐（如結對程式設計 / pair programming），應該進一步降低 WIP 限制。可以把團隊人數除以 1.5（或其他你認為合適的數字）。

以五人團隊為例：5 / 1.5 ≈ 3 個項目。

WIP 限制為 3、五個人——如果每個人都獨自工作，很快就會有人沒事做。為了在這個限制下讓所有人都參與，團隊成員必須在項目上協作：

• 結對程式設計 (pair programming)
• 一起撰寫規格 (specifications)
• 結對測試 (testing in pairs)

這正是敏捷團隊追求的協作方式。而且作為一個好的副作用，工作項目會更快地移過看板。

對於不習慣密切協作的團隊來說，這可能是一個很大的改變。不要一開始就把 WIP 限制設得太低，而是逐步降低，同時改善流程。

6.3.3 Drop Down and Give Me 20#

Don Reinertsen 提出了一個設定合適 WIP 限制的技術。他建議：

1. 先觀察：從你目前的位置開始——視覺化工作項目，計算它們，了解你目前的 WIP 是多少（無約束系統中的正常水平）
2. 加倍這個數字作為初始 WIP 限制。你加倍 WIP 限制是因為根據統計推導，在正常變異下幾乎沒有團隊會達到這個上限。可以安全地說，這個限制一開始完全不會產生任何影響——每個人都應該能做到
3. 然後從這個新的限制每隔固定時間（每月或每兩週）遞減 20-30%，直到你開始遇到問題、隊列堆積、或者看到人們在任務之間閒置

實例：假設一個團隊通常同時有大約 4-5 個項目在進行。按照 Reinertsen 的推理，你應該從允許板上 10 個項目開始。然後以固定間隔降低 20%：第一次降到 8 → 然後 6 → 然後 5 → 依此類推。

當你這樣做時，你不僅在降低 WIP 限制（這會讓項目更快地通過你的系統）。你還在開啟一個持續追求改善的趨勢——一種精實思維 (Lean thinking) 的心態。

這個方法的好處：

• 初始 WIP 限制很高，前幾次降低不會造成大問題，幫助團隊習慣評估和改變限制
• WIP 限制的實施成本很低——你選一個數字，不接超過那個數字的工作。如果不行，可以回到之前的水平
• 這使得 WIP 限制非常適合用於實驗

降低 20% 會怎樣？試試看；如果不行，回去想想發生了什麼。你需要怎樣做才能降低 WIP 但仍保持項目在系統中流動？

這種方法教導團隊持續評估限制以改善流動。因為初始 WIP 限制很高，前幾次降低不會造成大問題。這幫助團隊養成定期評估和改變限制的習慣。

雖然此處以全團隊 WIP 限制為例，但同樣的思路也適用於按欄位 (column-based) 的 WIP 限制。你可以在感到痛苦的欄位停止降低，在其他欄位繼續降低。

6.3.4 隨便挑一個數字然後跳舞 (Pick a Number, and Dance)#

如果你不知道合適的 WIP 限制是什麼——就隨便挑一個數字吧！沒錯，你沒看錯。隨便挑一個數字！

更準確地說：做一個有根據的猜測，但不要想太多。這個數字，正如我們說過很多次的，可以而且應該隨著進展和你認為合適時而改變。使用 6.1 節描述的尋找好限制的原則來引導你設定 WIP 限制。

到目前為止我們考慮的都是整個板和整個團隊的 WIP 限制。設定一個單一的 WIP 限制有時被稱為 CONWIP（Constant WIP，恆定在製品）系統。

6.4 基於欄位限制 WIP (Limiting WIP Based on Columns)#

大多數作者合作過的團隊都選擇按欄位設定 WIP 限制，而非整個團隊。這提供了更精細的控制，有機會處理瓶頸 (bottlenecks) 和不均勻的流動。

話雖如此，為整個板設定 WIP 限制仍然是有用的，而且如果你不知道從哪裡開始，它提供了一個好的起點。

在本節中，我們將深入探討按欄位限制 WIP 的常見方法、一些注意事項，以及按欄位限制 WIP 能為你帶來什麼。

6.4.1 從瓶頸開始 (Start from the Bottleneck)#

所有工作流程都有某個瓶頸，它決定了整個流程的步調：

• 在瓶頸上游增加吞吐量，只會在瓶頸前堆積工作
• 在瓶頸下游增加吞吐量是徒勞的，因為沒有足夠的輸入

例如：工作項目在 Test 欄位前堆積，如果不做任何事，WIP 和前置時間都會增加。如果你在 Development 欄位設定 WIP 限制為 3，開發人員在隊列開始堆積時就必須停止開發工作。他們可以轉而幫助測試人員完成工作，而不是拉入新工作（因為那只會增加更多 WIP）。

在餵養瓶頸的步驟上設定 WIP 限制，可以防止瓶頸被淹沒，並驅動行為去解決瓶頸，從而改善整體流動。

6.4.2 選擇能幫助你改善的欄位 (Pick a Column That Will Help You Improve)#

你為什麼買這本書？你覺得看板能幫你改善什麼？大多數團隊已經對（至少一些）問題所在有相當好的了解。

常見的情境是使用看板來讓團隊在更少的工作項目上協作，以便更快地完成它們。在以開發人員為主的團隊中，可能有理由在 Development 欄位（大部分活躍工作發生的地方）設定一個挑戰性的 WIP 限制來驅動協作。

• 許多團隊從 6.3 節描述的「全團隊全板」方法開始，然後將數字分配到不同欄位
• 你也可以只在一個欄位應用總數：例如，將開發人員數量的 1.5 倍作為 Development 欄位的 WIP 限制

6.4.3 故事點數限制 (A Limited Story, Please)#

限制 WIP 的方式和世界上的團隊一樣多，但有一種經常被問到的方式值得一提：你可以根據工作項目的估算大小來限制 WIP，例如使用 story points（故事點數）。Story points 是一種使用相對度量來估計團隊工作量的方法，在 Scrum 和 Extreme Programming (XP) 等敏捷方法中被廣泛使用。

以故事點數限制 WIP 意味著：只要不超過約定的限制（例如 10 個故事點數），就可以拉入新工作。

這種方式的特點：

• 通常更適合按欄位決定，而非整個團隊
• 工作項目的大小可能在工作過程中改變——例如分析後發現比預期簡單
• 許多使用 Scrum 的團隊已經在這樣做了——在規劃迭代時根據通常完成的故事點數來拉入新工作

6.4.4 如何視覺化 WIP 限制 (How to Visualize WIP Limits)#

欄位型 WIP 限制通常在每個欄位上方標註數字（例如 Analyze [2] Dev [3] Test [2]）。但變化形式非常多。

作者在與團隊合作時看到的一些方式：

• 為每個工作項目畫框——當你超出限制時就會很明顯，因為你必須把工作項目放在框外或疊在其他項目上面
• 塑膠資料夾或其他實體佔位符——為每個允許的工作項目卡片提供實體位置，與畫框類似，是很好的視覺指標，幫助追蹤你是否在 WIP 限制內

如你所見，在板上的欄位使用 WIP 限制有很多方式，可以幫助你找到問題、瓶頸和其他減慢流程流動的事物。什麼對你最有效，需要你自己通過實驗來找到。

不要害怕實驗。嘗試新東西並失敗，總比滿足於次優設置要好。你用什麼取決於想像力和團隊需要。嘗試某些東西，然後改變以改善。

6.5 基於人員限制 WIP (Limiting WIP Based on People)#

有些團隊的情況是人們從頭到尾負責工作，將工作交接給其他人是不常見或不可行的。工作流程仍然可以是一系列步驟，事實上，顯示工作目前處於什麼狀態是有價值的，即使同一個人在整個過程中都在做這項工作。

典型的例子是第一線支援 (first-line support)——你收到一個客戶的緊急案件，一直跟到解決。這樣的案件可能經歷以下階段：為客戶找到替代方案、提交 bug、測試包含修復的新版本、最後關閉案件。所有這些階段很可能由支援團隊的同一個人處理。

這呼喚了另一種策略：限制每個人的工作項目數量。你的重點不在於優化整個工作流程的流動，而是確保沒有人承擔太多工作，同時每個人都有事做。

另一個適用場景是對抗各層級的多工 (multitasking)：每人的 WIP 限制可以幫助視覺化某些人參與了太多工作項目（這類人被稱為「囤積者 / hoarders」），這可能是整個團隊 WIP 過高的驅動因素。你可以透過明確的每人限制來討論如何防止這種情況。

6.5.1 常見的按人員限制 WIP 方法 (Common Ways to Limit WIP Per Person)#

頭像 (Avatar) 限制#

如果你使用頭像 (avatars) 來表示誰在做什麼，一個簡單的方法是限制每個人可以同時「在場」的頭像數量。例如，你可以為每個人印三個頭像，這有效地將每人的 WIP 限制設為 3。現在很容易看到誰在做什麼、每個人正在處理多少項目。

Sean 的故事：Marcus 曾輔導過一個八人團隊，有個叫 Sean 的人幾乎是自己一手建起這個應用程式的。每個決策都以某種方式經過他。當團隊建立看板系統時，每人只印了三個頭像。第一天早會花了大約 35 分鐘，大部分時間在等 Sean 放置他的三張（「只有三張？可以給我多五張嗎？拜託？」）便利貼來決定他今天該做什麼工作。

在讓他煩惱了一會兒之後，團隊討論了這個情況對團隊和項目流動造成的問題。讓 Sean 大吃一驚的是，當他休假或生病時，團隊仍然能夠交付東西。也許有些工作項目不需要 Sean 參與？也許不讓 Sean 參與每件事可以增加其他人的自主感和精通感？也許這可以釋放 Sean 的時間去做那些事實上只有他知道的複雜工作？結局是好的，但一開始對可憐的 Sean 來說確實有點震驚。

個人泳道 (Swim Lanes)#

另一種常見方式是為每個人設定一條泳道 (swim lane)，然後在每條泳道設定 WIP 限制。這允許在板上的任何欄位中，該泳道有一定數量的項目。

這種方法也可以用於：

• 多團隊看板上限制每個團隊的工作
• 團隊內小組 (teamlets) 的工作限制

這些基於人員的策略專注於確保每個人都有事做，但對於讓工作流向完成狀態幫助不大。你的客戶很少在意你是否忙碌——他們只在意你是否交付了東西。可以從這裡開始，但值得質疑這種方式限制 WIP 的效果。

6.6 常見問答 (Frequently Asked Questions)#

6.6.1 限制的是工作項目還是任務？(Work Items or Tasks)#

團隊經常在工作流程的某些步驟中將工作項目拆分為任務 (tasks)。例如在 Development 欄位，任務可能是「實作資料存取」、「撰寫 HTML 頁面」、「完成商業邏輯」。在 Testing 欄位，可能是「準備測試資料」、「撰寫報告」、「執行手動測試」。任務是工作項目的一部分，可以理解為在某個欄位中完成工作項目所需做的所有事情。

只有當每個任務在 Development 中都完成了，工作項目才會移到工作流程的下一步。有些團隊甚至將欄位分成子欄位，形成任務的迷你看板。

重點：

• 大多數團隊以工作項目計算 WIP 限制，而非任務
• 任務只是追蹤完成工作項目所需做的事情
• 任務通常不直接交付客戶價值——客戶不在意任務多快流過板上，只在意有用的東西何時被交付
• 在某些欄位中，你可能會想限制任務數量，例如為了限制多工或確保協作

6.6.2 隊列是否應計入 WIP 限制？(Should You Count Queues Against the WIP Limit)#

隊列 (queues) 通常被視覺化為一個欄位中的子欄位。例如 Development 欄位中的「Done」，或 Test 欄位中的「Ready for Test」。

上圖展示了 Development 欄位 WIP 限制為 4，分為 Doing 和 Done 兩個子區域。開發人員正在做 1 個項目、已完成 3 個項目，剛好達到 WIP 限制。

另一種視覺化方式是將隊列放在 Test 欄位的「Ready to Test」子欄位中，這樣就計入測試步驟的 WIP 限制。

你在團隊上如何視覺化取決於你想達成什麼——也就是說，誰應該「擁有」那些等待被測試的票據：

• 如果開發人員在自己的區域收到信號會有幫助嗎？
• 還是測試人員將隊列中的項目計入他們的 WIP 限制更有用？

這個選擇需要與團隊討論，但隊列欄位的實際功能在任何情況下都是相同的：卡在那裡的項目會停滯並阻礙流動，人們無法在隊列前的欄位拉入新工作。透過這個設置，你可以輕鬆看到哪些項目已完成、哪些項目開發人員還在處理。

還有第三種方式（在 6.4.1 節中也展示過）：隊列作為獨立欄位，擁有自己的 WIP 限制，不計入任何人的限制。這個限制不會從「你的」欄位「偷走」容量。這種方式可以防止瓶頸（例如單一測試人員）被淹沒——在他面前建立一個緩衝區，確保他不會被淹沒但總是有工作可做，他可以從前面的緩衝區（測試隊列）中拉取工作。

有時候隊列應該計入 WIP 限制，甚至隊列本身就是 WIP 限制（如獨立隊列欄位的情況）。在其他時候，隊列和執行欄位之間的區分是一種視覺化詳細步驟的方式。

「隊列是否應計入 WIP 限制？」的答案同樣是「視情況而定」。例如，如果你發現測試是瓶頸，隊列加上 WIP 限制是確保測試人員總有工作可做、同時不被淹沒的好方法。有了 WIP 限制，你就不會在不違反限制的情況下用工作淹沒隊列。當你看到隊列填滿到 WIP 限制時，就是討論如何清除正在累積的阻塞的時候了。

6.7 練習：WIP It, WIP It Real Good#

現在是開始討論 WIP 限制的時候了。再次強調，這應該是一個團隊的努力。記住，沒有最佳的 WIP 限制——它是一個你可以用來幫助你改善工作的工具。

如果你想不出一個明顯的 WIP 限制，先討論 6.3、6.4 和 6.5 節中的要點。

可以聚焦的討論問題：

• 你應該為整個板設定單一的 WIP 限制嗎？為什麼這對你有好處？
• 你能從限制某些欄位開始嗎？哪些欄位？為什麼？
• 如果按人員限制 WIP，會驅動什麼行為？
• 帶有 WIP 限制的泳道會對你的情況有幫助嗎？

如果你不知道如何回答這些問題，就嘗試某個看起來合適的東西，注意觀察發生了什麼，並從中學習。

當你確定了一個好的策略和數字後，開始討論這個政策在日常工作中應該如何被對待：

• 你的限制設置方式鼓勵了什麼行為？
• 當你打破 WIP 限制時應該怎麼做？
• 被阻塞的/排隊的項目是否應計入限制？

一如既往，從簡單開始，在看到需要時逐步使方法變得更進階。

6.8 本章總結 (Summary)#

本章討論了如何尋找和視覺化良好的 WIP 限制：

• 沒有唯一正確的 WIP 限制——限制 WIP 不是目標，改善流動才是。WIP 限制只是幫助發現阻礙流動之問題的工具
• 較低的 WIP 限制會讓工作更快移動，也更快暴露問題。追求低但不要太低
• 開始時保持簡單——也許簡單到只是一句口號：「Stop starting, start finishing」

全團隊/全工作流限制#

• 有助於改善協作
• 幫助保持專注於完成工作項目後再接新的

基於欄位的限制#

• 聚焦於讓項目在工作流中流動
• 可以幫助管理瓶頸
• 也許你已經對需要改善的地方有直覺，可以從該欄位開始限制
• 工作也可以按估算大小（如故事點數）來限制

基於人員的限制#

• 限制頭像數量是一種簡單的方式
• 使用泳道是另一種方式
• 可以防止過度多工和個人介入板上每個項目

工作項目 vs. 任務#

• 大多數團隊在工作項目層級設定 WIP 限制，而非任務層級

WIP 限制是改善工作流程流動的方式。但「流動」到底是什麼？它是精實 (Lean) 的核心概念之一，也是下一章的主題。