Extreme Programming（極限編程，簡稱XP）是由Kent Beck在1996年提出的。Kent Beck在九十年代初
期與Ward Cunningham共事時，就一直共同探索著新的軟件開發方法，希望能使軟件開發更加簡單而有
效。Kent仔細地觀察和分析了各種簡化軟件開發的前提條件、可能行以及面臨的困難。1996年三月，
Kent終于在為DaimlerChrysler所做的一個項目中引入了新的軟件開發觀念——XP。

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

?

什么是軟件開發

軟件開發的內容是：需求、設計、編程和測試！
需求：不僅僅是用戶需求，應該是開發中遇到的所有的需求。比如，你首先要知道做這個項目是為了解
決什么問題；測試案例中應該輸入什么數據……為了清楚地知道這些需求，你經常要和客戶、項目經理
等交流。
設計：編碼前，肯定有個計劃告訴你要做什么，結構是怎樣等等。你一定要按照這個來做，否則可能會
一團糟。
編程：如果在項目截止日，你的程序不能跑起來或達不到客戶的要求，你就拿不到錢。
測試：目的是讓你知道，什么時候算是完成了。如果你聰明，你就應該先寫測試，這樣可以及時知道你
是否真地完成了。否則，你經常會不知道，到底有哪些功能是真正完成了，離預期目標還差多遠。

軟件開發中，客戶和開發人員都有自己的基本權利和義務。
客戶：
?? 定義每個用戶需求的商業優先級；
?? 制訂總體計劃，包括用多少投資、經過多長時間、達到什么目的；
?? 在項目開發過程中的每個工作周，都能讓投資獲得最大的收益；
?? 通過重復運行你所指定的功能測試，準確地掌握項目進展情況；
?? 能隨時改變需求、功能或優先級，同時避免昂貴的再投資；能夠根據各種變化及時調整項目計劃；
?? 能夠隨時取消項目；項目取消時，以前的開發工作不是一堆垃圾，已開發完的功能是合乎要求的，
正在進行或未完成的的工作則應該是不難接手的。
開發人員：
?? 知道要做什么，以及要優先做什么；
?? 工作有效率；
?? 有問題或困難時，能得到客戶、同事、上級的回答或幫助；
?? 對工作做評估，并根據周圍情況的變化及時重新評估；
?? 積極承擔工作，而不是消極接受分配；
?? 一周40小時工作制，不加班。

這就是軟件開發，除此之外再還有其它要關心的問題！

?

靈巧的輕量級軟件開發方法

一套軟件開發方法是由一系列與開發相關的規則、規范和慣例。重量級的開發方法嚴格定義了許多的規
則、流程和相關的文檔工作。靈巧的輕量級開發方法，其規則和文檔相對較少，流程更加靈活，實施起
來相對較容易。

在軟件工程概念出現以前，程序員們按照自己喜歡的方式開發軟件。程序的質量很難控制，調試程序很
繁瑣，程序員之間也很難讀懂對方寫的代碼。1968年，Edsger Dijkstra給CACM寫了一封題為GOTO?
Statement Considered Harmful 的信，軟件工程的概念由此誕生。程序員們開始摒棄以前的做法，轉
而使用更系統、更嚴格的開發方法。為了使控制軟件開發和控制其它產品生產一樣嚴格，人們陸續制定
了很多規則和做法，發明了很多軟件工程方法，軟件質量開始得到大幅度提高。隨著遇到的問題更多，
規則和流程也越來越精細和復雜。

到了今天，在實際開發過程中，很多規則已經難于遵循，很多流程復雜而難于理解，很多項目中文檔的
制作過程正在失去控制。人們試圖提出更全面更好的一攬子方案，或者寄希望于更復雜的、功能更強大
的輔助開發工具（Case Tools），但總是不能成功，而且開發規范和流程變得越來越復雜和難以實施。
為了趕進度，程序員們經常跳過一些指定的流程，很少人能全面遵循那些重量級開發方法。

