迭代軟件開發(fā)流程

1、1. 傳統(tǒng)開發(fā)流程的問題傳統(tǒng)的軟件開發(fā)流程是一個文檔驅(qū)動的流程，它將整個軟件開發(fā)過程劃分為順序相接的幾個階段，每個階段 都必需完成全部規(guī)定的任務(wù)（文檔）后才能夠進(jìn)入下一個階段。如必須完成全部的系統(tǒng)需求規(guī)格說明書之后才能夠進(jìn)入概要設(shè)計階段，編碼必需在系統(tǒng)設(shè)計完成之后才能夠進(jìn)行。這就意味著只有當(dāng)所有的系統(tǒng)模塊全部 開發(fā)完成之 后，我們才進(jìn)行系統(tǒng)集成，對于一個由上百個模塊組的復(fù)雜系統(tǒng)來說，這是一個非常艱巨而漫長 的工作。廊的開爰孫程_瀑布範(fàn)隨著我們所開發(fā)的軟件項目越來越復(fù)雜，傳統(tǒng)的瀑布型開發(fā)流程不斷地暴露岀以下問題：需求或設(shè)計中的錯誤往往只有到了項目后期才能夠被發(fā)現(xiàn)例如：系統(tǒng)交付客戶之后才發(fā)現(xiàn)原先對

2、于需 求的理解是錯誤的，系統(tǒng)設(shè)計中的問題要到測試階段才能被發(fā)現(xiàn)。對于項目風(fēng)險的控制能力較弱項目風(fēng)險在項目開發(fā)較晚的時候才能夠真正降低，往往是經(jīng)過系統(tǒng)測試 之后，才能確定該設(shè)計是否能夠真正滿足系統(tǒng)需求。軟件項目常常延期完成或開發(fā)費用超岀預(yù)算項目開發(fā)進(jìn)度往往會被意外發(fā)生的問題所打亂，需要進(jìn)行 返工或其他一些額外的開發(fā)周期，造成項目延期或費用超支。項目管理人員專注于文檔的完成和審核來估計項目的進(jìn)展情況所以項目經(jīng)理對于項目狀態(tài)的估計往往 是不準(zhǔn)確的，當(dāng)他回答系統(tǒng)已完成了80%的開發(fā)任務(wù)時，剩下20%的開發(fā)任務(wù)實際上消耗的是整個項目80%的開發(fā)資源。在傳統(tǒng)的瀑布模型中，需求和設(shè)計中的問題是無法在項目開發(fā)

3、的前期被檢測岀來的，只有當(dāng)?shù)谝淮蜗到y(tǒng)集成時， 這些設(shè)計缺陷才會在測試中暴露岀來，從而導(dǎo)致一系列的返工：重新設(shè)計、編碼、測試，進(jìn)而導(dǎo)致項目的延期 和開發(fā)成本的上升。傳統(tǒng)瀑布模型的問題*覲才食圧就讓缺屢*咖 的幵則加莊駅津甜試上2. 采用迭代化開發(fā)控制項目風(fēng)險為了解決傳統(tǒng)軟件開發(fā)流程中的問題，我們建議采用迭代化的開發(fā)方法來取代瀑布模型。在瀑布模型中，我 們要完成的是整個軟件系統(tǒng)開發(fā)這個大目標(biāo)。在迭代化的方法中，我們將整個項目的開發(fā)目標(biāo)劃分成為一些更易于完成和達(dá)到的階段性小目標(biāo)，這些小目標(biāo)都有一個定義明確的階段性評估標(biāo)準(zhǔn)。迭代就是為了完成一定 的階段性目標(biāo)而所從事的一系列開發(fā)活動，在每個迭代開始前都

4、要根據(jù)項目當(dāng)前的狀態(tài)和所要達(dá)到的階段性 目標(biāo)制定迭代計劃，整個迭代過程包含了需求、設(shè)計、實施（編碼）、部署、測試等各種類型的開發(fā)活動，迭代完成之后需要對迭代完成的結(jié)果進(jìn)行評估，并以此為依據(jù)來制定下一次迭代的目標(biāo)。需求與傳統(tǒng)的瀑布式開發(fā)模型相比較，迭代化開發(fā)具有以下特點：允許變更需求需求總是會變化，這是事實。給項目帶來麻煩的常常主要是需求變化和需求”蠕變，它們會導(dǎo)致延期交付、工期延誤、客戶不滿 意、開發(fā)人員受挫。通過向用戶演示迭代所產(chǎn)生的部分系統(tǒng)功能，我們可以 盡早地收集用戶對于系統(tǒng)的反饋，及時改正對于用戶需求的理解偏差，從而保證開發(fā)岀來的系統(tǒng)真正地解決客戶的問題。逐步集成元素在傳統(tǒng)的項目開發(fā)中

