ExtremeProgramming（極限程式設計，簡稱XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與WardCunningham共事時，就一直共同探索著新的軟體開發方法，希望能使軟體開發更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟體開發的前提條件、可能行以及面臨的困難。1996年三月，Kent終於在為DaimlerChrysler所做的一個專案中引入了新的軟體開發觀念——XP。 
XP是一個輕量級的、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟體專案都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小週期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。

為什麼稱為“Extreme”（極限）

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

XP的軟體開發是什麼樣

1極限的工作環境

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

2極限的需求

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

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

3極限的設計

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

4極限的程式設計

既然程式設計很重要，XP就提倡兩個人一起寫同一段程式（PairProgramming），而且程式碼所有權是歸於整個開發隊伍（CollectiveCodeOwnership）。程式設計師在寫程式和重整優化程式的時候，都要嚴格遵守程式設計規範。任何人都可以修改其他人寫的程式，修改後要確定新程式能通過單元測試。

5極限的測試

既然測試很重要，XP就提倡在開始寫程式之前先寫單元測試。開發人員應該經常把開發好的模組整合到一起（ContinuousIntegration），每次整合後都要執行單元測試；做任何的程式碼複核和修改，都要執行單元測試；發現了BUG，就要增加相應的測試（因此XP方法不需要BUG資料庫）。除了單元測試之外，還有整合測試，功能測試、負荷測試和系統測試等。所有這些測試，是XP開發過程中最重要的文件之一，也是最終交付給使用者的內容之一。

XP中一些基本概念的簡介

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

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

ReleasePlan和ReleaseScope：整個開發過程中，開發人員將不斷地釋出新版本。開發人員和客戶一起確定每個釋出所包含的UserStory。

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

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

ContinuousIntegration（整合）：把開發完的UserStory的模組一個個拼裝起來，一步步接近乃至最終完成最終產品。

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

UnitTest（單元測試）：在開始寫程式前，程式設計師針對大部分類的方法，先寫出相應的測試程式。

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

小結

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

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

什麼時候來避免極限程式設計

極限程式設計，有時也被叫做XP，已經被證明了是許多專案經理和專案程式設計師開發專案的成功的開發方法，具有很好的開發風格。但是它並不適用與所有的情況或所有的專案團體。如果你不考慮你的開發小組、開發部門或開發公司的情況，而去試圖選擇極限程式設計作為你的核心開發方法，這才是本末倒置。你應該確保你的開發單位是適用於這個極限程式設計開發方法的特殊需要的。

在簡單的團隊中，極限程式設計把開發者而不是專案經理作為專案開發的核心人員，它選擇使用開發人員來進行專案的決策。這個技術可以提高開發效率，也可以使管理介面的麻煩最小化，但是極限程式設計會給你帶來你不曾有的問題，它愛管閒事，並缺乏有效的管理。另外，管理應該在合適的時候新增進來，如果不進行開發管理將對你的專案開發有害無益。

－＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

藉口程式設計(Excuse Programming)。是的，這就是很多專案團隊，尤其是專案經理們一直在做的事情。他們總是一直在給出一個又一個的藉口。為沒有很好地進行需求開發和需求管理找藉口，為沒有跟蹤專案風險和專案問題並且系統化地、及時地解決它們找藉口。

最常見的藉口就是時間，也就是沒有時間。為什麼會沒有時間呢？因為時間都被浪費到做錯誤的事情上了，所以他們就需要加班。他們是在做片面的極限程式設計，或者，應該說是額外程式設計(Extra Programming)，這是一個惡性迴圈，他們需要走出這個怪圈，讓事情走上正軌。但屢見不鮮的情況是，專案經理往往過於自負，很難走出這個怪圈。他們總在給出一個又一個的藉口，沒有例外管理，而是藉口管理。

