第八章：服務類別（Classes of Service）#
本章涵蓋以下主題：
- 什麼是服務類別（Class of Service）
- 如何將服務類別應用於實際工作
- 常見的服務類別範例
在前面的章節中，我們學到了許多管理工作流的方法。但這些原則、經驗法則和最佳實踐都沒有解決一個問題：並非所有工作項目都具有相同的重要性。某些類型的工作可能需要比其他工作更快地通過工作流。這就是「服務類別」（Classes of Service）概念派上用場的時候了。
8.1 緊急案例（The Urgent Case）#
特別緊急的工作項目是許多團隊都熟悉的情境——經常需要彈性地調整流程，以允許重要且有價值的例外情況突破你的正常規則和政策。
這可能是：
- 生產環境問題（production issue）
- 為了符合法規或合約而必須進行的修復
- 必須立即把握的商業機會
- 任何讓你放下手邊工作、全力推動完成的事項
一個常見的視覺化方式是在看板上增加一條專用泳道（swim lane），清楚標示這是一種不同類別的工作項目，並且附帶特殊的政策。
緊急項目的政策範例#
- 擁有專屬泳道
- 使用粉紅色便利貼書寫
- 不計入 WIP 限制
- 應優先於一般項目處理；事實上，所有人都應該放下手邊工作來幫忙解決這個問題（也稱為 swarming，參見 7.2.3 節）
- 只需要粗略估計即可判斷是否能在特定截止日期前完成
- 應該是例外情況；例如，同一時間泳道中只能有一個緊急項目，且每週最多兩個
最後一點在某些環境中特別重要——當推動緊急工作的人無法立即感受到加速處理的成本時。根據 Little’s Law（第五章），增加更多工作會導致流程中所有工作的前置時間（lead time）變長。利用看板來視覺化這一點，可以幫助人們理解並避免不必要的加速處理。
Figure 8.2: Urgent class of service summary
教練的建議：緊急項目的回顧#
為了確保緊急類別不被過度使用，並從這些例外中學習和改進，可以在每個緊急項目完成後引入一項額外活動：簡短的回顧（retrospective）或根本原因分析（root-cause analysis）。
因為這類項目是例外，你應該把它們視為蘊含知識寶藏的機會：
- 我們流程中的什麼環節導致了這個緊急項目的出現？
- 我們如何防止類似情況再次發生？
- 我們對這個項目的處理方式是否如預期般運作？
有些利害關係人在得知團隊打算在完成緊急項目後進行回顧會議時，會重新分類他們的「緊急」項目。也許它其實沒有那麼緊急！這正是我們想要的效果——緊急類別只用於真正緊急的事情，而不是讓「我的項目」更快完成的快速通道。
緊急（Urgent），有時也稱為加速（Expedite），只是一種與一般項目具有不同政策的工作項目類別範例。你可以說這些工作項目擁有不同的服務類別。
8.2 什麼是服務類別？（What Is a Class of Service?）#
你在緊急類別中所做的，就是明確聲明某一類工作項目會獲得特定的服務。事實上，並非所有工作項目都具有相同的價值水平或時間壓力。你希望這些差異能明確地反映在看板上和其他工作政策中。這就是服務類別成為看板社群中重要概念的原因。
為不同的工作項目分配不同的服務類別，是一種簡單且透明的方式，讓團隊能夠：
- 自我組織工作
- 透過讓工作項目的價值、風險資訊和政策明確化來滿足業務需求
- 利用不同的服務水平來提升客戶滿意度
Figure 8.1: Kanban board with classes of service
8.2.1 建立服務類別時要考慮的面向#
從緊急類別的範例中可以看到，工作項目行為的許多面向都可以在建立服務類別時納入考量。以下是服務類別可能影響的幾個面向。
視覺化（Visualization）#
為了讓所有團隊成員和其他相關人員能輕鬆辨識工作項目的服務類別，你需要讓它具有視覺可見性：
- 使用泳道（swim lane），如緊急類別的範例
- 使用特殊顏色的便利貼
- 在工作項目卡片上標示服務類別——例如使用貼紙或圖示
對 WIP 的影響（Impact on WIP）#
需要考慮的問題：
- 該服務類別是否影響 WIP 限制？
- 它是否在某些欄位影響 WIP，而在其他欄位不影響？
- 如果該服務類別有自己的泳道，該泳道是否有 WIP 限制或最大/最小項目數？
優先順序（Prioritization）#
- 與其他類別相比，該類別如何排定優先順序？
- 該類別的工作項目是否應該在其他類別之前被拉取？
- 是否有 swarming 政策，讓所有人放下手邊工作，全力推動該項目通過工作流？
- 也許 FIFO（First In, First Out，先進先出）排隊方式對這類工作是合適的政策
風險資訊如延遲成本（cost of delay）、特殊技能需求和技術影響，都是典型的考量因素，應該被明確化，以賦予團隊成員即時做出良好風險決策的能力。
不同的工作流（Different Workflow）#
- 該類別是否應該遵循與其他類別不同的工作流？
- 也許它跳過某個欄位：例如，缺陷（Defect）類別不需要分析步驟
- 也許它對工作流的某個步驟有不同的政策：例如，非 QA 開發人員可以執行缺陷的 QA 工作
- 也許它需要比其他類別更簡略的估算
根據服務類別來調整工作流以優化結果。對於緊急項目，可以優化速度；而對於被歸類為無形（Intangible）的項目，則可以將程式碼品質作為首要目標。
8.2.2 常見的服務類別（Common Classes of Service）#
除了已經提到的緊急類別之外，還有其他常見的服務類別。其中最廣泛使用的是 David J. Anderson 在其著作《Kanban: Successful Evolutionary Change for Your Technology Business》中描述的類別：
| 類別名稱 | Anderson 的術語 | 說明 |
|---|---|---|
| 緊急（Urgent） | Expedite | 最高優先順序 |
| 固定交付日期（Fixed Delivery Date） | Fixed Delivery Date | 有明確截止日 |
| 無形（Intangible） | Intangible | 無直接商業價值但仍重要 |
| 一般（Regular） | Standard | 日常麵包和奶油工作 |
| 缺陷（Defect） | — | 本書額外加入，許多組織常用 |
本書使用「Regular」而非 Anderson 的「Standard」，以避免與精實（Lean）概念中的「標準化工作」（standard work）混淆。
以下逐一介紹這些類別。如果這些類別不完全適合你的具體情況，請根據需要進行調整和改變。
固定交付日期（Fixed Delivery Date）#
固定交付日期類別用於必須在特定日期前交付的工作項目。這些項目必須被適當地排定優先順序，並及時拉動通過工作流，因為未能按時交付通常會導致：
- 成本增加
- 錯過商業機會
- 合約或法律義務違約
- 技術原因（如第三方服務在某個日期停止支援）
使用固定交付日期類別時需要注意排程：不能太晚（會錯過截止日期），但也不能太早（會延遲其他更有價值的工作）。
固定交付日期項目的政策範例：
- 使用紫色便利貼書寫
- 在卡片上清楚標示截止日期
- 優先於其他風險較低的類別被拉取（例如優先於除緊急類別以外的所有類別）
- 如果截止日期受到威脅，應考慮將其提升為緊急/加速類別
Figure 8.3: Fixed Delivery Date class of service summary
不要過度使用這個類別，把工作項目變成傳統計畫驅動甘特圖（Gantt chart）中的任務。僅在外部截止日期和類似限制條件下謹慎使用，否則會打亂正常項目的工作流。
一般項目（Regular）#
一般類別包含填滿工作週的日常工作項目。流動（flow）和專注（focus）會使這些項目儘可能快速地通過系統，並具有合理可預測的前置時間。
另一個我們聽過的名稱是「逐漸緊急」（Increasingly Urgent）。通常這些項目現在並不緊急，但隨著時間推移，其緊迫性會增加。
一般項目的政策範例：
- 使用黃色便利貼（最常見的標準色）
- 按 FIFO 順序（First In, First Out，先進先出）拉取
無形項目（Intangible）#
這類項目沒有有形的、具體的商業價值，或者至少不容易估算其價值，但仍然很重要。包括：
- 低優先順序的缺陷
- 小型的可用性改善
- 設計變更
這個類別也涵蓋了 Stephen R. Covey（《高效能人士的七個習慣》作者）所說的**「重要但不緊急」**的任務。這些是你可能會忽略的工作，但你應該專注於此以實現效能：
- 改善工作
- 消除技術債
- 增加中長期產能
- 其他有助於降低未來成本或創造未來選項的事情
這類工作延遲的成本很低，容易讓人一天接一天地無限期推遲。一種避免方法是確保始終為這類工作保留一些產能。額外的好處是，這樣做會在系統中創造餘裕（slack），可用於讓其他類別的工作更快地流動。
無形項目的政策範例：
- 使用綠色便利貼書寫
- 只有在沒有其他類別的項目可用時才會被拉取
- 可能以某種方式限制看板上的數量，例如：
- 看板上始終應有兩個無形項目
- 應佔迭代故事點數的 20%
- 每月完成三個項目的速率
無形類別也可以採用其他形式，例如 Google 著名的「20% 時間」，分配特定日子用於無形工作。有些團隊使用「改善卡片」（improvement cards），例如允許看板上始終有一張團隊自選的改善卡片。有人稱這些為「技術金卡」（technical gold cards），因為它們是開發人員渴望處理但從未有時間著手的改進。
缺陷（Defects）#
缺陷是你不想看到的工作類別。缺陷通常是第一次工作中缺乏品質的表現——這是被引入並加到你已在進行的工作上的返工（rework）。
缺陷也可能是其他事情，例如生產環境的 bug 或需要立即處理的伺服器故障。
缺陷項目的政策範例：
- 使用紅色便利貼書寫
- 跳過分析步驟，直接進入開發欄位
- 不必進行估算
- 在拉到「完成」之前，應進行根本原因分析，以了解如何避免未來出現類似缺陷
- 必須在 bug 追蹤工具中管理：關閉並指派給 QA 等
- 可以在正常發佈排程之外發佈：不必等待下次正常發佈
Figure 8.4: Defect class of service summary
8.2.3 運用服務類別（Putting Classes of Service to Use）#
服務類別可以幫助團隊面對許多決策。核心在於讓政策、工作項目價值和風險資訊更加明確（參見第三章），從而幫助團隊自我組織並拉取正確的工作項目。這反過來使工作更順暢、更快速地通過工作流，因為你不需要在每個問題或決策點上都等待他人的決定或批准。
利用分配比例管理產能#
一種使用服務類別的方式是決定團隊的產能應該有多少用於不同類別——例如決定每個類別始終在看板上的工作項目數量（或百分比）。
Figure 8.5: Board with color-coded classes of service and distribution ratios
在看板左側，團隊張貼了圖例和各服務類別之間的偏好分配比例。每個服務類別旁邊都寫有百分比和具體數字，指示團隊努力維持的工作分配方式。當你完成一個工作項目時，可以輕鬆地查看看板，決定從「待辦」欄位拉取哪張卡片，以保持團隊約定的分配。
透過使用不同顏色來代表每個服務類別，團隊成員可以快速計算看板上各色卡片的數量，判斷下一步應該拉取哪種類別的工作。這個簡單的機制幫助團隊自我組織，無需等待外部決策。
確保低優先順序工作不被遺忘#
更重要的是，這個系統確保工作以適當的方式被排定優先順序。等待在「待辦」欄位中的缺陷卡片被優先處理，確保團隊關注缺陷，即使對業務利害關係人來說，開發新功能可能更有趣也更重要。
這種方式也確保低優先順序的工作至少在某種程度上被完成，而不是不斷被推遲到「以後再說」。例如，團隊可以保證始終至少有一個無形項目正在進行。因為無形項目在工作流中被拉到下一個欄位的優先順序較低，它也為更重要的工作創造了一些餘裕，讓它們更快到達「完成」。
動態調整分配#
不同類別的分配比例當然可以持續修改，以適應不斷變化的業務需求：
- 如果產品存在明顯的品質問題 → 增加缺陷的比例，直到問題解決
- 如果團隊剛剛衝刺以趕上截止日期 → 提高無形項目的數量，償還累積的技術債
真實案例：「一切都是雜項」
在一位教練輔導的客戶中，一次審查顯示他們把約 70% 的預算花在了被歸類為「雜項」的工作上——儘管他們已經為三項主要投資撥出了專門的資金並要求優先處理。原因很簡單：在忙碌的當下，很難拒絕「這個小東西我們週五前需要」。如果他們有明確的服務類別分配，就能更容易、更快速地發現他們偏離了軌道。
降低協調成本#
有了明確的政策，選擇工作的協調成本（coordination costs）就會大大降低。團隊已經擁有了如何從待辦清單中選擇工作的原則，且通常已視覺化在看板上。團隊更加自我組織，可以即時（just in time）而非以防萬一（just in case）地進行工作選擇。
交易成本與協調成本
- 交易成本（Transaction costs）：與交付價值相關的設置和清理活動，如規劃、估算、預算、整合和部署。這些都是浪費，因為客戶更希望直接獲得價值而不支付這些成本。
- 協調成本（Coordination costs）：與他人合作時產生的特定成本，包括所有需要的會議、電話、郵件等。
例如，聯繫一位不在場的業務利害關係人有很高的協調成本。相較之下，走到隔壁桌詢問在場的利害關係人則成本極低。
排程（Scheduling）是一個持續且動態的過程——從工作項目的排序中產生經濟上最優的結果。
排程是一個過程——而且是一個持續且動態的過程——從工作項目的排序中產生經濟上最優的結果。這是一個重大責任；所以讓我們嘗試以穩健且透明的方式來做這件事。
— Mike Burrows (@asplake on Twitter)
如果你致力於透過小批量（小型工作項目）在工作流中快速流動，你將同時最小化交易成本和協調成本。這將通過持續且動態地選擇要處理的工作項目來實現，而不是為可能改變的未來制定計畫。實現這一目標的工具就是透明、明確的政策，例如限制某個服務類別在看板上同時存在的項目數量。
8.3 管理服務類別（Managing Classes of Service）#
雖然不同的服務類別可能已被清楚定義並獲得所有人的認同，但工作並不總是完美符合你的分類。例如：
- 工作項目可能由多個任務組成，每個任務屬於不同的服務類別
- 你可能根據工作來源以不同方式處理工作項目
以下介紹幾種常見的方法和實踐來處理這些情況。
拆分與重新分類（Divide and Reclassify）#
有時單一工作項目可能混合了不同的服務類別，特別是較大的工作項目。這可能導致你難以決定該項目屬於哪個服務類別，因此不確定如何處理。它可能同時感覺像是 bug 和無形項目。
解決方法： 嘗試將大項目拆分為更小的項目，看看新項目是否屬於其他類別並應相應處理。
大小很重要（Size Matters）#
有時你無法拆分大項目（由於工作項目的性質或技術環境/組織中的依賴關係）。其他時候，團隊可能有些項目的規模或複雜度比其他項目大一個數量級。
大項目的前置時間會不同，也許需要其他政策。這可以是考慮特殊服務類別的理由。例如，允許大項目在看板上存在較長時間，並在此期間始終分配一定量的工作給它。
某些客戶更加重要（Some Clients Are More Equal Than Others）#
不同的客戶可能具有不同的重要性，通常體現為不同的服務水平協議（SLA）。你可能想要：
- 在爭取新合約時偏好某個客戶
- 某個部門或特定產品被給予優先權
如果這種差異意味著你需要以不同的政策來處理工作，那麼新的服務類別可能就是解決方案。
以不同方式切分（Slicing It Differently）#
另一種區分服務類別的方式是根據工作的來源（source of demand）進行分類。這樣你可能會得到像這些類別：
- 行銷部門（Marketing）
- 客戶支援問題（Customer Support Issues）
- 開發者需求（Developer Requests）
這是另一種對工作項目進行分類並明確每個類別政策的方式。每個類別關聯的具體政策會因你的情境而異。
不要過度複雜化。 經驗法則是不要使用超過 5 到 7 個服務類別，因為太多會使所有人難以理解和記住，也難以在日常決策中運用這些政策。話雖如此，不要害怕發揮想像力和探索，以了解你的工作如何運作。
放大、探索、然後簡化（Zoom In, Explore, and Simplify）#
面對這麼多不同的切分、拆分和改變服務類別的方式，一個顯而易見的問題是：應該多細緻？
Zoom in（更多欄位/類別）, explore, and then simplify 是一個我見過有效的模式。
— Jabe Bloom (@cyetain on Twitter)
Jabe Bloom 的意思是：
- 放大（Zoom in）：首先增加細節——更多看板欄位和服務類別
- 探索（Explore）：嘗試不同的應用方式，直到找到適合團隊的做法
- 簡化（Simplify）：嘗試精簡你所創建的東西——哪些可以移除，哪些類別可以合併
8.4 練習：分類吧！（Exercise: Classify This!）#
與你的團隊坐下來，開始思考服務類別如何為你服務：
- 是否應該使用緊急泳道？ 這個服務類別應該有什麼樣的政策？如何確保不是所有東西都是「緊急」？同一時間只能有一個緊急項目在進行嗎？
- 思考你做的不同類型的工作。 也許你已經為某些工作使用了不同的顏色（例如 bug）。是否有「大家都知道」的隱含政策，可以透過討論和寫下來而受益？
- 是否有經常被遺忘或頻繁獲得低優先順序的工作？ 服務類別和相關政策能幫助你完成低優先順序的工作嗎？你能用文字表述該政策嗎？什麼樣的視覺化可以幫助你記住政策？
- 你目前有哪些可以簡化的政策？
8.5 總結（Summary）#
本章討論了如何將明確的政策與特定類型的工作關聯起來——一個稱為服務類別（Classes of Service）的概念：
- 服務類別是一種強大的方式，讓你針對特定類型工作的服務水平將政策明確化
- 為工作項目指定服務類別可以影響：視覺化、優先順序、對 WIP 的影響、以及工作流
- 服務類別幫助團隊自我組織：
- 工作選擇與排程
- 工作分配
- 確保工作產能按照決定進行分配
- 常見的服務類別包括：
- 緊急（Urgent / Expedite） — 優先於其他工作
- 固定交付日期（Fixed Delivery Date） — 必須在特定日期前完成
- 一般（Regular） — 日常項目，逐漸緊急，按 FIFO 拉取
- 缺陷（Defect） — 品質不佳產生的返工（越少越好）
- 無形（Intangible） — 現在沒有有形商業價值，但未來有：償還技術債
- 你應該使用適合自己需求和情境的類別，以本章的範例作為靈感。沒有放之四海而皆準的正確答案。