XP 能容納常見的合約形式，只需稍作修改。特別是固定價格／固定範圍的合約，在用規劃遊戲運作時，會變成固定價格／固定日期／大致固定範圍的合約。

固定價格#

大家在「用極限方式跑固定價格合約」上遇到的麻煩似乎最多。既然你要玩規劃遊戲，怎麼可能做固定價格／固定日期／固定範圍的合約？

你最後會得到的是：固定價格／固定日期／範圍大致可變的合約。

作者參與過的每一個「價格與範圍都固定」的專案，結束時雙方都說：「需求當初就不清楚。」

典型的固定價格＋固定範圍專案，會把雙方拉往完全相反的方向：供應商想做得越少越好，客戶想要求得越多越好。在這股張力中，雙方都想要專案成功，於是各自從主要目標上退讓——但張力永遠存在。

在 XP 中，這段關係發生了微妙卻重要的改變：初始範圍只是一個「舉例」。

「舉例來說，以 500 萬德國馬克，我們認為能在 12 個月內產出以下這些故事。」

客戶要決定的是：這些故事值不值 500 萬馬克。

如果團隊最後產出的就是那些初始故事，很好。但更可能的是，客戶會用更有價值的故事替換掉其中一些——沒有人會抱怨自己拿到更有價值的東西；每個人都會抱怨自己拿到了當初要求的東西，卻不是他們現在才知道自己想要的東西。

XP 團隊提供的與其說是固定價格／日期／範圍，不如說更像一份訂閱：團隊會為客戶以最高速工作一段特定時間，並追蹤客戶的學習；每次迭代開始時，客戶都有一次正式的機會改變方向、引入全新的故事。

小發布帶來的第二個差異#

團隊一旦簽下 12 個月份量的故事，就會與客戶玩規劃遊戲決定第一次發布的範圍。所以一份 12 個月的合約，可能在三、四個月後就把系統送上線，此後每月或每兩月發布一次。

增量交付內建了兩項好處：

• 如果進度比初估慢，或商業條件讓整個專案變得沒有意義，客戶可以終止合約
• 它給了客戶自然的時點去改變專案方向

委外（Outsourcing）#

在典型的委外開發中，客戶最後拿到一堆自己不知道怎麼維護的程式碼。他們有三個選擇：

• 自己來——讓系統的後續演化慢到爬行
• 僱用原供應商繼續演化系統——但原供應商能收他們很多錢
• 僱用另一家不熟悉這份程式碼的供應商

如果你真的想，XP 也做得到委外：團隊可以搬去和客戶一起住，或客戶搬來和團隊一起住，雙方玩規劃遊戲決定要做什麼；合約結束時團隊離開，把程式碼留給客戶。

某種意義上，這比典型的委外協議更好：

• 客戶擁有單元測試與功能測試，能確保自己所做的任何改動不會弄壞既有功能
• 客戶有人在程式設計師肩後看著，所以對系統內部有一定概念
• 客戶能沿途掌舵開發方向

內包（Insourcing）#

你大概看得出作者對委外並不熱衷：委外那種「砰」的一聲交付，違反了增量式變更原則。

XP 能提供委外的一個小變體：逐步把團隊成員換成客戶方的技術人員——作者稱之為「內包（insourcing）」。

它保有委外的許多優點，例如讓供應商把詳細的技術知識帶給客戶；而由於責任是逐步轉移的，內包不會讓客戶承擔「繼承一支自己撐不住的程式」的風險。

隨著成員來去，團隊整體必然時快時慢。藉由持續量測實際達成的生產力，團隊能調整自己在規劃遊戲的迭代中要承諾完成多少；當專家離開、由較無經驗的人接替時，團隊可以重新估算剩餘的故事。

計時計料（Time and Materials）#

在計時計料合約中，XP 團隊按小時或按天計費，流程其餘部分照常運作。

• 供應商想投入盡可能多的人、盡可能長的時間，以最大化營收；而且會被誘惑讓團隊加班，以提高每月營收
• 客戶想用盡可能少的人、在盡可能短的時間內，完成盡可能多的功能

供應商與客戶之間良好的關係能讓 T&M 運作，但底層的張力永遠存在。

完工獎金與遲交罰則#

要在固定價格或 T&M 中對齊供應商與客戶的利益，一個絕佳做法是為專案的準時完成提供獎金。

某種意義上，這對 XP 團隊而言是一場「傻子才不下的注」——規劃遊戲給予的控制力，讓他們極可能拿得到這筆獎金。

完工獎金的邪惡雙胞胎是遲交罰則。同樣地，規劃遊戲讓 XP 團隊在同意罰則時佔有優勢：團隊相當確定自己能準時完成系統，因此不太可能需要付錢。

但獎金與罰則條款與 XP 併用時，有一點要當心：規劃遊戲必然導致專案範圍發生變化。

一個真心想坑供應商的客戶，可以說：「四月一號了，你還沒做完原始合約裡的所有故事。沒有獎金，而且你最好開始付罰款。」——而他們甚至可以在系統已經成功上線的情況下這麼說。

一般而言這不會是問題：如果是聖誕節、樹下有禮物，客戶不太可能去清點它們是否正好是原始那封給聖誕老人的信上列的禮物——尤其當那些替換本來就是客戶自己做的。

老實說，作者會對「和那種客戶簽任何一種合約」都相當警戒。

提前終止#

XP 的特色之一，是客戶能沿途精確看見自己拿到了什麼。那如果他們在進行到一半時發現整個專案已經不再合理呢？

可以考慮加入一條條款，讓客戶能終止專案並按比例支付總成本的份額——或許再加上一筆補償金，補償供應商必須在短時間內另尋合約。

框架開發#

如何用 XP 開發框架？如果規則之一是「刪掉任何目前沒被使用的功能」，那你最後不就把整個框架都刪掉了嗎？

在 XP 專案裡，你絕不會花六個月造框架、然後才開始用它；你也不會把「框架團隊」與「應用團隊」分開。

在 XP 中我們建造應用程式。 如果經過幾年不斷精煉之後，某些抽象開始顯得普遍有用，那才是開始思考如何讓它們更廣泛可用的時機。

如果專案的目的本來就是開發一個供外部使用的框架，你仍然可以用 XP：

• 規劃遊戲中的業務端，由一位真的建造過「該框架所要支援的那類應用」的程式設計師擔任
• 框架的功能轉化為故事

一旦框架被部署到團隊之外，你就必須對「會改動可見介面」的重構採取更保守的態度。

棄用（deprecation）——給客戶一定的預告期，告知某個功能即將消失——讓你能繼續演化框架的介面，代價是讓兩套介面並存一段時間。

盒裝產品#

你也可以把 XP 用於盒裝軟體。規劃遊戲中的業務端由行銷部門擔任——由他們指認市場想要哪些故事、每個故事需要多少、以及故事該以什麼順序實作。

• 遊戲公司僱用遊戲高手來試玩測試軟體
• 金融交易軟體公司僱用交易員
• 如果你在做排版程式，不找一位專家排版師加入團隊就是瘋了

而那正是你會希望由他來決定「故事 A 還是故事 B 該延到下一次發布」的人。