第七章：管理流動 (Managing Flow)#

本章探討如何管理工作流程中的流動 (flow)，這是看板的核心實踐之一。從豐田生產系統 (Toyota Production System) 的「一件流」(one-piece continuous flow) 理想出發，作者帶我們深入了解如何消除浪費、保持工作流動、運用每日站會協調團隊，以及透過瓶頸理論 (Theory of Constraints) 持續改善流程。

一件連續流 (One-piece continuous flow) 是一個理想狀態：每一項為客戶創造價值的工作，從一個增值步驟直接移動到下一個，直到抵達客戶手中，中間沒有任何等待或批次處理。不是「以防萬一」地建立庫存，而是「剛好及時 (just in time)」——在正確的時間、正確的地點、正確的數量交付。

這種連續流將每個流程串成緊密連結的鏈條，問題無處隱藏。當某個環節停止或中斷時，你會立刻知道發生了什麼，並被迫一起解決問題。這迫使人們思考，透過思考成為更好的團隊成員。

7.1 為什麼要追求流動？(Why Flow?)#

如果能達到一件連續流的理想狀態，你將擁有：

• 零延遲：沒有排隊、沒有等待
• 零批次處理：沒有庫存堆積
• 零過度生產：只交付客戶真正需要的東西，並在需要時立即交付
• 更高的靈活性與回應能力
• 更好的風險管理
• 更快的回饋循環，帶來品質提升（做對的東西，並把東西做對）
• 更高的可預測性，帶來更高的信任
• 更少的加急請求
• 更快的持續價值交付

此外，追求流動還會暴露改善機會，並為你的改善努力提供方向：更快的流動。

7.1.1 消除浪費 (Eliminating Waste)#

豐田花了比任何其他公司更多的時間去完善一件連續流的願景，而這段旅程的重要部分就是專注於消除浪費。

我們所做的一切，就是觀察從客戶下訂單到我們收到款項之間的時間線，然後透過消除非增值的浪費來縮短這條時間線。 ——大野耐一 (Taiichi Ohno)

換一種方式來問：「是什麼阻止了工作的流動？」 從客戶的角度審視你的流程：客戶希望從這個流程中得到什麼？客戶想要的就是價值，其他一切都是浪費。流程中的某些步驟增加價值，其他步驟則不會。

豐田早期識別了製造業的七種浪費類別，後來將同樣的思維應用到產品開發等其他領域。Mary 和 Tom Poppendieck 則為軟體開發領域做了類似的分類。

7.1.2 軟體開發的七種浪費 (The Seven Wastes of Software Development)#

Mary 和 Tom Poppendieck 為軟體開發識別了以下七種浪費：

關於「浪費」的反思：看板社群中有人認為精實軟體開發對浪費的執念是不健康的，認為應該聚焦於縮短交付時間和風險管理，浪費會在這個過程中自然被識別和消除。關鍵不在於某個活動本身是否是浪費，而是時間投資回報率 (ROTI, Return of Time Invested)——它是否幫助你提升理解或交付客戶價值。

7.2 幫助工作流動 (Helping the Work to Flow)#

看板的核心實踐之一是管理工作在工作流程中每個狀態的流動。這意味著監控和衡量工作如何流動，同時保持工作持續移動。你可以採取多種方法來幫助工作流動。

7.2.1 限制在製品 (Limiting Work in Process)#

限制 WIP 是保持工作流動的基本實踐。在製品越少，工作流動越快，你發現的改善機會也越多。根據 Little’s Law：WIP 越多，每個項目的前置時間 (lead time) 就越長。

流動效率 vs. 資源利用率：優化流動是一個策略決策。為了更好的流動，你可能會讓人員偶爾閒置——這是一個取捨。

• 資源利用率優先的例子：鋁熔煉廠——設備啟動成本極高，你希望熔爐一直運轉，準備大量材料（高 WIP）
• 流動效率優先的例子：消防隊——他們有大量的閒置時間（等待、準備、訓練），以便在火災發生時能立即出動。我們作為社會接受這一點，因為我們不希望打電話求助時他們正忙著

聚焦流動效率可以減少大量多餘工作和浪費，實際上也能改善資源效率。

7.2.2 減少等待時間 (Reducing Waiting Time)#

