1，敏捷過程

為了使軟件開發團隊具有高效工作和快速響應變化的能力，17位著名的軟件專家于2001年2月聯合起草了敏捷軟件開發宣言。

敏捷軟件開發宣言由下述4個簡單的價值觀聲明組成。

（1）個體和交互勝過過程和工具

優秀的團隊成員是軟件開發項目獲得成功的最重要因素;當然,不好的過程和工具也會使最優秀的團隊成員無法發揮作用。

團隊成員的合作、溝通以及交互能力要比單純的軟件編程能力更重要。

正確的做法是,首先致力于構建軟件開發團隊(包括成員和交互方式等),然后再根據需要為團隊配置項目環境(包括過程和工具)。

（2）可以工作的軟件勝過面面俱到的文檔

軟件開發的主要目標是向用戶提供可以工作的軟件而不是文檔;但是,完全沒有文檔的軟件也是種災難。開發人員應該把主要精 力放在創建可工作的軟件上面，僅當迫切需要并且具有重大意義時，才進行文檔編制工作，而且所編制的內部文檔應該盡量簡明扼要、主題突出。

（3）客戶合作勝過合同談判

客戶通常不可能做到一次性地把他們的需求完整準確地表述在合同中。能夠滿足客戶不斷變化的需求的切實可行的途徑是,開發團隊與客戶密切協作,因此，能指導開發團隊與客戶協同工作的合同才是最好的合同。

（4）響應變化勝過遵循計劃

軟件開發過程中總會有變化,這是客觀存在的現實。一個軟件過程必須反映現實，因此，軟件過程應該有足夠的能力及時響應變化。然而沒有計劃的項目也會因陷入混亂而失敗，關鍵是計劃必須有足夠的靈活性和可塑性,在形勢發生變化時能迅速調整，以適應業務和技術等方面發生的變化。

在理解上述4個價值觀時應該注意，這些聲明只不過是對不同因素在保證軟件開發成功方面所起作用的大小做了比較，說一個元素更重要并不是說其他因素不重要，更不是說某個因素可以被其他因素代替。

根據上述價值觀提出的軟件過程統稱為敏捷過程，其中最重要的是極限編程

2，極限編程

極限編程(eXtreme Programming,XP)是敏捷過程中最富盛名的一個,其名稱中“極限”二字的含義是指把好的開發實踐運用到極致。目前.極限編程已經成為種典型的開發方法,廣泛應用于需求模糊且經常改變的場合。

(1)極限編程的有效實踐

下面簡述極限編程方法采用的有效的開發實踐。

客戶作為開發團隊的成員

必須至少有一名客戶代表在項目的整個開發周期中與開發人員在- -起緊密地配合工作,客戶代表負責確定需求、回答開發人員的問題并且設計功能驗收測試方案。

使用用戶素材

所謂用戶素材就是正在進行的關于需求的談話內容的助記符。根據用戶素材可以合理地安排實現該項需求的時間。

短交付周期

每兩周完成一次的迭代過程實現了用戶的一些需求，交付出目標系統的-個可工作的版本。通過向有關的用戶演示迭代生成的系統，獲得他們的反饋意見。

驗收測試

通過執行由客戶指定的驗收測試來捕獲用戶素材的細節。

結對編程

結對編程就是由兩名開發人員在同一臺計算機上共同編寫解決同-個問題的程序代碼,通常一個人編碼，另一個人對代碼進行審查與測試，以保證代碼的正確性與可讀性。結對編程是加強開發人員相互溝通與評審的一種方式。

測試驅動開發

極限編程強調“測試先行”。在編碼之前應該首先設計好測試方案，然后再編程,直至有測試都獲得通過之后才 可以結束工作。

集體所有

極限編程強調程序代碼屬于各個開發小組集體所有，小組每個成員都有更改代碼的權利，每個成員都對全部代碼的質量負責。

持續集成

極用編程主張在一天之內多次集成系統，而且隨著需求的變更 .應該不斷地進行回歸測試

可持續的開發速度

開發人員以能夠長期維持的速度努力工作，XP規定開發人員每周工作時間不超過40小時 、連續加班不可以超過兩周，以免降低生產率。

開放的工作空間

XP項目的全體參與者(開發人員、客戶等)一起在個開放的場所中工作。項目組成員在這個場所中自由地交流和討論。

及時調整計劃

計劃應該是靈活的、循序漸進的。制定出項目計劃之后.必須根據項目進展情況及時進行調整，沒有一成不變的計劃。

簡單的設計

開發人員應該使設計與計劃要在本次迭代過程中完成的用戶索材完全匹配，設計時不需要考慮未來的用戶素材。在一次次的迭代過程中,項目組成員不斷變更系統設計，使之相對于正在實現的用戶素材而言始終處于最優狀態。

重構

所謂代碼重構就是在不改變系統行為的前提下，重新調整和優化系統的內部結構，以降低復雜性、消除冗余、增加靈活性和提高性能。應該注意的是.在開發過程中不要過分依賴重構。特別是不能輕視設計，對于大中型系統而言，如果推遲設計或者干脆不做設計，將造成一場災難。

使用隱喻

可以將隱喻看作把整個系統聯系在一起的全局視圖，它描述系統如何運作，以及用何種方式把新功能加人到系統中。

(2)極限編程的整體開發過程

上圖描述了極限編程的整體開發過程。首先,項目組針對客戶代表提出的“用戶故事"(用戶故事類似于用例，但比用例更簡單，通常僅描述功能需求)進行討論，提出隱喻，在此項話動中可能需要對體系結構進行“試探"(所謂試探就是提出相關技術難點的試探性解決方案)。然后,項目組在隱喻和用戶故事的基礎上，根據客戶設定的優先級制訂交付計劃(為了制訂出切實可行的交付計劃，可能需要對某些技術難點進行試探)。接下來開始多個選代過程(通常每個迭代歷時1~3周)，在迭代期內產生的新用戶故事不在本次迭代內解決，以保證本次開發過程不受干擾。開發出的新版本軟件通過驗收測試之后交付用戶使用。

（3）極限編程的迭代過程

上圖描述了極限編程的迭代開發過程。項目組根據交付計劃和“項目速率”(即實際開發時間和估計時間的比值)，選擇需要優先完成的用戶故事或待消除的差錯，將其分解成可在1~2天內完成的任務,制訂出本次迭代計劃。然后通過每天舉行一次的“站立會議”(與會人員站著開會以縮短會議時間,提高工作效率)，解決遇到的問題，調整迭代計劃,會后進行代碼共享式的開發工作。所開發出的新功能必須100%通過單元測試,并且立即進行集成，得到的新的可運行版本由客戶代表進行驗收測試。開發人員與客戶代表交流此次代碼共享式編程的情況，討論所發現的問題，提出新的用戶故事,算出新的項目速率，并把相關的信息提交給站立會議。

綜上所述，以極限編程為杰出代表的敏捷過程,具有對變化和不確定性的更快速、更敏捷的反應特性，而且在快速的同時仍然能夠保持可持續的開發速度。上述這些特點使得敏捷過程能夠較好地適應商業競爭環境下對小型項目提出的有限資源和有限開發時間的約束。