隨着敏捷軟件開發宣言的簽署和發佈，多個敏捷方法框架在全球得到傳播和使用。因爲各個敏捷方法框架由不同的專家組維護，所以各個方法有不同的表述方式，有不同的着眼點和側重點。本文將爲你介紹敏捷開發方法框架的共同特徵，理解與傳統軟件工程的聯繫和不同。
短迭代的生命週期模型
生命週期是事物發展的客觀規律，軟件同樣存在生命週期。早期的軟件生命週期往往是說“軟件從計劃、需求開始，經歷分析設計、實現、部署、維護，直到最後逐漸消亡的”。這是受到了第一個軟件生命週期模型—瀑布型生命週期影響，上述語句實質上簡要的描述了瀑布型生命週期。現在的軟件生命週期不再只考慮瀑布型生命週期，另外常見的軟件生命週期模型有原型模型、螺旋模型、迭代模型。所以現在的軟件生命週期說明應當不再包括瀑布型生命週期中的典型階段。本書對軟件生命週期及軟件生命週期模型採用如下定義：
軟件生命週期是指軟件的產生直到報廢的全部過程。
軟件生命週期模型是指人們爲開發更好的軟件而歸納總結的軟件生命週期的典型實踐參考。
敏捷軟件開發明確對生命週期模型提出了要求：短迭代開發。迭代模型的歷史可以追溯到上世紀50年代，但以往的迭代模型並沒有對迭代週期長度提出要求。而在敏捷軟件開發中，迭代週期長度一般不超過2個月，而常見的迭代週期是2周到4周，因此可以稱之爲“短迭代”。
有些敏捷軟件開發在主開發過程前安排有預研或計劃或架構或需求階段等等，在主開發過程後安排有系統集成測試或驗收測試或試運行等等，這樣做並不違反敏捷開發原則，但其主開發過程應當採用短迭代開發，而且主開發過程的工期應當佔有顯著的比例，形成多個短迭代。
敏捷開發講究固定的節奏，建議按照固定的節奏開發，所以短迭代的週期長度在開始選定之後，一般不作改變。同樣的原因，敏捷迭代與迭代之間一般不安排緩衝期，上個迭代未完成的內容放到下個迭代中進行處理。
敏捷開發迭代與瀑布生命週期的階段是不同的。瀑布型中需求分析階段的產物一般是需求規格說明書，不同階段的產物是不同的；而敏捷開發迭代的產物是軟件本身，前期迭代的產物也許不完整，但各個敏捷開發迭代的產物是一致的、逐步改進完善的軟件本身。
開發中可運行的軟件
軟件最終是需要運行的，而正在開發中的軟件往往是難以運行的。在瀑布型生命週期和衍生於瀑布型的其他多個生命週期模型中，爲了保證最終運行的軟件滿足用戶的需要，安排了多個對於文檔的里程碑評審。而敏捷軟件開發則是儘快的把軟件運行起來，主要根據可運行的軟件來判斷軟件是否滿足用戶需要。顯然的，通過軟件本身來判斷比起通過文檔來判斷，更加直接，更加準確。
爲了讓開發中的軟件可運行，敏捷軟件開發在這方面的基本要求是敏捷開發迭代的產物可以運行，也即是每個迭代至少得到一次可運行的軟件。
而敏捷軟件開發推薦更加快速更高頻度的獲得可運行的軟件，這樣帶來更大的好處。極限的，每次代碼修改都能得到可運行的軟件，這樣的做法叫做“持續集成”（下文將詳細說明）。按照得到可運行軟件頻率從高到低，得到下列排序：
1， 持續集成— 一天之內可能集成多次
2， 每日集成
3， 每週或每雙週集成
4， 每迭代集成
爲了判斷可運行的軟件滿足用戶需要並得到高質量產出，敏捷軟件開發在得到可運行軟件的同時還常常採用如下方法：
1， 靜態代碼檢查
2， 自動化測試
3， 產品展示
4， 用戶試用
短線溝通和快速反饋
現代管理學的研究表明管理者在溝通方面花費了大量的時間，參與方數量的線性增長將帶來溝通工作量的指數增長。敏捷軟件開發講究短線溝通和快速反饋，在這方面的基本要求是安排用戶檢查每個迭代的可運行產物。推薦面對面的交流，爲了密切交流，辦公環境值得爲此進行改變，讓團隊的溝通更加便捷，比如整個團隊在相同的房間裏，位置接近，大會議桌式分佈。
快速反饋的範圍包括了客戶、領導、同伴，希望客戶能夠快速的告訴團隊“這個樣子不是我想要的”，XP推薦現場客戶，這樣反饋更加及時。
變化的需求和架構
瀑布型生命週期假設在需求里程碑之後，需求可以凍結；而敏捷開發不做需求可以凍結的假設。瀑布型生命週期假設在設計里程碑之後，設計可以凍結，而敏捷開發也不做設計可以凍結的假設。
相反的，敏捷開發認爲需求變更和設計變化是正常的，爲此利用短迭代的機會，不斷的澄清需求，設計儘量不做超前設計，將設計濃縮到架構，而架構也不是不變的，架構在每個迭代中將會演進。
