隨著敏捷軟件開發宣言的簽署和發布，多個敏捷方法框架在全球得到傳播和使用。因為各個敏捷方法框架由不同的專家組維護，所以各個方法有不同的表述方式，有不同的著眼點和側重點。本文將為你介紹敏捷開發方法框架的共同特征，理解與傳統軟件工程的聯系和不同。

短迭代的生命周期模型

生命周期是事物發展的客觀規律，軟件同樣存在生命周期。早期的軟件生命周期往往是說“軟件從計劃、需求開始，經歷分析設計、實現、部署、維護，直到最后逐漸消亡的”。這是受到了第一個軟件生命周期模型—瀑布型生命周期影響，上述語句實質上簡要的描述了瀑布型生命周期。現在的軟件生命周期不再只考慮瀑布型生命周期，另外常見的軟件生命周期模型有原型模型、螺旋模型、迭代模型。所以現在的軟件生命周期說明應當不再包括瀑布型生命周期中的典型階段。本書對軟件生命周期及軟件生命周期模型采用如下定義：

軟件生命周期是指軟件的產生直到報廢的全部過程。

軟件生命周期模型是指人們為開發更好的軟件而歸納總結的軟件生命周期的典型實踐參考。

敏捷軟件開發明確對生命周期模型提出了要求：短迭代開發。迭代模型的歷史可以追溯到上世紀50年代，但以往的迭代模型并沒有對迭代周期長度提出要求。而在敏捷軟件開發中，迭代周期長度一般不超過2個月，而常見的迭代周期是2周到4周，因此可以稱之為“短迭代”。

有些敏捷軟件開發在主開發過程前安排有預研或計劃或架構或需求階段等等，在主開發過程后安排有系統集成測試或驗收測試或試運行等等，這樣做并不違反敏捷開發原則，但其主開發過程應當采用短迭代開發，而且主開發過程的工期應當占有顯著的比例，形成多個短迭代。

敏捷開發講究固定的節奏，建議按照固定的節奏開發，所以短迭代的周期長度在開始選定之后，一般不作改變。同樣的原因，敏捷迭代與迭代之間一般不安排緩沖期，上個迭代未完成的內容放到下個迭代中進行處理。

敏捷開發迭代與瀑布生命周期的階段是不同的。瀑布型中需求分析階段的產物一般是需求規格說明書，不同階段的產物是不同的；而敏捷開發迭代的產物是軟件本身，前期迭代的產物也許不完整，但各個敏捷開發迭代的產物是一致的、逐步改進完善的軟件本身。

開發中可運行的軟件

軟件最終是需要運行的，而正在開發中的軟件往往是難以運行的。在瀑布型生命周期和衍生于瀑布型的其他多個生命周期模型中，為了保證最終運行的軟件滿足用戶的需要，安排了多個對于文檔的里程碑評審。而敏捷軟件開發則是盡快的把軟件運行起來，主要根據可運行的軟件來判斷軟件是否滿足用戶需要。顯然的，通過軟件本身來判斷比起通過文檔來判斷，更加直接，更加準確。

為了讓開發中的軟件可運行，敏捷軟件開發在這方面的基本要求是敏捷開發迭代的產物可以運行，也即是每個迭代至少得到一次可運行的軟件。

而敏捷軟件開發推薦更加快速更高頻度的獲得可運行的軟件，這樣帶來更大的好處。極限的，每次代碼修改都能得到可運行的軟件，這樣的做法叫做“持續集成”（下文將詳細說明）。按照得到可運行軟件頻率從高到低，得到下列排序：

1， 持續集成— 一天之內可能集成多次

2， 每日集成

3， 每周或每雙周集成

4， 每迭代集成

為了判斷可運行的軟件滿足用戶需要并得到高質量產出，敏捷軟件開發在得到可運行軟件的同時還常常采用如下方法：

1， 靜態代碼檢查

2， 自動化測試

3， 產品展示

4， 用戶試用

短線溝通和快速反饋

現代管理學的研究表明管理者在溝通方面花費了大量的時間，參與方數量的線性增長將帶來溝通工作量的指數增長。敏捷軟件開發講究短線溝通和快速反饋，在這方面的基本要求是安排用戶檢查每個迭代的可運行產物。推薦面對面的交流，為了密切交流，辦公環境值得為此進行改變，讓團隊的溝通更加便捷，比如整個團隊在相同的房間里，位置接近，大會議桌式分布。

快速反饋的范圍包括了客戶、領導、同伴，希望客戶能夠快速的告訴團隊“這個樣子不是我想要的”，XP推薦現場客戶，這樣反饋更加及時。

變化的需求和架構

瀑布型生命周期假設在需求里程碑之后，需求可以凍結；而敏捷開發不做需求可以凍結的假設。瀑布型生命周期假設在設計里程碑之后，設計可以凍結，而敏捷開發也不做設計可以凍結的假設。

相反的，敏捷開發認為需求變更和設計變化是正常的，為此利用短迭代的機會，不斷的澄清需求，設計盡量不做超前設計，將設計濃縮到架構，而架構也不是不變的，架構在每個迭代中將會演進。

總結

以上是生活随笔為你收集整理的试论敏捷开发方法的共同特征的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。