你是否有工作項目坐在看板的 Done 欄位中等待被拉到下一個狀態？項目是否停留在「等待部署」或「待辦」這類狀態？工作花在等待上的時間比實際被處理的時間還長，並不罕見。

第一步：讓等待變得可見

如果你還沒有明確的方式來顯示工作在某個狀態已完成並準備好進入下一個狀態，這應該是你的第一步。這讓等待可視化，向他人發出信號表示工作項目準備好被拉取，也讓追蹤和衡量等待時間變得更容易。收集等待時間的資料並加以分析，可以幫助你了解哪些地方可以改善。如果你難以說服他人時間被浪費在等待上，用數據來呈現會是很好的敲門磚。

有時你也需要往工作流程之外看——你是從零開始工作，還是工作在其他地方（我們通常稱為看板上游 upstream）已經開始或準備好了？也許工作正在那裡等你。你是工作抵達客戶之前的最後一環嗎？為了減少等待時間，往往需要走出你自己的工作流程和看板之外。

確保工作已準備好 (Ensuring That Work Is Ready)

避免等待的絕佳方式是確保工作始終為下一個狀態做好準備：

• 規劃並拆分工作以最小化依賴
• 讓外部人員或資源事先準備好待命
• 設計工作以利於協作，讓完成某項工作的團隊成員可以輕鬆參與你正在做的事
• 在工作開始前清楚溝通預期結果

實例規格 (Specification by Example) 是確保彼此理解的最佳方式之一：以驗收標準或具體範例（使用真實數字和真實資料）的形式撰寫規格。功能在範例被滿足時即完成——不多也不少。

讓工作項目更小且大小一致 (Making Work Items Smaller and Similarly Sized)

• 更小的工作項目 → 縮短前置時間、降低 WIP
• 大型工作項目通常更難估計，有時會隱藏問題
• 大小一致的工作項目 → 更均勻的流動、更高的可預測性 → 建立信任、減少加急需求
• 實務上也消除了成本方程式中的成本因素，因為所有工作現在時間成本相同

7.2.3 移除阻塞 (Removing Blockers)#

阻塞 (blockers) 屬於特殊類別的等待——那些阻止你但在你直接控制之外的事物，例如第三方依賴、等待外部程式碼審查、或等待資訊。

在我們的經驗中，這類阻塞常被接受為「自然秩序」——「我們無能為力」，但事實往往恰恰相反。在支援系統中提交了一張工單或發了一封電子郵件，不代表你已經盡力避免被阻塞。你可以打電話，甚至走過去直接和他們談話。你解釋了這如何影響你、如果得到協助對你的工作推進有多大幫助嗎？

「永遠不要被阻塞」——敏捷開發的首要指令 (The Prime Directive of Agile Development)

Robert C. Martin (Uncle Bob) 主張「永遠不要被阻塞」是每個敏捷開發者的首要指令：

就像一個好的撞球手在出桿時總會確保為下一桿做好準備，好的敏捷開發者每一步都在為下一步鋪路。好的敏捷開發者永遠不會走出一步讓自己或他人的進度停滯。

這個原則延伸到團隊和組織的所有層面。對於程式開發，這可能意味著為外部系統建立介面 (interface) 來編碼——如果其他方未按時交付，你可以提供自己的實作（stub 或 fake）繼續工作。

如果真的被阻塞了怎麼辦？

• 避免開始新工作——拉取新工作會增加 WIP，減慢其他所有工作
• 尋找可以幫忙完成的事，解決瓶頸或其他問題
• 保留一些在被阻塞時可以做的任務（如升級建置伺服器、自動化手動工作）
• 這類工作可以在被阻塞時拾起，在阻塞解除時迅速放下

追蹤阻塞 (Tracking Blockers)

• 在阻塞上記錄開始和結束日期，或每天在便利貼上點一個點
• 計算工作項目總週期時間中有多少是被阻塞的
• 追蹤阻塞數量的變化和平均移除時間可以驅動改善

群聚 (Swarming)

許多看板團隊中會出現一種被稱為 swarming（群聚） 的行為：當 WIP 限制被達到、困難的阻塞出現、或某個工作項目太大/太遲/太複雜而無法由單一人員處理時，團隊成員會群聚到問題周圍，更快地解決它並恢復正常流動。