5、，由于要求一下子集成系統(tǒng)中所有的模塊，集成階段往往要占到整個項目很大比例 的工作量（最 高可達(dá)40%），這一階段的工作經(jīng)常是不確定并且非常棘手。在迭代式方法中，集成可 以說是連續(xù)不斷的，每一次迭代都會增量式集成一些新的系統(tǒng)功能，要集成的元素都比過去少得多，所以工作量和難度都是比較低的。盡早降低風(fēng)險迭代化開發(fā)的主要指導(dǎo)原則就是以架構(gòu)為中心，在早期的迭代中所要解決的主要問題就是盡快確定系統(tǒng) 架構(gòu)，通過幾次迭代來盡快地設(shè)計岀能夠滿足核心需求的系統(tǒng)架構(gòu)，這樣可以迅速降低整個項目的風(fēng) 險。等到系統(tǒng)架構(gòu)穩(wěn)定之后，項目的風(fēng)險就比較低了，這個時候再去實現(xiàn)系統(tǒng)中尚未完成的功能，進(jìn)而完成整個項目。有助于提高團(tuán)隊的

6、士氣開發(fā)人員通過每次迭代都可以在短期內(nèi)看到自己的工作成果，從而有助于他們增強信心，更好地完成開 發(fā)任務(wù)。而在非迭代式開發(fā)中，開發(fā)人員只有在項目接近尾聲時才能看到開發(fā)的結(jié)果，在此之前的相當(dāng) 長時間，大家還是在不確定性中摸索前近。生成更高質(zhì)量的產(chǎn)品每次迭代都會產(chǎn)生一個可運行的系統(tǒng)，通過對這個可運行系統(tǒng)進(jìn)行測試，我們在早期的迭代中就可以及 時發(fā)現(xiàn)缺陷并改正，性能上的瓶頸也可以盡早發(fā)現(xiàn)并處理。因為在每次迭代中總是不斷地糾正錯誤，我 們可以得到更高質(zhì)量的產(chǎn)品。保證項目開發(fā)進(jìn)度每次迭代結(jié)束時都會進(jìn)行評估，來判斷該次迭代有沒有達(dá)到預(yù)定的目標(biāo)。項目經(jīng)理可以很清楚地知道有 哪些需求已經(jīng)實現(xiàn)了，并且比較準(zhǔn)確地估計

7、項目的狀態(tài)，對項目的開發(fā)進(jìn)度進(jìn)行必要的調(diào)整，保證項目 按時完成。容許產(chǎn)品進(jìn)行戰(zhàn)術(shù)改變迭代化的開發(fā)具有更大的靈活性，在迭代過程中可以隨時根據(jù)業(yè)務(wù)情況或市場環(huán)境來對產(chǎn)品的開發(fā)進(jìn)行 調(diào)整。例如為了同現(xiàn)有的同類產(chǎn)品競爭，可以決定采用搶先競爭對手一步的方法，提前發(fā)布一個功能簡 化的產(chǎn)品。迭代流程自身可在進(jìn)行過程中得到改進(jìn)和精煉一次迭代結(jié)束時的評估不僅要從產(chǎn)品和進(jìn)度的角度來考察項目的情況，而且還要分析組織和流程本身有 什么待改進(jìn)之處，以便在下次迭代中更好地完成任務(wù)。迭代化開發(fā)流程頂目進(jìn)聲迭代化方法解決的主要是對于風(fēng)險的控制問題，從下圖可以看岀，傳統(tǒng)的開發(fā)流程中系統(tǒng)的風(fēng)險要到項目開發(fā) 的后期（主要是測試階段

