什麼是極限編程 (Extreme Programming, XP)？
Extreme Programming（極限編程，簡稱 XP）由 Kent Beck 於 1996 年提出。Kent Beck 在 90 年代初與 Ward Cunningham 合作時，持續探索更簡單有效的軟體開發方法。1996 年 3 月，他在為 DaimlerChrysler 的專案中正式引入 XP。XP 是一種輕量級、敏捷且嚴謹的軟體開發方法論，核心價值為 溝通、簡單、回饋、勇氣，旨在從四個面向改善專案：加強溝通、從簡單做起、尋求回饋、勇於面對現實。
XP 的軟體開發觀
軟體開發包含四大活動：需求、設計、編程、測試。
- 需求：不僅是用戶需求，包含專案中遇到的所有需求（如：專案解決什麼問題、測試資料為何）。需頻繁與客戶、專案經理溝通釐清。
- 設計：編碼前需有計劃與架構，否則易陷入混亂。
- 編程：若截止日程式無法運行或不符需求，無法交付價值。
- 測試：目的是知道何時「完成」。聰明做法是先寫測試，即時掌握完成度。
客戶與開發人員的權利與義務
| 角色 | 權利 / 義務 |
|---|
| 客戶 | 定義商業優先級、制定整體計畫、每週最大化投資報酬、透過驗收測試掌握進度、隨時調整需求/優先級避免高昂返工、可隨時終止專案（已完成功能合格、未完成工作易交接） |
| 開發人員 | 清楚知道做什麼與優先順序、高效工作、遇困難能獲協助、持續評估與重估、主動承擔而非被動接受、每週 40 小時不加班 |
為何稱為「極限」？
相較傳統開發，XP 將列出的每個實務做到極致、做到最好；不提倡的（如前期整體大設計）一概忽略。嚴格執行 XP 的專案，開發過程平穩、高效、快速，能達到每週 40 小時不加班且不延期。
XP 的五大極限面向
1. 極限的工作環境
- 全員同地開放空間辦公，牆面貼 Story Card、CRC Card、白板討論。
- 每日晨會站立開會，每週 40 小時拒絕加班。
- 提供茶點、下班可共玩遊戲，營造心理安全感。
2. 極限的需求
- 客戶是團隊一員，共同將需求拆解為 User Story（如「計算年級總人數：各班人數累加」）。
- Story 記錄於卡片，依商業價值設定優先級；開發端評估風險，高風險優先探索。
- 每個迭代（通常 ≤ 3 週）交付可用系統，客戶定義驗收測試。
3. 極限的設計
- 核心為 測試驅動開發 (TDD) 迭代：先寫失敗的單元測試，再實作通過測試的最簡程式碼。
- 提倡 簡單設計：僅滿足當下需求，拒絕 Big Design Up Front。
- 持續進行 設計複核、程式碼複核、重構，並以測試保護回歸。
4. 極限的編程
- 配對編程：兩人共寫同一段代碼，代碼集體擁有權。
- 嚴守編碼規範，任何人可修改他人代碼，修改後必須通過單元測試。
5. 極限的測試
- 編碼前先寫單元測試；持續整合後必跑測試；修改代碼必跑測試；發現 Bug 增加測試（故無需 Bug 資料庫）。
- 包含單元、整合、功能、負載、系統測試，皆為重要交付文件。
XP 核心慣例與規則
1. 專案團隊
所有貢獻者皆為團隊一員。必要角色：客戶（最好是真實用戶）、程式設計師、測試人員、分析師、教練、專案經理。鼓勵跨角色貢獻，平等互補。
2. 計劃遊戲、驗收測試、小規模發布
- 發布計劃：客戶闡述需求，開發估算成本/風險，客戶依重要性訂大略計畫，過程中持續調整。
- 迭代計劃：每 2-3 週一個迭代，將需求拆解為小任務並估算，經驗累積下估算越準。每迭代結束客戶可見可用系統，無「快完成 90%」的模糊說法。
- 驗收測試：客戶定義，開發視同單元測試般重視，最好自動化。
- 頻繁小規模發布：每迭代發布，甚至每日/每次整合發布，品質由測試保證。
3. 簡單設計、配對編程、測試驅動、重構
- 簡單設計：用最簡單方式滿足當下需求並通過測試，設計過程貫穿專案始終，螺旋式演進。
- 配對編程：雙人同機，代碼至少被另一人複核，提高品質與知識流動。研究顯示 90% 程式設計師兩個月後認同效率更高。
- 測試驅動開發：測試隨專案積累，全隊共同維護。Check-in 前跑全測試，發現 Bug 即加測試，接手任務跑通測試即證明未破壞系統。
- 重構：消除重複、提高復用性，隨時隨地進行，配合測試保護。
4. 頻繁整合、集體代碼擁有權、編碼規範
- 頻繁整合：每完成一個 User Story 整合一次，跑測試並發布新版本，客戶隨時掌握進度。
- 集體代碼擁有權：人人有權閱讀、修改、重構任何代碼，修改後跑測試防崩潰。
- 編碼規範：統一風格，代碼如出一人之手，支撐集體擁有權。
5. 系統隱喻、不加班
- 隱喻：用生動比喻統一團隊對系統理解（如搜尋引擎＝「一群蜘蛛在網上捕捉內容帶回巢穴」）。
- 不加班：加班代表估算失誤，教練應與客戶調整計畫/資源。
XP 關鍵概念速查
| 概念 | 說明 |
|---|
| User Story | 客戶撰寫的小需求故事，幾天可完成，可隨時新增/修改 |
| Story Estimates / Velocity | 團隊估算每個 Story，依實際速度反覆校準 |
| Release Plan / Scope | 決定每次發布包含哪些 Story |
| Iteration / Iteration Plan | 1-3 週開發週期，客戶選最高價值 Story 進入 |
| The Seed | 第一個迭代交付的系統，實現最重要的幾個 Story |
| Continuous Integration | 將完成的 Story 模組逐步組裝 |
| 驗收測試 | 客戶定義測試案例，開發自動化執行 |
| Unit Test | 程式設計師編碼前先寫測試 |
| Refactoring | 去除冗餘、提高復用性與彈性 |
結語
XP 成功關鍵在重視客戶回饋——開發目的是滿足客戶需求。XP 讓團隊自信面對需求變化，強調團隊合作（經理、客戶、開發同為一員），透過充分溝通與簡單有效的方式開發高品質軟體。設計簡單高效，程式設計師透過測試獲取回饋並根據變化調整代碼，儘早交付。XP 如智力拼圖，單看碎片無意義，拼湊完成卻呈現完美畫面。
