研究顯示：半數軟體專案延期，三分之一超支。問題不在技術，而在開發方法。XP（Extreme Programming）作為最知名的敏捷方法，結合 Java 等 OO 語言的彈性，能大幅提升專案成功率。
圖 1 - 軟體專案成功與失敗統計
| 價值 | 說明 |
|---|---|
| 溝通 | 專案問題多源於缺乏溝通，XP 讓不溝通成為不可能 |
| 簡單 | 永遠做最簡單能行的事，賭今天不需要複雜方案 |
| 回饋 | 早且頻繁從客戶、團隊、實際使用者獲取具體回饋 |
| 勇氣 | 相信回饋勝過預測、敢於暴露無知、敢於延遲決策、敢於保持簡單 |
圖 2 - XP 十二項實踐
快速制定粗略計畫，隨專案推進持續細化。關鍵原則：客戶做商業決策，開發團隊做技術決策。產出：使用者故事卡、未來兩個釋出版本的粗略計畫。
兩人共同編寫所有生產代碼。優勢：雙人審查設計、知識傳播、雙人熟悉每模組、幾乎不可能同時疏忽測試。研究證實效率優於單人。
所有單元測試通過才能提交代碼，自動化執行（xUnit 框架）。
在不改變功能前提下改善代碼。時機：實現功能前（讓新功能更易加入）與後（簡化剛寫的代碼）。配合測試，重構不會破壞既有功能。
符合四條件：通過所有測試、無重複代碼、明確表達意圖、最少類別與方法。遵循 YAGNI 原則：You Aren't Going to Need It。
任何人可修改任何代碼改進它。人人擁有、人人負責。破壞測試者負責修復。配合持續整合與單元測試運作。
每天整合數次，每次皆跑完所有單元測試。避免「大爆炸整合」帶來的數百種可能錯誤原因，小步整合讓錯誤定位極快。
客戶隨時可用，澄清故事、做商業決策。消除開發等待決策的瓶頸。故事卡是對話的承諾，非靜態需求文件。
盡可能小、但仍具商業價值。盡早交付價值、獲取實際回饋、調整後續計畫。
持續加班殺死效率、製造錯誤、導致人才流失。加班是問題癥狀非解方。
避免無謂爭辯、支援重構與結對輪換。目標：無人能辨識出代碼作者。團隊共識、漸進演進。
提供系統架構共同願景，讓大家理解組件如何交互、新代碼該放哪裡。重點在共同理解，非隱喻之美。
XP 本身不重要，它產生的結果才關鍵。若能更快、更少痛苦地開發出更好軟體，就值得採納。實務經驗已驗證：XP 能改善開頭提到的嚴峻統計數字。
