控制迭代過程 防止業務流程管理失敗

在20世紀90年代後期，IT發現了原型概念，並將其應用於應用開發。原型模型是迭代過程的前身——小規模設計和構建，在組件中快速完成，然後測試和調整組件。和現今的迭代方法一樣，這個前身是一個好主意，但實際上並不奏效。調整通常需要比預期更長的時間，業務用戶經常失去耐心，這一概念從未被廣泛接受。

在二十世紀初期，迭代過程被採納為業務流程管理（BPM）的一個中心原則，BPM本身是從業務再造中發展而來。大概在同一時間，IT重新設計了原型模型，而這一次，將其作為設計和解決方案的「迭代」嵌入到敏捷軟體開發方法中。

所以，再一次的，我們使迭代成為一個主流過程，並再次獲得各種結果。 在我們進一步討論之前，我想清楚地說明我是迭代方法的支持者——我只是希望它能正常工作，真正有幫助。 但實際上，根據歷史，迭代過程有好有壞。 讓我們先來討論一下缺點，最後以優點結束。

迭代過程中的問題

有一個謬見，認為迭代可以使項目更早完成。我，以及很多專業人士都沒聽說過迭代確實節省時間的項目。（當然，肯定有人可以證明迭代可以節省時間，但我並不認識。）

我知道有評價團體讚揚了敏捷方法，然而，迭代，卻被報告有難以置信的70%的項目失敗率，BPM相關項目則更高。值得注意的是，很多這些項目最終都取得了成功，一旦它們完成了永無止境的設計、構建、評估和重新設計的迭代工作。 那麼在迭代過程中，我們需要怎樣做，才能縮小謬見與現實之間的差距呢？我們首先來討論我親身經歷過的幾個迭代現實。

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

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

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

混亂：經過幾次解決方案的迭代，沒有一個員工知道他們應該做什麼或應該怎麼做。最後的結果就是業務人員和經理的沮喪。

用模擬控制迭代次數

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

對於一些CIO和應用開發領導者來說，這種「正確的方式」需要將業務和IT BPM相關的概念，方法和技術相結合，來最好地解決每個問題。 然而，在將BPM方法（通常是瀑布型方法）和IT BPM方法（通常是基於敏捷的方法）相結合時，關鍵是設置機制來控制迭代次數，以及每次迭代的預期。

在這部分討論中，我假設應用解決方案開發團隊能夠創建滿足業務和技術需求的應用。這個假設意味著應用將提供所需的服務。這並不意味著應用解決方案的運行完全順利，或者如預期般有效。這也不意味著應用解決方案是靈活的或完整的。也不意味著應用解決方案消除了複雜性。 但這些需要迭代的問題可以有效地處理。

在IT BPM和業務BPM方面，我建議團隊考慮使用模擬建模來評估每個迭代設計。模擬工具將指出瓶頸，解決方案在不同工作負載下如何工作，以及設計中的許多其他問題。 使用模擬結果，重點關注設計改進，團隊不斷優化設計。這樣，改進評估是基於嚴格的模擬效率評估，而不是「讓我們試試，來看看結果。」最終，迭代次數受到控制，需要的次數更少。

同時，這種方法也產生了更好的業務設計。

讓迭代過程更順利

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

一旦業務流程模型在使用模擬工具時，可以證明有效和高效，那麼這些應用可以由BPM套件（BPMS）工具生成。假設使用BPMS工具，可以生成「straw man」版本的應用。 此外，使用傳統測試技術，「stub」來測試應用，模擬將數據傳遞給另一個應用，和「驅動程序」來模擬解決方案系統從其他應用接收數據的情況，可以進一步優化模型和解決方案設計，以確保支持計算機應用的工作流程和運營，可以完成目標結果。

在BPM項目中應該考慮stub和驅動類型的迭代——特別是那些由BPMS工具支持的項目。至於業務設計迭代過程，stub和驅動類型迭代必須計劃和仔細的控制。此外，業務設計迭代，當正確管理時，該項目測試和修改周期可以帶來更好的結果。 總而言之，控制迭代的這兩個方法，消除了業務流程開發中的許多固有問題，讓團隊可以更快地創建更好的結果。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！