軟體開發交不出東西，也交不出價值。這種失敗造成巨大的經濟與人力衝擊。我們需要一種新的軟體開發方式。
風險的八種樣貌#
- 時程延誤——交付日到了，你得告訴客戶：軟體還要再六個月才會好。
- 專案被取消——在數次延誤之後，專案根本沒上線就被砍掉。
- 系統腐壞——軟體成功上線，但幾年後變更成本或缺陷率高到系統非換不可。
- 缺陷率過高——軟體上線了，但缺陷多到根本沒人用。
- 業務被誤解——軟體上線了，但它沒有解決當初提出的業務問題。
- 業務已改變——軟體上線了，但它要解決的業務問題，六個月前就被另一個更急迫的問題取代了。
- 假性功能豐富——軟體塞滿了一堆看似有趣的功能，每一個寫起來都很好玩，但沒有一個替客戶多賺到錢。
- 人員流動——兩年後，專案上所有優秀的程式設計師都開始厭惡這支程式，然後離職。
XP 如何逐一回應這些風險#
XP 是一套在開發流程的所有層級上處理風險的軟體開發紀律。它同時也生產力極高、產出高品質軟體，而且執行起來很有趣。
- 時程延誤——XP 要求短發布週期（最多幾個月），讓任何延誤的範圍都受限。發布之內用 1 至 4 週的迭代交付客戶要求的功能，取得細緻的進度回饋；迭代之內用 1 至 3 天的任務來規劃，讓團隊在迭代進行中就能解決問題。最後，XP 要求先實作最高優先的功能，因此任何被擠出發布的功能，價值都比較低。
- 專案被取消——XP 要求客戶挑出業務上最合理的最小發布，這樣上線前能出錯的東西比較少，而軟體的價值最大。
- 系統腐壞——XP 建立並維護一整套完整的測試，每次變更後都重跑（一天數次），確保品質基線。XP 永遠讓系統維持在最佳狀態，不允許髒東西（cruft）累積。
- 缺陷率過高——XP 從兩個視角測試：程式設計師逐函式寫測試，客戶逐程式功能寫測試。
- 業務被誤解——XP 要求客戶成為團隊不可分割的一員。專案規格在開發過程中持續被精煉，讓客戶與團隊的學習成果能反映到軟體裡。
- 業務已改變——XP 縮短發布週期，單一發布的開發期間變化就比較少。發布進行中，客戶隨時歡迎用新功能替換掉尚未完成的功能——團隊甚至不會察覺自己做的是剛發現的需求，還是幾年前就定義好的功能。
- 假性功能豐富——XP 堅持只處理最高優先的任務。
- 人員流動——XP 要求程式設計師為自己工作的估算與完成負責，給他們實際耗時的回饋以改進估算，並尊重那些估算。誰能做估算、誰能改估算，規則清楚。因此程式設計師比較不會因為被要求做明顯不可能的事而挫折。
XP 也鼓勵團隊成員之間的人際接觸，減少那種常常是工作不滿核心的孤獨感。此外，XP 內建了一套明確的人員流動模型：新成員被鼓勵逐步承擔越來越多責任，過程中由彼此與既有程式設計師協助。
我們的任務#
如果我們接受「專案風險」就是要解決的問題，那該去哪裡找解法？
我們要做的是發明一種能處理這些風險的軟體開發風格，並且：
- 盡可能清楚地把這套紀律傳達給程式設計師、管理者與客戶
- 訂出因地制宜的調整指引——也就是講清楚什麼是固定的、什麼是可變的
本書第一、二部正是在做這件事：逐步走過「創造一種新開發風格」這個問題的各個面向，然後解決它。我們會從一組基本假設出發，推導出解法，並由這些解法決定軟體開發中各項活動——規劃、測試、開發、設計、部署——該如何進行。