關鍵字：GDD
分布式異地開發是一種能夠使業務在位于不同地區、國家或時區的項目團隊之間進行合作的軟件開發模式。本文通過一個普通的場景舉例說明了GDD 模式是如何在 24 小時周期中運行，這使得假定在印度班加羅爾和美國丹佛的團隊協同工作成為一體。 分布式異地開發（GDD）是一種快速的 IT 策略轉換以及橫跨或大或小的企業之間軟件和系統的開發過程。GDD 包括廣泛多樣的場景，其中，與軟件和系統開發項目有關的人員被擴展至超越常規的單一建筑物或校園環境。典型的 GDD 場景包括分布在不同地理位置的公司――全市范圍的、地區的、全國的以及國際間的――同樣包括合作伙伴關系以及各種外包關系。成功的 GDD 允許團隊以更快的速度、更低的成本開發高質量的軟件及系統，并能夠得到增強的業務靈活性以及更強的處理全球化競爭壓力的能力。
然而，認識到這些競爭優勢的挑戰是十分重要的。這其中主要的是需要在由防火墻、距離、時區、國界線、語言及文化－－或是上述所有因素所帶來的障礙之間進行準確而清晰的通信。由于管理所有軟件開發生命周期多個緯度的需要，在一個分布式環境中通過一個可重復的過程，同時維護有效的安全性，這些問題被進一步地合并在一起 －－例如軟件需求、變更及資產、測試、編碼等等。
本文第一部分介紹了GDD以及其業務需求，并展示了 IBM 軟件開發平臺是如何能夠對一個成功的 GDD 策略提供支持得。第一部分同時還論述了核心戰略的考慮，例如什么樣的項目最適合于一個 GDD 解決方案。
現在，在第二部分，我用一個示例場景舉例展示了關于應用 IBM Rational 工具以支持 GDD 的一些可能性。
GDD 的布局基礎
正如我在第一部分所討論的，團隊跨越時間以及空間的分布給整個軟件和系統開發的周期內帶來了挑戰并增加了復雜性。而比協同位置團隊（也就是，位于下一層或附件建筑物中的團隊）的 GDD 場景更大復雜的問題是標準、方法、過程以及最佳實踐的實現；組合管理；有效的需求管理；高效的知識及工作傳遞方法；以及健壯的軟件變更管理。日益明顯地，開發組織正在轉向使用軟件工具來幫助他們進行標準化并指導他們的過程，提高團隊的協作；考慮到 GDD 場景的復雜性，這些工具的潛在價值就更加重要了。
每個 GDD 項目中都包含著獨特的業務以及涉眾需求。這些需求依次定義了工作目標以及子任務職責所處的工作模式。例如，對于一個新系統項目而言，你在GDD環境中所選擇的管理需求變更的方法，與關聯于第三方的遺留維護合同的管理需求變更方的法將有很大的不同。這就是為什么GDD工具的實施不同于“一種尺寸適合所有需求”的解決方式。為了最優化地支持不同的業務需求，定制產品下層基礎平臺以及靈活的集成相關工作是必須的，因此GDD場景的支持工具需要是可配置的。
但是雖然每個GDD項目是不同的，仍然存在著一些公共的部分。在許多GDD場景中，同時關聯著本地以及遠程開發資源。那些在本地能夠最有效運行的規則以及任務有著高度的“面向客戶”的活動，例如業務建模、需求定義以及可配置性。而能夠高效地在遠程執行的工作包括代碼開發及測試－－規則主要與開發團隊相關而不是應用客戶。本地以及遠程站點也許都需要他們自己的測試或集成以及變更管理規劃。同時雖然總體的項目管理責任處于本地級別，但某些級別的項目管理也許場需要在遠程進行。
網絡性能以及服務器基礎結構也在很大程度上決定了是否能夠良好的對一個GDD項目進行組織。GDD項目經理需要考慮：
遠程站點對數據庫服務器的維護、數據存儲復制以及類似工作的需求及能力。
遠程用戶范圍，例如在分開地點的小團隊或是在家工作的個體開發者將需要建立、顯示、更改以及刪除各種不同的項目資產，從需求文檔到用例模型，從代碼到測試計劃。
遠程站點及用戶使用“瘦客戶端”的潛力，例如 Citrix、Windows Terminal Server（WTS），或是網絡客戶端。精簡客戶端可以給分布式團隊更大的靈活性及可移動性，但是也許不能支持工具所有的本地接口特性。
另外，例如網絡拓撲以及安全策略會進一步使得配置及開發GDD工具變得更復雜。業務需求及基礎結構性能將聯合起來幫助對一個特定的GDD環境進行最優化的工具配置。
一個GDD場景
在這里所描述的GDD配置場景舉例說明了今天 IBM Rational 工具對分布式團隊支持方法中的一種。我們假定的用戶是 Alcrohm 公司，一個財富1000 強的鋁合金供應商。
問題中的項目包括對一個企業級用戶應用軟件的正在進行中的維護以及重要的特性增強。關鍵任務應用是統一用于銷售的客戶關系管理系統、建議系統和合同管理能力，以及支持 Alcrohm 的所有三個部門（工業產品、客戶包裝以及自動化部分）中的團隊。當前的版本是由一個大部分由C++編寫的用戶界面的傳統桌面型客戶/服務器應用軟件。Alcrohm不得不在短期時間內繼續維護代碼。但是，與維護工作相比，Alcrohm計劃實現一個新的應用軟件版本，這個版本能夠通過標準網絡瀏覽器訪問，加上Java語言的服務器端代碼以及業務邏輯。這個新版本的開發將能夠更有效的進行配置以及管理，因為它能夠減小客戶端安裝以及升級的需要。它還將能夠與Alcrohm跨越整體IT基礎結構的包括面向服務的體系架構（SOA）的長期目標更好地進行吻合。
這個項目使用每天24小時、每周7天（7×24）的分布式開發模型，包括兩個獨立的地理場所：位于美國科羅拉多州丹佛的 Alcrohm 中央辦公現場內；以及位于印度班加羅爾的海外開發中心。我們稱現場的場所為“Site A”，非現場的場所為“Site B”。
這種GDD場景為 Alcrohm 提供成本以及時間計劃上的優勢，例如可變化的人員安排、減小國外勞動率，并通過保持項目能夠通過“晝夜不�！保ㄒ簿褪钦f，當位于東半球的開發團隊在家或睡覺時，西半球的開發團隊是在辦公室中工作的）的運作以減小上市時間。但是這些優點的出現同時也增加了風險。這個項目有著很重大的技術困難，這些難題也會檢驗協同位置的團隊有效協作、理解需求、交付高質量成果的能力。Alcrohm 選擇了來自 IBM Rational 的強壯的、集成的軟件工具以解決這些問題，并支持成功的成果。
建立任務
Site A 的室內開發團隊集中于新特性開發和相關的測試，同時也包括構建/部署。Site B 的遠程轉包商承擔維護開發、對現存的客戶/服務器應用軟件進行單元測試任務。這個高層次的職責分解對于什么角色、任務以及最終工具將在每個地點如何運行具有關鍵的影響。
在 Site A 執行的任務包括：
捕獲需求、創建需求文檔和管理需求
系統構架及建模
業務分析及高層次系統設計
新特性開發
對預發布的新應用軟件的構造進行組件、功能以及系統測試
對當前應用軟件版本的維護版本進行功能及系統測試
所有構造以及部署活動
項目和組合管理
在 Site B 執行的任務包括：
對當前客戶/服務器版本的應用軟件代碼進行維護
對代碼維護過程中所修正代碼的組件進行單元測試
對維護階段項目進行構造及修正需求
在進行了成功的單元測試后是在Site B開發下面維護版本的運行，Site B將代碼發送給Site A，Site A執行確認、功能以及系統測試。項目規約以及與現有應用軟件的維護版本有關的需求變更、模型和圖表在Site A及Site B之間進行通信。項目管理是在Site A處理的核心能力，所有Alcrohm應用軟件的組件以及資源組合都在這里進行監控。
這些強有力的任務劃分允許Alcrohm以相對低的風險得到GDD的常規經驗，特別是其非現場的合作伙伴。如果所有這些在次一級項目中都進行的很順利，Alcrohm也許在未來會選擇利用其它分布式開發模型，例如新特性組件開發。
確定資產位置及訪問
現在讓我們來看什么資產是在兩個站點都需要的。Alcrohm的關鍵目標是能夠在兩個站點間引用資產。哪些工具要被使用以及他們如何進行配置將很大程度上取決于關鍵的開發資產在哪里創建以及他們又將在哪里被使用。
對兩種版本應用軟件的需求在Site A被本地的捕獲。Site A因此需要對需求的讀/寫訪問，同時包括業務模型以及用例圖。對需求特性的更新以及大部分對需求的更改也都將在Site A發生。Site B也需要對需求的讀/寫訪問。因為他們隨著時間對現存的應用軟件進行維護，Site B的團隊將需要增加需求，對現存需求進行修正，對需求文件添加輔助信息，并分配屬性，例如優先級、難度以及狀態。Site B的團隊成員還將需要在需求間跟蹤關系的能力，這樣，他們可以測量改變的影響。
雖然兩個團隊將在不同分支上進行工作，然而兩個站點都將需要對共享代碼庫進行訪問。兩個站點還需要瀏覽、創建以及修正變更請求，增加需求以及缺陷報告。
為了達到這種高等級的共享訪問，兩個站點需要在本地服務器上對關鍵數據進行復制。
配置IBM Rational工具
當確定了什么資產是在每個站點上都需要的，Alcrohm需要找到一種分配他們的方法。IBM Rational工具為在兩個Alcrohm站點間進行通信與協作提供了一個范圍廣泛的可能。實際上，在這個GDD項目中所使用的產品與很多企業，例如Alcrohm，已經使用的保證在他們更傳統的、協同位置開發項目中的高質量產品的工具是相同的：
IBM Rational Unified Process，或稱作RUP － 支持健壯的、迭代的過程。對很多GDD項目來說，包括本場景，最好的方法是首先在規程間建立工作流程，然后配置工具基礎來幫助自動化這個工作流程。RUP包括了最佳實踐，并提供了支持標準的、集成的以及迭代過程的指導，所有這些對一個分布式團隊的成功來說都是極為關鍵的。RUP也定義了一個共享的詞匯表和一個清晰定義的項目任務與責任，所有這些都促進了一個跨越分布式團隊的公共視圖。并且由于它是基于網絡的，RUP很容易支持分布式工作。于是RUP成為使用其它工具的基礎。
IBM Rational ClearCase ―― 用于安全的資產管理以及整體過程控制。沒有健壯的、安全的資產管理能力，大部分GDD項目都會承擔很大的風險。資產管理保證了只有被授權的人可以瀏覽或改變項目資產；它還提供了可靠的對被授權用戶錯誤操作事件的恢復能力，例如對源代碼文件的意外刪除或該寫。資產管理進一步為更改控制、審計、重新構建以及從可執行代碼或者版本到需求、變更請求等的可回溯追蹤性提供了基礎。GDD團隊需要對資產以及對資產的更改在分布式環境中無縫的協作。同時需要能夠在一個項目的不通分支同時工作的能力，通過24×7開發模型加速部署。
在類似于Alcrohm的GDD場景中，每個分布式開發團隊擁有一個數據存儲，IBM Rational ClearCase MultiSite為分布式資產管理提供了一個健壯的、可擴展的解決方案。Alcrohm 將利用 Rational ClearCase MultiSite 與 Rational ClearCase 的結合以可靠的復制并同步包括二進制或文本對象的數據存儲，從需求至代碼、可執行應用以及其中的任何東西。每個站點中的團隊成員用他們自己本地的數據存儲的副本進行工作，因此WAN或企業內部網性能問題被最小化。特性的分支和合并簡化了在多于一個位置中對相同文件所作改變的同步，因此有效地支持了24×7的開發工作周期。多個項目資產副本的存在同樣幫助最小化停工、返工以及其它服務器的損耗帶來的影響或災難。IBM Rational ClearCase MultiSite還提供了一個基于瀏覽器的接口，以允許管理員從他們自己的本地站點管理所有的副本。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
