在20世紀90年代后期，IT發(fā)現(xiàn)了原型概念，并將其應(yīng)用于應(yīng)用開發(fā)。原型模型是迭代過程的前身——小規(guī)模設(shè)計和構(gòu)建，在組件中快速完成，然后測試和調(diào)整組件。和現(xiàn)今的迭代方法一樣，這個前身是一個好主意，但實際上并不奏效。調(diào)整通常需要比預期更長的時間，業(yè)務(wù)用戶經(jīng)常失去耐心，這一概念從未被廣泛接受。

[[199829]]

在二十世紀初期，迭代過程被采納為業(yè)務(wù)流程管理(BPM)的一個中心原則，BPM本身是從業(yè)務(wù)再造中發(fā)展而來。大概在同一時間，IT重新設(shè)計了原型模型，而這一次，將其作為設(shè)計和解決方案的“迭代”嵌入到敏捷軟件開發(fā)方法中。

所以，再一次的，我們使迭代成為一個主流過程，并再次獲得各種結(jié)果。

在我們進一步討論之前，我想清楚地說明我是迭代方法的支持者——我只是希望它能正常工作，真正有幫助。

但實際上，根據(jù)歷史，迭代過程有好有壞。

讓我們先來討論一下缺點，最后以優(yōu)點結(jié)束。

迭代過程中的問題

有一個謬見，認為迭代可以使項目更早完成。我，以及很多專業(yè)人士都沒聽說過迭代確實節(jié)省時間的項目。(當然，肯定有人可以證明迭代可以節(jié)省時間，但我并不認識。)我知道有評價團體贊揚了敏捷方法，然而，迭代，卻被報告有難以置信的70%的項目失敗率，BPM相關(guān)項目則更高。值得注意的是，很多這些項目最終都取得了成功，一旦它們完成了永無止境的設(shè)計、構(gòu)建、評估和重新設(shè)計的迭代工作。

那么在迭代過程中，我們需要怎樣做，才能縮小謬見與現(xiàn)實之間的差距呢?我們首先來討論我親身經(jīng)歷過的幾個迭代現(xiàn)實。

無休止：迭代可以不斷進行，不斷擴展解決方案的設(shè)計和構(gòu)建，遠遠超出預期。在迭代中，并不是為了第一次就讓新的設(shè)計起作用——目標是快速，并且“靈活”，然后通過多次迭代進行改進。對于更傾向于分析的管理者，解決方案總是可以更好，永遠沒有盡頭。在這種情況下，管理者認為下一次迭代會比這一次更好。

風險增加：每當團隊創(chuàng)建新的迭代模型時，必須對其進行全面重新檢查——如果沒有，交付有問題的產(chǎn)品的風險，隨著每個模型而增加。這再次延長了構(gòu)建解決方案所需的時間。這是一種反復試驗的方法，最終會帶來一個很好的解決方案，但它可能不是最有效的方法。

中斷：在某一截點，宣布成功，并安裝解決方案。但迭代過程還在繼續(xù)，因為已經(jīng)安裝的可能并不完整。這會導致業(yè)務(wù)中斷，因為部分解決方案或者不同版本不斷實施，再次發(fā)生改變。

混亂：經(jīng)過幾次解決方案的迭代，沒有一個員工知道他們應(yīng)該做什么或應(yīng)該怎么做。最后的結(jié)果就是業(yè)務(wù)人員和經(jīng)理的沮喪。

用模擬控制迭代次數(shù)

迭代是一個很好的概念，當被正確使用和控制時，可以很好地起作用。

對于一些CIO和應(yīng)用開發(fā)領(lǐng)導者來說，這種“正確的方式”需要將業(yè)務(wù)和IT BPM相關(guān)的概念，方法和技術(shù)相結(jié)合，來最好地解決每個問題。 然而，在將BPM方法(通常是瀑布型方法)和IT BPM方法(通常是基于敏捷的方法)相結(jié)合時，關(guān)鍵是設(shè)置機制來控制迭代次數(shù)，以及每次迭代的預期。

在這部分討論中，我假設(shè)應(yīng)用解決方案開發(fā)團隊能夠創(chuàng)建滿足業(yè)務(wù)和技術(shù)需求的應(yīng)用。這個假設(shè)意味著應(yīng)用將提供所需的服務(wù)。這并不意味著應(yīng)用解決方案的運行完全順利，或者如預期般有效。這也不意味著應(yīng)用解決方案是靈活的或完整的。也不意味著應(yīng)用解決方案消除了復雜性。

但這些需要迭代的問題可以有效地處理。在IT BPM和業(yè)務(wù)BPM方面，我建議團隊考慮使用模擬建模來評估每個迭代設(shè)計。模擬工具將指出瓶頸，解決方案在不同工作負載下如何工作，以及設(shè)計中的許多其他問題。

使用模擬結(jié)果，重點關(guān)注設(shè)計改進，團隊不斷優(yōu)化設(shè)計。這樣，改進評估是基于嚴格的模擬效率評估，而不是“讓我們試試，來看看結(jié)果。”最終，迭代次數(shù)受到控制，需要的次數(shù)更少。同時，這種方法也產(chǎn)生了更好的業(yè)務(wù)設(shè)計。

讓迭代過程更順利

當交付目標產(chǎn)品或服務(wù)的概率很高時，當模擬和財務(wù)評估表明業(yè)務(wù)的工作流程和其他方面最優(yōu)時，說明新的業(yè)務(wù)流程模型，是起作用的。將現(xiàn)有的狀態(tài)模擬結(jié)果與新的解決方案的運營模擬相比較時，團隊還能夠預測項目效益——使用新運營(工作流程)時，通過新設(shè)計，消除業(yè)務(wù)問題可以節(jié)省的成本，通過消除或減少錯誤可以節(jié)省的成本。

一旦業(yè)務(wù)流程模型在使用模擬工具時，可以證明有效和高效，那么這些應(yīng)用可以由BPM套件(BPMS)工具生成。假設(shè)使用BPMS工具，可以生成“straw man”版本的應(yīng)用。

此外，使用傳統(tǒng)測試技術(shù)，“stub”來測試應(yīng)用，模擬將數(shù)據(jù)傳遞給另一個應(yīng)用，和“驅(qū)動程序”來模擬解決方案系統(tǒng)從其他應(yīng)用接收數(shù)據(jù)的情況，可以進一步優(yōu)化模型和解決方案設(shè)計，以確保支持計算機應(yīng)用的工作流程和運營，可以完成目標結(jié)果。

在BPM項目中應(yīng)該考慮stub和驅(qū)動類型的迭代——特別是那些由BPMS工具支持的項目。至于業(yè)務(wù)設(shè)計迭代過程，stub和驅(qū)動類型迭代必須計劃和仔細的控制。此外，業(yè)務(wù)設(shè)計迭代，當正確管理時，該項目測試和修改周期可以帶來更好的結(jié)果。

總而言之，控制迭代的這兩個方法，消除了業(yè)務(wù)流程開發(fā)中的許多固有問題，讓團隊可以更快地創(chuàng)建更好的結(jié)果。