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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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