本文來自于 Rational Edge：本文討論了敏捷軟件配置管理（Agile Software Configuration Management）的概念，一種適合于敏捷開發(fā)方法的 SCM 風格。文中還介紹了IBM Rational SCM 工具集如何實現(xiàn)敏捷軟件配置管理，以支持敏捷項目。

　　并不久以前，敏捷開發(fā)方法，例如極限編程（eXtreme Programming，XP）、動態(tài)系統(tǒng)開發(fā)方法（Dynamic Systems Development Method，DSDM），或 Scrum 作為新的且稍微有爭議的軟件開發(fā)項目的交付方法被引入。如今，敏捷開發(fā)實踐，例如迭代開發(fā)、測試驅(qū)動的開發(fā)，和持續(xù)的集成成為了普遍現(xiàn)象，并且人們已經(jīng)接受并采用它們作為另一種軟件開發(fā)的方法。不論您的看法或經(jīng)驗是什么，您不能否認的是，敏捷開發(fā)項目可以并且已經(jīng)證明能夠成功，準時，并按照預算交付功能。

　　本文討論了敏捷開發(fā)的具體方面 —— 敏捷軟件配置管理，或簡稱“敏捷 SCM”的概念，一個精心設(shè)計的輕型 SCM，可以由軟件開發(fā)項目使用和實踐敏捷開發(fā)方法。作為此討論的一部分，我還將關(guān)注企業(yè)級 SCM 工具集，例如 IBM Rational SCM 工具集，能夠如何實現(xiàn)，以支持敏捷項目。

敏捷開發(fā)

　　大多數(shù)敏捷開發(fā)方法所共用的方法是讓用戶或客戶直接參與并與之交流，并且在頻繁的，短期的迭代（典型的為二到十二個星期）中進行功能開發(fā)。典型的是，在每個迭代的開始，敏捷團隊會與客戶商談來確定新的特性或變更請求。這些由開發(fā)人員進行估計，并且隨后，由客戶為下一次迭代設(shè)置優(yōu)先級，如圖 1 中所示。任何還沒有在迭代中實現(xiàn)的特性或變更請求將與所有新的請求一起保留下來，并且由客戶為下一次迭代重新設(shè)定優(yōu)先級。允許開發(fā)人員致力于當前迭代的請求，或者在必要時重構(gòu)并簡化現(xiàn)存的代碼。這樣做的意圖是，保持設(shè)計的簡單，并且防止不必要的特性膨脹。代碼還是不斷地集成的，并頻繁地以很小的單位進行實現(xiàn)、測試及提交，這可以利用在提交時刻調(diào)用的自動化構(gòu)建過程來檢查集成錯誤。

圖 1：在每個迭代的開始，敏捷團隊會與客戶商談來確定新的特性或變更請求。這些由開發(fā)人員進行估計，并且隨后，由客戶為下一次迭代設(shè)置優(yōu)先級。

　　如同所有軟件開發(fā)過程，敏捷開發(fā)方法需要一個基于核心及支持團隊的環(huán)境，一些在傳統(tǒng)上稱為軟件配置管理，或 SCM 的東西。不幸的是，一些實踐者將 SCM 看作是一個陳舊的且不必要的控制規(guī)程。但這是一個誤解。雖然事實上過多的喝錯誤類型的 SCM 可以扼殺敏捷開發(fā)項目，但是敏捷實踐，例如迭代開發(fā)和持續(xù)集成，如果沒有 SCM 將不會成功這也是事實。

　　因此，對于這些類型的項目，您需要多少，以及什么類型的 SCM？要回答這些問題，讓我們引入一個相對新的概念：敏捷 SCM（Agile SCM）。

敏捷 SCM

　　敏捷 SCM 概念本身可能是由 Brad Appleton 和 Stephen Berczuk 在他們的書 Software Configuration Management Patterns 中 和 SCM portal CM Crossroads 中被首次進行了詳細地討論。 2 其中一個觀察是：

