我們的規劃方式是：快速做出一份整體計畫，然後在越來越短的時間視野上——年、月、週、日——一層層精煉它。計畫要做得又快又便宜，這樣我們必須改變它時才不會有太大慣性。

規劃的目的#

規劃是「猜測與客戶一起開發一套軟體會是什麼樣子」的過程。它的目的包括：

• 把團隊凝聚起來
• 決定範圍與優先序
• 估算成本與時程
• 讓所有相關者相信這套系統真的做得出來
• 提供一個回饋的基準

影響規劃的原則#

• 只做下一個視野所需的規劃——在任何細節層級上，都只規劃到下一個視野（下次發布、下次迭代結束）。這不表示你不能做長程規劃，你可以——只是不要有太多細節。你可以把這次發布規劃得非常細，而用一組條列涵蓋接下來（提議中的）五次發布。這樣一份草圖，比起把六次發布全部詳細規劃，損失並不多。
• 被接受的責任——責任只能被接受，不能被給予。這意味著 XP 中不存在由上而下的規劃。管理者不能走到團隊面前說：「這是我們要做的一堆事，這是它會花的時間。」專案經理必須請團隊承擔完成這些工作的責任，然後傾聽答案。
• 負責實作的人才有資格估算——如果團隊承擔了完成某事的責任，就由團隊說要花多久；如果團隊中某個人承擔了責任，就由那個人說要花多久。
• 忽略各部分之間的相依性——規劃時就當作開發的各個部分可以任意調換順序。只要你小心地先實作最高業務優先序的東西，這條簡單規則就能讓你免於麻煩。（「咖啡多少錢？」「咖啡 25 分，續杯免費。」「那給我續杯就好。」——這種事並不常發生。）
• 區分「為排優先序而規劃」與「為開發而規劃」——要意識到規劃的目的。為了讓客戶排優先序的規劃，所需細節遠少於為了實作的規劃——後者你需要具體的測試案例。

規劃遊戲#

XP 的規劃刻意把規劃流程抽象成兩位參與者——業務端（Business）與開發端（Development）。這有助於移除計畫討論中某些沒有幫助的情緒熱度。

與其說「Joe，你這白痴，你答應我週五給我的」，規劃遊戲說的是：「開發端學到了一些東西。它需要業務端協助，以最好的方式回應。」

當然，一組簡單規則不可能消除情緒，也無意如此。規則的存在是為了提醒每個人自己希望怎麼行動，並在事情不順時提供一個共同的參照點。

為什麼需要規則#

業務端往往不喜歡開發端。需要系統的人與建造系統的人之間的關係緊繃到一個地步，常常像是幾百年的世仇：不信任、指控、微妙而迂迴的權謀，樣樣俱全。在這種環境裡，你開發不出像樣的軟體。

如果這不是你的環境，恭喜你。最好的環境是相互信任：雙方互相尊重，雙方都相信對方心裡在乎自己的最佳利益、也在乎更大群體的利益，雙方都願意讓對方做好自己的工作，結合兩邊的技能、經驗與觀點。

但你無法靠立法造出這種關係。你不能只是說：「我們知道我們搞砸了，我們非常抱歉，不會再發生了。從午餐後開始，我們用完全不同的方式合作吧。」——世界和人都不是那樣運作的。壓力之下，人們會退回到早先的行為，無論那行為過去的成效有多糟。

通往相互尊重的路上，需要的是一組治理這段關係如何進行的規則：誰能做哪些決定、決定何時被做出、這些決定如何被記錄。

但永遠別忘記：遊戲規則只是輔助，是通往你真正想要的客戶關係的一步。 規則永遠捕捉不到真實人際關係的微妙、彈性與熱情。

然而沒有任何規則，你根本無從開始改善現況。規則就位、關係開始改善之後，你才能開始修改規則讓開發更順暢；而最終，一旦它們成為習慣，你可以把規則整個拋掉。

不過首先，你得先學會照規則玩。

遊戲的目標與策略#

• 目標——最大化團隊產出之軟體的價值。從軟體的價值中，你必須扣掉開發成本，以及開發過程中承擔的風險。
• 策略——投入盡可能少的資源，盡可能快地把最有價值的功能放進正式環境，但只在搭配「為降低風險而設計的程式設計與設計策略」的前提下進行。借由第一套系統帶來的技術與業務教訓，業務端會清楚看見現在什麼才是最有價值的功能，團隊再迅速把它送上線。如此循環。

