極限編程（eXtreme Programming，簡稱XP）是一種輕量級、高效、低風險、柔性、可預測的、科學的軟件開發方法，其特性包含在12個最佳實踐中。
1. 計劃遊戲 ( Planning Game )
（1）快速制定計劃、隨着細節的不斷變化而完善；
（2）詳解：要求結合項目進展和技術情況，確定下一階段要開發與發佈的系統範圍。當計劃趕不上實際變化時就應更新計劃。
2. 小型發佈 ( Small Release )
（1）系統的設計要能夠儘可能早地交付；
（2）詳解：強調在非常短的週期內以遞增的方式發佈新版本，從而可以很容易地估計每個迭代週期的進度，便於控制工作量和風險；同時，也可以及時處理用戶的反饋。
3. 系統隱喻( System Metaphor )
（1）找到合適的比喻傳達信息；
（2）詳解：通過隱喻來描述系統如何運作、新的功能以何種方式加入到系統。它通常包含了一些可以參照和比較的類和設計模式。
4. 簡單設計( Simple Design )
（1）只處理當前的需求使設計保持簡單；
（2）詳解：任何時候都應當將系統設計的儘可能簡單。不必要的複雜性一旦被發現就馬上去掉。
5. 測試驅動( Test-driven )
（1）先寫測試代碼再編寫程序；
（2）詳解：程序員不斷地編寫單元測試，在這些測試能夠準確無誤地運行的情況下開發纔可以繼續。
6. 重構( Refactoring )
（1）重新審視需求和設計，重新明確地描述它們，以符合新的和現有的需求；
（2）詳解：代碼重構是指在不改變系統行爲的前提下，重新調整、優化系統的內部結構以減少複雜性、消除冗餘、增加靈活性和提高性能。
7. 結對編程( Pair Programming )
（1）由兩個程序員在同一臺電腦上共同編寫解決同一問題的代碼。
（2）詳解：通常一個人負責寫編碼，而另一個負責保證代碼的正確性與可讀性。
8. 集體所有權（Collective Ownership）
（1）任何人在任何時候都可以在系統中的任何位置更改任何代碼。
（2）詳解：每個成員都有更改代碼的權利，所有的人對於全部代碼負責。
9. 持續集成( Continuous Integration )
（1）可以按日甚至按小時爲客戶提供可運行的版本；
（2）提倡在一天中集成系統多次，而且隨着需求的改變，要不斷的進行迴歸測試，避免了一次系統集成的惡夢。
10. 每週工作40小時 ( 40-hour Week )
（1）要求項目團隊人員每週工作時間不能超過40小時，加班不得連續超過兩週，否則反而會影響生產率。
11. 現場客戶( On-site Customer )
（1）在團隊中加入一位真正的、起作用的用戶，他將全職負責回答問題。
（2）詳解：要求至少有一名實際的客戶代表在整個項目開發週期在現場負責確定需求、回答團隊問題以及編寫功能驗收測試。
12. 編碼標準( Code Standards )
（1）強調通過指定嚴格的代碼規範來進行溝通，儘可能減少不必要的文檔。
轉載至http://www.open-open.com/lib/view/open1337605915886.html