失敗的原因很簡單，這個世界沒有萬能藥。因此，一些人提出，將重量級開發方法中的規則和流程進行
刪減、重整和優化，這樣就產生了很多適應不同需要的輕量級流程。在這些流程中，合乎實際需要的規
則被保留下來，不必要的復雜化開發的規被拋棄。而且，和傳統的開發方法相比，輕量級流程不再象流
水生產線，而是更加靈活。

Extreme Programming（XP）就是這樣一種靈巧的輕量級軟件開發方法。

?

為什么稱為“Extreme”（極限）?

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

?

XP的軟件開發是什么樣

1 極限的工作環境

為了在軟件開發過程中最大程度地實現和滿足客戶和開發人員的基本權利和義務，XP要求把工作環境也
做得最好。每個參加項目開發的人都將擔任一個角色（項目經理、項目監督人等等）并履行相應的權利
和義務。所有的人都在同一個開放的開發環境中工作，最好是所有人在同一個大房子中工作，還有茶點
供應；每周40小時，不提倡加班；每天早晨，所有人一起站著開個短會；墻上有一些大白板，所有的
Story卡、CRC卡等都貼在上面，討論問題的時候可以在上面寫寫畫畫；下班后大家可以一起玩電腦游
戲……。

2 極限的需求

客戶應該是項目開發隊伍中的一員，而不是和開發人員分開的；因為從項目的計劃到最后驗收，客戶一
直起著很重要的作用。開發人員和客戶一起，把各種需求變成一個個小的需求模塊（User Story），例
如“計算年級的總人數，就是把該年級所有班的人數累加。”；這些模塊又會根據實際情況被組合在一
起或者被分解成更小的模塊；它們都被記錄在一些小卡片（Story Card）上，之后分別被程序員們在各
個小的周期開發中（Iteration，通常不超過3個星期）實現；客戶根據每個模塊的商業價值來指定它們
的優先級；開發人員要做的是確定每個需求模塊的開發風險，風險高的（通常是因為缺乏類似的經驗）
需求模塊將被優先研究、探索和開發；經過開發人員和客戶分別從不同的角度評估每個模塊后，它們被
安排在不同的開發周期里，客戶將得到一個盡可能準確的開發計劃；客戶為每個需求模塊指定驗收測試
（功能測試）。

每發布一次開發的軟件（經過一個開發周期），用戶都能得到一個可以開始使用的系統，這個系統全面
實現了相應的計劃中的所有需求。而在一些傳統的開發模式中，無論什么功能，用戶都要等到所有開發
完成后才能開始使用。?

3 極限的設計?

從具體開發的角度來看，XP內層的過程是一個個基于測試驅動的開發（Test Driven Development）周
期，諸如計劃和設計等外層的過程都是圍繞這些展開的。每個開發周期都有很多相應的單元測試
（Unit Test）。剛開始，因為什么都沒有實現，所以所有的單元測試都是失敗的；隨著一個個小的需
求模塊的完成，通過的單元測試也越來越多。通過這種方式，客戶和開發人員都很容易檢驗，是否履行
了對客戶的承諾。XP提倡對于簡單的設計（Simple Design），就是用最簡單的方式，使得為每個簡單
的需求寫出來的程序可以通過所有相關的單元測試。XP強調拋棄那種一攬子詳細設計方式（Big?
Design Up Front），因為這種設計中有很多內容是你現在或最近都根本不需要的。XP還大力提倡設計
復核（Review）、代碼復核以及重整和優化（Refectory），所有的這些過程其實也是優化設計的過
程；在這些過程中不斷運行單元測試和功能測試，可以保證經過重整和優化后的系統仍然符合所有需
求。?

4 極限的編程?

既然編程很重要，XP就提倡兩個人一起寫同一段程序（Pair Programming），而且代碼所有權是歸于整
個開發隊伍（Collective Code Ownership）。程序員在寫程序和重整優化程序的時候，都要嚴格遵守
編程規范。任何人都可以修改其他人寫的程序，修改后要確定新程序能通過單元測試。?

5 極限的測試?

