在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和驅動類型迭代必須計劃和仔細的控制。此外,業務設計迭代,當正確管理時,該項目測試和修改周期可以帶來更好的結果。
總而言之,控制迭代的這兩個方法,消除了業務流程開發中的許多固有問題,讓團隊可以更快地創建更好的結果。