• 有些團隊將此作為遇到阻塞或缺陷時的明確政策
• Swarming 也可以描述在專業領域之外工作以幫助高風險或高價值工作更快完成的行為

7.2.4 避免返工 (Avoiding Rework)#

有時缺陷會從工作流程的某個狀態逃逸，在後續狀態中才被發現。這導致工作項目在流程中倒退，增加該項目和其他項目的週期時間（因為它增加了 WIP）。

精實軟體開發的關鍵原則之一是從一開始就內建品質 (build quality in)：

• 結對程式設計 (pair programming)
• 測試驅動開發 (test-driven development)
• 持續整合 (continuous integration)
• 測試自動化 (test automation)
• 在引入缺陷和修復缺陷之間的時間最小化

價值需求與失敗需求 (Value Demand and Failure Demand)

John Seddon 引入了 failure demand（失敗需求） 的概念——「因為未能為客戶做某件事或未能正確做某件事而產生的對系統的需求」。例如：

• 未考慮使用者體驗的錯誤設計
• 沒有真正使用者參與或回饋而產生的糟糕需求
• 因為誤解和溝通不良導致的返工

讓失敗需求流動得更快並沒有太大意義；你應該盡可能消除失敗需求，為更多的價值需求 (value demand) 騰出空間。弄清楚客戶需要什麼和重視什麼，並只交付那些東西——這也是在內建品質。

一個簡單實用的做法：開始追蹤和視覺化失敗需求。當失敗需求進入看板時，在便利貼上放一個小紅點。當它離開看板時，進行根因分析 (root cause analysis) 以了解如何在未來避免。

7.2.5 跨職能團隊 (Cross-functional Teams)#

跨職能團隊是一個擁有不同專業技能的團隊。當團隊具備完成所有請求所需的技能和資源時，它就是真正的跨職能團隊。這意味著：

• 更少依賴與其他團隊的交接
• 更不容易等待他人或被阻塞
• 產品負責人或業務分析師在團隊中 → 可以即時決定要做什麼
• 團隊同時具備編碼和測試技能 → 程式碼不需要交給別人測試

追求跨職能有助於減少等待、更容易避免和移除阻塞、避免返工，也可能降低 WIP。

功能團隊 vs. 元件團隊 (Feature Teams vs. Component Teams)

• 功能團隊 (Feature team)：從頭到尾負責某個功能，需要做系統的垂直切片 (vertical slice)，團隊內需有混合能力
• 元件團隊 (Component team)：只負責資料存取層或使用者介面層——當這樣組織時，團隊之間會互相等待，資訊在交接中遺失，對整體進度和品質造成更大風險

在一個約 250 人的專案中，團隊被分成五層深的階層結構，底層團隊被命名為 Integration、Data Access、UI Mobile 等。從這個結構可以輕易推斷出：在所有團隊都完成之前，沒有人能算完成。最慢的團隊決定了整個專案的速度——僅僅因為專案的組織方式。

以功能來組織團隊與看板流程契合良好，甚至可以在共同看板上以不同的泳道 (swim lanes) 來視覺化。

7.2.6 SLA 或前置時間目標 (SLA or Lead-Time Target)#

有些團隊發現他們的服務等級協議 (SLA) 提供了清晰的目標，其他團隊則喜歡自己設定目標（例如平均前置時間）來追蹤進度。這有助於培養「時間至關重要」的心態，讓工作流動更快。

時間盒 (Timeboxing) 是許多敏捷方法用來管理風險並專注於最重要事項的技術。當團隊規模和時間都固定時，範圍需要靈活，你必須優先建構最重要的東西。使用時間盒也讓你意識到在任務上花了多少時間，幫助避免鍍金 (gold plating)——在超過額外努力所增加的價值之後仍繼續工作。

7.3 每日站會 (Daily Standup)#

幫助工作流動的一個方式是每天（甚至更頻繁地）談論並處理那些阻礙工作流動的問題。每日站會 (daily standup) 在軟體開發社群中因 Scrum 和 XP 等方法而普及。它是讓團隊所有人了解當前狀況和工作進度的絕佳工具。