　　配置管理在利用平衡且有效的 SCM 過程集方面成為關(guān)鍵的“支柱”并且也是敏捷開發(fā)方法的標準。“敏捷倡導者”著重強調(diào)在敏捷項目上應(yīng)用瘦的及輕型的 配置管理（CM），這將需要更少的打擾/入侵（Grady Booch 所謂的低摩擦），以使敏捷項目能夠成功，而與此同時配置管理有不能太小（由于過度反應(yīng)）以至于導致項目失敗。與我剛才的觀點一致的是，雖然敏捷項目上的 SCM 趨向于更加輕型且更少的可見性，但是 SCM 本身是此類項目的關(guān)鍵需求。也許不一致的是，大多數(shù)敏捷項目采用入門級或輕型的 SCM 工具，例如 CVS、Subversion，或 BitKeeper —— 這些工具有局限性但基本上擁有滿足敏捷項目的功能。它們也是趨向于較小的影響并且重視開發(fā)經(jīng)驗的工具，而不是對一個嚴格控制過程的遵循。

　　然而，理論上，您沒有理由不能使用 SCM 工具來支持敏捷開發(fā)實踐。您當然不必要使用工具的所有特性，并且大多數(shù)工具允許某種程度上的過程定制化，從重量級到輕量級的，以及兩者之間的任意程度。有了企業(yè)級工具，例如 IBM Rational ClearCase，一些組織總想使用所有的“突出特性”來定義重量級的 SCM 過程，只因為該工具提供支持。然而，這樣的過程對滿足您項目的需求是不必要的。要找到正確的過程和定制級別，您應(yīng)該首先確定并定義您的需求，這意味著確切地了解您的開發(fā)過程是什么，或者應(yīng)該是什么，然后確定 SCM 如何提供支持。

　　一般來說，SCM 是關(guān)于開發(fā)過程“管理”的，換句話說，SCM 允許項目保留控制措施，而與此同時又能夠允許開發(fā)人員在過程中擁有創(chuàng)建的自由度。利用敏捷開發(fā)方法，開發(fā)人員擁有高度的自由和權(quán)利來實現(xiàn)變更。然而，持續(xù)集成和測試驅(qū)動的開發(fā)實踐的一個結(jié)果是，它們實際上形成了一個規(guī)劃良好的并且?guī)缀踝灾蔚?SCM 方法。例如，在每個代碼變更時，敏捷開發(fā)人員必須首先撰寫一個單元測試，然后撰寫足夠的代碼使測試能夠工作，隨后按照需要的重構(gòu)以完成該變更。提交（或檢入）代碼變更，并且代碼變更的單元測試成為集成套件中的一個部分。通過集成構(gòu)建機制編譯和執(zhí)行完整的單元測試套件，可以直接可視化地看到變更的所有副作用 —— 所有找到的問題都能夠立即修改。

　　在敏捷 SCM 中，該管理模型是日常開發(fā)活動的正常部分，并且因此對開發(fā)人員是相當透明的。要更詳細地了解此管理模型，讓我們看看 SCM 的一些不同的特征，以及如何典型地實現(xiàn)它們來支持敏捷開發(fā)方法：

　　·分支。敏捷項目實現(xiàn)簡單的分支策略，典型的是活動開發(fā)線（Active Development Line） 3 和版本預備線（Release Prep Line）?；顒娱_發(fā)線由開發(fā)人員用來提交他們的變更并且持續(xù)集成構(gòu)建通過此方法來執(zhí)行。版本預備線是用于在客戶使用之前穩(wěn)定化或工程化一個版本的，通常不允許開發(fā)人員向它提交變更。
　　·工作區(qū)。開發(fā)人員擁有一個單個私有的工作區(qū)，最初指向活動開發(fā)線最新版本的集合。在開發(fā)人員開始致力于新的特性或變更請求時，并且就在他們向活動開發(fā)線提交變更來檢查集成問題之前他們的工作區(qū)以最小量更新著。
　　·標簽。如傳統(tǒng)的 SCM 一樣，標簽放置在代碼版本集合重要的里程碑上，在每個版本構(gòu)建上至少有一個標簽，以便在必要時能夠重新產(chǎn)生構(gòu)建環(huán)境。
　　·構(gòu)建和集成。成功的敏捷開發(fā)的關(guān)鍵因素是自動化的構(gòu)建過程。構(gòu)建過程監(jiān)控關(guān)于提交的活動開發(fā)線，在一個較寬松的限期自動地執(zhí)行集成構(gòu)建和單元測試。該構(gòu)建成功或失敗的通知是敏捷團隊中關(guān)鍵的通信因素。
　　·變更控制。如早先討論的一樣，一個隱含的授權(quán)過程伴隨著敏捷開發(fā)團隊，授權(quán)開發(fā)人員做出基于客戶優(yōu)先級的變更，或者在必要時重構(gòu)。請求要么記錄在變更控制系統(tǒng)中，要么對于更不正式的項目來說，特別是在極限程序設(shè)計項目中，記錄在卡片上或活動掛圖上。