8、）才能夠被真正降低。而迭代化開發(fā)中的風(fēng)險，可以在項目開發(fā)的早期通過幾次迭代來盡快地解決掉。在早期的迭代中一旦遇到問題，如某一個迭代沒有完成預(yù)定的目標(biāo)，我們還可以及時調(diào)整開發(fā)進(jìn)度以保證項目按時完成。一般到了項目開發(fā)的后期（風(fēng)險受控階段），由于大部分高風(fēng)險的因素（如需求、架構(gòu)、性能等）都已經(jīng)解決，這時候只需要投入更多的資源去實現(xiàn)剩余的需求即可。這個階段的項目開發(fā)具有很強的可控性，從而保證我們按時交付一個高質(zhì)量的軟件系統(tǒng)。鳳險鳳險鳳磴受控階段探索階段解決盼段迭代化開發(fā)不是一種高深的軟件工程理論，它提供了一種控制項目風(fēng)險的非常有效的機制。在日常的工作我們 也經(jīng)常地應(yīng)用到這一基本思想，如對于一個非常大型

9、的工程項目，我們經(jīng)常會把它分為幾期來分步實施，從而把復(fù)雜的問題分解為相對容易解決的小問題，并且能夠在較短周期內(nèi)看到部分系統(tǒng)實現(xiàn)的效果，通過盡早暴露問題來幫助我們及早調(diào)整我們的開發(fā)資源，加強項目進(jìn)度的可控程度，保證項目的按時完成。3. 管理迭代化的軟件項目當(dāng)我們在實際工作中實踐迭代化思想時，Rational統(tǒng)一開發(fā)流程 RUP（Rational Unified Process）可以給予我們實踐的指導(dǎo)。RUP是一個通用的軟件流程框架，它是一個以架構(gòu)為中心、用例驅(qū)動的迭代化軟件開發(fā)流程。RUP是從幾千個軟件 項目的實踐經(jīng)驗中總結(jié)岀來的，對于實際的項目具有很強的指導(dǎo)意義，是軟件開發(fā)行業(yè) 事實上的行業(yè)標(biāo)

10、準(zhǔn)。3.1軟件開發(fā)的四個階段在RUP中，我們把軟件開發(fā)生命周期劃分為四個階段，每個階段的結(jié)束標(biāo)志就是一個主要的里程碑（如下圖 所示）。產(chǎn)品仕 11 1生命周期生奇周期彊初撓作產(chǎn)品發(fā)布目標(biāo)里揑陳構(gòu)架里程曄性能里程殖里握誨對間這四個階段主要是為了達(dá)到以下階段性的目標(biāo)里程碑：* 先啟(Inception):確定項目開發(fā)的目標(biāo)和范圍精化(Elaboration):確定系統(tǒng)架構(gòu)和明確需求構(gòu)建(Construction):實現(xiàn)剩余的系統(tǒng)功能* 產(chǎn)品化仃ransition):完成軟件的產(chǎn)品化工作，將系統(tǒng)移交給客戶每個目標(biāo)里程碑都是一個商業(yè)上的決策點，如先啟階段結(jié)束之后，我們就要決定這個項目是否可行、是否要繼

11、 續(xù)做這個項目。每一個階段都是由里程碑來決定的，判斷一個階段是否結(jié)束的標(biāo)志就是看項目當(dāng)前的狀態(tài)是否 滿足里碑中所規(guī)定的條件。從這種階段劃分模式中可以看岀，項目的主要風(fēng)險集中在前兩個階段。在精化階段中經(jīng)過幾次迭代后，我們要 為系統(tǒng)建立一個穩(wěn)定的架構(gòu)，在此之后再實現(xiàn)更多的系統(tǒng)需求時，不再需要對該架構(gòu)進(jìn)行修改。同時，在精化階段中，我們通過迭代來不斷地收集用戶的需求反饋，便得系統(tǒng)的需求逐步地明確和完整。3.2關(guān)于開發(fā)資源的分配基于RUP風(fēng)險驅(qū)動的迭代化開發(fā)模式，我們只需要在項目的先啟階段投入少量的資源，對項目的開發(fā)前景和 商業(yè)可行性進(jìn)行一些探索性的研究。在精化階段再投入多一些的研發(fā)力量來實現(xiàn)一些與架構(gòu)