搭配工作流程的視覺化看板，每日站會可能是許多團隊在開始使用時最能立竿見影看到效果的實踐。

7.3.1 站會的通用良好做法 (Common Good Practices Around Standups)#

站會要簡短 (A Standup Is Short)

• 保持在 5-15 分鐘
• 「站立」是為了保持會議簡短和活力充沛
• 站在視覺化工作流程（你的看板）旁邊，以便看到和討論工作項目

站會要準時開始（和結束）(A Standup Starts and Ends on Time)

• 對大多數團隊來說，只要討論的內容重要且引人入勝，準時不是問題
• 選擇一個適合所有團隊成員的固定時間

站會要聚焦 (A Standup Is Focused)

• 討論對出席者重要的事情
• 如果討論開始拖延且只涉及兩個人，請他們在站會後繼續

站會要有規律 (A Standup Is Regular)

• 每天在相同的時間和地點進行
• 這為一天創造了節奏，很快就會成為團隊的習慣

7.3.2 看板團隊的站會實踐 (Kanban Practices Around Daily Standups)#

聚焦接力棒——而非跑者 (Focus on the Baton, Not the Runners)

看板團隊的站會與傳統站會的首要區別是：看板團隊傾向於聚焦看板上的工作，而非團隊中的個人。

這與 Scrum 中讓每個人回答「三個問題」的做法形成對比：

• 昨天做了什麼？
• 今天要做什麼？
• 有什麼障礙？

三個問題是好的做法，讓每個人在會議中都有發言，你也能得到每個人的狀態概覽。但你可能會錯過討論手頭工作的機會。也許有一個項目被阻塞了，值得花整個會議討論如何解決；或者也許什麼都沒有被阻塞，工作按預期流動，那麼你可以提早結束會議。

最重要的是，焦點不在於個人做了或沒做什麼，而在於流程、工作流或個別工作項目是否存在問題。這幫助你理解你們是一個團隊，成員互相幫助一起完成工作。

走看板 (Walk the Board)

看板團隊通常從右到左列舉工作，從 Done 欄位開始向上游移動。這是為了強調拉動原則 (pull principle)：你是在把工作拉向你，把功能拉進生產環境，而非把工作推到下一個狀態。

如果受限於 15 分鐘的時間盒而無法走完整個看板，從右到左意味著你可能沒時間討論最左邊的部分——但那些也是離完成最遠的工作。

對每個工作項目可以問兩個問題：

1. 我們需要做什麼來讓這個工作項目更接近完成？
2. 誰來做？

聚焦異味 (Focusing on Smells)

書中描述了看板團隊在一次站會中發現的多個「異味」(smells)：

• 緊急泳道中有兩個項目，但政策規定只能有一個
• Done 欄位中 Eric 仍在工作——是否需要增加一個 Deploying 欄位？
• Test 欄位超出 WIP 限制（限制 2，實際 3）——Adam 是否應該幫忙其他地方？
• Test 欄位中有長時間無人處理的工作（用點標記每天）
• Development/Done 欄位堆積形成瓶頸——開發人員是否該停下來幫 Adam 測試？
• Daphne 在 Development 欄位囤積多個項目——是否需要幫助？
• Analyze 欄位中有「重要」標記的工作項目無人處理

7.3.3 讓站會發揮最大效益 (Get the Most Out of Your Standup)#

良心問題 (Question of Conscience)

「你是否正在做沒有出現在看板上的工作？」 這是站會中一個很好的問題。「旁邊的小工作」不僅佔用原本該做的時間，還會養成習慣，長期下來看板會變得越來越不相關。嘗試讓看板盡可能反映現實。

做錯事情 (Working on the Wrong Thing)

「我們現在是否在做最重要的事情？我們怎麼知道？優先順序是否清楚？」 如果團隊成員開始說不知道接下來該做什麼，或覺得在做錯誤的事，可能需要重新審視優先排序的政策。

不理解工作 (Not Understanding the Work)

隨著看板演化，許多政策和增強功能以最好的意圖被加入看板。但過了一段時間，這些政策可能變得難以理解和看見，即使是團隊內部的人也是如此。對於外部人員來說，工作遵循的規則更是難以跟隨。