　　雖然這些 SCM 特性典型地處在敏捷過程中，但是它們很可能根據(jù)特定項目所需的敏捷程度而“調(diào)整”。例如，一些項目也許不能構(gòu)建在每個提交上，取而代之的是計劃一個單個的每日或每夜的集成構(gòu)建。還有，項目不是獨立存在的，它們通常是組織中許多項目中的一個。企業(yè)組織中常?；旌嫌忻艚莺蛡鹘y(tǒng)的計劃驅(qū)動的項目，并且因此一個已知的項目可能存在于特定的市場區(qū)段中。該企業(yè)環(huán)境常常是決定選擇哪個 SCM 工具集并且所選工具集需要支持哪些額外的管理方面的最大的因素。

　　敏捷 SCM 和企業(yè)

　　如果您孤立地看一個單個的敏捷項目，那么它的 SCM 需求幾乎肯定地可以由相當簡單的工具集來滿足。項目本身就可以使用并管理這樣的工具集。然而，與其支持具體項目的工具集相比，大多數(shù)大型組織更喜歡將單個的 SCM 工具集標準化，并且圍繞它開發(fā)組織過程。這樣做有兩個主要原因：

　　·減少工具集及其過程的所有權(quán)的總成本
　　·能夠符合所期望的（或強制的）一致性或規(guī)章制度框架

　　所有權(quán)的總成本常常是主觀問題，因為其包含許多可以計量的方面，例如許可、管理，和支持成本，以及其他主觀方法，例如功能或可伸縮性。企業(yè)級工具集，例如 IBM Rational 工具集經(jīng)常有更高的許可、管理，和支持成本（最初時是當然的），但如果正確地實現(xiàn)了，這些企業(yè)工具集可以總體地提高組織能力。它們還擁有已證實的可伸縮性，一個單個的、統(tǒng)一的基礎(chǔ)結(jié)構(gòu)能夠支持大型的，地理上分散的開發(fā)組織。如上面所提到的，這類工具的主要危險是試圖使用超過所需的更多功能，這樣會扼殺敏捷項目。需要建立一個組織的 SCM 框架，并且應(yīng)該以某種可配置的方式來實現(xiàn)，以便滿足不同項目的需求。

　　最近的行業(yè)法規(guī)，例如 Sarbanes Oxley、Basel II，和 CFR 21 Part 11 會向 SCM 過程施加繁重的管理成本，特別是關(guān)于變更控制的方面。雖然實踐，例如“職責的分離”—— 不允許開發(fā)人員部署到實際的環(huán)境中 —— 應(yīng)該實現(xiàn)，但是對敏捷項目嚴格強制實施變更控制會扼殺它們。然而，不滿足這些法規(guī)的商業(yè)成本是巨大的，因此雖然敏捷項目可能希望避免不必要的管理實踐，但是它們不得不在大多數(shù)情況下接受一些額外的開銷。好的消息是，如果實現(xiàn)的正確，那么自動化的 SCM 工具集可以實現(xiàn)大多數(shù)的管理方面，使商家維持組織的控制，而又允許單個項目和它們的開發(fā)人員致力于有創(chuàng)造性地開發(fā)新的軟件功能來解決商業(yè)問題。

用 IBM Rational 工具集實現(xiàn)敏捷 SCM

　　讓我們來考慮，對于使用 IBM Rational 工具集的敏捷項目來說，管理的嚴格性和靈活性之間的平衡如何能夠被達到呢？

　　一個普遍的誤解是企業(yè)級 SCM 工具集 —— 例如 IBM Rational 工具集 —— 不能用于支持實現(xiàn)敏捷開發(fā)方法。這些工具集中所提供的重要功能是來支持許多不同的類型和大小的開發(fā)環(huán)境的，因此，確定該功能的哪個要素應(yīng)該使用是不容易的，并且存在的一個風險是，對 SCM 過程將進行過渡的設(shè)計。目前，在 IBM Rational SCM 工具集中還不存在現(xiàn)成的敏捷 SCM 配置。取而代之，留給工具集實施者的是找到滿足其需求的適當?shù)呐渲谩?/p>

　　好消息是，在 IBM Rational 工具集的支撐下，許多組織已經(jīng)設(shè)法找到了這種配置，并且將成功地實現(xiàn)敏捷開發(fā)方法。從觀察來看，有許多這些項目所共用的最佳實踐。雖然這些最佳實踐不是絕對的，但是它們應(yīng)該足以給您一個框架及實現(xiàn)您自己的敏捷 SCM 過程的起始點。它們可以如下概括為：

