克服在企業中應用敏捷方法的技術挑戰

來源: InfoQ 發布時間: 2010-10-28 15:34 閱讀: 466 次推薦: 0 原文鏈接 [收藏]

摘要：本文談到了在企業中應用敏捷方法面臨的一些挑戰，并提出了一些應對的策略。使用自動化腳本和檢查清單以一致的方式建立開發環境，使用標準的工具和透明的測試數據有助于自動化測試和持續集成，并確保對完成有一個更嚴格的標準。這些方法并非無所不包，但它們會幫助團隊在企業環境中獲得更高的生產效率。

　　在企業中應用敏捷方法是一項具有挑戰性的任務。實現敏捷不像安裝軟件那樣能在一天內完成。而是需要適應企業環境，其中包括：文化、技術和組織方面。本文將探討面臨的一些挑戰，這些挑戰與建立開發環境、自動化測試、持續集成相關，并且同在企業環境中明確完成的定義（DoD）相關。

　　建立開發環境

　　每位技術負責人和開發經理都想縮減團隊成員建立開發環境的時間。然而，為了在項目中獲得較高的產出，開發人員要持續投入許多精力，讓事情變得有條不紊。缺乏文檔，是建立開發環境時間過長的關鍵原因。第二個關鍵原因是建立過程中包含多少手工步驟。那么，如何克服這些挑戰呢？關于文檔我遵循幾個信條——簡單，注重細節和自動化。簡單是指，讓文檔的創建、維護、查看以及傳播保持簡單。在為我的團隊建立開發環境相關的內容時，我使用wiki來管理。wiki頁面有一名所有者，它會作為迭代的一部分被更新。注重細節是指，記錄建立環境所需的內容時，要形成明確且易懂的指南。這表示，為了讓開發人員開始編寫代碼并與團隊的其余工作進行整合，要記錄下開發人員所需的所有細節。下面是我在有關開發環境的wiki頁面中所記錄的：

需要安裝的軟件包列表：在我的案例中，這部分需要Java Developer Kit (JDK)、 Eclipse整合開發環境(IDE)、Apache Ant、Apache Axis 以及SQL Server精簡版管理工具。
每個安裝包要包括安裝文件的位置（網絡驅動器/外部網/內部網/其他）以及安裝所需的證書。例如，apache ant，在我們subversion版本庫中的位置，是由subversion工作副本指定的相對路徑——/Software/Apache/Ant/1.7.0。
對于每個安裝包，要指出在機器上需要配置的系統變量及本地變量。例如，ant需要ANT_HOME變量，axis2 需要AXIS2_HOME環境變量指向開發機器的目錄結構。
需要獲取的其他庫列表——包括任何java文檔（JARS）、.NET DLL文件或是其他文件。例如，用于訪問Microsoft SQL Server 2005的Java數據庫連接(JDBC) JARs，或者使用IBM Websphere MQ所需的JARs。
如何讓用戶訪問消息隊列服務器、數據庫服務器和遠程機器——聯系人、以及相關步驟和表單的鏈接。諸如開發環境中的應用程序認證信息或用戶特定的認證表單這類細節，可以在這里指定。例如，我指定了一個email模板，其中包括登錄用戶名、我們團隊的應用程序標識符和聯系人姓名，這一模板用于給我們的中間件支持組發送email，以獲得訪問消息隊列服務器的權限。
源代碼是如何組織的？如何獲取代碼庫的訪問權限？這一部分會提供一個代碼組織結構的概要。例如，我是基于數據域（客戶數據、賬戶數據、文檔數據）以及核心可重用的公共模塊（例如：logger、router、exception handler、notifications manager等）來組織代碼的。這一部分也會提供subversion主干的位置以及如何得到代碼庫寫權限的指南。
通過源代碼控制系統建立代碼的工作副本（或者本地開發副本）。基于企業桌面應用程序的政策，這一部分提供了關于工作副本位置的指南。例如，用戶只擁有某個特定目錄的寫權限。
關鍵文件的位置——應用程序日志文件、錯誤文件、服務器跟蹤日志、線程（堆棧）信息。例如，Tomcat servlet 容器日志和Websphere MQ 綁定文件的文件路徑。
瀏覽隊列和添加隊列的步驟。這一部分指出了在消息隊列服務器中開發人員需要注意的重要隊列。這部分還會提供創建新隊列的命名規范，以及相關的支持信息。
瀏覽數據庫表格，創建像數據庫表格、數據庫視圖和存儲過程之類的數據庫對象。在我的案例中，這一部分包含了用SchemaSpy生成的SQL Server 2005數據庫文檔。
開發人員使用的腳本/工具——開發人員用于自動化日常任務的工具。例如，能編譯并執行JUnit測試套件的apache ant腳本，以及能基于java源碼生成javadoc的腳本。

　　建立開發環境最重要的方面或許就是自動化了。自動化有幾個優點——在整個流程中堅持自動化，就算不能消除錯誤，也能顯著地減少錯誤。下面是一些自動化所面臨的挑戰：

缺少機器的管理權限：由于安全原因和公司政策，系統管理員也許不會對開發人員開放開發機器的所有權限。這可能會阻礙軟件安裝、設置環境變量和執行腳本。
需要與外部部門進行協調：外部部門可能會提供安裝軟件，提供證書或是批準安裝軟件的請求。
需要利用托管解決方案：大型企業會有為中間件功能（消息隊列，企業服務主線，應用程序適配器）提供支持的專用共享主機，與它們交互通常需要得到技術支持。

