為了理解敏捷和架構的關系，我們繼續討論第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中的３個角色（開發者，產品主管和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］提出了可伸縮系統架構的重要性的演變。

 

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

 

那么，RUP擁有應用于迭代和增量軟件過程條件下的架構開發指南就不足為奇了。目前，RUP指南包括一組用于定義系統的架構視圖，每個視圖都從架構上反映了一個或多個重要利益相關者的視角。其中，有如下兩個強制的視圖。

 

用例視圖。每個系統只有一個用例視圖，用例視圖圖示了所有用例和場景，從架構上包含了重要的系統行為、類或者技術風險。

 

邏輯視圖。每個系統只有一個邏輯視圖，邏輯視圖圖示了關鍵的用例實現、子系統、包和類，從架構上包含了重要的系統行為。

 

此外，RUP額外規定了4種可選的視圖，這4種視圖可以根據所配置系統類型等方面的重要性酌情使用。

 

進程視圖。當系統擁有多個控制線程，并且線程之間有交互或依賴時推薦使用該視圖。該視圖通過把類和子系統映射為進程和線程說明了系統的進程分解。

 

配置視圖。當系統分布在多個結點之間并且結構上存在牽連時，推薦使用該視圖。配置視圖圖示了處理系統中一組結點的分布，包含進程和線程的物理分布。

 

實現視圖。當實現不是嚴格由設計驅動時，即設計和實現模型中的相應包之間的責任分布是不同的時，推薦使用該視圖。實現視圖在給個人或團隊分配實現任務時非常有用。恰當的實現結構會支持高效的持續集成。

 

數據視圖。當持續數據是系統的關鍵部分時，推薦使用該視圖，例如，包含數據模式、數據定義和算法等內容的系統。

 

 

5,炫目的敏捷架構師

 

在敏捷項目中，傳統架構師的象牙塔已經逐漸成為最薄弱的一環，而他們的許多工作職責也已經被整個敏捷團隊所分解。敏捷架構師的出現，正符合了查爾斯•達爾文的“適者生存”理論。在一個團隊中，敏捷架構師角色的重要性是毋庸置疑的，而且許多敏捷團隊都認為他是任何敏捷軟件開發團隊中最有價值的成員之一。

 

敏捷架構師的目標：

1. 以最優質量交付可用的解決方案。

2. 維護概念完整性

3. 與團隊一起工作

4. 編寫系統級別的測試

5. 參與緊密的協作

6. 做堅定的指導者

7. 做熟練的協調者

8. 不做大型的預先建模

9. 尋找大規模重構的機會

10. 敏捷架構師是萬能膠

原文鏈接：http://www.cnblogs.com/bluedoctor/archive/2012/06/26/2563430.html