1. 完整團隊
- 我們希望客戶、管理者和開發人員緊密工作在一起，以了解彼此面臨的問題，並共同解決這些問題。
- 誰是客戶? XP團隊中的客戶是指 “定義產品特性並安排這些特性的優先順序的人或團體”。
2. 使用者故事 (User Stories)
- 對於做計劃而言，了解需求這件事，只需要做到 “能評估它” 就夠了。
- 你必須知道這裡頭存在許多細節，也必須知道細節的大致分類，但不必知道特定的細節(spicifies)。
- 使用者故事(user story)是一種記憶符號，用來輔助正在進行的、關於需求的談話。它是一種做計劃的工具，客戶使用他並根據需求之優先順序及預算代價，來進行實現需求的時程規劃。
3. 短的交付週期
- XP專案每兩周交付一次可以工作的軟體
- Iteration計畫
- 由一組user story組成，經由客戶根據開發人員認定的預算而選出來的user story。
- 開發人員評估 “之前的iteration所完成的工作量” 來為 “這次的iteration設定預算”。
- 一個iteration一旦開始，代表客戶同意在其間部會在修改user story的定義和優先順序
- 發布計畫 - XP團隊通常會建立一個計畫，用以規劃大約6輪的iteration內容，這是所謂的release plan，一次發布內容大約包含3個月的工作。
4. 驗收測試 (Acceptance Tests)
- 可使用客戶指定的驗收測試形式，來記錄有關user story的細節。
- User story的驗收測試是在實作該user story之前或同時開始撰寫的。
- 驗收測試是由業務分析師、品管專家及測試人員於iteration期間撰寫的，驗收測試描述了每個特性(feature)的所有細節，並以此作為 “驗證這些特性是否被正確完成” 的最終依據。
5. 結對程式設計 (Pair Programming)
- 程式碼由結對的程式設計師使用相同的工作平台共同完成的。一個操作鍵盤輸入程式碼，另一個觀看程式碼。兩人頻繁互換角色，團隊成員都應該和其他成員一起工作過。
- 結對程式設計會大力促進知識在團隊裡傳播。非但不會降低程式設計人員的效率，反而會大大減少缺陷發生的機率。
6. 測試驅動開發 (Test-Driven Development, TDD)
- 撰寫所有產品程式碼的目的都是為了使失敗的單元測試能夠通過。
- 當撰寫程式碼是為了使測試案例通過時，那程式碼天生就是可被測試的，非常利於重構
- 此設計具有極弱的耦合性，利於物件導向設計OOD開發
7. 集體所有權
- 每一對程式設計者都具有簽出(check out or pull)任何模組並改善它的權力。每個程式設計師都不對任何一個特定的模組或技術單獨負起責任。
- 每個人都參與介面(GUI)工作，每個人都參與中介軟體的工作，每個人都參與資料庫的工作。
8. 持續整合 (Continuous Integration, CI)
- 程式設計師每天都會簽入(check in or push)他們的程式碼許多次並進行整合。
- 規則很簡單: 只要第一個簽入的人完成簽入即可，而後面所有簽入的人，都要負責程式碼的合併工作(merge)。
- XP團隊使用非鎖死特性(nonblocking)的原始碼控制工具，一位程式設計師可在任何時候簽出任何模組，不必考慮使否有其他人已簽出。
9. 可持續的開發速度
- 軟體專案並非全速短跑，而是馬拉松長跑。
- 團隊必須以一種 “可持續” 的速度前進。
- XP的規則不允許團隊加班工作，如果發布目標近在眼前，才允許加班。
10. 開放的工作空間
- 在充滿積極討論的屋子(war room)裡工作，生產率不會降低，反而倍增。
11. 計畫遊戲
- 計畫遊戲的本質是劃分業務和開發之間得職責。業務人員(客戶)的職責是決定特性的重要性，開發人員的職責是決定實現一個特性所花費的代價。
12. 簡單設計
1. 考慮能夠工作的最簡單的事情。
2. 你不需要它。
3. 一次，並且只有一次。不能容忍重複的程式碼。
13. 重構 (Refactoring)
- 不改變程式碼行為的前提下，進行的改造。
- 每次改造後，都會進行單元測試
- 重構是持續進行的。
- 使唯一不具體、不直接的XP實踐。是將整個系統聯繫在一起的全域視圖。
- 例如，我曾經開發過一個以每秒 60個宇元的速度，將文本（text）輸出到螢幕的系統。以這樣的速度，宇元充滿整個螢幕需要一段時間。所以我們讓產生文本的程式把產生的
文本放到一個矮面區當中。當級衝區滿了的時候，我們把該程式交換到磁片上。當锾衝區快要變空時，我們把該程式交換回來並讓它繼續運行。
- 我們用裝卸卡車拖運垃圾來比喻整個系統。缓衝區是小卡車。螢幕是垃圾場。程式是垃圾製造者。所有的名字相互吻合，這有助於我們從整體上去考量系統。