　　實現(xiàn)一個簡化的分支策略。敏捷項目實現(xiàn)簡單的分支策略。在 Base ClearCase 和 ClearCase UCM（統(tǒng)一的變更管理，Unified Change Management）中，分支（UCM 術(shù)語中的“流”）可以很容易且很廉價地生成。因此經(jīng)常會有這樣的趨勢，定義比確切需要的更復雜的分支策略。敏捷項目積極地鼓勵持續(xù)集成和重構(gòu)，但是開發(fā)人員孤立于分支上，那么將出現(xiàn)有問題的或復雜的合并操作。這在命名空間重構(gòu)（重命名、添加，或刪除文件或目錄）的情況下尤為正確。因此，大多數(shù)敏捷項目實現(xiàn)一個特定的分支，作為活動開發(fā)線，并且開發(fā)人員直接處理的上面的內(nèi)容。在 Base ClearCase 中，這要么是主分支，要么是具體的項目集成分支，在 UCM 中，這是 UCM 項目的集成流。要隔離一個版本的環(huán)境，也會實現(xiàn)一個版本準備線。通過創(chuàng)建一個擁有可以放置在活動開發(fā)線之下的候選標簽（或者 UCM 基線）的版本分支（或 UCM 流）來實現(xiàn)。該標簽將手動地生成 —— 或者更可能自動化地 —— 作為集成構(gòu)建的一部分。說明此結(jié)構(gòu)的圖如圖 2 所示?！　?/p>

圖 2：要隔離一個版本的環(huán)境，通過創(chuàng)建一個擁有可以放置在活動開發(fā)線之下的候選標簽（或者 UCM 基線）的版本分支（或 UCM 流）來實現(xiàn)一個版本準備線。該標簽將手動地生成 —— 或者更可能自動化地 —— 作為集成構(gòu)建的一部分。

　　敏捷項目不但提供簡化的分支策略，它還傾向于配置 ClearCase 默認為“無限制的”檢出模型。這允許開發(fā)人員檢出和檢入一個活動開發(fā)線上任意點上的文件（雖然如果在此期間另一個開發(fā)人員也檢出和檢入同樣的文件，應(yīng)該對這些進行一些合并）。默認的 ClearCase 模型對于第一次的檢出是“受限制的”。這意味著，您不需要必須合并而保證能夠?qū)⒃貦z入回去。然而，這還意味著，其他人不能檢出受限制的元素，直到您將其放回為止，檢出無限制元素的人必須等待在合并之前您將該元素檢入回去。這種方法真的違反敏捷原則。

　　使用快照視圖開發(fā)人員工作區(qū)。如果開發(fā)人員將要致力于單一的分支，那么不用選擇動態(tài)的視圖。動態(tài)視圖的能力在于當它們監(jiān)測的分支更新時，它們可以自動地更新自己。因此，如果許多開發(fā)人員在單個的分支上加上動態(tài)的視圖，那么在它們的工作區(qū)中幾乎不能控制或隔離。雖然開發(fā)人員分支不能實現(xiàn)，如我們已經(jīng)討論過的，但這可以導致其他的問題。因此敏捷項目會實現(xiàn)快照視圖，從中開發(fā)人員可以更新他們的工作區(qū)來從其他開發(fā)人員那里引入變更。在實踐中，這給予開發(fā)人員足夠的控制和隔離。

　　自動化構(gòu)建過程。單個的分支開發(fā)和增量的的檢入只有在頻繁地執(zhí)行自動化的構(gòu)建和測試時才能夠?qū)嵭?。大多?shù)敏捷項目將它們的構(gòu)建過程配置為在每個開發(fā)人人員的檢入之上執(zhí)行。除了編譯代碼，這種構(gòu)建過程還驗證新的代碼，用以觀察代碼是否符合預定義的編碼習慣，并且在必要處執(zhí)行單元測試。在敏捷開發(fā)方法中，該實踐常稱為持續(xù)集成。其預期的結(jié)果是為了盡早地暴露集成問題，以便容易地處理，以及在項目的每個階段都有建立好的、測試了的，以及可能的可發(fā)布的構(gòu)建。持續(xù)集成常常與測試驅(qū)動的開發(fā)實踐雜亂的鏈接在一起。這是因為開發(fā)人員需要對其代碼的所有方面實現(xiàn)單元測試來驗證構(gòu)建已經(jīng)編譯了，以及符合最低水平的功能質(zhì)量。在 ClearCase 術(shù)語中，敏捷項目構(gòu)建過程用于監(jiān)控集成分支（或 UCM 流）以及在檢入時執(zhí)行構(gòu)建教本。這由構(gòu)建執(zhí)行工具，例如 CruiseControl（http://cruisecontrol.sourceforge.net）或 IBM Rational BuildForge（http://www.ibm.com/software/rational/buildmanagement/）來實行。

