極限編程

出自 MBA智库百科(https://wiki.mbalib.com/)

極限編程(Extreme Programming，XP)

　　極限編程是由Kent Beck在1996年提出的。Kent仔細地觀察和分析了各種簡化軟體開發的前提條件、可能性以及面臨的困難。1996年3月，Kent提出了新的軟體開發觀念——XP。

　　XP是一種輕量級的、靈巧的軟體開發方法。同時，該方法具有嚴謹和周密的特征。XP的基礎和價值觀是交流、朴素、反饋和勇氣，即任何一個軟體項目都可以從四個方面入手進行改善：加強交流、從簡單做起、尋求反饋和勇於實事求是。XP是一種近似螺旋式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小周期，通過積極的交流、反饋以及其他一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。

　　“Extreme(極限)”是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好。XP所不提倡的，則一概忽略(如開發前期的整體設計等)。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進度。

　　極限編程要求有極限的工作環境、極限的需求、極限的設計、極限的編程和極限的測試。

　　1．極限的工作環境

　　為了在軟體開發過程中最大程度地實現和滿足客戶和開發人員的基本權利和義務，XP要求把工作環境也做得最好。每個參加項目開發的人都將擔任～個角色(項目經理、項目監督人等)並履行相應的權利和義務。所有的人都在同一個開放的開發環境中工作，每周40小時，不提倡加班。

　　2．極限的需求

　　客戶應該是項目開發隊伍中的一員，而不是和開發人員分開的。因為從項目的計划到最後驗收整個過程客戶一直起著很重要的作用。開發人員和客戶一起，把各種需求分割為一個個小的需求模塊，這些模塊又會根據實際情況被組合在一起或者被再次分解成更小的模塊。上述需求模塊都被記錄在一些小卡片(Story Card)上，之後將這些卡片分別分配給程式員們，併在一段時間內(通常不超過3個星期)實現。客戶根據每個模塊的商業價值進行排序，確定開發的優先順序。開發人員要做的是確定每個需求模塊的開發風險。風險高的(通常是因為缺乏類似的經驗)需求模塊將被優先研究、探索和開發。經過開發人員和客戶分別從不同的角度評估每個模塊後，它們被安排在不同的開發周期里，客戶將得到一個儘可能準確的開發計劃。

　　3．極限設計

　　從具體開發過程的角度來看，XP內部的過程是多個基於測試驅動的開發(Test Driven Development)周期。諸如計劃和設計等外層的過程都是圍繞這些測試展開的，每個開發周期都有很多相應的單元測試(Unit Test)。通過這種方式，客戶和開發人員都很容易檢驗所開發的軟體原型是否滿足了用戶的需求。XP提倡簡單的設計(Simple Design)，即針對每個簡單的需求用最簡單的方式進行設計和後續的編程工作。這樣寫出來的程式可以通過所有相關的單元測試。

　　XP強調拋棄那種一攬子詳細設計方式(Big Design Up Front)，因為在這種設計中有很多內容是現在或近期所不需要的。

　　XP還大力提倡設計覆核(Review)、代碼覆核、重整和優化(Re{ectory)。所有的這些過程的目標，歸根到底還是對設計的優化。在這些過程中不斷運行單元測試和功能測試，可以保證經過優化後的系統仍然符合用戶的需求。

　　4．極限編程

　　編程是程式員使用某種程式設計語言編寫程式代碼，並最終得到能夠解決某個問題的程式的過程。XP極其重視編程，提倡配對編程(Pair Programming)，即兩個人一起寫同一段程式，而且代碼所有權是歸於整個開發隊伍(Collective Code Ownership)。程式員在寫程式和優化程式的時候，都要嚴格遵守編程規範。任何人都可以修改其他人寫的程式，修改後要確定新程式能通過單元測試。

　　5．極限測試

　　測試在XP中是很重要的。XP提倡開發人員經常把開發好的模塊整合到一起(Continuous Integration)，並且在每次整合後都進行單元測試。對代碼進行的任何覆核和修改，也都要進行單元測試。發現了錯誤，就要增加相應的測試，因此XP方法不需要錯誤資料庫。

　　除了單元測試之外，XP還要進行整合測試、功能測試、負荷測試和系統測試等。這些測試是XP開發過程中最重要的活動之一，與之相對應的測試文檔也是最終交付給用戶的內容之一。

　　根據極限編程的價值觀，可以總結出使用該方法進行項目開發的時候應該遵循的規則。

　　1、完整團隊

　　XP項目的所有參與者(開發人員、客戶和測試人員等)一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。

　　2、計劃

　　在XP項目中，計劃是持續的、循序漸進的。XP項目組只為下兩周的開發活動估算開發成本，而客戶則根據成本和商業價值來選擇要實現的功能模塊。

　　3、客戶測試

　　客戶測試已經開發好的模塊是否符合客戶的需求。

　　4、簡單設計

　　XP項目團隊應當保持設計方案恰好和當前的系統需求相匹配。它通過了所有的測試，不包含任何重覆，表達出了編寫者想表達的所有東西，並且包含儘可能少的代碼。

　　5、配對編程

　　所有的產品軟體都是由兩個程式員併排坐在一起共同開發的。

　　6、測試驅動開發

　　編寫單元測試是一個驗證行為，更是～個設計行為。同樣，它也是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋迴圈，尤其是功能驗證方面的反饋迴圈。

　　7、改進設計

　　隨時利用重構方法改進已經過時的代碼，保持代碼儘可能的乾凈、具有表達力。

　　8、持續集成

　　XP團隊總是對現有模塊進行集成。

　　9、代碼所有權歸集體所有

　　任何配對的程式員都可以在任何時候改進任何代碼。沒有程式員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其他方面的開發。

　　10、編碼標準

　　制定編碼標準，並且整個團隊都必須遵守該編碼標準。使系統中所有的代碼看起來就好像是一個人編寫的。

　　11、可持續的速度

　　XP團隊成員以能夠長期維持的速度努力工作，保存精力，把項目看做是馬拉松長跑，而不是全速短跑。

李彤，王煒，鬱湧編著,軟體工程概論,科學出版社,2012.02,第186頁