從瀑布型開發到迭代型開發的轉變(2)

　　你能夠在每一個迭代中發現并更正缺陷。這會生成健壯的架構和高質量的應用。你甚至能夠在早期的迭代中而不是在項目末期的大規模測試階段發現缺陷。你能夠在性能瓶頸沒有破壞你的計劃之前發現它。

　　它能夠更好的利用項目的人員資源。很多開發組織使用一種管道式的組織方式來匹配他們的瀑布型開發方法：分析人員將被完成的需求發送給設計人員，設計人員將被完成的設計發送給開發編程人員，編程人員再將他們開發的組件發送給集成人員，集成人員將組件集成起來發送給測試人員測試。這種多次的傳遞不僅容易產生錯誤而且應用造成誤解;這種方式也會使人們感覺他們對最終的產品有很少的責任。迭代開發過程鼓勵在項目的各個環節中團隊成員參與范圍更加寬廣的活動，允許團隊成員扮演多種角色。項目經理能夠更好的利用可得到的項目人員并其可以消除有風險的傳遞。

　　團隊成員能夠沿著項目的道路進行學習。工作在迭代開發的項目中的開發人員在軟件開發周期內有很多的機會從他們所范的錯誤中吸取教訓，并能夠從一個迭代到另一個迭代的過程中增進他們的技能。通過評估每一個迭代，項目經理能夠為團隊成員發現培訓的機會。相反，工作在瀑布型開發方法中的開發人員典型的被限制在狹窄的技術專長上，并且僅僅有機會從事設計、編碼或者測試之一方面的工作。

　　你能夠沿著項目的道路改進開發的過程。迭代末尾的評估不僅能夠從產品或者計劃方面揭示項目的狀態;他們也可以幫助項目經理分析在下一個迭代中如何改進項目的組織結構和過程。

　　一些項目經理反抗采用迭代的開發方法，將迭代開發視為一種沒有盡頭的、不可控的形式。然而，在 RUP 中，這個項目是能夠被很好的控制的。迭代的次數、周期和目標被仔細的計劃;并且項目參與者的任務和角色被良好的定義。此外，進展的客觀量度應該能夠被獲取。雖然團隊要從一個迭代到下一個迭代中重做一些事情，但是這個工作也是可以被仔細的控制的。

　　回頁首

　　轉化的四個步驟

　　多數的瀑布型的項目將開發工作劃分為階段或者時期;我們也可以將這個劃分視為向迭代方法轉換的第一步。但是為了實現向迭代開發方法的過渡，我們要使用下面四個步驟來應用不同的過程原則：

　　盡早的構建功能原型。

　　劃分詳細設計、實現和測試階段到不同的迭代中。

　　在項目早期基線化一個可執行的架構。

　　采用迭代式的和風險驅動的管理過程。

　　讓我們來更進一步的解釋每一個步驟。

　　步驟 1 ：盡早的構建功能原型

　　作為向迭代開發轉換的第一步，在需求和設計階段考慮一個或者更多的功能原型。這些原型的目標是減少主要的技術風險和澄清項目涉眾對系統應該做什么的理解。

　　通過識別最重要的三個技術風險和最重要的三個有必要澄清的功能部分開始。技術風險也許與新技術、對整個方案影響很多的未決定的技術選擇或者你知道的很難滿足的技術需求有關。功能上的風險也許與項目涉眾為關鍵的功能性提供了模糊的需求或者幾個需求對項目系統都是核心的有關。

　　對于每一個重要的技術風險，擬訂你要原型化什么以減少風險?？紤]一下下面的例子：

　　技術風險: 項目需要將一個已存在的應用移植到 IBM WebSphere Application Server 上運行。用戶已經開始抱怨應用的性能，并且你所擔心的是移植后也許性能會更加的慢。

　　原型: 構建一個架構的原型來找出移植你的應用的不同方法。要求一個專家級的 WebSphere 架構師來幫助你。評價結果并編寫架構的和設計的指導方針為開發團隊提供什么 應該做和什么 不應該做。這將增加你移植的應用的性能是足夠好的以避免在項目后期返工的可能性。

　　技術風險: 你正在為安排和估計軟件項目構建一個新的應用。你知道對于這個應用和購買的軟件的關鍵區分將是如何能夠很好的支持迭代計劃。然而，這也是在你的需求說明中最模糊的部分之一。

　　原型: 基于你關于如何支持迭代項目計劃的設想構建一個功能原型。通過向不同的項目涉中演示原型，你將可以鼓勵他們更加注意項目的計劃，并且他們能夠告訴你他們對你的哪些設想是贊同的、哪些是不贊同的。原型將幫助你澄清計劃的需求，也能夠為你提供關于用戶體驗和對于你的應用的外表和感覺的有用的信息。這個原型甚至能夠產生一些可重用的代碼。

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-iterative/