1. 傳統開發流程的問題
傳統的軟件開發流程是一個文檔驅動的流程，它將整個軟件開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務（文檔）后才能夠進入下一個階段。如必須完成全部的系統需求規格說明書之后才能夠進入概要設計階段，編碼必需在系統設計完成之后才能夠進行。這就意味著只有當所有的系統模塊全部開發完成之后，我們才進行系統集成，對于一個由上百個模塊組的復雜系統來說，這是一個非常艱巨而漫長的工作。

隨著我們所開發的軟件項目越來越復雜，傳統的瀑布型開發流程不斷地暴露出以下問題：

• 需求或設計中的錯誤往往只有到了項目后期才能夠被發現例如：系統交付客戶之后才發現原先對于需求的理解是錯誤的，系統設計中的問題要到測試階段才能被發現。
• 對于項目風險的控制能力較弱項目風險在項目開發較晚的時候才能夠真正降低，往往是經過系統測試之后，才能確定該設計是否能夠真正滿足系統需求。
• 軟件項目常常延期完成或開發費用超出預算項目開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發周期，造成項目延期或費用超支。
• 項目管理人員專注于文檔的完成和審核來估計項目的進展情況所以項目經理對于項目狀態的估計往往是不準確的，當他回答系統已完成了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個項目80%的開發資源。

在傳統的瀑布模型中，需求和設計中的問題是無法在項目開發的前期被檢測出來的，只有當第一次系統集成時，這些設計缺陷才會在測試中暴露出來，從而導致一系列的返工：重新設計、編碼、測試，進而導致項目的延期和開發成本的上升。

2. 采用迭代化開發控制項目風險
為了解決傳統軟件開發流程中的問題，我們建議采用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟件系統開發這個大目標。在迭代化的方法中，我們將整個項目的開發目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據項目當前的狀態和所要達到的階段性目標制定迭代計劃，整個迭代過程包含了需求、設計、實施（編碼）、部署、測試等各種類型的開發活動，迭代完成之后需要對迭代完成的結果進行評估，并以此為依據來制定下一次迭代的目標。

與傳統的瀑布式開發模型相比較，迭代化開發具有以下特點：

• 允許變更需求
  需求總是會變化，這是事實。給項目帶來麻煩的常常主要是需求變化和需求"蠕變"，它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。通過向用戶演示迭代所產生的部分系統功能，我們可以盡早地收集用戶對于系統的反饋，及時改正對于用戶需求的理解偏差，從而保證開發出來的系統真正地解決客戶的問題。
• 逐步集成元素
  在傳統的項目開發中，由于要求一下子集成系統中所有的模塊，集成階段往往要占到整個項目很大比例的工作量（最高可達40%），這一階段的工作經常是不確定并且非常棘手。在迭代式方法中，集成可以說是連續不斷的，每一次迭代都會增量式集成一些新的系統功能，要集成的元素都比過去少得多，所以工作量和難度都是比較低的。
• 盡早降低風險
  迭代化開發的主要指導原則就是以架構為中心，在早期的迭代中所要解決的主要問題就是盡快確定系統架構，通過幾次迭代來盡快地設計出能夠滿足核心需求的系統架構，這樣可以迅速降低整個項目的風險。等到系統架構穩定之后，項目的風險就比較低了，這個時候再去實現系統中尚未完成的功能，進而完成整個項目。
• 有助于提高團隊的士氣
  開發人員通過每次迭代都可以在短期內看到自己的工作成果，從而有助于他們增強信心，更好地完成開發任務。而在非迭代式開發中，開發人員只有在項目接近尾聲時才能看到開發的結果，在此之前的相當長時間，大家還是在不確定性中摸索前近。
• 生成更高質量的產品
  每次迭代都會產生一個可運行的系統，通過對這個可運行系統進行測試，我們在早期的迭代中就可以及時發現缺陷并改正，性能上的瓶頸也可以盡早發現并處理。因為在每次迭代中總是不斷地糾正錯誤，我們可以得到更高質量的產品。
