上一篇中我們已經瞭解了敏捷項目管理的由來，也知道了對於敏捷管理的需求，這一篇，我們瞭解下敏捷開發在日常項目中的關鍵實踐，也就是怎麼用的。
目錄
-
迭代-增量開發
從管理的角度看，在朝向敏捷方法的改變中這是一個最容易注意到的實踐。迭代開發實施的是重複和半並行化的開發活動，而不是在整個項目中只對每個軟件開發週期（需求、設計、編程等）執行一次（這是軟件開發的傳統方法或瀑布方法）。這就意味着活動極爲窄小而且相互之間極爲接近。它們似乎要混合在一起，而且活動的順序可以變更。敏捷項目管理中，迭代越短越好。這是敏捷過程需要每個迭代有一個大約爲 2～6 周的時間框的原因。迭代帶來項目的節奏，而增量說明了項目的實際進展。舉個例子：一個項目會有一些非常高層次的需求，項目團隊將會對這些需求中的一個（比如，首先是最高優先級的條目）進行關注並詳加研究。而後團隊獲得了更詳盡的需求，編寫單元測試，設計並編寫程序代碼，然後週期性地執行測試用例。在迭代的末期，一個高層次的需求—項目中的一塊，就完成了。這就是迭代-增量開發真正閃光之處。在項目啓動兩週之後，一項需求就被轉化成了可工作的軟件並且可以向顧客展示。想想瀑布項目在兩週之後會是個什麼樣子吧。而更好的是，通過採用這種方法，我們爲顧客打開了一個早期反饋環，顧客現在可以做出變更並且按照他們所期待的正確方向導航項目。
在每次迭代中，涉衆將塑造迭代範圍的增量方向。在迭代期間，對項目的範圍更顯著（而且是破壞性更小的）的調整是可能的而且經常是受歡迎的。不是每天參與項目進展的涉衆會被要求在迭代期間參加。如此，開發團隊也可以從周圍的涉衆中獲得重要的反饋，從而也可以滿足他們的期望。
迭代-增量開發的其他優點包括：
在早期的迭代中就可以減少或消除最高的風險。
計劃與評估的信心隨着迭代一次一次地增加。
根據以往的迭代成果，可以決定完成日期的趨勢。
完成就是完成，不是 90%完成。
士氣通過不斷的反饋而增加。 -
測試驅動開發
試想下，如果一個項目開發完成後，在把產品交付給客戶時存在着大量未經測試的軟件代碼，那無疑對執行官來說是個定時炸彈。不過，公平起見，其實軟件工程師們也未必知道這些問題。原因之一是開發人員進行的是編寫代碼、調試代碼、對其修正等任務。對他們來說看到的是類、對象和方法以及不同類型的許多條件和循環交織在一起的網絡。可能會有一些永遠不會被執行的語句嵌套在這些子句中，因爲決定（守衛並保護）這些語句是否執行的條件永遠得不到滿足。但有誰能保證這些條件永遠都不會滿足呢？
敏捷開發推動一種稱爲測試驅動開發的實踐。這個實踐背後的思想是：開發人員在編寫實際代碼之前先編寫單元測試。如果不知道測試什麼，怎麼能知道爲什麼而編碼呢？結果就是一個能測試實際對象但不會干擾對象本身的單元測試。測試對象包含所有不同守衛和條件的消息，能夠確保對象按計劃執行。
測試驅動開發對項目的質量有顯著的正面影響。測試用例隨着迭代的進行而演化，所以，在每次迭代之後所產生的代碼庫都經過了測試。對於瀑布方法，測試用例的編寫和執行通常都是在項目的末端進行。此時正是預算喫緊和資源開始轉移到其他項目的時候。測試驅動開發背後的思想是單元測試代碼要與實現功能的組件分開，位於單元測試自己的組件中。編寫測試代碼和功能代碼的活動幾乎是並行的，其中測試代碼的編寫稍微提前一些。單元測試和功能經常由相同的開發人員（開發人員對）開發。兩個組件都經過編譯，單元測試執行組件的行爲。
由於在敏捷方法中測試用例與實際代碼並行存儲，所以要自動執行這些單元測試只需一小步。這正是敏捷開發人員在特定觸發器發生時使用工具做的事情。 -
持續集成
組件的集成以及隨之而來的測試對軟件工程師來說並不新鮮。而敏捷開發真正的不同在於其持續的方法。將集成測試拖延到項目的最後階段進行並且期望整個架構能夠井井有條是傳統方法的一個主要問題。敏捷管理就是在每一個模塊完成後進行持續的集成，也就避免了在很長時間迭代時再集成遇到問題。
執行集成的觸發條件也可以與常規軟件工程活動鏈接在一起，比如，通過配置管理系統（subversion 或者 CVS[Concurrent Versioning System，併發版本控制系統]）將代碼簽入（check in）。有了持續集成基礎設施，機構內的團隊、經理和執行官可以知道系統最近的成功版本是什麼。如果瀑布項目的開發人員報告說某個需求已經 100%完成，那會和敏捷開發人員所報告的某些東西已經 100%完成完全不一樣。在敏捷項目中，100%意味着已經開發、已經測試而且已經集成。 -
面對面交流
在以前的項目開發中，項目團隊成員就算不在同一個房間裏也通常都相互接近，也有可能使用電子信息交流，如電子郵件。雖然現在我們很少在意這個，但口頭和非口頭的交流中有一些東西是電子通信不可替代了。敏捷開發把交流缺失問題考慮在內，要求團隊成員彼此直接協作，人對人地進行，沒有電子的防火牆存在。尤其當業務分析師和軟件開發人員一起工作的時候，面對面的交流是很重要的。匿名共享需求文檔只會打開曲解和誤解之門，更不用說書面信息比口頭交流還要慢很多。事先聲明，我並沒有說需求都是寫在文檔中的，它們是團隊成員們共同開發、澄清或者協商而成的。最後但不是最不重要的一點，我們都是人，而項目是個社會網絡。我們需要這些網絡來增加士氣和趣味。試想下一個完全以分佈的方式工作的團隊必然沒有面對面交流來的更直觀，更加能獲取趣味的。