軟件測試中讓敏捷方法和企業(yè)架構和諧共舞
一份來(lái)自Cutter Consortium的報告向我們提出了這樣一個(gè)問(wèn)題：“敏捷方法和企業(yè)架構兼容嗎?”并且也給出了這樣一個(gè)答案：“是的，但需要付出努力”。該報告的作者推薦運用特殊技巧以允許敏捷方法和企業(yè)架構互相受益。此外，他們的觀(guān)察結果、分析和建議也直接是適用于敏捷方法和“面向服務(wù)的架構SOA”之間的結合。
企業(yè)架構(EA)和敏捷方法(AM)擁有共同的目標——交付能夠跟業(yè)務(wù)需要對齊的軟件，并響應對這些業(yè)務(wù)需要無(wú)可避免的變更。然而，EA和AM在達成這個(gè)目標時(shí)卻采用了截然不同的方式。在報告中，對EA和AM定義如下：
EA處理如下的企業(yè)級問(wèn)題：
通過(guò)提供一個(gè)整體的業(yè)務(wù)過(guò)程藍圖將業(yè)務(wù)策略連接到IT系統，藍圖可以映射到架構模式、核心服務(wù)和應用兼容性等方面。
通過(guò)維護一個(gè)當前的數據模式(schemas)、過(guò)程流和服務(wù)定義等內容的詳細目錄來(lái)改進(jìn)貫穿于整個(gè)企業(yè)的一致性
通過(guò)減少系統間的冗余以及標識可以統一的組件和系統來(lái)改進(jìn)操作效率
確保靈活的IT能力，能夠響應技術(shù)廠(chǎng)商以及新的或者增強性的業(yè)務(wù)流程自動(dòng)化的變化
通過(guò)維護IT 組合(portfolio)、當前和目標架構以及遷移路線(xiàn)圖來(lái)支持項目成本化和優(yōu)先級劃分
為正在進(jìn)行中的操作和系統開(kāi)發(fā)提供一個(gè)穩定的、可信賴(lài)的基礎設施平臺和公用服務(wù)
敏捷方法關(guān)注于以下觀(guān)念：
改進(jìn)效率：關(guān)注于近期的問(wèn)題，僅開(kāi)發(fā)能夠滿(mǎn)足當前需要的的部分，允許以后形成設計
改進(jìn)項目可見(jiàn)的可管理性：關(guān)注于允許任務(wù)的完成能被有效評估的短期的、迭代的開(kāi)發(fā)周期
通過(guò)提供一個(gè)完整的過(guò)程，關(guān)注于廣泛的自動(dòng)化測試、盡可能早并且經(jīng)常解決集成問(wèn)題、允許多個(gè)(缺少豐富經(jīng)驗的)開(kāi)發(fā)人員在共同的代碼上開(kāi)展工作以及從最終用戶(hù)處得到持續反饋等方式來(lái)改進(jìn)質(zhì)量。
通過(guò)建立在持續重構過(guò)程上的集成來(lái)改進(jìn)(內部質(zhì)量的)可維護性
改進(jìn)處理變更的能力：它是一個(gè)需求變更、一個(gè)澄清、一個(gè)新的需要優(yōu)先處理的特性?通過(guò)綜合客戶(hù)反饋計劃迭代內容。
通過(guò)隱式知識的使用、共享的團隊空間以及關(guān)注問(wèn)題的小的組成部分來(lái)改進(jìn)交流效果。
我們會(huì )先從EA的視角來(lái)檢驗AM然后反過(guò)來(lái)檢驗以分析EA和AM之間的鴻溝。從EA的視角來(lái)看：
敏捷迭代提出的使用一到六個(gè)周的時(shí)間盒來(lái)構建一個(gè)可運行的部分系統的要求，很少得到采納。當在一個(gè)迭代發(fā)生時(shí)嘗試EA時(shí)，常常會(huì )割裂時(shí)間盒——在這個(gè)周期結束時(shí)并沒(méi)有得到可工作的軟件。
在一個(gè)典型的敏捷項目中，當系統的設計激增時(shí)，采用演進(jìn)的設計、有機的增量的方式風(fēng)險很大，可能會(huì )導致冗余和不同應用間的不兼容性。EA組希望引領(lǐng)設計和推薦的公用基礎設施組件、數據庫模式定義等……
敏捷非常依賴(lài)于可執行的的工件，例如：編寫(xiě)好的測試(不管是單元測試還是系統測試)。EA的工件不是可以測試的。它們限制了項目的影響范圍，因為他們沒(méi)有反饋環(huán)——當沒(méi)有遵照設計時(shí)，不會(huì )給出警告。
敏捷提倡的客戶(hù)作為團隊成員是不能被承認的。EA組中不會(huì )存在任何一個(gè)客戶(hù)，但是它有一個(gè)從IT到運營(yíng)到開(kāi)發(fā)團隊到最終用戶(hù)的間接的大型的廣泛客戶(hù)群。
從AM的視角看，EA也不是非常有意義的：
EA關(guān)注于對齊IT系統和業(yè)務(wù)策略。一個(gè)映射了從現在到將來(lái)系統的計劃被開(kāi)發(fā)出來(lái)，然后落到一個(gè)獨立的項目中。使用了AM的團隊可能會(huì )使用此類(lèi)文檔中的信息，但當這些文檔到達團隊時(shí)它們已經(jīng)失去了上下文環(huán)境，會(huì )變得難以理解。而且，文檔是可測試的。不能接觸現實(shí)狀況，這也是EA團隊被視作“象牙塔”架構的一個(gè)主要原因。
為了減少冗余并增進(jìn)一致性，EA組會(huì )針對如何構建應用而產(chǎn)出參考架構、推薦框架、發(fā)布指南。AM團隊將這些決定看做是單個(gè)項目的領(lǐng)域，不會(huì )由未在”前線(xiàn)“上的人來(lái)口述。
EA也關(guān)注于企業(yè)內不同應用的集成。同樣，EA組推薦使用參考架構和框架的特定方案。許多的AM團隊任務(wù)這些決定的是不成熟的甚至是毫無(wú)根據的。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