　　執(zhí)行并再利用預構(gòu)建好的二進制碼。構(gòu)建任何相當復雜的軟件應(yīng)用程序都會花費時間，從幾分鐘到幾小時。在敏捷項目中，開發(fā)人員將會經(jīng)常交付并集成小的變更，因此很顯然他們不可能在得到反饋之前等待兩小時完成構(gòu)建操作。為了避免這種情況，敏捷項目“執(zhí)行”并再利用預構(gòu)建好的二進制碼，并且只有再必要時重新構(gòu)建整個系統(tǒng)（例如，每夜或每周）。有許多方式來執(zhí)行二進制碼。ClearCase 常常用于執(zhí)行二進制碼，標簽或基線設(shè)置在相關(guān)的版本之下，來指示可復用的二進制碼的復合集。對于 C/C++ 項目，ClearCase clearmake 實用程序也擁有一個避免構(gòu)建的機制，可以用于將大部分這種執(zhí)行自動化并再利用過程，雖然沒有證據(jù)證明敏捷項目使用此機制。對于 Java 項目，另一種方法是，在相關(guān)管理工具，例如 Ivy（http://jayasoft.org/ivy）或 Maven（http://maven.apache.org）中執(zhí)行預構(gòu)建好的庫。當項目再利用大量開源組件時，或在傳遞相關(guān)性方面存在問題時（也就是，庫依賴于其他的庫）這一點尤為適當。

　　作為復合的應(yīng)用程序而發(fā)布。當說到發(fā)布應(yīng)用程序時，試圖發(fā)布所有的文件，而不是發(fā)布個別集合。大多數(shù)敏捷項目更喜歡每次部署全部的或復合的應(yīng)用程序，而不是只部署已經(jīng)變更的個別的文件。雖然這不是硬性規(guī)定，每次以同樣的方式發(fā)布全部的應(yīng)用程序趨向于使過程更加可重復并且防止文件丟失所導致的問題。該實踐對敏捷項目比對高要求形式的項目更為重要，因為它們在每次迭代之后生成可執(zhí)行的、可測試的，并且可發(fā)布的應(yīng)用程序。很明顯，這依賴于應(yīng)用程序的目標環(huán)境。如果是 Web 門戶，那么該方法很好，但如果是一個消費者應(yīng)用程序（運行在，比方說，Microsoft Windows 上），那么完整的版本不可能每次都給客戶，所以就需要每次一個補丁。

　　限制 MultiSite 技術(shù)的使用。分布式的敏捷項目需要無限制的對單個代碼行的訪問。ClearCase MultiSite 技術(shù)從站點到站點復制完整的數(shù)據(jù)庫。為了避免每個站點所做出的變更的沖突，其實現(xiàn)了一個所謂 mastership（主權(quán)） 的概念。這意味著如果一個項目在多個站點上開發(fā)，并且開發(fā)人員正共用同一個分支，那么每個開發(fā)人員在提交變更之前要請求主權(quán)。有許多方法來處理這件事（包括創(chuàng)建基于站點的集成分支），但它們都增加了額外層次的復雜度，并且會減慢開發(fā)過程。出于這些原因，敏捷項目傾向于避免 MultiSite 技術(shù)。這就是為什么開發(fā)了 ClearCase Remote Client (CCRC) 技術(shù)，它允許基于脫離單個服務(wù)器的分布式開發(fā)。CCRC 的第一個版本限制了功能，然而，從版本 7.0 開始，它將對大多數(shù)分布式項目提供足夠的功能。因此它應(yīng)該成為進行分布式靈活項目的推薦方法。圖 3 中的屏幕快照說明了工作于 Eclipse 環(huán)境中的 ClearCase Remote Client。

　　　　

　　　　　　　　圖 3：工作于 Eclipse 環(huán)境中的 ClearCase Remote Client