• 保證項目開發進度
  每次迭代結束時都會進行評估，來判斷該次迭代有沒有達到預定的目標。項目經理可以很清楚地知道有哪些需求已經實現了，并且比較準確地估計項目的狀態，對項目的開發進度進行必要的調整，保證項目按時完成。
• 容許產品進行戰術改變
  迭代化的開發具有更大的靈活性，在迭代過程中可以隨時根據業務情況或市場環境來對產品的開發進行調整。例如為了同現有的同類產品競爭，可以決定采用搶先競爭對手一步的方法，提前發布一個功能簡化的產品。
• 迭代流程自身可在進行過程中得到改進和精煉
  一次迭代結束時的評估不僅要從產品和進度的角度來考察項目的情況，而且還要分析組織和流程本身有什么待改進之處，以便在下次迭代中更好地完成任務。

迭代化方法解決的主要是對于風險的控制問題，從下圖可以看出，傳統的開發流程中系統的風險要到項目開發的后期（主要是測試階段）才能夠被真正降低。而迭代化開發中的風險，可以在項目開發的早期通過幾次迭代來盡快地解決掉。在早期的迭代中一旦遇到問題，如某一個迭代沒有完成預定的目標，我們還可以及時調整開發進度以保證項目按時完成。一般到了項目開發的后期（風險受控階段），由于大部分高風險的因素（如需求、架構、性能等）都已經解決，這時候只需要投入更多的資源去實現剩余的需求即可。這個階段的項目開發具有很強的可控性，從而保證我們按時交付一個高質量的軟件系統。

迭代化開發不是一種高深的軟件工程理論，它提供了一種控制項目風險的非常有效的機制。在日常的工作我們也經常地應用到這一基本思想，如對于一個非常大型的工程項目，我們經常會把它分為幾期來分步實施，從而把復雜的問題分解為相對容易解決的小問題，并且能夠在較短周期內看到部分系統實現的效果，通過盡早暴露問題來幫助我們及早調整我們的開發資源，加強項目進度的可控程度，保證項目的按時完成。

3. 管理迭代化的軟件項目
當我們在實際工作中實踐迭代化思想時，Rational統一開發流程RUP(Rational Unified Process)可以給予我們實踐的指導。RUP是一個通用的軟件流程框架，它是一個以架構為中心、用例驅動的迭代化軟件開發流程。RUP是從幾千個軟件項目的實踐經驗中總結出來的，對于實際的項目具有很強的指導意義，是軟件開發行業事實上的行業標準。

XPQIB>3.1 軟件開發的四個階段
在RUP中，我們把軟件開發生命周期劃分為四個階段，每個階段的結束標志就是一個主要的里程碑（如下圖所示）。

這四個階段主要是為了達到以下階段性的目標里程碑：

• 先啟(Inception)：確定項目開發的目標和范圍
• 精化(Elaboration)：確定系統架構和明確需求
• 構建(Construction)：實現剩余的系統功能
• 產品化(Transition)：完成軟件的產品化工作，將系統移交給客戶

每個目標里程碑都是一個商業上的決策點，如先啟階段結束之后，我們就要決定這個項目是否可行、是否要繼續做這個項目。每一個階段都是由里程碑來決定的，判斷一個階段是否結束的標志就是看項目當前的狀態是否滿足里碑中所規定的條件。

從這種階段劃分模式中可以看出，項目的主要風險集中在前兩個階段。在精化階段中經過幾次迭代后，我們要為系統建立一個穩定的架構，在此之后再實現更多的系統需求時，不再需要對該架構進行修改。同時，在精化階段中，我們通過迭代來不斷地收集用戶的需求反饋，便得系統的需求逐步地明確和完整。

3.2 關于開發資源的分配
基于RUP風險驅動的迭代化開發模式，我們只需要在項目的先啟階段投入少量的資源，對項目的開發前景和商業可行性進行一些探索性的研究。在精化階段再投入多一些的研發力量來實現一些與架構相關的核心需求，逐步地把系統架構搭建起來。等到這兩個階段結束之后，項目的一些主要風險和問題也得到了解決，這時候再投入整個團隊進行全面的系統開發。等到產品化階段，主要的開發任務已經全部完成，項目不再需要維持一個大規模的開發團隊，開發資源也可以隨之而減少。在項目開發周期中，開發資源的分配可以如下圖所示。