嘗試總是找到更簡單的方式來描述工作。記住你的視覺化也可以讓路過看板的人了解情況。一個局外人能理解這是如何運作的嗎？你自己呢？

自發性改善 (Spontaneous Kaizen)

僅僅聚焦在看板上的異味、偏差和問題當然沒有用——如果你不試著對它們做點什麼的話。當站會結束後，你有時會看到一些人留在看板旁，組成小組開始討論會議中提到的工作。這被稱為自發性改善 (spontaneous kaizen)——團隊開始自發地討論和改善工作。

這種行為應該被鼓勵，你可以透過將站會中的討論推遲到會後來觸發這類對話。當幾個人在站會中開始跑題時，你可以說：

• 「我們能在這個會議結束後馬上碰面再多談嗎？」
• 「讓我們在會後在看板這裡找出那個工作項目的解決方案。」
• 「你們能在會後一起想出更好的方法來解決那個問題嗎？」

提供幫助，並鼓勵他們在需要時引入相關人員來解決問題或改善狀況。

便利貼問題 (Sticky Questions)：在 Spotify 紐約辦公室，一個團隊想出了視覺化「需要在站會後繼續討論的問題」的好方法——把主題寫在小便利貼上貼到想討論的人身上，直到討論結束才撕下來。

7.3.4 擴展站會 (Scaling Standups)#

當多個團隊在同一產品或專案上工作時，如何擴展每日站會？

首先問「為什麼？」(Why?)

在大型會議中保持簡短、聚焦和活力充沛要困難得多。所以首先要問：為什麼需要多團隊站會？解決什麼問題？不應該討論什麼？

實際演變案例：一個約 40 人的大團隊拆成五個小團隊後，從「大站會 (Big Daily)」→「每日同步 (Daily Sync)」（只討論需要跨團隊同步的事項）→「發布同步 (Release Sync)」（只問「今天我們發布什麼？」），最後大多數時候 2-3 分鐘就結束。

多團隊站會的要點

• 大站會在小團隊站會之前還是之後？ 之前可以向團隊傳達資訊但可能錯過最新狀態；之後可以得到狀態但錯過傳達資訊的機會
• 誰參加？ 至少每個團隊一人，且該人能做決策
• 需要什麼視覺化？ 是否需要大看板？顯示什麼資訊？
• 如何同步狀態？ 避免在大看板上放太多細節（意味著重複資訊且需要在兩個看板間保持同步）

由下而上或由上而下？(Bottom Up or Top Down?)

也可以反過來：有一個大團隊拆成小團隊 (teamlets)，使用粗粒度的看板（不含細節），聚焦在工作上。如果小團隊需要交換詳細資訊，可以有自己的看板和站會。

讓所有人經常見面也能促進大團隊中所需的協作。你能知道誰在做什麼、該找誰談、誰在等你，這增加了解決阻塞、最小化等待時間和分享有價值資訊的可能性。

持續問自己「這個會議是否為投入的時間提供了價值」是避免掉入陷阱的方式。如果沒有，找其他方式保持團隊之間的同步——出色的團隊視覺化可能是一種方式，頻繁的 demo 可能是另一種。讓工具為你工作，而不是你為工具工作。

7.4 我接下來該做什麼？(What Should I Be Doing Next?)#

如果你想要工作順暢流動，你不會希望因為不知道接下來做什麼而被阻塞。這個問題在站會中經常出現，而你作為團隊希望能自己回答這個問題。

許多視覺化技術和明確政策都在幫助你朝更自主化的方向發展：優先順序排列的欄位、不同顏色的服務等級、阻塞或緊急指標、加急泳道、WIP 限制——這些都幫助回答「我接下來該做什麼？」

具體範例：Adam 的決策過程#

以下是測試員 Adam 在不同情境下的決策邏輯：

情境一：Test 欄位中 Beth 正在測試一個項目。Adam 先幫她完成這個項目（「停止啟動，開始完成」），清空 Test 欄位。

情境二：Test 欄位清空後，Development/Done 佇列中有兩個項目。根據 WIP 限制，可以拉入測試。Beth 和 Adam 各取一個並完成。

