第九章：規劃與估算 (Planning and Estimating)#

在使用看板的過程中，你不僅需要關注自己的看板，還需要考慮團隊周圍的情境。有時候，其他團隊或上下游流程會與你的工作產生交集，你需要讓他們了解你的進度，也需要知道接下來該做什麼。

考慮一個團隊的看板，Inbox 欄位只剩下兩個工作項目——它將如何被補充？你需要與誰溝通才能知道下一步該做什麼？多久能與他們開一次會？這些就是你需要進行規劃的原因。

上游 (Upstream) 指的是在你之前進行的工作——可能是其他部門或其他人執行的任務。這些可以用獨立的看板來視覺化呈現：

在看板的另一端，你可能也需要與下游 (Downstream) 流程互動——例如協助將工作部署到生產環境。在你的流程與其他流程交會的兩端（上游與下游），通常都需要某種形式的同步或規劃。

另一個需要規劃的原因是與其他團隊同步。想像兩個團隊在同一產品上工作，例如後端團隊剛完成了一次重大變更，這將影響前端團隊，因此部署時需要密切監控與協調。

本章將展示幾種在看板中處理規劃與同步需求的方法，包括：

• 常見的視覺化技巧與規劃思維
• 快速估算技術，產出「足夠好」的規劃材料
• 將估算視為風險管理——及早發現你不知道的事、感覺有風險的事、可能會造成問題的事

9.1 規劃排程：何時該進行規劃？#

規劃本質上是提前進行的活動，但不能太早——因為太早規劃的事物可能會改變，導致你需要重做一遍。更重要的是，為更多工作做規劃實際上就是在創造更多的在製品 (WIP)，因為你已經開始了一些會在那裡等待的工作。另一方面，你也不希望規劃得太晚，因為那樣規劃就變得毫無意義——未來已經到來了。

理想的規劃時機是恰到好處 (Just in time)——不太早、不太晚，而是在需要的那一刻。

9.1.1 即時規劃 (Just-in-Time Planning)#

當你在規劃時，你正在建立一小批工作項目的「庫存」。這有好處——團隊知道下次有產能時該做什麼；但也有壞處——庫存就是更多的 WIP，而如同第三章所學，更多 WIP 會讓每個項目通過工作流程的速度變慢。

一長串堆積的工作項目也會讓你變得不夠敏捷。如果突然出現一個緊急工作項目需要優先處理，你必須將它與所有已規劃的工作項目重新排序。

你應該為新工作做即時規劃 (just-in-time planning)——在你即將開始工作時才規劃，將預先規劃的工作庫存保持在最低限度。

但這又帶來另一個問題：規劃通常有成本，例如召開規劃會議、客戶無法隨傳隨到、或者需要做相當多的前置工作。

一種平衡方法是使用事件驅動規劃 (Event-driven Planning)：讓流程中的事件告訴你何時有產能接受更多工作。你可以建立一個簡單的訊號系統，在工作流程中視覺化呈現，提醒你何時該規劃更多項目。

相比之下，如果你每個月固定規劃一次（無論是否需要），就有兩種風險：

• 開會時其實不需要更多工作，因為你還沒完成手上的事
• 下一次規劃會議還有兩週，但你已經沒事可做了

即時規劃重點整理：

• Just in time = 在需要的時候才做
• 提前規劃太多會產生工作庫存，導致敏捷性降低
• 規劃太頻繁會導致過多不必要的會議
• 在流程中建立訊號，通知你何時需要更多工作
• 讓流程中的事件來驅動規劃

9.1.2 訂購點 (Order Point)#

透過引入訂購點 (Order Point)，你可以在工作項目降至特定數量時，從利害關係人那裡拉入新工作。其實在 6.4.2 節已經討論過這個概念。

運作方式很簡單：

1. Inbox 欄位包含六個工作項目
2. 在第三個項目下方畫一條線——這就是訂購點
3. 團隊從上方開始處理，一路往下做到這條虛線
4. 當 Inbox 降到這個水位時，團隊聯繫利害關係人安排會議，取得更多工作
5. 訂購點下方的三個項目形成一個小緩衝，確保在會議協調與召開期間仍有工作可做

訂購點是一個簡單的視覺化機制：它在流程中創造了一個事件，訊號告訴團隊何時需要規劃更多工作。同時確保規劃是即時的——在需要更多工作時才進行，而非建立大量工作庫存「以防萬一」。

