隨著敏捷軟件開(kāi)發(fā)宣言的簽署和發(fā)布，多個(gè)敏捷方法框架在全球得到傳播和使用。因?yàn)楦鱾€(gè)敏捷方法框架由不同的專家組維護(hù)，所以各個(gè)方法有不同的表述方式，有不同的著眼點(diǎn)和側(cè)重點(diǎn)。本文將為你介紹敏捷開(kāi)發(fā)方法框架的共同特征，理解與傳統(tǒng)軟件工程的聯(lián)系和不同。

短迭代的生命周期模型

生命周期是事物發(fā)展的客觀規(guī)律，軟件同樣存在生命周期。早期的軟件生命周期往往是說(shuō)“軟件從計(jì)劃、需求開(kāi)始，經(jīng)歷分析設(shè)計(jì)、實(shí)現(xiàn)、部署、維護(hù)，直到最后逐漸消亡的”。這是受到了第一個(gè)軟件生命周期模型—瀑布型生命周期影響，上述語(yǔ)句實(shí)質(zhì)上簡(jiǎn)要的描述了瀑布型生命周期。現(xiàn)在的軟件生命周期不再只考慮瀑布型生命周期，另外常見(jiàn)的軟件生命周期模型有原型模型、螺旋模型、迭代模型。所以現(xiàn)在的軟件生命周期說(shuō)明應(yīng)當(dāng)不再包括瀑布型生命周期中的典型階段。本書(shū)對(duì)軟件生命周期及軟件生命周期模型采用如下定義：

軟件生命周期是指軟件的產(chǎn)生直到報(bào)廢的全部過(guò)程。

軟件生命周期模型是指人們?yōu)殚_(kāi)發(fā)更好的軟件而歸納總結(jié)的軟件生命周期的典型實(shí)踐參考。

敏捷軟件開(kāi)發(fā)明確對(duì)生命周期模型提出了要求：短迭代開(kāi)發(fā)。迭代模型的歷史可以追溯到上世紀(jì)50年代，但以往的迭代模型并沒(méi)有對(duì)迭代周期長(zhǎng)度提出要求。而在敏捷軟件開(kāi)發(fā)中，迭代周期長(zhǎng)度一般不超過(guò)2個(gè)月，而常見(jiàn)的迭代周期是2周到4周，因此可以稱之為“短迭代”。

有些敏捷軟件開(kāi)發(fā)在主開(kāi)發(fā)過(guò)程前安排有預(yù)研或計(jì)劃或架構(gòu)或需求階段等等，在主開(kāi)發(fā)過(guò)程后安排有系統(tǒng)集成測(cè)試或驗(yàn)收測(cè)試或試運(yùn)行等等，這樣做并不違反敏捷開(kāi)發(fā)原則，但其主開(kāi)發(fā)過(guò)程應(yīng)當(dāng)采用短迭代開(kāi)發(fā)，而且主開(kāi)發(fā)過(guò)程的工期應(yīng)當(dāng)占有顯著的比例，形成多個(gè)短迭代。

敏捷開(kāi)發(fā)講究固定的節(jié)奏，建議按照固定的節(jié)奏開(kāi)發(fā)，所以短迭代的周期長(zhǎng)度在開(kāi)始選定之后，一般不作改變。同樣的原因，敏捷迭代與迭代之間一般不安排緩沖期，上個(gè)迭代未完成的內(nèi)容放到下個(gè)迭代中進(jìn)行處理。

敏捷開(kāi)發(fā)迭代與瀑布生命周期的階段是不同的。瀑布型中需求分析階段的產(chǎn)物一般是需求規(guī)格說(shuō)明書(shū)，不同階段的產(chǎn)物是不同的；而敏捷開(kāi)發(fā)迭代的產(chǎn)物是軟件本身，前期迭代的產(chǎn)物也許不完整，但各個(gè)敏捷開(kāi)發(fā)迭代的產(chǎn)物是一致的、逐步改進(jìn)完善的軟件本身。

開(kāi)發(fā)中可運(yùn)行的軟件

軟件最終是需要運(yùn)行的，而正在開(kāi)發(fā)中的軟件往往是難以運(yùn)行的。在瀑布型生命周期和衍生于瀑布型的其他多個(gè)生命周期模型中，為了保證最終運(yùn)行的軟件滿足用戶的需要，安排了多個(gè)對(duì)于文檔的里程碑評(píng)審。而敏捷軟件開(kāi)發(fā)則是盡快的把軟件運(yùn)行起來(lái)，主要根據(jù)可運(yùn)行的軟件來(lái)判斷軟件是否滿足用戶需要。顯然的，通過(guò)軟件本身來(lái)判斷比起通過(guò)文檔來(lái)判斷，更加直接，更加準(zhǔn)確。

為了讓開(kāi)發(fā)中的軟件可運(yùn)行，敏捷軟件開(kāi)發(fā)在這方面的基本要求是敏捷開(kāi)發(fā)迭代的產(chǎn)物可以運(yùn)行，也即是每個(gè)迭代至少得到一次可運(yùn)行的軟件。

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

1， 持續(xù)集成— 一天之內(nèi)可能集成多次

2， 每日集成

3， 每周或每雙周集成

4， 每迭代集成

為了判斷可運(yùn)行的軟件滿足用戶需要并得到高質(zhì)量產(chǎn)出，敏捷軟件開(kāi)發(fā)在得到可運(yùn)行軟件的同時(shí)還常常采用如下方法：

1， 靜態(tài)代碼檢查

2， 自動(dòng)化測(cè)試

3， 產(chǎn)品展示

4， 用戶試用

短線溝通和快速反饋

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

快速反饋的范圍包括了客戶、領(lǐng)導(dǎo)、同伴，希望客戶能夠快速的告訴團(tuán)隊(duì)“這個(gè)樣子不是我想要的”，XP推薦現(xiàn)場(chǎng)客戶，這樣反饋更加及時(shí)。

變化的需求和架構(gòu)

瀑布型生命周期假設(shè)在需求里程碑之后，需求可以凍結(jié)；而敏捷開(kāi)發(fā)不做需求可以凍結(jié)的假設(shè)。瀑布型生命周期假設(shè)在設(shè)計(jì)里程碑之后，設(shè)計(jì)可以凍結(jié)，而敏捷開(kāi)發(fā)也不做設(shè)計(jì)可以凍結(jié)的假設(shè)。

相反的，敏捷開(kāi)發(fā)認(rèn)為需求變更和設(shè)計(jì)變化是正常的，為此利用短迭代的機(jī)會(huì)，不斷的澄清需求，設(shè)計(jì)盡量不做超前設(shè)計(jì)，將設(shè)計(jì)濃縮到架構(gòu)，而架構(gòu)也不是不變的，架構(gòu)在每個(gè)迭代中將會(huì)演進(jìn)。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。