這樣安排可以最充分有效地利用公司的開發資源，緩解軟件公司對于人力資源不斷增長的需求，從而降低成本。另外一方面，由于前兩個階段（先啟和精化）的風險較高，我們只是投入部分的資源，一旦發生返工或是項目目標的改變，我們也可以將資源浪費降到最低點。在傳統的軟件開發流程中，對于開發資源的分配基本上是貫穿整個項目周期而不變的，資源往往沒有得到充分有效地利用。

基于這種資源分配模式，一個典型的項目在項目進度和所完成的工作量之間的關系可能如下表中的數據所示。

3.3 迭代策略
關于迭代計劃的安排，通常有以下四種典型的策略模式：

• 增量式(Incremental)
  這種模式的特點是項目架構的風險較?。ㄍ情_發一些重復性的項目），所以精化階段只需要一個迭代。但項目的開發工作量較大，構建階段需要有多次迭代來實現，每次迭代都在上一次迭代的基礎上增加實現一部分的系統功能，通過迭代的進行而逐步實現整個系統的功能。
• 演進式(Evolutionary)
  當項目架構的風險較大時（從未開發過類似項目），需要在精化階段通過多次迭代來建立系統的架構，架構是通過多次迭代的探索，逐步演化而來的。當架構建立時，往往系統的功能也已經基本實現，所以構建階段只需要一次迭代。
• 增量提交(Incremental Delivery)
  這種模式的特點產品化階段的迭代較多，比較常見的例子是項目的難度并不大，但業務需求在不斷地發生變化，所以需要通過迭代來不斷地部署完成的系統；但同時又要不斷地收集用戶的反饋來完善系統需求，并通過后續的迭代來補充實現這些需求。應用這種策略時要求系統架構非常穩定，能夠適應滿足后續需求變化的要求。
• 單次迭代(Grand Design)
  傳統的瀑布模型可以看作是迭代化開發的一個特例，整個開發流程只有一次迭代。但這種模式有一個固有的弱點，由于它對風險的控制能力較差，往往會在產品化階段產生一些額外的迭代，造成項目的延誤。

這幾種迭代策略只是一些典型模式的代表，實際應用中應根據實際情況靈活應用，最常見的迭代計劃往往是這幾種模式的組合。

3.4 制定項目開發計劃
在迭代化的開發模式中，項目開發計劃也是隨著項目的進展而不斷細化、調整并完善的。傳統的項目開發計劃是在項目早期制定的，項目經理總是試圖在項目的一開始就制定一個非常詳細完善的開發計劃。與之相反，迭代開發模式認為在項目早期只需要制定一個比較粗略的開發計劃，因為隨著項目的進展，項目的狀態在不斷地發生變化，項目經理需要隨時根據迭代的結果來對項目計劃進行調整，并制定下一次迭代的詳細計劃。

在RUP中，我們把項目開發計劃分為以下三部分：

• 項目計劃
  確定整個項目的開發目標和進度安排，包括每一個階段的起止時間段。
• 階段計劃
  當前階段中包含有幾個迭代，每一次迭代要達到的目標以及進度安排。
• 迭代計劃
  針對當前迭代的詳細開發計劃，包括開發活動以及相關資源的分配。

項目開發計劃也是完全體現迭代化的思想，每次迭代中項目經理都會根據項目情況來不斷地調整和細化項目開發計劃。迭代計劃是在對上一次迭代結果進行評估的基礎上制定的，如果上一次迭代達到了預定的目標，那么當前迭代只需要解決剩下的問題；如果上一次迭代中留有一些問題還沒有解決，則當前迭代還需要繼續去解決這些問題。所以必須注意，迭代是不能重疊的，即你還沒有完成當前迭代時，你決不能進入下一迭代，因為下一次迭代的計劃是根據當前迭代的結果而制定的。