建站
咨詢
售后
建站咨詢
新聞中心
為了理解敏捷和架構的關系，我們繼續(xù)討論第1部分曾經討論的3個主要的方法：XP、Scrum和RUP。
創(chuàng)新互聯自成立以來，一直致力于為企業(yè)提供從網站策劃、網站設計、成都做網站、成都網站設計、電子商務、網站推廣、網站優(yōu)化到為企業(yè)提供個性化軟件開發(fā)等基于互聯網的全面整合營銷服務。公司擁有豐富的網站建設和互聯網應用系統(tǒng)開發(fā)管理經驗、成熟的應用系統(tǒng)解決方案、優(yōu)秀的網站開發(fā)工程師團隊及專業(yè)的網站設計師團隊。
1,極限編程：架構形成
XP是以程序員為中心的開發(fā)，其中沒有一個核心實踐明確討論了軟件架構，然而，這并不是說XP項目和XP團隊不用或不理解架構在軟件開發(fā)中的作用。Beck［2000］提到：“架構在XP項目中和在其他軟件項目中一樣重要”。因此，我們在概念上從XP方法入手是一個好的開端。接著Beck繼續(xù)解釋架構是如何形成的。
首次迭代，先挑選一些簡單的和基本的故事，這些故事可以支持你創(chuàng)建整個架構。接下來，縮小范圍，用最簡單有效的方法實現這些故事。這個過程一旦結束，你就擁有了架構。
這些評論在XP的視角上提供了附加的解釋。如果一個范圍適度的系統(tǒng)，通過少量故事的一兩次迭代展現出一個合理的架構基線，那么這種方法可能非常有效，使用這種模型就可能形成相當好的架構。并且，由于XP主要被推薦和應用于小團隊，其有關團隊大小和架構策略的觀點是一致的。
此外，如果時間證明形成的系統(tǒng)架構不能支持系統(tǒng)繼續(xù)演化，那么系統(tǒng)也可以較快地改寫或者重構。事實上，重構代碼是XP這個快速開發(fā)方法的關鍵組成部分，也是XP的特色。正如Beck［2000］所提到的：XP熱中于重做，而不是減少重做的頻率。對XP程序員來說，沒有重構的日子就像沒有陽光的日子一樣。
在一個重構課堂上，Highsmith講述了一個敏捷項目第一次發(fā)布的情況，項目是由一個10人小團隊花費了大約7個月的時間后交付的。這次交付足以使公司在一個新興市場穩(wěn)坐頭把交椅，并通過產品用戶的客觀反饋，更好地理解產品到底需要做什么。Highsmith接著講述了一個大約60天的重構階段，團隊重新改寫了系統(tǒng)以前實現的一個重要部分，把這部分加入到更好的結構基線中，并實現了新出現的需求。
由于僅花費兩個月來重新開發(fā)系統(tǒng)，嘗試早期交付過程的確是獲取需求和形成架構的高效方法，并且能夠很快推出滿足新興市場需求的產品，而盡早交付是XP方法的基本原則。因此，該重構模型在此環(huán)境中非常有效。
2, Scrum
我們在第1部分中提到，Scrum是一個敏捷軟件項目管理過程，其特征是面向團隊和授權、固定周期的評審和調整，以及驅動組織變更以實現提高軟件生產率的目標的過程。
雖然Scrum并沒有描述軟件工程實踐本身，[9]但是許多Scrum領導者認為XP是合適的開發(fā)過程，并且許多Scrum主管推薦把XP作為Scrum的同伴過程。例如，Sutherland［2005b］在PatientKeeper公司把XP實踐應用于系統(tǒng)開發(fā)，以及Scrum和高級Scrum持續(xù)改進中。此外，Scrum中的３個角色（開發(fā)者，產品主管和Scrum主管）都不承擔特定的架構職責。相反，Scrum依賴于一條久經考驗的敏捷宣言原則“最好的架構、需求和設計來自于自組織的團隊”。因此，正如其言，Scrum沒有多少關于軟件架構的內容，我們需要在其他地方尋找敏捷架構指南。
3,在FDD中的架構
我們在第6章中提到，域對象建模是FDD 8個最佳實踐之一（其他7個是按特征開發(fā)、私有代碼所有權、特征團隊、審查、定期構建、配置管理和結果的可視化）。域對象建模是唯一涉及系統(tǒng)架構的最佳實踐，這樣，域對象建模在特定敏捷實踐中為架構概念占據了重要的一席之地。
域對象建模是從應用系統(tǒng)支持的現實世界對象（實體）的視角創(chuàng)建系統(tǒng)模型的過程，是所有面向對象設計和架構技術的關鍵原則，也是FDD的一項關鍵實踐。域對象模型除了定義這些對象之外，還用于定義這些實體間的關系。這些關系可以是靜態(tài)的（通用性/特異性、多重性和依賴性），也可以是動態(tài)的（消息傳遞），這樣域模型就可以達到團隊想要的足夠高（或足夠低）的建模深度。正如Palmer［Palmer和Felsing 2002］所提到的一樣。
當分析師和開發(fā)者得知需求……他們開始在頭腦中形成待建系統(tǒng)的思維圖像。他們非常細心，并對這個想象中的設計做些假設。這些隱含的假設可能造成人們工作的不一致。開發(fā)全局的域模型會使這些假定暴露出來。
顯然，當敏捷方法應用于可伸縮系統(tǒng)時，任何這樣的誤解都會引起系統(tǒng)性能的不一致（實用程序或性能缺陷）和系統(tǒng)間接口的不一致（設計缺陷）。反過來，本來可以避免的一些重構或重做工作就成為必須要做的事情了。因此，在可伸縮系統(tǒng)中必須保證有一些建模。
根據我們的經驗，當團隊采用更多的敏捷開發(fā)實踐時，許多團隊都很少依賴需求和架構約定（和更具擴展性的建模），這些需求和架構約定可能是他們以前方法中的“生命周期”早期階段獲取的。然而，同時，這些團隊會依賴于簡單卻高效的域模型的可視化展示，將其作為項目的原始架構。我們也看到，許多敏捷團隊不論在開始還是在開發(fā)過程中都相當依賴這個關鍵制品。
4, RUP：以架構為中心
我們在第1部分中提到過，RUP的根源在于開發(fā)一套支持面向對象開發(fā)方法的軟件過程。此外，RUP的大部分內容融入了Rational公司技術領導在做咨詢時從應用程序到大規(guī)模系統(tǒng)中所獲取的經驗教訓，這些技術領導有Grady Booch、Philippe Kruchten、Walker Royce和 Ivar Jacobson等人。綜合起來，形成RUP的實踐主要來自于針對面向對象開發(fā)方法的大規(guī)模系統(tǒng)的開發(fā)。的確，RUP已經被一些公司（如Ericsson等公司）應用于大規(guī)模系統(tǒng)的項目，在這樣的項目中同時有幾千名開發(fā)人員參與開發(fā)。
RUP的主要特點是“以架構為中心和用例驅動”。Booch對“以架構為中心”進行了如下描述：
（1）架構是可以命名和管理的東西；
（2）人們使用架構容納用例，有意識地管理風險，并且通過迭代和增量的方式完善架構。
所以，作為高效大規(guī)模系統(tǒng)軟件開發(fā)的基礎實踐，RUP考慮架構已經很長時間了。Kruchten［2004］提出了可伸縮系統(tǒng)架構的重要性的演變。
由于很多軟件系統(tǒng)并不復雜，架構可以讓開發(fā)者保持相互理解。然而，為了適應新的需求，隨著系統(tǒng)的演變和發(fā)展，情況就完全不同了，系統(tǒng)無法同步增長。集成新技術需要完全重建系統(tǒng)。此外，設計者也缺少判斷系統(tǒng)組成部分合理性的智能工具。所以，糟糕的架構總是被列為軟件失敗的原因就不奇怪了。沒有架構，或者使用糟糕的架構是軟件項目的主要技術風險。
那么，RUP擁有應用于迭代和增量軟件過程條件下的架構開發(fā)指南就不足為奇了。目前，RUP指南包括一組用于定義系統(tǒng)的架構視圖，每個視圖都從架構上反映了一個或多個重要利益相關者的視角。其中，有如下兩個強制的視圖。
用例視圖。每個系統(tǒng)只有一個用例視圖，用例視圖圖示了所有用例和場景，從架構上包含了重要的系統(tǒng)行為、類或者技術風險。
邏輯視圖。每個系統(tǒng)只有一個邏輯視圖，邏輯視圖圖示了關鍵的用例實現、子系統(tǒng)、包和類，從架構上包含了重要的系統(tǒng)行為。
此外，RUP額外規(guī)定了4種可選的視圖，這4種視圖可以根據所配置系統(tǒng)類型等方面的重要性酌情使用。
進程視圖。當系統(tǒng)擁有多個控制線程，并且線程之間有交互或依賴時推薦使用該視圖。該視圖通過把類和子系統(tǒng)映射為進程和線程說明了系統(tǒng)的進程分解。
配置視圖。當系統(tǒng)分布在多個結點之間并且結構上存在牽連時，推薦使用該視圖。配置視圖圖示了處理系統(tǒng)中一組結點的分布，包含進程和線程的物理分布。
實現視圖。當實現不是嚴格由設計驅動時，即設計和實現模型中的相應包之間的責任分布是不同的時，推薦使用該視圖。實現視圖在給個人或團隊分配實現任務時非常有用。恰當的實現結構會支持高效的持續(xù)集成。
數據視圖。當持續(xù)數據是系統(tǒng)的關鍵部分時，推薦使用該視圖，例如，包含數據模式、數據定義和算法等內容的系統(tǒng)。
5,炫目的敏捷架構師
在敏捷項目中，傳統(tǒng)架構師的象牙塔已經逐漸成為最薄弱的一環(huán)，而他們的許多工作職責也已經被整個敏捷團隊所分解。敏捷架構師的出現，正符合了查爾斯?達爾文的“適者生存”理論。在一個團隊中，敏捷架構師角色的重要性是毋庸置疑的，而且許多敏捷團隊都認為他是任何敏捷軟件開發(fā)團隊中最有價值的成員之一。
敏捷架構師的目標：
1. 以最優(yōu)質量交付可用的解決方案。
2. 維護概念完整性
3. 與團隊一起工作
4. 編寫系統(tǒng)級別的測試
5. 參與緊密的協(xié)作
6. 做堅定的指導者
7. 做熟練的協(xié)調者
8. 不做大型的預先建模
9. 尋找大規(guī)模重構的機會
10. 敏捷架構師是萬能膠
原文鏈接：http://www.cnblogs.com/bluedoctor/archive/2012/06/26/2563430.html
文章標題：詳細解讀敏捷和架構的關系
文章鏈接：http://m.5511xx.com/article/dhsjisd.html
