極限程式設計 (xp) 是於 1998 年由 smalltalk 社群中的大師級人物 kent beck 首先倡導的。
下面是極限程式設計的有效實踐： 1、
完整團隊
xp 專案的所有參與者（開發人員、客戶、測試人員等）一起工作在乙個開放的場所中，他們是同乙個團隊 的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。 2、
計畫遊戲
計畫是持續的、循序漸進的。每 2 周，開發人員就為下 2 周估算候選特性的成本，而客戶則根據成本和商 務價值來選擇要實現的特性。
3 、客戶測試
作為選擇每個所期望的特性的一部分，客戶可以根據指令碼語言來定義出自動驗收測試來表明該特性可以工 作。
4 、簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想 表達的所有東西，並且包含盡可能少的**。
5 、結對程式設計
所有的產品軟體都是由兩個程式設計師、併排坐在一起在同一臺機器上構建的。
6 、測試驅動開發
編寫單元測試是乙個驗證行為，更是乙個設計行為。同樣，它更是一種編寫文件的行為。編寫單元測試避 免了相當數量的反饋迴圈，尤其是功功能能驗證方面的反饋迴圈。程式設計師以非常短的迴圈週期工作，他們 先增加乙個失敗的測試，然後使之通過。
7 、改進設計
隨時利用重構方法改進已經腐化的**，保持**盡可能的乾淨、具有表達力。
8 、持續整合
團隊總是使系統完整地被整合。乙個人拆入（ check in ）後，其它所有人責任**整合。
9 、集體**所有權
任何結對的程式設計師都可以在任何時候改進任何**。沒有程式設計師對任何乙個特定的模組或技術單獨負責， 每個人都可以參與任何其它方面的開發。
10 、編碼標準
系統中所有的**看起來就好像是被單獨一人編寫的。
11 、隱喻
將整個系統聯絡在一起的全域性檢視；它是系統的未來影像，是它使得所有單獨模組的位置和外觀變得明顯 直觀。如果模組的外觀與整個隱喻不符，那麼你就知道該模組是錯誤的。
12 、可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們儲存精力，他們把專案看作是 馬拉松長跑，而不是全速短跑。
極限程式設計是一組簡單、具體的實踐，這些實踐結合在形成了乙個敏捷開發過程。極限程式設計是一種優良的、通用的軟體開發方法，專案團隊可以拿來直接採用，也可以增加一些實踐，或者對其中的一些實踐進行修改後再採用。
極限程式設計的核心思想在於：從長遠看，早期發現錯誤以及降低複雜度可以節約成本。極限程式設計強調我們將任務 / 系統細分為可以在較短週期解決的乙個個子任務 / 模組，並且強調測試、**質量和及早發現問題。通常，通過乙個個短小的迭代週期，我們就可以獲得乙個個階段性的進展，並且可以及時形成乙個版本供使用者參考，以便及時對使用者可能的需求變更作出響應。
RUP,極限程式設計（xp），敏捷過程簡介
1.rup rational unified process，統一軟體開發過程，統一軟體過程 是乙個物件導向且基於網路的程式開發方 統一過程 rup 是rational軟體公司 rational公司被ibm併購 創造的軟體工程方法。rup描述了如何有效地利用商業的可靠的方法開發和部署軟體，是一種重量...
挑戰極限 極限程式設計中的「極限」
最近，一直在看robert martin的 敏捷軟體開發 原則 模式和實踐 該文中以極限程式設計 xp 來講述敏捷的實踐。看完有關於 xp實踐的部分，對 xp基本的主張和如何去實踐有了乙個大概的了解。但是，一直有個問題在我腦海中，那就是這種開發實踐方式為什麼會被稱為 極限程式設計 看完這部分之後，對...
極限程式設計下的極限測試
極限測試主要由兩部分測試組成 單元測試和驗收測試。單元測試是極限測試中主要採用的測試方法，它具有兩條簡單規則 所有 模組在編碼開始之前必須設計好單元測試用例。在產品發布之前需要通過單元測試。極限測試中的單元測試和普通的單元測試之間最大的區別是 極限測試中的單元測試必須在模組編碼之前就完成設計和生成。...