情境三：Adam 獨自測試，Test 欄位沒有工作，也沒有新工作可拉入。他的第一個直覺可能是去幫開發人員，確保他們的項目完成並移入 Development/Done 欄位。但 Adam 完全缺乏此工作項目所需的開發技能。不是所有人都能做所有事，無論我們多希望如此。

這時他看到在前面的欄位中，有一個步驟正在缺乏工作（即瓶頸正在形成）——Analyze 欄位中 Frank 和 Beth 各在處理一個項目，但什麼都還沒完成。更重要的是，Analyze/Done 佇列是空的，當開發人員完成手上的工作時，將沒有新工作可拉。Adam 去幫助 Beth 分析功能——事實上，測試人員的觀點在分析功能時是很有價值的。

如果 Adam 也無法幫助分析怎麼辦？ 他應該抵制拉取新工作增加 WIP 的衝動，找些有趣但可以隨時放下的工作：升級測試伺服器、清理預備環境資料庫、更新舊 API 文件等。這些不應該是需要通過正常工作流程的工作（那會增加 WIP 並拖慢一切），而是那些你推遲了很久的事情。

這也是一個絕佳的機會來進行改善、發明或學習新事物，幫助你在未來工作得更快。

沒有閒置，就不會有改善。 ——Dr. Arne Roock

總結：接下來該做什麼的決策順序#

flowchart TD
A[接下來該做什麼？] --> B{能幫忙完成\n 進行中的工作？}
B -->|是| C[去幫忙完成]
B -->|否| D{能幫忙解決\n 瓶頸？}
D -->|是| E[去解決瓶頸]
D -->|否| F{WIP 限制內\n 有新工作？}
F -->|是| G[拉入新工作]
F -->|否| H[做改善/學習\n 等有幫助的事]

這些是經驗法則，幫助剛接觸看板和流動觀念的團隊理解原則，不應被當作硬性規則。你可能有其他政策優先於這些指南。根據情境，先解決瓶頸可能比幫助完成工作更有意義。

閒置不是壞事——閒置使改善成為可能。這是你不在為客戶產生價值的時間，但為了能夠改善，這是必要的。

7.5 管理瓶頸 (Managing Bottlenecks)#

佇列 (queues) 和 WIP 限制共同作用，在你正經歷問題時就創造出流程問題的前導指標 (leading indicator)。它們告訴你瓶頸在哪裡，甚至在瓶頸發生之前就展示它們正在形成。

看板走查範例#

起始狀態：一天開始時，所有步驟都有工作，人們正在工作。

工作移動：開發人員想拉入新工作，從 Analyze/Done 拉取一個項目。

瓶頸出現：Development 欄位已達到最大容量。項目顯然沒有從 Development 經過 Test 夠快地移動——測試中有瓶頸。

如果我們什麼都不做，只是忽略 WIP 限制繼續拉入新的開發工作，Test 將被堆積的等待工作淹沒，增加所有工作的前置時間，導致高 WIP 的所有負面效果。

我們需要釋放人力來修復問題，而即將開始新工作的開發人員顯然有多餘的產能可以幫忙。在許多情況下，這只是短期解決方案——例如測試可能需要特殊技能，使得開發人員無法像需要的那樣高效。如果 Test 是反覆出現的瓶頸，就有必要尋求長期解決方案，例如僱用更多測試人員或加強測試自動化。

7.5.1 約束理論簡介 (Theory of Constraints: A Brief Introduction)#

約束理論 (Theory of Constraints) 是由 Eliyahu M. Goldratt 在《目標 (The Goal)》一書中提出的管理哲學，基於一個核心觀念：所有系統的產出量都受到至少一個約束（瓶頸）的限制。

• 沒有約束 → 產出量瞬間且無限（點擊「購買」車就出現在車道上）
• 約束減慢整個系統
• 對約束的任何改善都是對整個系統的改善
• 對其他部分的改善不是真正的改善，因為瓶頸在為整個工作流程定步調

五個聚焦步驟 (Five Focusing Steps)：

1. 識別 (Identify) 系統的約束——例如工廠中所有零件都必須經過的單一機器
2. 利用 (Exploit) 約束以最大化其產出——確保機器一直運轉
3. 從屬 (Subordinate) 所有其他工作以支持約束的利用——不要送有缺陷的零件到機器
4. 提升 (Elevate) 約束——例如購買另一台機器分擔工作量
5. 重複 (Rinse and repeat)——重新審視系統，看約束是否仍是最大的約束

