2001年在軟件工程界首次出現“敏捷”這個名詞，17個過程方法學家舉行了一個討論會。發現他們的“輕量級”的方法有很多共同的地方，因此一致同意把這些方法統稱爲“敏捷”的方法。並且成立了個叫敏捷聯盟的組織，還定下了所謂的“敏捷宣言”。從此，越來越多的人瞭解到敏捷方法。
敏捷方法有一些共同的特徵。其中有兩個最主要的特徵是：輕量和簡單。敏捷方法論包含最少的流程和文檔，減少正式性。目的是做眼前能做的事情，而不去預測太遠的未來，首先完成緊迫的事情。快速的、增量的開發能更快地交付客戶使用，更快得到反饋。開發方法要稱之爲敏捷，需要具備4個基本特徵：增量的、協作的、直接的、適應性強的。
1.SCRUM(橄欖球裏的爭球)方法論
關鍵詞：30天迭代粒度，每日站立會議，進度透明，客戶參與
Scrum是一種迭代式增量軟件開發過程，通常用於敏捷軟件開發。Scrum在英語的意思是橄欖球裏的爭球。雖然Scrum是爲管理軟件開發項目而開發的，它同樣可以用於運行軟件維護團隊，或者作爲計劃管理方法。在SCRUM方法論中其核心仍然迭代和增量，首先對於產品需求會劃分爲多個迭代或增量，每個迭代都需要在1個月能夠交付，而一個月即是一次衝刺，而一個迭代版本又需要轉化到每天的進度跟蹤和問題解決，這就是每天的15分鐘會議(每日站立會議)，在會議上必須回答當天的進度，明天的計劃和是否存在問題。
Scrum是一個包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。管理Scrum過程有很多實施方法，從白板上的即時貼到軟件包。Scrum最大的好處是它非常容易學習，而且應用Scrum不需要太多的投入。
每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是爲了進行持續過程改進。會議的時間限制在4小時。Scrum提倡所有團隊成員坐在一起工作，進行口頭交流，以及強調項目有關的規範（disciplines），這些有助於創造自我組織的團隊。
Scrum的一個關鍵原則是承認客戶可以在項目過程中改變主意，變更他們的需求，而預測式和計劃式的方法並不能輕易地解決這種不可預見的需求變化。同樣，Scrum採用了經驗方法– 承認問題無法完全理解或定義，而是關注於如何使得開發團隊快速推出和響應不斷出現的需求的能力最大化。其實踐主要包括:
- 客戶成爲開發團隊中的一部分。 (例如客戶肯定對開發的結果真正感興趣。)
- 頻繁的包含可以工作的功能的中間可交付成果。
- 頻繁的風險和緩解計劃是由開發團隊自己制定。
- 計劃和模塊開發的透明 – 讓每一個人知道誰負責什麼，以及什麼時候完成。
- 頻繁的利益所有人會議，以跟蹤項目進展
- 平衡的 (發佈，客戶，員工，過程) 儀表板更新 – 擁有預警機制提前瞭解可能的延遲或偏差。
- 沒有問題會被藏在地毯下。認識到或說出任何沒有預見到的問題並不會受到懲罰。
- 在工作場所和工作時間內必須全身心投入。– 完成更多的工作並不意味着需要工作更長時間。
2.FDD(Feature-Driven Development)-特徵驅動開發
關鍵詞：Feature，客戶價值，兩週迭代粒度，Domain Model
Feature-Driven本質上還是Model Driven，是先規劃出整套的Domain Model，做爲系統起始的核心。接下來就是依據Model，開始找出所有的Feature。而Feature = 可以爲客戶產生價值的最小開發單位。羣集後的Feature稱之爲Feature Set。而系統的某一個主題領域就是組合了很多Feature Set。接下來，項目經理就是依據Feature來規畫開發的週期，書上建議每次的週期是兩週，所以每個Feature必然不可以超過兩週，會超過兩週的Feature必須再予以細分。所謂兩週內的工作，包含爲這個Feature設計、開發、測試、佈置。所謂兩週內的工作，包含爲這個Feature設計、開發、測試、佈置。
在RUP中強調的是用例驅動，通過用例進行需求的分析和建模，再過渡到架構設計和後續的開發中。而在FDD中強調特徵驅動，特徵是比用例更加小的粒度單位，而且特徵更加能夠體現客戶價值。在傳統的瀑布模型中我們往往在後續編碼完成後才能夠看到交付的功能，而FDD本身也是一種迭代的思路，只是迭代的單位是Feature，而這些Feature將貫徹從需求到編碼測試的全過程，只到每個功能都能夠滿足一個客戶價值的實現。因此通過特徵和特徵集將傳統的瀑布方法進行了橫切，一切軟件開發活動包括項目計劃都是以特徵爲單位和特徵驅動。在FDD中主要包括5步流程，具體如下：
- Develop an Overall Model (開發一個主域模型)
- Build a Features List (通過主域模型分解特徵集合)
- Plan By Feature (根據特徵制定項目計劃和編排進度)
- Design By Feature (根據特徵進行設計,開始迭代)
- Build By Feature (根據特徵進行編碼，測試和構建)
3.DSDM-動態系統開發方法，也稱業務中心框架開發方法
關鍵詞：業務爲中心 用戶參與 迭代 快速交付團隊協作和溝通
DSDM（動態系統開發方法，也稱業務中心框架開發方法）是衆多敏捷開發方法中的一種，它倡導以業務爲核心，快速而有效的進行系統開發。我們可以把DSDM看成一種控制框架，重點在於快速交付、並補充如何應用這些控制的指導原則的框架。
DSDM是一整套的方法論，不僅僅包括軟件開發內容和實踐，也包括了組織結構，項目管理，估算，工具環境，測試，配置管理，風險管理，重用等各個方面的內容。
DSDM 的基本觀點是，任何事情都不可能一次性的圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的爲準。實施的思路是，在時間進度和可用資源預先固定的情況下，力爭的最大化滿足業務需求（傳統方法一般是需求固定，時間和資源可變），交付所需要的系統。對於交付的系統，必須達到足夠的穩定程度以在實際環境中運行；對於業務方面的某些緊急需求，也要求能夠在短時間內得到滿足，然後在以後迭代階段中對功能進行進一步完善。對於DSDM主要包括以下9條基本原則:
- 用戶必須持續參與
- 必須授予DSDM團隊制定決策的權力
- 注重產品的經常交付
- 滿足業務用途是接受交付品的主要依據
- 迭代和增量式開發對得到正確的業務解決方案是必不可少的
- 開發過程中的所有變化可逆
- 在高層次上制定需求的基線
- 測試自始自終貫穿於開發週期之中
- 所有項目涉衆間的通力合作是不可或缺的
4.Crystal Methods-水晶方法族
關鍵詞：協作 角色 文檔 迭代 風險管理
水晶方法論由Alistair Cockburn在20實際90年代末提出。之所以是個系列，是因爲他相信不同類型的項目需要不同的方法。雖然水晶系列不如XP那樣的產出效率，但會有更多的人能夠接受並遵循它。
水晶方法把開發看作是一系列的協作遊戲，而寫文檔的目標就是只要能幫助團隊在下一個遊戲中取得勝利就行了。水晶方法的工作產品包括用例、風險列表、迭代計劃、核心領域模型，以及記錄了一些選擇結果的設計註釋。水晶方法也爲這些產品定義了相應的角色。然而，值得注意的是，這些文檔沒有模板，描述也可不拘小節，但其目標一定要清晰，那就是滿足下次遊戲就可以了。我總是將這些思想以下面的方式向我的團隊成員表達：通過它們，你只要瞭解你明天加入這個團隊所要知道的內容就行了。
對於水晶方法論，根據方法論的輕重可以分爲透明水晶和橙色水晶等。透明水晶一般是輕量級的團隊適用。不管是哪種水晶，都會對團隊的角色，團隊的工件和產出，核心實踐，支持過程等進行定義。
5. XP（極限編程）
關鍵詞：UserStory 測試驅動 結對編程 持續集成 重構小版本發佈 溝通
ExtremeProgramming（極限編程，簡稱XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與 WardCunningham共事時，就一直共同探索着新的軟件開發方法，希望能使軟件開發更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟件開發的前提條件、可能行以及面臨的困難。1996年三月，Kent終於在爲DaimlerChrysler所做的一個項目中引入了新的軟件開發觀念——XP。
XP是一個輕量級的、靈巧的軟件開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比較簡單的小週期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。
XP採用緊湊的迭代開發方式。強調交流、簡潔、反饋、勇敢 四種價值觀。強調能滿足用戶需求的可用的軟件（working software)爲最終目標，而不是漂亮的文檔。XP通過12條原則來保證目標的達成。
- 通過客戶、開發人員、經理三方共同參加的計劃遊戲（planning game）來確定開發計劃
- 小版本發佈----儘快發佈，儘早發佈
- 通過系統隱喻（metaphor)來讓每個人瞭解整個系統
- 簡單設計----爲明確的功能進行最優的設計，不考慮未來可能需要的功能。
- 重構（refactoring）---不斷優化系統設計，使之保持簡單
- 單元測試----先寫測試，後寫代碼
- 結對編程(pair programming)----系統的每一行代碼都是2個人用一個鍵盤完成的。
- 代碼集體擁有--開發隊伍中任何人可以修改任何其他人的代碼，代碼不屬於某個個人。
- 持續集成----至少每天將整個系統集成一次，保持一個能運轉的系統。
- 40小時工作制----保證休息，保持體力
- 現場客戶----客戶自己也是軟件開發隊伍的重要一份子
- 編碼標準----必須有統一的編碼規範，確保代碼的可讀性
6.ASD（Adaptive Software Development）-自適應軟件開發
關鍵詞：領導 預測 協作 學習 自適應
這種方法強調的是速度和靈活性。它最適合這種場合: 公司需要應用軟件能夠迅速見效，還能隨客戶使用需求的增長而靈活變化。這種方法的發明者是Jim Highsmith。預測—協作—學習是自適應的模型的。“預測—協作—學習”不斷迭代，從而讓團隊不斷進化，不斷適應多變的環境。
預測—就是對目標做一個分析，給出一個大的方向，但不要太具體，但是大方向一定要對。這不僅是提供給團隊目標，還有就是讓團隊中的每個人會因爲這個目標而興奮，而產生激情。在這個過程中，項目組中要定期的散焦，在一個過程開始時不要太關注於細節實現，而過程進行時要從散焦變成聚焦，逐步協商合作，統一每個人的思想，逼近正確目標，以爲後續的工作提供可靠的保證。
協作—第一個障礙是強權管理，第二個障礙是個人主義。相互信任、相互尊重、相互參與、相互承諾是創造雙贏的核心。無論是和客戶也好，還是人與人之間也好，還是公司與公司也好，協作絕對是一個人，一個團隊，一個公司最具競爭力的核心。能不能在內部和外部出現協作，是能否自動適應各種環境的重要因素。協作需要的是努力得整合自己和別人觀點的分歧。
學習—學習是一種態度。自我批評、反饋、信息共享是其核心。我們一定要不停地問自己至少下面三個問題：和客戶討論時，我們要反覆地問，“我們在做正確的事嗎？”，在設計編碼測試時，我們要反覆地問，“我們用正確的手段做這件事嗎？”，在事後分析時，我們也要反覆地問，“還能有更好的方法做這件事嗎？”，在項目過程中要給予這種時間進行反饋、自我批評、並交流個人的心得體會。於是，我們就在一種高速—慢速—再高速—再慢速—超高速的發展。