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

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

　　很多項目團隊發(fā)現在他們知道項目是真正關(guān)于什么的之前劃分一個(gè)項目成為有意義的迭代是困難的。但是，當你已經(jīng)進(jìn)入了詳細設計階段時(shí)，你通常對需求是什么和系統的架構看起來(lái)象什么樣子有了很好的理解。這是我們試驗迭代開(kāi)發(fā)的時(shí)候了!

　　你能夠使用兩個(gè)主要的方法來(lái)確定你應該在什么樣的迭代中作些什么事情。讓我們從正反兩方面討論一下每一個(gè)方法。

　　方法 1 ：同時(shí)開(kāi)發(fā)一個(gè)或者多個(gè)子系統。讓我們假設你有九個(gè)子系統，每一個(gè)都有數量日益增加的組件。你可以劃分詳細設計、實(shí)現和測試階段到三個(gè)迭代中，每個(gè)迭代瞄準實(shí)現九個(gè)子系統中的三個(gè)。如果在不同的子系統之間存在有限的依賴(lài)這將工作的相當的好。例如，如果你的九個(gè)子系統的每一個(gè)都為用戶(hù)提供良好定義的一系列能力，你可以在第一個(gè)迭代中開(kāi)發(fā)優(yōu)先級最高的子系統，其次重要的子系統在第二個(gè)迭代中實(shí)現，以此類(lèi)推。這種方法有很大的優(yōu)點(diǎn)：如果你的進(jìn)度落后了時(shí)間計劃，你仍然可以交付可運行的具有最重要能力的部分系統。

　　然而，如果你有一個(gè)分層的體系架構，在上層的子系統依賴(lài)于底層子系統的能力，這種方法將不能夠很好的工作。如果你必須要在一個(gè)時(shí)間內構建一個(gè)子系統，這樣的體系架構將迫使你首先構建底層的子系統，然后構建越來(lái)越上層的子系統。但是為了構建在底層子系統的正確的能力，你通常需要在上層的子系統上進(jìn)行大量的詳細設計和實(shí)現的工作，因為他們決定了什么是你在底層子系統中需要的。這產(chǎn)生了 “catch-22”的現象;第二個(gè)方法解釋了如何解決這個(gè)問(wèn)題。

　　方法 2 ：首先開(kāi)發(fā)最重要的場(chǎng)景。如果你使用方法 1 ，你一次只能開(kāi)發(fā)一個(gè)子系統。使用方法 2 ，你將重點(diǎn)放在了重要的場(chǎng)景上，或者使用系統的關(guān)鍵方法上，然后再添加更多的不是那么重要的場(chǎng)景。這與方法 1 有什么不同呢?讓我們來(lái)看一個(gè)例子。

　　假設你正在構建一個(gè)新的應用，這個(gè)應用將為用戶(hù)提供管理缺陷的能力。這是一個(gè)分層的應用，被構建在 WebSphere Application Server 上，使用 DB2 作為底層的數據庫。在首先的迭代中，你開(kāi)發(fā)了一系列重要的場(chǎng)景，比如輸入一個(gè)簡(jiǎn)單的缺陷。在第二次迭代中，你為這些場(chǎng)景添加了復雜性 — 例如，你也許使缺陷能夠被一個(gè)工作流來(lái)處理。在第三次迭代中，你通過(guò)為非典型的用戶(hù)提供完整的支持，比如保存部分的缺陷條目然后返回到這個(gè)條目中的能力等等。

　　使用這種方法，你在 所有的迭代中完成 所有的子系統的工作，但是在第一個(gè)迭代中你仍然關(guān)注最重要的場(chǎng)景，而將不是非常重要的或者最小難度的場(chǎng)景留到最后的迭代中實(shí)現。

　　如果你正工作在一個(gè)良好定義的體系架構的系統中時(shí)，方法 1 是更加適合的 — 比如，一個(gè)已存在系統的增進(jìn)或者開(kāi)發(fā)使用簡(jiǎn)單體系架構的新應用。多數構建復雜應用的項目應該使用方法 2 ，但是他們應該以這樣的方式來(lái)計劃迭代，這種方法能夠削減后來(lái)迭代的范圍以彌補可能的時(shí)間推延。

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

　　你可以將這個(gè)步驟看作是更加正式和有組織的完成步驟 1 ( 盡早的構建功能原型)的方法。但是什么是“可執行的架構”呢?

　　可執行的架構是系統的部分的實(shí)現，它被構建以演示架構的設計所支持的關(guān)鍵的功能。更重要的是，它能夠證明設計能夠滿(mǎn)足對于性能、生產(chǎn)能力、容量可靠性、可測量性和其他方面的需求。構建一個(gè)可執行的架構允許你在稍后的階段中在一個(gè)堅實(shí)的基礎上構建所有的系統功能性的能力。這個(gè)可執行的架構是一個(gè) 進(jìn)化的原型，它的目的是當系統的架構成熟時(shí)，保持已經(jīng)被證明的特性并保證他們最大可能的滿(mǎn)足系統的需求。換句話(huà)說(shuō)，這些特性將是交付系統的一部分。與你在步驟 1中構建的 功能原型相比，這個(gè)進(jìn)化的原型覆蓋了架構問(wèn)題的所有方面。

　　生成一個(gè)進(jìn)化的原型意味著(zhù)你要設計、實(shí)現和測試一系統的個(gè)框架結構或者架構。在應用的角度上，系統的功能還沒(méi)有被完成，但是大多數的構建模塊之間的接口已經(jīng)被實(shí)現了，你能夠(并應該)在某種程度上編譯并測試架構。指導初始的負載和性能測試。這個(gè)原型也會(huì )反映你的關(guān)鍵設計的決定，包括技術(shù)、主要組件和他們之間接口的選擇。

　　但是你將如何為這個(gè)進(jìn)化的原型提出系統的架構呢?關(guān)鍵是將重點(diǎn)放在最重要的百分之二十到三十的用例上(系統為用戶(hù)提供的完全的服務(wù))。這里是一些決定什么用例是最重要的方法。

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