既然測試很重要，XP就提倡在開始寫程序之前先寫單元測試。開發人員應該經常把開發好的模塊整合到
一起（Continuous Integration），每次整合后都要運行單元測試；做任何的代碼復核和修改，都要運
行單元測試；發現了BUG，就要增加相應的測試（因此XP方法不需要BUG數據庫）。除了單元測試之外，
還有整合測試，功能測試、負荷測試和系統測試等。所有這些測試，是XP開發過程中最重要的文檔之
一，也是最終交付給用戶的內容之一。?

?

?

XP中的重要慣例和規則

1 項目開發小組（Team）

在XP中，每個對項目做貢獻的人都應該是項目開發小組中的一員。而且，這個小組中必須至少有一個人
對用戶需求非常清晰，能夠提出需求、決定各個需求的商業價值（優先級）、根據需求等的變化調整項
目計劃等。這個人扮演的是“客戶”這個角色，當然最好就是實際的最終用戶，因為整個項目就是圍繞
最終用戶的需求而展開的。程序員是項目開發小組中必不可少的成員。小組中可以有測試員，他們幫助
客戶制訂驗收測試；有分析員，幫助客戶確定需求；通常還有個Coach（教練），負責跟蹤開發進度、
解決開發中遇到的一些問題、推動項目進行；還可以又一個項目經理，負責調配資源、協助項目內外的
交流溝通等等。項目小組中有這么多角色，但并不是說，每個人做的工作是別人不能插手或干預的，XP
鼓勵每個人盡可能地為項目多做貢獻。平等相處，取長補短；這就是最好的XP開發小組。

2 計劃項目（Planning Game）、驗收測試、小規模發布（Small Releases）

XP開發小組使用簡單的方式進行項目計劃和開發跟蹤，并以次預測項目進展情況和決定未來的步驟。根
據需求的商業價值，開發小組針對一組組的需求進行一系列的開發和整合，每次開發都會產生一個通過
測試的、可以使用的系統。

?? 計劃項目

XP的計劃過程主要針對軟件開發中的兩個問題：預測在交付日期前可以完成多少工作；現在和下一步該
做些什么。不斷的回答這兩個問題，就是直接服務于如何實施及調整開發過程；與此相比，希望一開始
就精確定義整個開發過程要做什么事情以及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP
中又兩個主要的相應過程：

軟件發布計劃（Release Planning）。客戶闡述需求，開發人員估算開發成本和風險。客戶根據開發成
本、風險和每個需求的重要性，制訂一個大致的項目計劃。最初的項目計劃沒有必要（也沒有可能）非
常準確，因為每個需求的開發成本、風險及其重要性都不是一成不變的。而且，這個計劃會在實施過程
中被不斷地調整以趨精確。

周期開發計劃（Iteration Planning）。開發過程中，應該有很多階段計劃（比如每三個星期一個計
劃）。開發人員可能在某個周期對系統進行內部的重整和優化（代碼和設計），而在某個周期增加了新
功能，或者會在一個周期內同時做兩方面的工作。但是，經過每個開發周期，用戶都應該能得到一個已
經實現了一些功能的系統。而且，每經過一個周期，客戶就會再提出確定下一個周期要完成的需求。在
每個開發周期中，開發人員會把需求分解成一個個很小的任務，然后估計每個任務的開發成本和風險。
這些估算是基于實際開發經驗的，項目做得多了，估算自然更加準確和精確；在同一個項目中，每經過
一個開發周期，下一次的估算都會有更過的經驗、參照和依據，從而更加準確。
這些簡單的步驟對客戶提供了豐富的、足夠的信息，使之能靈活有效地調控開發進程。每過兩三個星
期，客戶總能夠實實在在地看到開發人員已經完成的需求。在XP里，沒有什么“快要完成了”、“完成
了90%”的模糊說法，要不是完成了，要不就是沒完成。這種做法看起來好象有利有弊：好處是客戶可以
馬上知道完成了哪些、做出來的東西是否合用、下面還要做些什么或改進什么等等；壞處是客戶看到做
出來的東西，可能會很不滿意甚至中止合同。實際上，XP的這種做法是為了及早發現問題、解決問題，
而不是等到過了幾個月，用戶終于看到開發完的系統了，然后才告訴你這個不行、那個變了、還要增加
哪個內容等等。