調整訂購點的原則：

• 如果利害關係人很難召集、或需要大量前置工作才能知道下一步做什麼 → 緩衝應較大（協調成本較高）
• 如果你可以隨時聯繫利害關係人 → 可以設定較低的訂購點（協調成本較低）
• 持續實驗與改善

訂購點重點整理：

• 在 Inbox 中畫一條線，作為訊號
• 當工作項目降到線以下時，召開會議規劃更多工作
• 平衡 Inbox 中剩餘的工作量與規劃更多工作所需的時間

9.1.3 優先權過濾器 (Priority Filter)：視覺化什麼是重要的#

你是否遇過一份所有東西都是「優先順序 1」的功能清單？或者公司有不只一個「最高優先」的專案？在許多組織中，排序優先順序耗費大量時間和精力。

Corey Ladas 引入了一種叫做優先權過濾器 (Priority Filter) 的技術，簡化了排序過程並使其視覺化。

這個優先排序看板的欄位有遞增的優先順序：

每一欄的 WIP 限制加起來等於你的產能。WIP 限制隨優先順序降低而增大，反映了對低優先順序項目被處理的不確定性更高。

flowchart RL
E[開發看板] -->|拉取| A[P1\nWIP: 2]
A -->|拉取| B[P2\nWIP: 4]
B -->|拉取| C[P3\nWIP: 8]
C -->|拉取| D[Backlog\n 無限制]

Backlog 中的項目直到被提升到 Priority 3 時才會變成卡片。在此之前，它們只是寫在看板上的文字。有些團隊甚至用心智圖 (Mind Map) 來視覺化 Backlog，放在優先權過濾器看板旁邊。

優先權過濾器的一個關鍵洞察是：優先順序與時間緊密相連。你只需要在有空間接受更多工作時——也就是完成一個 P1 項目後——才關心「下一個最重要的事情是什麼」。

實際上，P2 和 P3 欄位中的項目不需要排序。當需要拉入新的 P1 項目時，你只需要考慮：

• 哪一個 P2 項目升到 P1？
• 哪一個 P3 項目升到 P2？
• 哪一個 Backlog 項目升到 P3？

不要花時間為可能永遠不會實作的事情排列先後順序。延遲決策直到需要時再做 (defer decisions until required)。有些團隊只用 P1 和 P2；有些則把欄位命名為更有意義的名稱，如「即將到來 (Upcoming)」或「下一個 (Next)」。

優先權過濾器重點整理：

• 視覺化呈現你的優先順序
• Priority 1 = 現在需要處理的事
• 限制在你的產能範圍內，以改善每個工作項目的前置時間
• 核心問題：「我們現在需要做的最重要的事是什麼？」——只在有 P1 空間時才問

9.1.4 迪士尼等候時間 (Disneyland Wait Times)#

想像你在遊樂園排隊等雲霄飛車，已經等了 35 分鐘。你又往前走了一步，遠處看到一個標示：「您從此處的預估等候時間為 8 分鐘。」這讓你有了規劃的依據——一個看似合理的預測。

遊樂園工作人員之所以能做到，是因為他們追蹤了資料並測量了流程的流動：每分鐘有 x 輛車離開月台，每輛車載 y 名乘客。然後只需數排隊人數，做個計算。

你也可以在看板上輕鬆實現這個指標。這不僅能安慰等待功能上線的利害關係人，更能建立團隊與利害關係人之間的信任。團隊追蹤了這些數據，可以有信心地說：預估等候時間是六天。

火車 vs. 地鐵：建立信任

搭長途火車時，你會提前買票、查班次、提早到站——因為錯過的成本很高。但搭地鐵呢？你直接走下去搭下一班就好。

利害關係人也是如此：如果他每六個月才與團隊見一次面，他會要求精確的估算和詳細的計畫。但如果她每週一和週三都能見到團隊，對詳細估算和計畫的需求就會降低——因為如果一個項目沒有如預期交付，很快就會交付。

你在做的是降低已規劃工作的 WIP。較低的規劃 WIP 意味著更頻繁地與利害關係人見面，從而建立信任。

如何計算 Disneyland 等候時間？

很多團隊覺得很難提出一個可信的天數，因為前置時間差異很大。以下是一些解決方法：

