敏捷實踐
敏捷原則
捷軟件開發宣言
我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發方法。通過這項工作，我們認爲：
＊ 個體和交互 勝過 過程和文檔
＊ 可以工作的軟件 勝過 面面俱到的文檔
＊ 客戶合作 勝過 合同談判
＊ 響應變化 勝過 遵循計劃
雖然右項也有價值，但是我們認爲左項具有更大的價值。
從上述的價值觀引出了下面１２條原則，它們是敏捷實踐區別於重型過程的特徵所在。
-
我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。
-
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優勢。
-
經常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
-
在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
-
圍繞被激勵起來的個人來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
-
在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
-
工作的軟件是首要的進度度量標準。
-
敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
-
不斷的關注優秀的技能和好的設計會增強敏捷能力。
-
簡單—使未完成的工作最大化的藝術—是根本的。
-
最好的架構、需求和設計出自於自組織的團隊。
-
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行爲進行調整。
每一位軟件開發人員、每一個開發團隊的職業目標，都是給他們的僱主和客戶交付最大可能的價值。可是，我們的項目以令人沮喪的速度失敗，或者未能交付任何價值。雖然在項目中採用過程方法是出於好意的,但是膨脹的過程方法對於我們的失敗至少是應該付一些責任的。敏捷軟件開發的原則和價值觀構成了一個可以幫助團隊打破過程膨脹循環的方法，這個方法關注的是可以達到團隊目標的一些簡單的技術。
最重要的敏捷過程—極限編程
極限編程實踐
-
客戶作爲團隊成員
-
用戶素材
-
短交付週期
3.1 迭代計劃
3.2 發佈計劃 -
驗收測試
-
結對編程
-
測試驅動的開發方法
-
集體所有權
-
持續集成
-
可持續的開發速度
-
開放的工作區間
-
計劃遊戲
-
簡單的設計
1） 考慮能夠工作的最簡單的事情
2） 你將不需要它。
3） 一次，並且只有一次。 -
重構
-
隱喻
極限編程是一組簡單、具體的實踐，這些實踐結合在一起形成了一個敏捷開發過程。該過程已經被許多團隊使用過，並且取得了好的效果。極限編程是一種優良的、通用的軟件開發方法。項目團隊可以拿來直接採用，也可以增加一些實踐，或者對其中的一些實踐進行修改後再採用。
重構
在不改變代碼外在行爲的前提下對代碼做出修改,以改進代碼的內部結構的過程。
可是我們爲什麼要改進已經能夠工作的代碼的結構呢？不是還有句古老的諺語：如果它沒有壞，就不要去修理它 ！
每一個軟件模塊都具有三項職責。第一個職責是它運行起來所完成的功能。這也是該模塊得以存在的原因。第二個職責是它要應對變化。幾乎所有的模塊在它們的生命週期中都要變化，開發者有責任保證這種改變應該儘可能地簡單。一個難以改變的模塊是拙劣的，即使能夠工作，也需要對它進行修正。第三個職責是要和閱讀它的人進行溝通。對該模塊不熟悉的開發人員應該能夠比較容易的閱讀並理解它。一個無法進行溝通的模塊也是拙劣的。同樣需要對它進行修正。