從瀑布型開(kāi)發(fā)到迭代型開(kāi)發(fā)的轉變(2)

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

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

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

　　你能夠沿著(zhù)項目的道路改進(jìn)開(kāi)發(fā)的過(guò)程。迭代末尾的評估不僅能夠從產(chǎn)品或者計劃方面揭示項目的狀態(tài);他們也可以幫助項目經(jīng)理分析在下一個(gè)迭代中如何改進(jìn)項目的組織結構和過(guò)程。

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

　　回頁(yè)首

　　轉化的四個(gè)步驟

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

　　盡早的構建功能原型。

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

　　在項目早期基線(xiàn)化一個(gè)可執行的架構。

　　采用迭代式的和風(fēng)險驅動(dòng)的管理過(guò)程。

　　讓我們來(lái)更進(jìn)一步的解釋每一個(gè)步驟。

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

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

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

　　對于每一個(gè)重要的技術(shù)風(fēng)險，擬訂你要原型化什么以減少風(fēng)險?？紤]一下下面的例子：

　　技術(shù)風(fēng)險: 項目需要將一個(gè)已存在的應用移植到 IBM WebSphere Application Server 上運行。用戶(hù)已經(jīng)開(kāi)始抱怨應用的性能，并且你所擔心的是移植后也許性能會(huì )更加的慢。

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

　　技術(shù)風(fēng)險: 你正在為安排和估計軟件項目構建一個(gè)新的應用。你知道對于這個(gè)應用和購買(mǎi)的軟件的關(guān)鍵區分將是如何能夠很好的支持迭代計劃。然而，這也是在你的需求說(shuō)明中最模糊的部分之一。

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

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