flowchart LR
A[1. 識別\nIdentify] --> B[2. 利用\nExploit]
B --> C[3. 從屬\nSubordinate]
C --> D[4. 提升\nElevate]
D --> E[5. 重複\nRepeat]
E --> A

利用 vs. 提升 (Exploit vs. Elevate)

大多數人直覺想到的是提升——增加更多人員或機器、更多培訓、更好的工具。但這些方案通常昂貴且需要時間產生效果。

約束理論建議你通常有另一個更簡單、更便宜的選擇：利用 (exploit) 瓶頸。這意味著先確保瓶頸被最大限度地使用。在瓶頸工作的人是否在做其他非瓶頸活動？是否有人可以替他們做那些工作？在我們的例子中，也許開發人員可以幫測試人員填寫時間報表和報銷。瓶頸中的任何閒置時間——任何他們無法進行瓶頸工作的時間——都會降低整個系統的產出。

具體來說，利用瓶頸的做法包括：

• 確保瓶頸資源始終有工作可做——例如在他們前面建立工作佇列
• 內建品質以最小化工作量——不要讓有缺陷的工作流入瓶頸
• 移除或至少限制中斷
• 移除阻礙他們工作或讓他們等待的障礙
• 仔細排定優先順序，確保他們總是在做最重要的任務——你不希望約束在不重要的任務上浪費時間
• 讓他們以穩定的節奏工作，均勻化工作到達率，而非以尖峰的方式送入工作

實際範例：確保測試人員總有工作可做，嘗試將工作項目拆分成可以個別測試的小交付物，讓工作快速準備好並以穩定的節奏抵達，而非一次大量湧入。讓測試人員與開發人員和其他上游人員（產品負責人、分析師、設計師等）密切合作，以內建品質並更好地理解他們正在測試的工作。

常見反模式：在非敏捷環境中工作的測試人員期望在迭代或發布結束時批次進行測試。大量時間花在準備、規劃、管理和類似活動上，甚至參與規劃下一個版本或其他專案——這增加了他們的 WIP，減少了他們在瓶頸活動上的時間。

瓶頸會移動：當你對系統做出改變時，瓶頸可能會轉移。這是五個聚焦步驟的最後部分（「重複」），應該持續評估：現在瓶頸在哪裡？你是否在處理正確的瓶頸？記住：對非瓶頸步驟的改善不是真正的改善。

7.6 本章總結 (Summary)#

本章討論了管理工作流動的多種方式：

• 流動（連續流） 是一個理想狀態，描述流程中每一步都創造價值，沒有中斷或等待
• 追求這個理想是永無止境的探索，幫助你獲得更順暢、更快的流動，同時發現流程中的問題
• 在客戶眼中不是價值的一切都是浪費；消除浪費帶來更好的流動
• 「管理流動」是看板的原則之一，你可以做很多事情來幫助工作流動：
  • 限制 WIP
  • 減少等待時間（確保工作準備好、讓工作項目更小更一致）
  • 盡快移除阻塞，或追求「永遠不被阻塞」
  • 從一開始就內建品質以避免返工；區分價值需求與失敗需求
  • 建立跨職能團隊以最小化等待
  • 使用 SLA 或目標時間來設定時間盒和優先順序
• 每日站會是團隊協作的利器：簡短、準時、聚焦、有規律
• 看板站會實踐：聚焦工作而非個人、從右到左走看板、聚焦異味和偏差
• 「我接下來該做什麼？」 的決策順序：完成進行中的工作 → 解決瓶頸 → 在 WIP 限制內拉入新工作 → 找其他有幫助的事做
• 瓶頸是減慢生產的流程步驟；佇列提供前導指標幫助發現瓶頸
• 約束理論 (Theory of Constraints) 是圍繞發現和消除瓶頸的管理理論，遵循五個聚焦步驟：識別、利用、從屬、提升、重複

關於約束理論還有很多可以學習的內容，本章只是簡短介紹。推薦閱讀 Goldratt 的《目標 (The Goal)》以及 Steve Tendon 和 Wolfram Muller 的《Tame the Flow》以深入了解。