12、相關(guān)的核心需求,逐步地把系統(tǒng)架構(gòu)搭建起來。等到這兩個階段結(jié)束之后，項目的一些主要風(fēng)險和問題也得到了解決，這時候再 投入整個團(tuán)隊進(jìn)行全面的系統(tǒng)開發(fā)。等到產(chǎn)品化階段，主要的開發(fā)任務(wù)已經(jīng)全部完成，項目不再需要維持一 個大規(guī)模的開發(fā)團(tuán)隊，開發(fā)資源也可以隨之而減少。在項目開發(fā)周期中，開發(fā)資源的分配可以如下圖所示。這樣安排可以最充分有效地利用公司的開發(fā)資源，緩解軟件公司對于人力資源不斷增長的需求，從而降低成本。 另外一方面，由于前兩個階段(先啟和精化)的風(fēng)險較高，我們只是投入部分的資源，一旦發(fā)生返工或是項目目標(biāo)的改變，我們也可以將資源浪費降到最低點。在傳統(tǒng)的軟件開發(fā)流程中，對于開發(fā)資源的分配基本上是貫穿整

13、個項目周期而不變的，資源往往沒有得到充分有效地利用?；谶@種資源分配模式，一個典型的項目在項目進(jìn)度和所完成的工作量之間的關(guān)系可能如下表中的數(shù)據(jù)所示。先啟精化構(gòu)建產(chǎn)品化工作量5%20%65%10%進(jìn)度10%30%50%10%3.3迭代策略關(guān)于迭代計劃的安排，通常有以下四種典型的策略模式： 增量式(Incremental)這種模式的特點是項目架構(gòu)的風(fēng)險較小(往往是開發(fā)一些重復(fù)性的項目)，所以精化階段只需要一個迭代。但項目的開發(fā)工作量較大，構(gòu)建階段需要有多次迭代來實現(xiàn)，每次迭代都在上一次迭代的基礎(chǔ)上增 加實現(xiàn)一部分的系統(tǒng)功能，通過迭代的進(jìn)行而逐步實現(xiàn)整個系統(tǒng)的功能。演進(jìn)式(Evolutionary)

14、當(dāng)項目架構(gòu)的風(fēng)險較大時(從未開發(fā)過類似項目)，需要在精化階段通過多次迭代來建立系統(tǒng)的架構(gòu)，架構(gòu)是通過多次迭代的探索，逐步演化而來的。當(dāng)架構(gòu)建立時，往往系統(tǒng)的功能也已經(jīng)基本實現(xiàn)，所以 構(gòu)建階段只需要一次迭代。增量提交(Incremental Delivery)這種模式的特點產(chǎn)品化階段的迭代較多，比較常見的例子是項目的難度并不大，但業(yè)務(wù)需求在不斷地發(fā)生變化，所以需要通過迭代來不斷地部署完成的系統(tǒng)；但同時又要不斷地收集用戶的反饋來完善系統(tǒng) 需求，并通過后續(xù)的迭代來補充實現(xiàn)這些需求。應(yīng)用這種策略時要求系統(tǒng)架構(gòu)非常穩(wěn)定，能夠適應(yīng)滿足后續(xù)需求變化的要求。單次迭代(Grand Design)傳統(tǒng)的瀑布模型可

15、以看作是迭代化開發(fā)的一個特例，整個開發(fā)流程只有一次迭代。但這種模式有一個固 有的弱點，由于它對風(fēng)險的控制能力較差，往往會在產(chǎn)品化階段產(chǎn)生一些額外的迭代，造成項目的延誤。這幾種迭代策略只是一些典型模式的代表，實際應(yīng)用中應(yīng)根據(jù)實際情況靈活應(yīng)用，最常見的迭代計劃往往是這 幾種模式的組合。3.4制定項目開發(fā)計劃在迭代 化的開發(fā)模式中，項目開發(fā)計劃也是隨著項目的進(jìn)展而不斷細(xì)化、調(diào)整并完善的。傳統(tǒng)的項目開發(fā)計 劃是在項目早期制定的，項目經(jīng)理總是試圖在項目的一開始就制定一個非常詳細(xì)完善的開發(fā)計劃。與之相反，迭代開發(fā)模式認(rèn)為在項目早期只需要制定一個比較粗略的開發(fā)計劃，因為隨著項目的進(jìn)展，項目的狀態(tài)在不斷 地發(fā)生變 化，項目經(jīng)理需要隨時根據(jù)迭代的結(jié)果來對項目計劃進(jìn)行調(diào)整，并制定下一次迭代的詳細(xì)計劃。在RUP中，我們把項目開發(fā)計劃分為以下三部分：項目計劃確定整個項目的開發(fā)目標(biāo)和進(jìn)度安排，包括每一個階段的起止時間段。階段計劃當(dāng)前階段中包含有幾個迭代，每一次迭代要達(dá)到的目標(biāo)以及進(jìn)度安排。迭代計劃針對