• 按不同大小使用時間範圍：例如，平均而言 Small 項目 1-3 天、Medium 項目 2-6 天、Large 項目 5-20 天
• 使用到期日績效 (Due Date Performance)：長期測量前置時間，例如「80% 的情況下，我們在 x 天內完成」。你還可以研究數據，找出未達標項目的典型特徵（依賴第三方的工作、特定類型的工作項目、特定服務等級），以提高可預測性

在實務經驗中，可預測性往往比速度更重要。頻繁且可預測地交付，能夠建立信任。

Disneyland 等候時間重點整理：

• 顯示工作的預期等候時間
• 從已通過你流程的工作的前置時間計算
• 可以按大小類型分別計算（如 S、M、L）
• 與利害關係人建立信任

9.2 估算工作——相對而言#

與規劃密切相關的是估算你將在完成前方工作上花費多少精力。這很困難，因為你在試圖預測未來，而歷史已經多次證明，我們這個行業經常錯估——而且差距很大。

估算 (Estimates) 常常是錯的，但估算的過程 (Estimating) 仍然有用。估算讓你有機會開始管理前方的不確定性，可以作為風險管理工具——及早發現誤解、不一致和需要進一步調查的領域。

以團隊的方式進行估算有助於建立對工作的共同理解 (Shared Understanding)。但根據邊際遞減法則，你也不想做太多估算。在 WAG（Wild Ass Guess，純粹的猜測）和完整規格之間存在一個甜蜜點——找到你的。

9.2.1 故事點數 (Story Points)#

估算之所以棘手，其中一個原因是：你試圖預測未來並確信它會如何發展。為了給出精確且準確的估算，你需要了解相當多的細節——而這通常是在專案一開始就被要求的，恰恰是你對即將進行的工作了解最少的時候。

更糟的是，人類不擅長以精確的方式估算。你可以自己試試：看一棟高樓，嘗試猜它有多高——這很難。

但如果換一個更簡單的問題：「那兩棟建築，哪一棟比較高？相對而言，一棟比另一棟高多少？」這些問題人們回答起來容易得多。

這導致全球的敏捷團隊都用相對方式而非精確數字來進行估算。最知名的敏捷估算工具就是 Story Points（故事點數），最初在 Scrum 和 Extreme Programming 等敏捷方法中引入。

Story Points 是一種表示工作項目之間相對大小的方式。你沒有說一個 story point 有多大，而是說：估為 5 點的東西大約是 2 點的東西的兩倍大，又大約是 14 點的東西的三分之一大。

Fibonacci 數列

Fibonacci 數列（0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…）常用於估算 story point 的大小。原因不僅是數學上的趣味——使用 Fibonacci 數列意味著項目越大，估算的精度自動降低，這反映了我們在估算大小差距很大的項目時，能力本身就會下降。如果你在討論一個項目是 12 點還是 13 點，你大概在欺騙自己——你並沒有那麼精確的資訊。

避免在估算中使用「天」或「小時」，因為這可能讓你和他人誤以為你在指真實天數。有些團隊使用「相對天數 (relative days)」這個術語來避免混淆。

Story Points 有什麼用？

• 它們傳達了估算不是精確的：你沒有說「完成這個功能需要 258 小時」
• 相對估算可以用來對照實際表現進行跟蹤：如果團隊上個月交付了估計為 34 點的工作，你可以預測下個月（相同團隊、相同類型的任務）大約能交付 30-40 點

Story Points 的問題

• Story Points 是相對的，因此不精確，這讓很多人不舒服
• 很容易掉入把 story points 轉換成天數或小時的陷阱
• 一個團隊做了 34 點，不代表三個團隊可以做 136 點——估算只對特定團隊有效
• 兩個團隊估算相同的工作可能得出不同的結果
• 團隊動態、誰在討論中更有影響力、團隊的強項和弱項都會影響估算

Story Points 是相對的：它們估算事物的相對大小，且相對於做出估算的團隊和情境。不要在團隊之間進行比較，也不要試圖將其轉換為絕對時間。

Story Points 重點整理：

• 比較工作項目的相對大小，而非給出精確估算
• 團隊之間不能互相比較
• 常用的數列是 Fibonacci 數列：1, 2, 3, 5, 8, 13, 21
• 使用對你有意義的數字

9.2.2 T-shirt 尺寸 (T-Shirt Sizes)#

Story Points 的問題促使許多團隊放棄它們，轉而使用完全不用數字的方式——例如 T-shirt 尺寸。這意味著你透過選擇 S、M、L 或 XL 來進行估算。