?? 驗收測試

客戶對每個需求都定義了一些驗收測試。通過運行驗收測試，開發人員和客戶可以知道開發出來的軟件
是否符合要求。XP開發人員把這些驗收測試看得和單元測試一樣重要。為了不浪費寶貴的時間，最好能
將這些測試過程自動化。

?? 頻繁地小規模發布軟件（Small Releases）

每個周期（Iteration）開發的需求都是用戶最需要的東西。在XP中，對于每個周期完成時發布的系
統，用戶都應該可以很容易地進行評估，或者已經能夠投入實際使用。這樣，軟件開發對于客戶來說，
不再是看不見摸不著的東西，而是實實在在的。XP要求頻繁地發布軟件，如果有可能，應該每天都發布
一個新版本；而且在完成任何一個改動、整合或者新需求后，就應該立即發布一個新版本。這些版本的
一致性和可靠性，是靠驗收測試和測試驅動的開發來保證的。

3 簡單設計，Pair Programming，測試驅動開發，重整和優化

XP程序員不但做為一個開發小組共同工作，還以兩個人為一個小開發單元編寫同一個程序。開發人員們
進行簡單的設計，編寫單元測試后再編寫符合測試要求的代碼，并在滿足需求的前提下不斷地優化設
計。

?? 簡單設計

XP中讓初學者感到最困惑的就是這點。XP要求用最簡單的辦法實現每個小需求，前提是按照這些簡單設
計開發出來的軟件必須通過測試。這些設計只要能滿足系統和客戶在當下的需求就可以了，不需要任何
畫蛇添足的設計，而且所有這些設計都將在后續的開發過程中就被不斷地重整和優化。

在XP中，沒有那種傳統開發模式中一次性的、針對所有需求的總體設計。在XP中，設計過程幾乎一直貫
穿著整個項目開發：從制訂項目的計劃，到制訂每個開發周期（Iteration）的計劃，到針對每個需求
模塊的簡捷設計，到設計的復核，以及一直不間斷的設計重整和優化。整個設計過程是個螺旋式的、不
斷前進和發展的過程。從這個角度看，XP是把設計做到了極致。

?? Pair Programming

XP中，所有的代碼都是由兩個程序員在同一臺機器上一起寫的——這是XP中讓人爭議最多、也是最難實
施的一點。這保證了所有的代碼、設計和單元測試至少被另一個人復核過，代碼、設計和測試的質量因
此得到提高。看起來這樣象是在浪費人力資源，但是各種研究表明事實恰恰相反。—— 這種工作方式
極大地提高了工作強度和工作效率。

很多程序員一開始是被迫嘗試這點的（XP也需要行政命令的支持）。開始時總是不習慣的，而且兩個人
的效率不會比一個人的效率高。這種做法的效果往往要堅持幾個星期或一兩個月后才能很顯著。據統
計，在所有剛開始Pair Programming的程序員中，90%的人在兩個月以后都很認為這種工作方式更加高
效。

項目開發中，每個人會不斷地更換合作編程的伙伴。因此，Pair Programming不但提高了軟件質量，還
增強了相互之間的知識交流和更新，增強了相互之間的溝通和理解。這不但有利于個人，也有利于整個
項目、開發隊伍和公司。從這點看，Pair Programming不僅僅適用于XP，也適用于所有其它的軟件開發
方法。

?? 測試驅動開發