避免 ClearQuest 變更控制的過度自定義。

　　實現(xiàn)一個開放的或可定制的變更請求工作流。IBM Rational 　　ClearQuest 工具提供非常強大且成熟的變更和缺陷跟蹤工具。雖然許多使用 ClearCase 的敏捷項目已經(jīng)完全避免使用 ClearQuest 的了，但是越來越多的項目在著眼于 ClearQuest 以及 UCM，看看是否可以用于幫助滿足組織遵從和法規(guī)的需求。的確，ClearQuest 可以在自動化獲取、劃分優(yōu)先級，及變更請求和特性儲備的分配上占有地位，如我在本文開頭所提到的。然而，過多的過程強制或過小的管理會令開始致力于新的變更任務(wù)的開發(fā)人員感到時間緊迫。如果不小心實行，這會嚴重地減慢整個開發(fā)過程并減少敏捷項目的生產(chǎn)率。為了避免這一點，敏捷項目實現(xiàn)輕量級的或可定制的 ClearQuest 變更請求工作流。當 ClearQuest 用于整個組織中時，這是尤為恰當?shù)?。在那些組織中的一些項目可能會需要更多的控制和管理，許多會嵌入 ClearQuest 工具中。然而，敏捷項目可能不需要或期望同等程度的過程控制和管理。在這種環(huán)境中工作的組織通過令變更請求工作流可以讓每個項目來配置而取得成功。然而，這種實現(xiàn)需要對 ClearQuest 工具和不同項目過程需求的詳細了解，并且應(yīng)該不容易著手。

適合于敏捷方法的過程

　　在本文中，我已經(jīng)討論了敏捷 SCM 的概念以及如何利用 IBM Rational ClearCase 和 IBM Rational ClearQuest 來實現(xiàn)的最佳實踐。希望該討論可以使您確信，可以找到并實現(xiàn)合適的過程來支持敏捷項目。值得注意的是敏捷 SCM 的實現(xiàn)不是只限于敏捷項目的。有許多項目不認為自己是敏捷的，但已經(jīng)有類似的 SCM 需求。這些趨向于較小的 IS/IT 項目，類似環(huán)境的配置會非常實際。但值得注意的是甚至是較大的項目也可以通過實現(xiàn)更輕量級的且精心設(shè)計的 SCM 過程，例如這里所介紹的，來得到一些東西。特別是，構(gòu)建自動化（包括編譯和測試）、預構(gòu)建好的二進制碼的執(zhí)行，和復合發(fā)布的實踐可被所有項目采用。

　　沒有理由說企業(yè)級 SCM 工具集，例如 IBM Rational 工具集，不能用于支持敏捷開發(fā)方法的實現(xiàn)。關(guān)鍵是，定義并實現(xiàn)一個著重于支持，而不是限制，敏捷團隊的敏捷 SCM 過程。對于這樣的團隊，找到正確的管理模型會是一個棘手的訓練，但是一般建議從更開放的過程開始，只在必要時實現(xiàn)限制。反饋也是敏捷開發(fā)方法的必要部分。SCM 可以有助于此反饋機制的一種方式是通過自動化的構(gòu)建和測試（及部署）過程。因此推薦您投入大量時間關(guān)注您整個過程中的這個方面。

注釋：

1 要了解敏捷和傳統(tǒng)的開發(fā)方法相對比的優(yōu)缺點和成功方面的討論，請參見 Barry Boehm 和 Richard Turner 的優(yōu)秀書籍，Balancing Agility and Discipline: A Guide for the Perplexed: Addison Wesley 2004 年。另外，要了解關(guān)于敏捷開發(fā)方法的最新討論和案例研究，您可以訪問并訂閱The Agile Journal（http://www.agilejournal.com）。

2 Stephen P. Berczuk 和 Brad Appleton，Software Configuration Management Patterns. Effective Teamwork, Practical Integration。 Addison Wesley 2003 年。另參見 Brad Appleton et al.，Streamed Lines: Branching Patterns for Parallel Software Development。PLoP Conference：1998 年。http://www.cmcrossroads.com/bradapp/acme/branching/

3 參見 Appleton，1998 年，Op. cit。

4 要了解更多關(guān)于如何為敏捷項目設(shè)立自動化的構(gòu)建環(huán)境的信息，請參見 Kevin A. Lee，IBM Rational ClearCase, Ant and CruiseControl。The Java Developers Guide to Accelerating and Automating the build process。 Addison Wesley 2006 年。