　　這些挑戰或許并不總能被解決，但還有一些辦法來處理它們。對開發人員而言，所有所需的軟件——不管來自何處——把它們加入源代碼控制系統。確保使用一致的命名和放置規范來組織軟件包，標識出版本號和程序庫依賴關系。這能確保每個開發人員不用在公司內四處詢問就可得到所需的軟件包。

　　對于那些需要由其他部門去安裝的軟件包，可以創建腳本來生成請求，如果可能的話，甚至可以通過程序提交請求。一旦他們從源代碼控制系統中得到文件的工作副本，你就會想要建立一個“設置”腳本。在我的項目中，我有一個apache ant腳本，用于建立用戶級環境變量、在開發數據庫中創建用戶編號/密碼、從網絡目錄拷貝許可密鑰至用戶的windows配置中，并為團隊支持的各種web服務生成XML消息樣例。

　　自動化測試和持續集成

　　開發人員因各種各樣的技術原因而不進行自動化測試。我常聽到下面這些理由：

“我有我更喜歡用的工具”——這個工具可能是開發人員自己創建的，或是來自某個特定的開源或廠商的軟件套件。這個工具可能會些局限，但開發人員會拒絕承認或予以解決。
“沒有測試數據”——尤其在需要多系統/進程之間協調數據時。

　　工具問題可以通過各種方式解決。向他們說明使用如JUnit或NUnit等標準測試工具的好處，指出用腳本進行整合的好處，并具有可持續的、可重復的方式進行測試的能力。在大型企業中，不太可能所有的人都使用同一工具。更現實的做法是，同一部門的開發團隊至少有一套標準的工具集。

　　我所做的是，提供標準的自動化測試腳本——這些腳本用于對JUnit測試用例進行編譯、執行，生成報告并通過email發送報告——這些腳本是每個開發人員開發環境的一部分。當開發人員從源代碼控制系統中下載工作副本時，測試腳本已經就位，并且他們會繼續加入自己的測試用例。我們團隊有一個標準的測試目錄結構，其中放置著測試用例和測試套件，腳本會從中選取并執行測試用例。

　　另外，在代碼復查期間，我會確保不但要復查代碼，同時也要復查測試代碼。對未包含在自動化測試中的測試用例進行重構也是復查工作的一部分。這同樣適用于包含了硬編碼數據的測試代碼，把硬編碼數據改為從配置文件或者數據庫中讀取。例如，一個測試方法指定用戶角色為 BRANCH_SUPERVISOR，而不是從配置文件中去獲得。復查時，把這一屬性保存在一個由名稱-值數據對組成的文件中，重構該測試方法，使之從屬性文件獲取用戶角色。這樣一來，這一屬性也可以被其他測試使用了。

　　對 SOA項目來說，服務中整合了應用程序服務器、遺留系統、數據源或應用程序包，一系列的系統測試也是必不可少的。最初，這些測試可以使用暫時代替后端整合點的mock對象執行。但最終你會希望在真實的整合點上運行這些測試。

　　在這種情況下，測試數據以及與多系統相關的數據極為重要。缺少良好的測試數據，特別是需要跨系統的數據，是導致無效自動化測試的一個重要原因。對需要依靠數據復雜性和系統運行時依賴較多系統的情況，可以分階段解決這一問題。可以從數據的本地副本開始，開發人員查詢多種數據源并填充到本地存儲。這聽起來非常像是手工操作，但如果數據是新的并且ETL作業/批處理過程對數據存儲的填充還未完成，這也許是啟動測試更為簡單的方式。

　　隨著時間的推移，你可以建立起一套類，封裝了來自多種數據存儲的測試數據，確保數據的有效性和質量，并把填充測試數據作為持續集成腳本的一部分。無論如何，如果把測試用例代碼和獲取測試數據的細節解耦，就更易于改變數據源策略而不影響測試代碼。我的團隊最初用配置文件來提供測試數據，隨后把數據遷移到一組數據訪問類中，并通過這些類獲取所需測試數據。

　　例如，我們用Data Access Object設計模式創建了一組java類，這些類封裝了對客戶數據和賬戶數據項的操作。這些類提供了一個簡單的有增刪查改方法的接口，JUnit的測試方法可以通過它訪問這些類。如果一個測試方法需要獲取客戶數據，它會導入DAO工廠和特定的DAO類并調用getCustomer()方法。在提取特定客戶對象時，測試可以繼續執行其余的邏輯。測試不需要了解如何查詢數據并將其打包至一個對象中的，而且這些接口能被其他測試重用。

　　定義什么是完成

　　在企業中，為完成指定一個標準是非常棘手的。在開發環境中執行地非常好的代碼在測試環境下也許根本無法工作。這也許是由于安全令牌/安全政策、網絡/連接問題、系統不穩定或是由于質量保證（QA）團隊或終端用戶更嚴格的質量測試。為了盡量減少遷移代碼時的意外，完成標準中應當包括：

建立一套全面的測試套件，這些測試套件是可復用的，并最大限度的減少（如果沒法消除的話）硬編碼的數據值。
在持續集成的過程中加入測試套件。例如，在我的團隊中，這意味著在特定目錄中加入JUnit測試套件，apache ant 腳本可以從這一目錄中提取并執行那些測試。
自動化測試用例不但要覆蓋功能測試還要覆蓋性能測試（例如，使用像JUnitPerf這樣的工具，通過使用性能閾值實現測試場景自動化）。
獲得廣泛的測試數據。如果測試需要整合遺留系統，讓開發遺留系統的團隊同你們一起創建測試并定義測試標準。開發人員未必總能了解在遺留系統上工作需要注意的細微差別。開發環境下測試良好的一些場景，并不能反映生產環境中的實際數據。
代碼復查不僅要在內部團隊中進行，而且也要在基礎團隊中進行（例如，DBA、系統管理員）。