保持系統盡可能簡單。這只是對工作項目大小的粗略估計，唯一表達的是：一個 S 項目的大小大約與你做過的其他 S 項目相同。更多的數值表示更高的估算精確度，而整個概念就是只表示工作的相對大小。

常見的實務做法：

• 大多數團隊使用 S、M、L 三個尺寸
• 任何比 L 更大的項目，都應該拆分成更小的工作項目，使其可以被估為 S、M 或 L
• XL 項目會佔據太多產能，且難以管理
• 可以視需要增加尺寸（如 XS、XXL），但大多數情況下不需要

估為 XL 的工作項目隱藏了大量的不確定性和風險。拆分一個 XL 項目後，發現變成兩三個新的 XL 項目，並不罕見——因為團隊不知道那個大項目裡面藏了什麼。

約定好：總是將估為 XL 的項目拆分到 L 或更小。這是管理不確定性和降低風險的好方法，同時也能限制你的 WIP。

與 Story Points 一樣，T-shirt 尺寸的好處是你可以根據團隊隨時間累積的實際數據來進行預測。例如：

• 如果團隊通常花 2-5 天完成一個 Small 項目，且過去 30 個 S 項目都是如此
• 那麼下一個 S 項目也可能花 2-5 天
• 基於此，你可以預測 Backlog 中的 30 個 S 項目大約需要 100 天完成

T-shirt 尺寸重點整理：

• 像 T-shirt 尺寸一樣分組估算
• S、M、L 最常用
• 只在需要時使用 XS 和 XL
• 相對估算
• 追蹤數據並根據實際數據進行預測，例如：「S 需要 3-5 天」

9.3 估算技術#

敏捷團隊有許多常見的估算方法。它們的共同點是協作，以及一個潛在主題：追求足夠好。你不想在估算上投入太多時間。

強烈建議以小組方式進行估算，最好包含不同能力、技能和角色的人。估算和規劃可以被視為一種知識收集練習——在消除不確定性的過程中揭露資訊。

9.3.1 卡片排列法 (A Line of Cards)#

假設你有 50 個工作項目，利害關係人問你估算它們的大小——這就是令人畏懼的「這個專案要做多久？」的問題。這個簡單的練習可以在團隊中快速進行，50 個項目大約只需 10-20 分鐘。

練習步驟：

1. 將工作項目的描述寫在獨立的索引卡上（事前準備好）
2. 把所有卡片疊成一堆放在桌上
3. 拿出第一張，放在卡片堆旁邊
4. 拿出下一張，問：「這個比第一個大還是小？」為了回答這個問題，你可能需要與團隊討論工作項目的內容。花點時間但不要太久——這是快速估算
5. 決定大或小後，將它放在桌上的卡片上方或下方，形成一條線

6. 重複步驟 4-5，直到所有卡片用完
7. 現在進入第二階段：分組。從線的底部（最小的）開始，宣告第一組估為 Small
8. 繼續往上走，決定卡片在哪裡變大、何時應該使用新的值（例如 Medium）。讓團隊喊出來
9. 很快你就走完整條線了。現在可以匯總值（例如 5 張 Small、4 張 Medium 等），得到整條線的總估算

這個練習可以作為重複性的活動——例如每次發布後（每兩週）重新估算 Backlog 中剩餘的工作項目，每次不超過 10 分鐘。

卡片排列法重點整理：

• 快速估算大量工作項目的簡單練習
• 選任一個工作項目，然後比較下一個：比較大還是比較小？
• 全部排好後，指定數值：例如 Story Points 或 T-shirt 尺寸

9.3.2 規劃撲克 (Planning Poker)#

Planning Poker 是另一種以團隊方式進行估算的方法，利用群體智慧和趣味性來產生良好的討論，並在過程中幫助估算。名稱由 James Grenning（敏捷宣言簽署者之一）所創，與撲克唯一的關聯是遊戲中使用某種「撲克牌」。

遊戲步驟：

1. 發牌給所有參與者
2. 抽出一個要估算的工作項目，向團隊簡要描述
3. 討論並回答關於該工作項目的問題
4. 當所有人都對工作項目有了足夠的了解後，進入估算
5. 每個人選一張代表自己認為的估算值的牌，不要讓別人看到
6. 數到三，所有人同時亮出自己的牌
7. 關鍵步驟：
   • 如果大家差不多一致 → 已找到估算值，繼續下一個
   • 如果估算差異很大（例如 2、4、8、13）→ 問問為什麼：
     • 估 2 和 4 的人認為這個項目是什麼意思？
     • 估 8 和 13 的人認為這個項目是什麼意思？
     • 回到步驟 5，重新投票
