迭代化軟體開發技術
1. 傳統開發流程的問題
傳統的軟體開發流程是一個文檔驅動的流程，它將整個軟體開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務（文檔）後才能夠進入下一個階段。如必須完成全部的系統需求規格說明書之後才能夠進入概要設計階段，編碼必需在系統設計完成之後才能夠進行。這就意味著只有當所有的系統模組全部開發完成之後，我們才進行系統整合，對於一個由上百個模組組的複雜系統來說，這是一個非常艱巨而漫長的工作。
隨著我們所開發的軟體項目越來越複雜，傳統的瀑布型開發流程不斷地暴露出以下問題：需求或設計中的錯誤往往只有到了項目後期才能夠被發現例如：系統交付客戶之後才發現原先對於需求的理解是錯誤的，系統設計中的問題要到測試階段才能被發現。
對於項目風險的控制能力較弱項目風險在項目開發較晚的時候才能夠真正降低，往往是經過系統測試之後，才能確定該設計是否能夠真正滿足系統需求。
軟體項目常常延期完成或開發費用超出預算項目開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發週期，造成項目延期或費用超支。
專案管理人員專註於文檔的完成和審核來估計項目的進展情況所以專案經理對於項目狀態的估計往往是不準確的，當他回答系統已完成了80%的開發工作單位時，剩下20%的開發工作單位實際上消耗的是整個項目80%的開發資源。
在傳統的瀑布模型中，需求和設計中的問題是無法在項目開發的前期被檢測出來的，只有當第一次系統整合時，這些設計缺陷才會在測試中暴露出來，從而導致一系列的返工：重新設計、編碼、測試，進而導致項目的延期和開發成本的上升。 2. 採用迭代化開發控制項目風險
為瞭解決傳統軟體開發流程中的問題，我們建議採用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟體系統開發這個大目標。在迭代化的方法中，我們將整個項目的開發目標劃分成為一些更易於完成和達到的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據項目當前的狀態和所要達到的階段性目標制定反覆項目計劃，整個迭代過程包含了需求、設計、實施（編碼）、部署、測試等各種類型的開發活動，迭代完成之後需要對迭代完成的結果進行評估，並以此為依據來制定下一次迭代的目標。 與傳統的瀑布式開發模型相比較，迭代化開發具有以下特點：允許變更需求
需求總是會變化，這是事實。給項目帶來麻煩的常常主要是需求變化和需求"蠕變"，它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。通過向使用者示範迭代所產生的部分系統功能，我們可以儘早地收集使用者對於系統的反饋，及時改正對於使用者需求的理解偏差，從而保證開發出來的系統真正地解決客戶的問題。
逐步整合元素
在傳統的項目開發中，由於要求一下子整合系統中所有的模組，整合階段往往要佔到整個項目很大比例的工作量（最高可達40%），這一階段的工作經常是不確定並且非常棘手。在迭代式方法中，整合可以說是連續不斷的，每一次迭代都會增量式整合一些新的系統功能，要整合的元素都比過去少得多，所以工作量和難度都是比較低的。
儘早降低風險
迭代化開發的主要指導原則就是以架構為中心，在早期的迭代中所要解決的主要問題就是儘快確定系統架構，通過幾次迭代來儘快地設計出能夠滿足核心需求的系統架構，這樣可以迅速降低整個項目的風險。等到系統架構穩定之後，項目的風險就比較低了，這個時候再去實現系統中尚未完成的功能，進而完成整個項目。
有助於提高團隊計程車氣
開發人員通過每次迭代都可以在短期內看到自己的工作成果，從而有助於他們增強信心，更好地完成開發工作單位。而在非迭代式開發中，開發人員只有在項目接近尾聲時才能看到開發的結果，在此之前的相當長時間，大家還是在不確定性中摸索前近。
產生更高品質的產品
每次迭代都會產生一個可啟動並執行系統，通過對這個可運行系統進行測試，我們在早期的迭代中就可以及時發現缺陷並改正，效能上的瓶頸也可以儘早發現並處理。因為在每次迭代中總是不斷地糾正錯誤，我們可以得到更高品質的產品。
保證項目開發進度
每次迭代結束時都會進行評估，來判斷該次迭代有沒有達到預定的目標。專案經理可以很清楚地知道有哪些需求已經實現了，並且比較準確地估計項目的狀態，對項目的開發進度進行必要的調整，保證項目按時完成。
容許產品進行戰術改變
迭代化的開發具有更大的靈活性，在迭代過程中可以隨時根據業務情況或市場環境來對產品的開發進行調整。例如為了同現有的同類產品競爭，可以決定採用搶先競爭者一步的方法，提前發布一個功能簡化的產品。
迭代流程自身可在進行過程中得到改進和精鍊
一次迭代結束時的評估不僅要從產品和進度的角度來考察項目的情況，而且還要分析組織和流程本身有什麼待改進之處，以便在下次迭代中更好地完成任務。 迭代化方法解決的主要是對於風險的控制問題，從可以看出，傳統的開發流程中系統的風險要到項目開發的後期（主要是測試階段）才能夠被真正降低。而迭代化開發中的風險，可以在項目開發的早期通過幾次迭代來儘快地解決掉。在早期的迭代中一旦遇到問題，如某一個迭代沒有完成預定的目標，我們還可以及時調整開發進度以保證項目按時完成。一般到了項目開發的後期（風險受控階段），由於大部分高風險的因素（如需求、架構、效能等）都已經解決，這時候只需要投入更多的資源去實現剩餘的需求即可。這個階段的項目開發具有很強的可控性，從而保證我們按時交付一個高品質的軟體系統。 迭代化開發不是一種高深的軟體工程理論，它提供了一種控制項目風險的非常有效機制。在日常的工作我們也經常地應用到這一基本思想，如對於一個非常大型的工程項目，我們經常會把它分為幾期來分步實施，從而把複雜的問題分解為相對容易解決的小問題，並且能夠在較短周期內看到部分系統實現的效果，通過儘早暴露問題來協助我們及早調整我們的開發資源，加強項目進度的可控程度，保證項目的按時完成。3. 管理迭代化的軟體項目
當我們在實際工作中實踐迭代化思想時，Rational統一開發流程RUP(Rational Unified Process)可以給予我們實踐的指導。RUP是一個通用的軟體流程架構，它是一個以架構為中心、用例驅動的迭代化軟體開發流程。RUP是從幾千個軟體項目的實踐經驗中總結出來的，對於實際的項目具有很強的指導意義，是軟體開發行業事實上的行業標準。3.1 軟體開發的四個階段
在RUP中，我們把軟體開發生命週期劃分為四個階段，每個階段的結束標誌就是一個主要的裡程碑（如所示）。 這四個階段主要是為了達到以下階段性的目標裡程碑：先啟(Inception)：確定項目開發的目標和範圍
精化(Elaboration)：確定系統架構和明確需求
構建(Construction)：實現剩餘的系統功能
產品化(Transition)：完成軟體的產品化工作，將系統移交給客戶
每個目標裡程碑都是一個商業上的決策點，如先啟階段結束之後，我們就要決定這個項目是否可行、是否要繼續做這個項目。每一個階段都是由裡程碑來決定的，判斷一個階段是否結束的標誌就是看項目當前的狀態是否滿足裡碑中所規定的條件。從這種階段劃分模式中可以看出，項目的主要風險集中在前兩個階段。在精化階段中經過幾次迭代後，我們要為系統建立一個穩定的架構，在此之後再實現更多的系統需求時，不再需要對該架構進行修改。同時，在精化階段中，我們通過迭代來不斷地收集使用者的需求反饋，便得系統的需求逐步地明確和完整。3.2 關於開發資源的分配
基於 RUP風險驅動的迭代化開發模式，我們只需要在項目的先啟階段投入少量的資源，對項目的開發前景和商業可行性進行一些探索性的研究。在精化階段再投入多一些的研發力量來實現一些與架構相關的核心需求，逐步地把系統架構搭建起來。等到這兩個階段結束之後，項目的一些主要風險和問題也得到瞭解決，這時候再投入整個團隊進行全面的系統開發。等到產品化階段，主要的開發工作單位已經全部完成，項目不再需要維持一個大規模的Team Dev，開發資源也可以隨之而減少。在項目開發週期中，開發資源的分配可以如所示。 這樣安排可以最充分有效地利用公司的開發資源，緩解軟體公司對於人力資源不斷增長的需求，從而降低成本。另外一方面，由於前兩個階段（先啟和精化）的風險較高，我們只是投入部分的資源，一旦發生返工或是項目目標的改變，我們也可以將資源浪費降到最低點。在傳統的軟體開發流程中，對於開發資源的分配基本上是貫穿整個項目周期而不變的，資源往往沒有得到充分有效地利用。基於這種資源分派模式，一個典型的項目在項目進度和所完成的工作量之間的關係可能如下表中的資料所示。 先啟 精化 構建 產品化
工作量 ~5% 20% 65% 10%
進度 10% 30% 50% 10% 3.3 迭代策略
關於反覆項目計劃的安排，通常有以下四種典型的策略模式：增量式(Incremental)
這種模式的特點是項目架構的風險較小（往往是開發一些重複性的項目），所以精化階段只需要一個迭代。但項目的開發工作量較大，構建階段需要有多次迭代來實現，每次迭代都在上一次迭代的基礎上增加實現一部分的系統功能，通過迭代的進行而逐步實現整個系統的功能。
演化式(Evolutionary)
當項目架構的風險較大時（從未開發過類似項目），需要在精化階段通過多次迭代來建立系統的架構，架構是通過多次迭代的探索，逐步演化而來的。當架構建立時，往往系統的功能也已經基本實現，所以構建階段只需要一次迭代。
增量提交(Incremental Delivery)
這種模式的特點產品化階段的迭代較多，比較常見的例子是項目的難度並不大，但業務需求在不斷地發生變化，所以需要通過迭代來不斷地部署完成的系統；但同時又要不斷地收集使用者的反饋來完善系統需求，並通過後續的迭代來補充實現這些需求。應用這種策略時要求系統架構非常穩定，能夠適應滿足後續需求變化的要求。
單次迭代(Grand Design)
傳統的瀑布模型可以看作是迭代化開發的一個特例，整個開發流程只有一次迭代。但這種模式有一個固有的弱點，由於它對風險的控制能力較差，往往會在產品化階段產生一些額外的迭代，造成項目的延誤。
這幾種迭代策略只是一些典型模式的代表，實際應用中應根據實際情況靈活應用，最常見的反覆項目計劃往往是這幾種模式的組合。3.4 制定項目開發計劃
在迭代化的開發模式中，項目開發計劃也是隨著項目的進展而不斷細化、調整並完善的。傳統的項目開發計劃是在項目早期制定的，專案經理總是試圖在項目的一開始就制定一個非常詳細完善的開發計劃。與之相反，反覆式開發法模式認為在項目早期只需要制定一個比較粗略的開發計劃，因為隨著項目的進展，項目的狀態在不斷地發生變化，專案經理需要隨時根據迭代的結果來對專案計劃進行調整，並制定下一次迭代的詳細計劃。在RUP中，我們把項目開發計劃分為以下三部分：專案計劃
確定整個項目的開發目標和進度安排，包括每一個階段的起止時間段。
階段計劃
當前階段中包含有幾個迭代，每一次迭代要達到的目標以及進度安排。
反覆項目計劃
針對當前迭代的詳細開發計劃，包括開發活動以及相關資源的分配。
項目開發計劃也是完全體現迭代化的思想，每次迭代中專案經理都會根據項目情況來不斷地調整和細化項目開發計劃。反覆項目計劃是在對上一次迭代結果進行評估的基礎上制定的，如果上一次迭代達到了預定的目標，那麼當前迭代只需要解決剩下的問題；如果上一次迭代中留有一些問題還沒有解決，則當前迭代還需要繼續去解決這些問題。所以必須注意，迭代是不能重疊的，即你還沒有完成當前迭代時，你決不能進入下一迭代，因為下一次迭代的計劃是根據當前迭代的結果而制定的。