請注意：我們是支援極限程式設計XP的，但極限程式設計是適用於那些非常清楚自己在做什麼的人。極限程式設計不適用於那些為了偽裝他們所作所為的人，極限程式設計適合於專家，而不是冒牌貨。極限程式設計不是藉口程式設計，它不是一個用於你不做正確的事情的藉口。

從藉口程式設計到極限程式設計
我們認為每個開發人員、經理——每個軟體開發社群的專業人士，都應該思考哪些是他們知道的，哪些是是他們不知道的，對自己和別人都應該絕對誠實。我們也應該十分認真和充滿熱情地提高我們的技能。除此之外，沒有其他捷徑，請不要再找藉口了。

所以讓我們非常坦誠地面對問題。但人們（例如專案經理等）的問題往往是他們並不知道他們自身的問題。他們還沒有意識到這一點。如果你試圖說服他們意識到他們有問題，你會尋找出更多的問題。別忘了他們都是藉口程式設計高手。你並沒有看清所有的問題。所以，有時，人們從自身的錯誤中學習，有些人從不學習也會僥倖成功，有些人從不學習並重復地犯相同的錯誤。

但是也有少數人會總是問自己：我如何才能做得比昨天更好？幸運地是，我們周邊還有一些這樣的人。當你給他們建議時，他們可能會反對，但當他們回到家裡，冷靜下來，開始思考，然後他們會回來找你。這些人還是有希望的。有希望的是，我們有越來越多這樣的人。

一旦藉口程式設計被馴服，我們可以原諒他們的過去。一切都可以被原諒。我們可以開始教育他們正確的方式，常常地我們甚至可以從他們身上學到不少東西。有很多種方式來武裝他們，他們可以閱讀書籍等，他們也可以從導師那裡尋找幫助，甚至是虛擬的導師。

作為一個經理或客戶，你總是需要以挑剔的眼光來選擇誰來做你的專案，一個團隊（尤其是她的領導）的選擇是一個非常關鍵的要素。如果他們是專家那就最好了，否則，尋找那些有潛力的，並設計一種策略讓他們以最快的速度前進——如何以最快的速度進行，這又是另一個話題。

 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

 敏捷開發（agile development）是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。簡言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

      敏捷開發是全新理論嗎？答案莫衷一是。細心的人們可以發現，敏捷開發其實借鑑了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。

      改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。“在敏捷軟體開發的過程中，我們每兩週都會得到一個可以工作的軟體，”Fowler介紹，“這種非常短的迴圈，使終端客戶可以及時、快速地看到他們花錢構建的軟體是一個什麼樣的結果。”

敏捷肯定是奔著軟體本身去的。

拋開軟體本身談過程，沒有技術的積累去談敏捷風格的專案管理，那都是扯談。

什麼過程，設計，整合，測試都是以軟體本身為主導的。

適度的 unit test 用例，自動化構建/自動化測試，那是敏捷的外在表現。

一個適度設計，持續改進的構思，是敏捷的精髓。最後把這些都反映到程式碼上，那就是一個敏捷的實施了。

如果能夠圍繞這些構造一個良好的技術討論氛圍，互助的精神，那就實現了敏捷的勝利以及價值了。

對不懂程式碼，沒有做過程式設計的人，關於敏捷，我們沒什麼好談的

敏捷開發有什麼缺點? 
   
1、敏捷開發以人為本，對PM的要求比較高，管人是需要一些藝術的.PM如果控制不好,整個專案的風險會比較大!

2、敏捷開發在平衡過程中，必然會對某些方面帶來忽略，容易在這些方面出現問題

3、敏捷開發對團隊成員要求很高，水平不能相差太遠，否則節奏不好控制 
 

參考來源：

http://tech.acnow.net/Html/Program/soft_project/SoftMethod/2005-8/7/230147673.shtml

http://hi.baidu.com/mayig/blog/item/dbf2f81f0c093ef5e0fe0b58.html

http://zhidao.baidu.com/question/5153690.html

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/lovingprince/archive/2007/04/25/1584258.aspx