一批業界專家（擁有大量的實踐經驗）聚集在一起概括出了一些可以讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，稱為敏捷聯盟。他們創造出了乙份說明，也就是敏捷聯盟宣言。
敏捷聯盟宣言
我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作我們認為：
雖然右邊也有價值，但是我們認為左項具有更大的價值。
個體和互動勝過過程和工具
團隊的構建比環境的構建更重要。
可以工作的軟體勝過面面俱到的文件
直到迫切需要並且意義重大的時候，才來編寫文件。
極限程式設計(xp)是敏捷方法中最重要的乙個，他有一系列簡單卻相互依賴的實踐組成。
客戶作為團隊成員
這樣可以更好地了解彼此所面臨的問題，並共同去解決這些問題。
使用者素材
必須要對使用者的需求很了解，這樣才能更好的設計與估算專案。
短週期交付
xp專案每兩周交付一次可以工作的軟體。
驗收測試
可以以客戶指定的驗收測試的形式來了解需求的細節。
結對程式設計
兩個人一起程式設計。(說實話，這種形式還沒有見過)
測試驅動開發
單元測試試一種驗證行為，更是一種設計行為。同樣，他也是一種編寫文件的行為。編寫單元測試避免了相當數量的反饋迴圈，尤其是功能驗證方面的反饋迴圈。
測試驅動的開發方法（tdd）
單元測試（單元是用來驗證系統中個別機制的白盒測試）
單元測試的流程如下：
單元測試的好處：
驗收測試（驗收測試時用來驗證系統滿足客戶需求的黑盒測試）
正如單元測試作為可編譯、執行的有關系統內部結構的文件那樣，驗收測試時有關系統特性的可編譯、執行的文件。
集體所有權
不是按照模組來劃分的，每個人都有權利去改進任何模組。每個成員都肯定有自己擅長和不擅長的地方，可以做自己擅長的事情，可以去請教其他擅長的成員他們擅長的專案。
持續整合
程式設計師每天會多次對**進行修改。
可持續開發速度
不加班（o(∩_∩)o哈哈~）
開放的工作空間
這樣可以更好的討論交流問題
計畫遊戲
計畫的本質是劃分業務人員和開發人員之間的職責。
初始探索
在專案開始的時候，開發費人員和客戶會盡量確定出所有真正重要的使用者素材。隨著專案的進展，客戶會不斷編寫新的使用者素材，素材的編寫會一直持續到專案完成。
開發人員共同對這些素材進行估算。估算是相對的不是絕對的，可以將大的素材進行分解，小的素材進行合併。可以定義乙個計量標準，如半天實現乙個素材，然後將每個素材進行標點。隨著專案的進行，估算會越來越準確。
發布計畫
知道了素材的速度以後，客戶就可以定義素材的優先級別，然後選擇那些會帶來最大收益的素材。開發與客戶對專案的首次發布時間達成一致，通常為2~4周。
迭代計畫
可發和客戶選定迭代規模，通常為兩周。迭代期間使用者素材的實現順序取決於開發人員。一旦開始迭代，客戶就不能改變該迭代期間需要實現的素材。就算沒有完成所有的素材，迭代也要在指定的日期結束。然後結合已開發完素材的速度來重新規劃開發速度。這樣的反饋有助於保持計畫於團隊事假狀況相同步。
任務計畫
在新的迭代開始時，客戶和開發人員共同指定計畫。開發人員將素材分解成開發任務，乙個任務就是乙個開發人員能夠在4~16小時之內實現的一些功能。然後開發人員認領開發任務，並估算任務所需要的點數。
不斷迭代即可
每次迭代完成，給客戶演示當前的程式，客戶對程式進行評價並提出反饋
結論通過一次次的迭代，專案進入了一種可**的，舒適的開發環境。每個人都知道將要做什麼，以及何時去做。當然並不是所有的專案都適合用xp進行開發。
簡單的設計
xp團隊的設計盡可能的簡單而且富有變現力。即一開始不會設計的很複雜，知道迫切而且必須使用複雜方案的時候再使用複雜的解決方案。以下有三條xp指導原則可以對開發人員進行指導
重構要經常性的對**進行重構。
每個軟體模組都具有三項職責：
怎麼樣才能讓軟體模組易於閱讀，易於修改呢？使用軟體開發的原則和模式可以幫助我們建立更加靈活和具有適應性的軟體模組。然而，要使得軟體模組易於閱讀和修改，所需喲啊的不僅僅是一些原則和模組，還需要你的注意力，需要紀律約束，需要創造美的激情。（**的編寫要自己滿意才行，當然這一切的前提都是在能完成任務的情況下）
隱喻隱喻通常可以歸結為乙個名字系統。這些名字提供了乙個系統組成元素的詞彙表，並且有助於定義他們之間的關係
極限程式設計是一組簡單的具體的實踐，這些實踐組合在一起形成了乙個敏捷軟體開發過程
敏捷軟體開發學習筆記
敏捷開發宣言 1.個體和互動 勝過 過程與工具 2.可以工作的軟體 勝過 面面俱到的文件 3.客戶合作 勝過 合同談判 4.響應變化 勝過 遵循計畫 principle 1.我們最優先要做的就是通過盡早的，持續的交付有價值的軟體來使客戶滿意 2.即使到了開發後期，也歡迎改變需求。敏捷過程利用變化來為...
敏捷軟體開發之敏捷實踐
good 勝過normal 個體和互動 過程和工具 可以工作的軟體 面面俱到的文件 客戶合作 合同談判 響應變化 遵循計畫 個體和互動勝過過程和工具 人是獲得成功的最為重要的因素。團隊的構建要比環境的構建重要得多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力...
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...