8. 重複直到對估算值達成共識（允許小幅差異）

Planning Poker 的主要目的是討論，而非估算值本身。只有透過互相交談，你才能理解每個人對完成工作所需的努力的看法。讓團隊進行估算是一種激發討論的方式。

另一種 Planning Poker 的做法（來自 Amr Elssamadisy 的 Agile Adoption Patterns）：

對每個需求：

1. 讓領域專家向團隊解釋需求
2. 進行以下估算輪次，只在未達共識時才繼續下一輪：
   • 第一輪：靜默投票，不討論
   • 第二輪：思考一兩分鐘，再次靜默投票，仍不討論
   • 第三輪：讓團隊成員解釋為什麼這樣投票，然後再投一次
   • 如果仍未達共識 → 將該故事暫時擱置，繼續下一個

這種方法聚焦於快速產出足夠好的估算——沒必要在你已經達成共識時詳細討論每個需求。

牌的選擇：

• 數字：1, 2, 3, 5, 8, 13
• ? = 「我完全沒有頭緒，在我能猜測之前請給我更多資訊」
• 咖啡杯 = 「我的大腦已經烤焦了，需要休息」
• 也有許多手機 App 可用，但不要花太多心思在工具上——估算值不是重點

對於從未合作過的團隊，可以先選一個小的故事並嘗試達成估算共識。所有其他工作都可以相對於這個故事來估算。或者，先做幾次「卡片排列法」，之後再開始 Planning Poker。

Planning Poker 重點整理：

• 消除誤解、激發對真實含義的討論的好練習
• 討論、選數字、展示給團隊
  • 不同意 → 繼續討論
  • 同意 → 進行下一個
• 討論重要；估算值本身沒那麼重要

9.3.3 Goldilocks（金髮女孩法）#

前面的技術都在估算工作項目的大小，但 Goldilocks 法提供了另一種思路：與其估算工作項目的大小，不如將工作項目調整到合適的大小。

這個技術取自童話故事《金髮女孩和三隻熊》：Goldilocks 進入三隻熊的家，試了椅子——爸爸熊的太大、小熊的太小，但媽媽熊的剛剛好 (Just Right)。

練習步驟：

1. 將一疊工作項目分成三個小堆：太小 (Too Small)、太大 (Too Big) 和剛剛好 (Just Right)
2. 描述每個工作項目，讓團隊投票決定放在哪一堆
3. 將「太大」堆中的項目拆分成較小的「剛剛好」項目
4. 將「太小」堆中的項目合併成「剛剛好」的工作項目

這個簡單的練習對預測非常有益。你現在擁有等量大小的項目，可以開始追蹤和測量。幾週後，你就知道團隊每週可以處理多少個「平均大小」的工作項目。因為所有工作項目大小相同，預測變得非常容易。

在 7.2.2 節中，我們談到了將工作項目變小且大小相似以增加流動性。Goldilocks 估算技術是這些想法的直接應用，不僅能幫助你估算，還能改善流動。

Goldilocks 重點整理：

• 不做估算，而是將工作切分成合適的大小
  • 合併太小的工作項目
  • 拆分太大的工作項目
• 得到一個「平均大小」工作項目的 Backlog

9.4 節奏 (Cadence)#

Cadence 大約意味著節拍或韻律——你的工作流程的心跳。

這並不像聽起來那麼奇怪；你的流程中已經有了節奏。一個簡單的例子是許多流程中的迭代 (Iteration)。在 Scrum 中，工作有一個自然的心跳——稱為 Sprint。每個 Sprint 開始時有規劃會議、結束時有回顧檢視、展示和回顧。

節奏為你提供了可預測性的基礎。有了定期的節奏，你可以開始測量和預測你的表現。例如：「我們的目標是每兩週交付 4-6 個工作項目。」兩週後，你可以回顧看看表現如何。

迭代與 Kanban

迭代通常以某種規劃或評估開始，然後執行，最後結束——最好以回顧來結尾。迭代就像時間盒限制的小專案，有明確的開始和目標。