反饋是XP的四個基本的價值觀之一——在軟件開發中，只有通過充分的測試才能獲得充分的反饋。XP中
提出的測試，在其它軟件開發方法中都可以見到，比如功能測試、單元測試、系統測試和負荷測試等；
與眾不同的是，XP將測試結合到它獨特的螺旋式增量型開發過程中，測試隨著項目的進展而不斷積累。
另外，由于強調整個開發小組擁有代碼，測試也是由大家共同維護的。即，任何人在往代碼庫中放程序
（Check In）前，都應該運行一遍所有的測試；任何人如果發現了一個BUG，都應該立即為這個BUG增加
一個測試，而不是等待寫那個程序的人來完成；任何人接手其他人的任務，或者修改其他人的代碼和設
計，改動完以后如果能通過所有測試，就證明他的工作沒有破壞愿系統。這樣，測試才能真正起到幫助
獲得反饋的作用；而且，通過不斷地優先編寫和累積，測試應該可以基本覆蓋全部的客戶和開發需求，
因此開發人員和客戶可以得到盡可能充足的反饋。

?? 重整和優化 (Refactoring)

XP強調簡單的設計，但簡單的設計并不是沒有設計的流水帳式的程序，也不是沒有結構、缺乏重用性的
程序設計。開發人員雖然對每個USER STORY都進行簡單設計，但同時也在不斷地對設計進行改進，這個
過程叫設計的重整和優化（Refactoring）。這個名字最早出現在Martin Fowler寫的《Refactoring:?
Improving the Design of Existing Code》這本書中。

Refactoring主要是努力減少程序和設計中重復出現的部分，增強程序和設計的可重用性。Refactoring
的概念并不是XP首創的，它已經被提出了近30年了，而且一直被認為是高質量的代碼的特點之一。但XP
強調，把Refactoring做到極致，應該隨時隨地、盡可能地進行Refactoring，只要有可能，程序員都不
應該心疼以前寫的程序，而要毫不留情地改進程序。當然，每次改動后，程序員都應該運行測試程序，
保證新系統仍然符合預定的要求。

4 頻繁地整合，集體擁有代碼（Collective Code Ownership），編程規范

XP開發小組經常整合不同的模塊。為了提高軟件質量，除了測試驅動開發和Pair Programming以外，XP
要求每個人的代碼都要遵守編程規范，任何人都可以修改其他人寫的代碼，而且所有人都應該主動檢查
其他人寫的代碼。

?? 頻繁地整合 （Integration ）

在很多項目中，開發人員往往很遲才把各個模塊整合在一起。在這些項目中，開發人員經常在整合過程
中發現很多問題，但不能肯定到底是誰的程序出了問題；而且，只有整合完成后，開發人員才開始稍稍
使用整個系統，然后就馬上交付給客戶驗收。對于客戶來說，即使這些系統能夠通過終驗收測試，因為
使用時間短，客戶門心里并沒有多少把握。

為了解決這些問題，XP提出，整個項目過程中，應該頻繁地，盡可能地整合已經開發完的USER STORY
（每次整合一個新的USER STORY）。每次整合，都要運行相應的單元測試和驗收測試，保證符合客戶和
開發的要求。整合后，就發布一個新的應用系統。這樣，整個項目開發過程中，幾乎每隔一兩天，都會
發布一個新系統，有時甚至會一天發布好幾個版本。通過這個過程，客戶能非常清楚地掌握已經完成的
功能和開發進度，并基于這些情況和開發人員進行有效地、及時地交流，以確保項目順利完成。

?? 集體擁有代碼（Collective Code Ownership）

在很多項目開發過程中，開發人員只維護自己的代碼，而且很多人不喜歡其他人隨意修改自己的代碼。
因此，即使可能有相應的比較詳細的開發文檔，但一個程序員卻很少、也不太愿意去讀其他程序員的代
碼；而且，因為不清楚其他人的程序到底實現了什么功能，一個程序員一般也不敢隨便改動其他人的代
碼。同時，因為是自己維護自己的代碼，可能因為時間緊張或技術水平的局限性，某些問題一直不能被
發現或得到比較好的解決。針對這點，XP提倡大家共同擁有代碼，每個人都有權利和義務閱讀其他代
碼，發現和糾正錯誤，重整和優化代碼。這樣，這些代碼就不僅僅是一兩個人寫的，而是由整個項目開
發隊伍共同完成的，錯誤會減少很多，重用性會盡可能地得到提高，代碼質量是非常好。

