基于DAD方法的可擴展的ASM敏捷框架

　　在敏捷的初期，往往敏捷開發是在小范圍內進行且項目管理相對簡單。小型的且集中的敏捷團隊管理思想仍然可以在這些情況指導我們完成任務。而如今，因為機遇和環境已經顯著改變，我們希望敏捷開發應用于更廣泛的項目，我們需要更龐大的團隊，為了降低地區經濟和市場領域的風險，同時在全球各個地區展開業務，CEO們希望利用分布式方式組織龐大的敏捷開發團隊;同時，他們還想與其他組織的成為合作伙伴。因此，他們需要遵守法規和行業標準，他們有著顯著的技術或文化環境問題需要克服，他們需要超越單系統的思維方式，真正有效地考慮跨系統的因子 - 團隊規模，地理分布，合規性，領域的復雜性，技術的復雜性，組織分布和企業規范。

　　圖表 XXVI：ASM是DAD模型基礎上面向八個維度拓展

　　不是每個項目團隊面臨所有這些可變維度帶來的新問題，也沒有任何兩個團隊面臨同一個問題具有相同的嚴重性，但所有這些問題增加了敏捷交付的復雜性。以你的情況，你的DAD敏捷交付過程需要適應新環境，而你必須找到策略來克服這些獨特的挑戰。

　　團隊規模 –核心敏捷方法能夠很好的工作于十到十五人的團隊，但如果團隊要大得多呢?有五十人，百人，或者一千人?隨著你團隊規模的增長，團隊溝通和協調的會更加困難。書面溝通反而比核心敏捷所提倡的面對面溝通更加有效，或者書面溝通以及面對面的溝通都顯得無力。

　　地理分布 – 如果我們的團隊分開來，他們不存在同一間會議室中，他們或許在同一建筑物內的不同樓層，或許在同一個城市的不同位置，甚至在不同的國家，這會發生什么有趣的事情呢?或者你讓你的一些工程師在家工作會又會發生什么呢?又或當你的團隊成員在不同的時區，又會發生什么?突然，我們發現有效的協作變得更加具有挑戰性，團隊的聯結被斷開將更有可能發生。

　　合規性 - 如果行業或地方監管法案出臺，所有的移動設備均需送檢過關后方能投入運營網絡，又或者企業要求所有流程必須合規企業ISO9000認證，請問這些將帶給產品交互過程何程度的影響呢?其實，往往是我們從外部強加的，除了客戶驅動的產品要求外的許多規則、需求增加了團隊的工作流程環節、工作內容。

　　領域的復雜性 - 有些項目團隊發現自己解決一個非常簡單的問題，如開發數據錄入、查詢應用程序或以信息公開為主的網站。有時候，問題領域是比較復雜的，如需要監控醫療藥品用品的生物化學工藝或大數據采集、存儲和分析以輔助交通管制決策等?；蛘?，也許情況正在發生迅速變化，如金融系統從前臺轉向后臺，端到端的服務走上電子平臺，需要較高的安全保障和兼顧易用性。有人認為，變化領域內的速度，系統的臨界性，以及商業模式是影響軟件過程中的關鍵因素。更復雜的領域需要更加注重探索和實驗，以降低風險，這其中的活動包括原型驗證，建模和仿真等。

　　組織分布 - 有時候，一個項目團隊包括來自不同部門的成員，不同的合作伙伴，或由外部服務公司雇傭、委派的成員。更多的組織上分散的團隊，越有可能的關系將是合同聯結的方式，而不是協作。例如，在一些項目的人雖然在要求，架構，設計，甚至是代碼上產出，但實際上因為處于安全原因，他們不得訪問源代碼所屬空間，不得獲得資源執行測試，對真正的產品的理解有極大的偏移，且缺乏組織凝聚力，這將大大增加您項目實施的風險。由于缺乏彼此的信任，從而減少合作意愿，甚至可能會增加與知識產權(IP)斗爭的風險。因此，許多組織都在努力重新調整他們的人力資源采購流程和與合作伙伴的新合同，以便更好地構建分布式環境中成功的交付產品、解決方案的信任。

　　技術的復雜性 - 有些應用程序從頭開始，易于提升整體的質量和滿足客戶需求;但如果你的工作與現有的遺留系統和遺留數據源存在極大的耦合需求，你的產品就有可能變得不完美了。同理，使用一個單一的平臺來建立一個系統，會相對容易;如果你正在構建一個運行時系統又需要在多種平臺上被使用，或兼用幾個不同的技術來構建。這個時候，你一定感到有難度。另一方面，技術復雜度還是相對主觀的因素，例如在敏捷計劃中，每個人針對工作項的復雜度的理解會因為個人經驗和技術水平的不同而不同。換句話說，不同的團隊成員評估同一工作項會有不同的結果，所以針對技術復雜度，我們在思考交付過程時需要一個復雜的解決方案。

　　組織的復雜性 - 你現有的組織結構和文化可能直接反映了瀑布式交付的價值理念;在組織內采用和推廣敏捷策略的因此增加了難度。更糟的是，你的組織內的不同團隊可能有不同的看法，因為他們認為應該如何工作需要考慮更多其自身的需求。而差異性策略即使是相當有效的，但作為一個整體，因為他們并不是向一個方向努力，因而可能大大增加了您項目的風險，也可能閉門造車般地重復投入資源開發著同一個輪子。

　　企業規范 - 大多數企業希望利用共同的基礎架構平臺，以降低生產成本，縮短產品上市時間，提高一致性，并促進可持續發展的步伐。如果你的項目團隊只專注于他們的迫切需要，理念和實際就要脫離了。為了充分利用公共平臺和資源，項目團隊需要采取有效的企業架構，企業業務建模，戰略性重用和資源組合。這些學科必須同心協力和更好的提升你的紀律敏捷交付流程。但是，這不是免費的，你的敏捷開發團隊需要招募企業的專業人士– 例如企業架構師和企業資產重用工程師 - 如果不是自己權力范圍內可以調動的資源。該企業的專業人士也需要學習紀律性敏捷交付的方式工作，因為，未來的工作相比于他們在傳統的團隊工作方式非常的不同。

　　需要指出的是，每個比例因子代表的范圍內的復雜度才是關鍵，而每個項目團隊都將面臨這些復雜性的不同組合。言下之意是，他們將需要調整。實際操作中我們發現前四個比例因子 - 團隊規模，地理分布，合規性，以及組織分布 - 是相對簡單的，能夠通過工具，采用適當的技術來解決。而其他四個縮放因子– 領域的復雜性，技術的復雜性，組織復雜性和企業規范 – 則更難解決。許多企業正努力實現(盡管期望如此)。

原文轉自：http://blog.csdn.net/u012936954/article/details/19502629