艾偉也談項目管理，克服在企業中應用靈活方法的技術挑戰

　　在企業中應用靈活方法是一項具有挑戰性的任務。實作靈活不像安裝軟體那樣能在一天内完成。而是需要适應企業環境，其中包括：文化、技術群組織方面。本文将探讨面臨的一些挑戰，這些挑戰與建立開發環境、自動化測試、持續內建相關，并且同在企業環境中明确完成的定義（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、系統管理者）。

　　本文談到了在企業中應用靈活方法面臨的一些挑戰，并提出了一些應對的政策。使用自動化腳本和檢查清單以一緻的方式建立開發環境，使用标準的工具和透明的測試資料有助于自動化測試和持續內建，并確定對完成有一個更嚴格的标準。這些方法并非無所不包，但它們會幫助團隊在企業環境中獲得更高的生産效率。

　　關于作者