為了防止修改其他人的代碼而引起系統崩潰，每個人在修改后都應該運行測試程序。（從這點，我們可
以再次看到，XP的各個慣例和規則是怎樣有機地結合在一起的。）

?? 編程規范

XP開發小組中的所有人都遵循一個統一的編程標準，因此，所有的代碼看起來好像是一個人寫的。因為
有了統一的編程規范，每個程序員更加容易讀懂其他人寫的代碼，這是是實現Collective Code?
Ownership的重要前提之一。

5 Metaphor（系統比喻），不加班

XP過程通過使用一些形象的比喻讓所有人對系統有個共同的、簡潔的認識。XP認為加班是不正常的，因
為這說明關于項目進度的估計和安排有問題。?

?? Metaphor（系統比喻）

為了幫助每個人一致清楚地理解要完成的客戶需求、要開發的系統功能，XP開發小組用很多形象的比喻
來描述系統或功能模塊是怎樣工作的。比如，對于一個搜索引擎，它的Metaphor可能就是“一大群蜘
蛛，在網上四處尋找要捕捉的東西，然后把東西帶回巢穴。”

?? 不加班

大量的加班意味著原來的計劃是不準確的，或者是程序遠不清楚自己到底什么時候能完成什么工作。而
且，開發管理人員和客戶也因此無法準確掌握開發速度；開發人員也因此非常疲勞。XP認為，如果出現
大量的加班現象，開發管理人員（比如Coach）應該和客戶一起確定加班的原因，并及時調整項目計
劃、進度和資源。

?

?

XP中一些基本概念的簡介

User Story：開發人員要求客戶把所有的需求寫成一個個獨立的小故事，每個只需要幾天時間就可以完
成。開發過程中，客戶可以隨時提出新的User Story，或者更改以前的User Story。

Story Estimates和開發速度：開發小組對每個User Story進行估算，并根據每個開發周期
（Iteration）中的實際情況反復計算開發速度。這樣，開發人員和客戶能知道每個星期到底能開發多
少User Story。

Release Plan和Release Scope：整個開發過程中，開發人員將不斷地發布新版本。開發人員和客戶一
起確定每個發布所包含的User Story。

Iteration（開發周期）和Iteration Plan：在一個Release過程中，開發人員要求客戶選擇最有價值的
User Story作為未來一兩個星期的開發內容。

The Seed：第一個開發周期（Iteration）完成后，提交給客戶的系統。雖然這不是最終的產品，但它
已經實現了幾個客戶認為是最重要的Story，開發人員將逐步在其基礎上增加新的模塊。

Continuous Integration（整合）：把開發完的User Story的模塊一個個拼裝起來，一步步接近乃至最
終完成最終產品。

驗收測試（功能測試）：對于每個User Story，客戶將定義一些測試案例，開發人員將使運行這些測試
案例的過程自動化。

Unit Test（單元測試）：在開始寫程序前，程序員針對大部分類的方法，先寫出相應的測試程序。

Refactoring (重整和優化) ：去掉代碼中的冗余部分，增加代碼的可重用性和伸縮性。?

?

小結

XP的一個成功因素是重視客戶的反饋——開發的目的就是為了滿足客戶的需要。XP方法使開發人員始終
都能自信地面對客戶需求的變化。XP強調團隊合作，經理、客戶和開發人員都是開發團隊中的一員。團
隊通過相互之間的充分交流和合作，使用XP這種簡單但有效的方式，努力開發出高質量的軟件。XP的設
計簡單而高效；程序員們通過測試獲得客戶反饋，并根據變化修改代碼和設計，他們總是爭取盡可能早
地將軟件交付給客戶。XP程序員能夠勇于面對需求和技術上的變化。

XP很象一個由很多小塊拼起來的智力拼圖，單獨看每一小塊都沒有什么意義，但拼裝好后，一幅美麗的
圖畫就會呈現在你面前。?

總結

以上是生活随笔為你收集整理的什么是Extreme Programming的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。