在上圖中：

• 開始時：團隊將下一個迭代的所有工作排在 Todo 欄位
• 中期：有些項目正在處理、有些已完成、有一個尚未開始
• 結束時：希望所有工作項目都已移到 Done 欄位。看板重置，團隊開始為下一個迭代規劃

從迭代式流程過渡

你也可以將迭代流程更明確地對應到看板上（Eric Willeke 建議），設置如下欄位：

Product Backlog → Ready for Planning → Sprint Backlog → Building → Accepted → Demo Complete → Done

這提供了從 Scrum（或其他迭代式方法）到 Kanban（基於流動）的平滑過渡——因為什麼都沒改變，只是你開始視覺化整個工作流程。

Kanban 的節奏方式

Kanban 對節奏沒有太多規定。主要焦點是工作項目如何個別地在看板上流動。這讓你可以將迭代（如規劃和回顧）與工作本身解耦：

• 每週規劃一次
• 每三週做一次回顧和回顧檢視
• 或使用流程中的事件來觸發規劃、回顧等（即拉式原則）

即使 Kanban 沒有規定迭代，如果你想要，仍然可以在 Kanban 中使用迭代。Kanban 只是三個簡單的原則（使工作可見、限制在製品、幫助工作流動），不對你的節奏或迭代做任何規定。

迭代式 vs. 流動式——哪個更好？

沒有絕對的答案：

• 如果你有一個 Backlog 是唯一的工作來源 → 迭代式可能更適合，提供很好的專注度
• 如果工作項目可能隨時出現（例如同時做支援維護和開發） → 流動式可能更好，沒有迭代的開始和停止

如果你從迭代式流程（如 Scrum）過渡到流動式方法，不要偷懶。保留有意義的實踐：繼續開規劃會議、繼續做回顧、繼續為利害關係人做展示——以適當的節奏。

9.5 以看板方式規劃：少一些痛苦，多一些收穫#

本節退後一步，思考為什麼要規劃和估算——以及可能的替代方案。

不要因為「Kanban 中沒有規劃」就停止規劃。太多看板團隊躲在這個「藉口」後面停止規劃。你比那更好。

順帶一提，Kanban 中也沒有提到程式碼品質、寫程式、做測試、或者部署程式碼是個好主意。

9.5.1 需求逐漸減少#

使用看板的團隊逐漸發現規劃和估算的需求在消退。這是因為：

• 需求的根源：對估算和計畫的需求源於管理風險和不確定性的慾望
• Kanban 的作用：你努力最小化 WIP 並幫助工作更快流動，這意味著沒有太多工作需要規劃
• 工作變小：因為你希望工作項目小而快，規劃和估算也就很快就能完成
• 頻繁拉入新工作：當團隊一天可能拉入多次新工作時，估算每個項目很快就會感覺繁瑣

當你開始質疑估算的價值時，去問問利害關係人真正的需求是什麼。使用看板一段時間後，利害關係人可能也發現了詳細估算和計畫需求的減少。至少可以做個實驗——嘗試一個月不做或用更輕量的方式進行規劃和估算。

Kanban 教你盡可能將流程的各個方面視覺化，讓團隊和周圍的人都能看到。這意味著目前的狀態對任何人來說都是顯而易見的。如果利害關係人缺少某些數據，就添加那些數據並使其可視化——例如印出 Backlog 並劃掉已完成的項目，或簡單的圖表顯示每週完成的項目數量。

「我們見過最好的報告！」

Marcus 幫助一個客戶將關鍵系統從 VB6 轉換到 VB.NET。面對「這要做多久？」的問題，團隊用了簡單的報告方式：

• 按文件大小（KB）列出所有 VB6 表單
• <20 KB = Small，20-50 KB = Medium，60-100 KB = Large，>100 KB = XL
• 開發者記錄每個表單的開始和結束日期
• 從中做出簡單的狀態圖和預測：「我們做了 3 個 Small 平均花 4 天。還有 60 個 Small。60 x 4 = 240 天」

這個高風險專案的指導委員會稱這是「公司有史以來最好的報告」。原因很簡單：透明、簡單、每天更新。這建立了信任。

9.5.2 邏輯推理：客戶的請求#

退後一步思考你為什麼在這裡。IT 部門或專案的主要目標是幫助業務更聰明、更容易或更好地工作。引用 Gojko Adzic 的話：創造商業影響——而非軟體。

