你知道敏捷和架構的關系嗎？

　　為了理解敏捷和架構的關系，我們繼續討論第1部分曾經討論的3個主要的方法：XP、Scrum和RUP。

　　1,極限編程：架構形成

　　XP是以程序員為中心的開發，其中沒有一個核心實踐明確討論了軟件架構，然而，這并不是說XP項目和XP團隊不用或不理解架構在軟件開發中的作用。Beck[2000]提到：“架構在XP項目中和在其他軟件項目中一樣重要”。因此，我們在概念上從XP方法入手是一個好的開端。接著Beck繼續解釋架構是如何形成的。

　　首次迭代，先挑選一些簡單的和基本的故事，這些故事可以支持你創建整個架構。接下來，縮小范圍，用最簡單有效的方法實現這些故事。這個過程一旦結束，你就擁有了架構。

　　這些評論在XP的視角上提供了附加的解釋。如果一個范圍適度的系統，通過少量故事的一兩次迭代展現出一個合理的架構基線，那么這種方法可能非常有效，使用這種模型就可能形成相當好的架構。并且，由于XP主要被推薦和應用于小團隊，其有關團隊大小和架構策略的觀點是一致的。

　　此外，如果時間證明形成的系統架構不能支持系統繼續演化，那么系統也可以較快地改寫或者重構。事實上，重構代碼是XP這個快速開發方法的關鍵組成部分，也是XP的特色。正如Beck[2000]所提到的：XP熱中于重做，而不是減少重做的頻率。對XP程序員來說，沒有重構的日子就像沒有陽光的日子一樣。

　　在一個重構課堂上，Highsmith講述了一個敏捷項目第一次發布的情況，項目是由一個10人小團隊花費了大約7個月的時間后交付的。這次交付足以使公司在一個新興市場穩坐頭把交椅，并通過產品用戶的客觀反饋，更好地理解產品到底需要做什么。Highsmith接著講述了一個大約60天的重構階段，團隊重新改寫了系統以前實現的一個重要部分，把這部分加入到更好的結構基線中，并實現了新出現的需求。

　　由于僅花費兩個月來重新開發系統，嘗試早期交付過程的確是獲取需求和形成架構的高效方法，并且能夠很快推出滿足新興市場需求的產品，而盡早交付是XP方法的基本原則。因此，該重構模型在此環境中非常有效。

　　2, Scrum

　　我們在第1部分中提到，Scrum是一個敏捷軟件項目管理過程，其特征是面向團隊和授權、固定周期的評審和調整，以及驅動組織變更以實現提高軟件生產率的目標的過程。

　　雖然Scrum并沒有描述軟件工程實踐本身，[9]但是許多Scrum領導者認為XP是合適的開發過程，并且許多Scrum主管推薦把XP作為Scrum的同伴過程。例如，Sutherland[2005b]在PatientKeeper公司把XP實踐應用于系統開發，以及Scrum和高級Scrum持續改進中。此外，Scrum中的3個角色(開發者，產品主管和Scrum主管)都不承擔特定的架構職責。相反，Scrum依賴于一條久經考驗的敏捷宣言原則“最好的架構、需求和設計來自于自組織的團隊”。因此，正如其言，Scrum沒有多少關于軟件架構的內容，我們需要在其他地方尋找敏捷架構指南。

　　3,在FDD中的架構

　　我們在第6章中提到，域對象建模是FDD 8個最佳實踐之一(其他7個是按特征開發、私有代碼所有權、特征團隊、審查、定期構建、配置管理和結果的可視化)。域對象建模是唯一涉及系統架構的最佳實踐，這樣，域對象建模在特定敏捷實踐中為架構概念占據了重要的一席之地。

　　域對象建模是從應用系統支持的現實世界對象(實體)的視角創建系統模型的過程，是所有面向對象設計和架構技術的關鍵原則，也是FDD的一項關鍵實踐。域對象模型除了定義這些對象之外，還用于定義這些實體間的關系。這些關系可以是靜態的(通用性/特異性、多重性和依賴性)，也可以是動態的(消息傳遞)，這樣域模型就可以達到團隊想要的足夠高(或足夠低)的建模深度。正如Palmer[Palmer和Felsing 2002]所提到的一樣。

　　當分析師和開發者得知需求……他們開始在頭腦中形成待建系統的思維圖像。他們非常細心，并對這個想象中的設計做些假設。這些隱含的假設可能造成人們工作的不一致。開發全局的域模型會使這些假定暴露出來。

　　顯然，當敏捷方法應用于可伸縮系統時，任何這樣的誤解都會引起系統性能的不一致(實用程序或性能缺陷)和系統間接口的不一致(設計缺陷)。反過來，本來可以避免的一些重構或重做工作就成為必須要做的事情了。因此，在可伸縮系統中必須保證有一些建模。

　　根據我們的經驗，當團隊采用更多的敏捷開發實踐時，許多團隊都很少依賴需求和架構約定(和更具擴展性的建模)，這些需求和架構約定可能是他們以前方法中的“生命周期”早期階段獲取的。然而，同時，這些團隊會依賴于簡單卻高效的域模型的可視化展示，將其作為項目的原始架構。我們也看到，許多敏捷團隊不論在開始還是在開發過程中都相當依賴這個關鍵制品。

　　4, RUP：以架構為中心

　　我們在第1部分中提到過，RUP的根源在于開發一套支持面向對象開發方法的軟件過程。此外，RUP的大部分內容融入了Rational公司技術領導在做咨詢時從應用程序到大規模系統中所獲取的經驗教訓，這些技術領導有Grady Booch、Philippe Kruchten、Walker Royce和 Ivar Jacobson等人。綜合起來，形成RUP的實踐主要來自于針對面向對象開發方法的大規模系統的開發。的確，RUP已經被一些公司(如Ericsson等公司)應用于大規模系統的項目，在這樣的項目中同時有幾千名開發人員參與開發。

　　RUP的主要特點是“以架構為中心和用例驅動”。Booch對“以架構為中心”進行了如下描述：

　　(1)架構是可以命名和管理的東西;

　　(2)人們使用架構容納用例，有意識地管理風險，并且通過迭代和增量的方式完善架構。

　　所以，作為高效大規模系統軟件開發的基礎實踐，RUP考慮架構已經很長時間了。Kruchten[2004]提出了可伸縮系統架構的重要性的演變。

　　由于很多軟件系統并不復雜，架構可以讓開發者保持相互理解。然而，為了適應新的需求，隨著系統的演變和發展，情況就完全不同了，系統無法同步增長。集成新技術需要完全重建系統。此外，設計者也缺少判斷系統組成部分合理性的智能工具。所以，糟糕的架構總是被列為軟件失敗的原因就不奇怪了。沒有架構，或者使用糟糕的架構是軟件項目的主要技術風險。

原文轉自：http://www.kjueaiud.com