棋子與玩家#

棋子是故事卡（story cards）。

玩家有兩位：

• 開發端——所有將負責實作系統的人的集合
• 業務端——所有將決定系統該做什麼的人的集合

有時候誰扮演業務端一目了然：如果是一位債券交易員出錢訂製軟體，那他就是業務端，由他決定什麼最重要、該先做。

那如果你在做的是大眾市場的盒裝產品呢？誰是業務端？

業務端需要對範圍、優先序與發布內容做決定——這些通常由行銷部門做出。如果他們夠聰明，會用三種來源支撐自己的決定：產品的真實使用者、焦點團體、業務人員。

作者見過最好的業務端玩家，有些是專家使用者。例如他曾參與一套共同基金的客服系統，業務端主要由一位客服主管擔任——她從基層做起，在前一代系統上工作了很多很多年，熟知每個細節。她起初有時難以區分「新系統該做什麼」與「舊系統做了什麼」，但與故事共事一段時間後，她學會了。

遊戲的三個階段#

• 探索（Exploration）——找出系統可以做哪些新東西
• 承諾（Commitment）——決定接下來要追求所有可能需求中的哪個子集
• 掌舵（Steer）——在現實形塑計畫的同時引導開發

各階段的動作通常在該階段進行，但並不嚴格。例如你在掌舵階段仍會寫新故事。這些階段也是循環的——掌舵一陣子之後，你會需要回到探索。

探索階段#

目的是讓雙方玩家都對「系統最終該做的所有事」有個概念。有三個動作：

• 寫一個故事——業務端寫下描述「系統需要做某件事」的故事。故事寫在索引卡上，包含一個名稱與描述其目的的一小段文字。
• 估算一個故事——開發端估算這個故事要多久才實作得完。如果開發端估不出來，可以請業務端釐清或拆分故事。
• 拆分一個故事——如果開發端估不了整個故事，或業務端意識到故事的一部分比其餘更重要，業務端可以把它拆成兩個以上的故事。

在你承諾一份時程之前，你會先量出理想時間與日曆時間之間的比值。

承諾階段#

目的是讓業務端選定下次發布的範圍與日期，並讓開發端有信心地承諾交付。有四個動作：

• 依價值排序（業務端）——把故事分成三堆：（1）沒有它系統就無法運作的；（2）比較不是必要、但提供顯著業務價值的；（3）有了會很好的。
• 依風險排序（開發端）——把故事分成三堆：（1）能精確估算的；（2）能估得相當好的；（3）完全估不出來的。
• 設定速度（開發端）——告訴業務端團隊每個日曆月能寫出多少理想工程時間。
• 選擇範圍（業務端）——選出這次發布要包含的卡片。做法有二：設定工程完成日期，再依估算與專案速度選卡；或是先選卡，再計算出日期。

掌舵階段#

目的是根據雙方學到的東西更新計畫。有四個動作：

• 迭代（Iteration）——每次迭代開始時（每一到三週），業務端挑出一次迭代份量、最有價值的故事來實作。第一次迭代的故事必須產出一套能端到端跑起來的系統，無論多麼胚胎階段。
• 復原（Recovery）——如果開發端意識到自己高估了速度，可以請業務端根據新的速度與估算，決定當前發布中最有價值、要保留下來的那組故事。
• 新故事（New story）——如果業務端在發布開發途中意識到需要一個新故事，可以寫下來。開發端估算它，然後業務端從剩餘計畫中移除等量估算的故事，把新故事插進去。
• 重新估算（Reestimate）——如果開發端覺得計畫已經無法準確反映開發現況，可以重估所有剩餘故事並重新設定速度。

只有一週怎麼規劃#

這是做固定價格投標的團隊常遇到的處境：你收到一份標案，只有一週可以回應。你沒有足夠時間寫出一整套「每個都能估算與測試」的故事，也沒有時間寫原型好從經驗中估算。

如果你沒有寫過類似系統的經驗，那你根本沒資格回應固定價格的標案。

一旦拿到合約，你該做的第一件事，就是回頭把規劃遊戲的開場階段玩一遍，好對「自己是否有能力依約交付」做一次立即的交叉檢核。