軟體是手段而非目的。客戶要的是能讓她更好地完成工作的能力。

• 客戶不在乎計畫或估算
• 你上一次聽到客戶打電話說「感謝你們上一個專案精確的估算和計畫」是什麼時候？——從來沒有
• 客戶要的是可以用來更好、更快或以新方式進行商業活動的能力 (capabilities)

只要你還能從規劃和估算中看到價值，就繼續做，但只做到足以改善工作在團隊中流動的程度。例如，估算時你可以學到很多關於工作項目的知識，但到了某個點，更多的估算不再揭示新知識，那時就該停止了。

Plans are worthless, but planning is everything. > 計畫是無價值的，但規劃是一切。 — Dwight D. Eisenhower

檢驗估算是否增加價值的方法（David J. Anderson 提出）： 如果你認為估算增加了價值，那就做更多估算。它增加價值，對吧？——如果你對這個建議感到猶豫，那就說明估算本身可能並沒有你想像的那麼有價值。

9.5.3 #NoEstimates——你可以完全不要估算嗎？#

（本節由 Torbjorn Gyllebring 撰寫）

很少有人停下來質疑估算；大多數人認為它是理所當然的。質疑這個假設，並找到不使用估算也能有效工作的方法，是 #NoEstimates 的核心問題。

什麼是 #NoEstimates？

在許多情境中，放棄估算並採用替代方式管理工作不僅可能，而且有益。幾種替代策略：

• 機率預測與模擬：研究需求的性質和類型，基於歷史數據使用 Monte Carlo 模擬創建穩健的計畫（Troy Magennis 是這個領域的先驅）
• 平均值的平均法則 (The Law of Average Averages)：「平均而言，一個平均的工作項目需要平均的時間完成。」假設需求足夠相似，或團隊已學會本能地將工作拆分成「合適大小」的塊，你就可以跳過估算，將所有項目視為平均
• 細粒度滴灌資金模型 (Drip-funding Model)：以小塊工作，朝「下一個最有價值的事情」的方向工作。當價值實現或你發現投入超過了價值，就停止投資
• 反轉估算問題：不問「完成這些東西要多久？」，而是問一個更有力的問題：「如果我願意投入這麼多，什麼是可能的？」

為什麼要 #NoEstimates？

• 估算可能驅動失能行為——估算變成承諾、計畫或截止日期
• 消除對估算的需求，就消除了這些問題及其相關的時間和資源成本
• 估算本身不是邪惡的，但它們往往被用於多重目的，且用途會隨時間變化
• 不使用估算會迫使你深入思考估算在流程中扮演的不同功能，邀請你找到更專注的解決方案

#NoEstimates 很難，需要紀律和技能，但機會令人興奮。

進一步閱讀：

• Twitter 上搜索 #NoEstimates
• Neil Killick: “#NoEstimates Part 1 - Doing Scrum Without Estimates”
• Woody Zuill: “If You Found Estimates Bring No Value - What Would You Do?”

9.6 本章總結#

本章探討了規劃與估算的各個面向：

規劃排程：

• 目標是即時規劃 (just in time)——不太早、不太晚
• 事件驅動規劃和訂購點是實現即時規劃的方法
• 更頻繁的規劃讓利害關係人參與更多、建立信任，但也有成本需要平衡
• Disneyland 等候時間是顯示預期交付時間的方式
• 規劃和估算常由你周圍的人要求——可以考慮將工作流程延伸到上游和下游

估算方法：

• 以精確方式估算比相對估算困難得多
• Story Points 和 T-shirt 尺寸是兩種常見的相對估算方式

估算技術：

• 卡片排列法 (A Line of Cards)：快速比較大小
• 規劃撲克 (Planning Poker)：激發討論、消除誤解
• Goldilocks：將工作調整到合適的大小

節奏 (Cadence)：

• 節奏是流程中的自然韻律或心跳
• 迭代式流程有自然的節奏
• Kanban 讓你可以為不同活動（回顧檢視、規劃、展示、回顧）設定適合的節奏，不必綁定到工作的流動

反思：

• 使用看板的團隊看到詳細計畫的需求隨著反饋迴圈的收緊而減少
• 客戶不要計畫和估算——他們要商業能力
• 估算和規劃在揭示新資訊時是有用的
• #NoEstimates 運動探索完全放棄估算，找到不使用估算也能有效工作的方式