過去 10 年中，軟件社區大量采用了敏捷實踐。這些實踐反映了現有的瀑布式軟件開發流程中的缺陷：
交付緩慢
瀑布式方法需要幾個月或者甚至幾年才能創建出可執行（且可審核）的系統，因此減少了利益相關者提供反饋的機會，限制了業務靈活性。
盡早決策
由於提供審核和建議的機會有限，利益相關者必須盡早地確定對系統成功至關重要的特性。
有限的調整機會
長期、固定的計劃減少了針對新環境進行調整的能力，無論是從技術發現還是從業務變更方面。
相比較而言，敏捷實踐持續集成小型系統變更，提供了一個用於持續審核的環境。它們將大型項目分解成為相對較小的用戶故事 和任務，然後將它們集成到一個持續集成 和構建流程中。持續集成變更能夠盡早揭示錯誤，供早期系統驗證所用。它還支持更加頻繁的審核，這有助於實現早期驗證。
在典型的 scrum 流程中，利益相關者（產品所有者）會確定產品積壓目錄 中某個工作列表（用戶故事）的優先級。在每次迭代開始時，產品所有者從產品積壓目錄選擇最高優先級的工作項目，與開發團隊討論它們的細節。然後，開發團隊將這些故事分解為任務，在隨後的 2 到 4 周的沖刺（sprint）（迭代）中完成。在沖刺階段，開發團隊會不斷地會面（每日 scrum 會議）和不斷地集成變更。沖刺結束時，開發團隊向產品所有者演示來自最新的系統構建版本的新功能。
許多早期敏捷成功故事擁有相同的特征：小型團隊、相同地點、構建相對較小的 IT 類型 Web 或數據庫應用程序。但是，復雜系統開發能夠（而且確實已經）從這些敏捷價值中獲益，包括更快的交付、延遲決策、持續集成、早期反饋和自適應規劃。
例如，在本文中，一家虛構的電信公司提供了一個嵌入式零部件的產品線。本文將介紹他們遵循的敏捷實踐，他們在現有的開發基礎架構中面臨的挑戰，以及他們遷移到 IBM Rational Team Concert 協作式軟件後如何應對這些挑戰。
一家移動通信行業的電信提供商負責供應移動電話的零部件。他們的團隊被組織成硬件團隊、固件（軟件團隊）、測試團隊和一個應用程序支持團隊。應用程序支持團隊創建開發工具和測試平台，並對遇到問題的客戶提供支持。客戶產品領導 (Customer product leads, CPL) 管理與客戶的關系，並將來自客戶的增強請求和缺陷報告提供給工程團隊。CPL 類似於 scrum 項目管理中的產品所有者角色。
以前，CPL 使用一個電子表格來跟蹤工作。通過在電子表格中上移或下移行來不斷調整開發的優先級。工程團隊使用了一個在內部開發的單獨系統來跟蹤測試和客戶發現的缺陷。固件團隊有兩個工作積壓列表：電子表格和問題跟蹤缺陷。工程經理在 Microsoft Excel 中編寫 Visual Basic (VB) 宏，以便從問題跟蹤系統外部收集數據，進而收集各種指標。他們使用一個現有的、基於分支的工具來處理配置管理 (CM)。
上世紀末的經濟低迷，這使得該企業有機會擴大其客戶群。每個客戶都擁有獨特的需求，可能還有額外的硬件需求。最初的一個硬件平台上的單個產品已增長為跨 4 個硬件平台的超過 18 個產品變體（product variant）。圖 2 描繪了從單一產品 A 到跨多個硬件平台的產品變體的增長過程的一部分。每條線表示一個產品變體，箭頭指示了變更在各個產品變體之間的流動方式。
移動通信行業是高度動態和敏捷的。制造商不斷根據反饋集成供應商的零部件的新版本，以盡早揭示問題和顯示進度。因此，提供商需要頻繁地提供新版本，有時一個月提供多次新版本來應對反饋。CPL 不斷與制造商通信，確定將在未來的交付中包含哪些變更。基於這些對話，CPL 每周與固件團隊領導重新計劃工作兩次（從敏捷角度講，就是每周兩次沖刺）。
出於多種原因，不斷擴大的客戶群為固件團隊帶來了大量挑戰。每個新客戶通常擁有定制的增強。由於功能成本、硬件平台、可用內存等因素，不是所有變更（增強和缺陷修復）都會提供給每個客戶產品變體。讓情況變得更糟的是，客戶可能選擇以不同的順序獲取變更。在圖 3 中所示的示例中，客戶 A 需要交付一個變更，但他不需要之前的 2 個變更。在未來的某個時候，之前的變更可能會也可能不會提供給客戶 A 的產品變體。
查看本欄目
不斷擴大的客戶群還要求工程團隊滿足所選的產品變體和新客戶的時間安排。管理這種環境的變更很復雜，因為不是所有變更都將提供給所有產品變體，或者它們可能以不同的順序提供。為了跟蹤工作，每個客戶產品變體都有自己的優先的工作積壓目錄，如圖 4 所示。請注意，只有一個開發團隊（固件團隊）完成了所有這些積壓工作。
隨著新客戶的增加，他們的工作積壓列表將記錄在 Excel 電子表格中的一個新選項卡中。在選項卡之間復制表示工作（用戶故事中的缺陷或增強）的行，以便記錄特定客戶對特定變更感興趣的事實。但是，在電子表格中，無法關聯重復的工作，如圖 5 所示。對於給定變更，沒有任何跡象表明哪個產品變體包含該變更以及何時提供它。
不斷擴大的客戶群還為舊有的配置管理系統帶來了挑戰。在基於分支的配置管理系統中，已修改的每個文件必須放在一個獨立分支中，如圖 5 所示。一次變更可能涉及 5、10 或超過 100 個文件，而且需要固件工程師為每個文件創建合適的分支。
此環境中的大多數合並操作都很復雜，因為不是所有變更都將交付給特定客戶，或者（更糟的情況是）可能不按順序交付。基於分支的配置管理系統中的復雜合並容易出錯，因為這些配置管理系統不會管理變更；它們只管理各個文件變體。執行合並的工程師負責了解哪些文件與變更關聯，這些文件位於哪個分支上，以及它們需要在何處合並。這是一個耗時、容易出錯的過程。
合並錯誤具有很高的代價，因為它們常常難以定位。由於這種復雜性和潛在的成本，固件團隊建立了一個稱為集成人員（Integrator）的角色。只有集成人員才有資格將變更合並到客戶分支中。不幸的是，集成人員成為了流程中的瓶頸，有時還會導致不能按時將特性或缺陷修復包含在需要每個月交付多次的版本中。
盡管他們沒有明確地自稱 “敏捷”，但移動通信行業中的公司遵循了許多敏捷原則，就像這家公司一樣。他們頻繁地集成變更（持續集成），甚至跨提供商，一個月集成多次。此外，基於他們從與客戶的頻繁對話中獲得的信息，他們不斷調整產品積壓工作的優先級（自適應規劃）。對於這家組織，此過程每周發生兩次。
更小規模的工作、自適應規劃和持續集成等敏捷實踐，可能讓未准備處理這些變更的開發組織手足無措。他們現有的工具不是為處理我們今天看到的頻繁變更和集成而設計的。在許多情況下，我們現在看到組織中的變更流程所花的時間比系統中的還要多。這個變更流程的開銷常常體現在變更管理工具的缺陷上，就像本文中的情況：過時的配置管理系統、Excel 和 VB 宏。
總體來講，這個工程組織面臨著三大關鍵挑戰：
Excel 難以跨產品線來規劃和跟蹤工作。在他們嘗試跨產品線管理和優先化變更，然後嘗試理解已對哪些產品變體做了哪些變更，何時將對一個產品變體執行特定的變更時，該過程會迅速土崩瓦解。
基於分支的配置管理軟件無法滿足他們的敏捷、持續集成需求。無法簡單地將代碼變更與電子表格計劃中的工作任務相關聯，所以很難看到其他人在以前的產品變體中做了哪些變更。配置管理工具對復雜的合並愛莫能助，這導致需要一個集成人員角色來執行合並。集成人員成為了瓶頸，延遲了變更的交付。
工程經理需要浪費一些時間在 Excel 電子表格中創建 VB 宏，以便連接到狀態信息的開發存儲庫。
該團隊選擇采用 Rational Team Concert 來應對這些挑戰。該組織有三大主要需求：
一個更加強大的配置管理工具
他們需要一個解決方案，以便在選擇將一個變更合並到一個產品變體中時，幫助更輕松地識別要合並的所有文件變體。它必須提供一種更輕松的方式來集成變更，以便不再需要集成人員角色。該軟件還必須支持 Excel 電子表格任務與執行的代碼變更之間的關系，以便在不同產品變體中重新應用該變更時，他們能夠更好地了解更改了哪些代碼。
簡化的跨產品線規劃
他們需要為一個將應用於多個產品變體的變更創建獨立但相關的工作任務，以便獨立地管理它們並設定優先級。工作任務需要進行關聯，以便 CPL 能夠確定哪些產品線擁有缺陷或增強，開發團隊可找到針對該缺點或增強的所有代碼變更。他們需要一種機制來簡化產品線內和跨產品線的工作時間安排。
更輕松、更有效的開發狀態可視化
工程經理厭倦了通過更新和運行 VB 宏來獲取開發流程的狀態。
本節介紹團隊如何使用 Rational Team Concert 應對與配置管理相關的挑戰。
將代碼變更與工作相關聯
為了解決第一個需求，Rational Team Concert 提供了與工作項 自動建立關系的功能。軟件開發人員可輕松地將一組代碼變更與分配給他們的工作相關聯。圖 6 的屏幕部分顯示了工作項和它們關聯的文件更改。這使得開發人員能快速查找對另一個產品線執行了哪些變更，無需查找代碼分支。采用 Rational Team Concert 之前，工程師必須查看代碼分支，查找其他人在另一個產品線上做了什麼。現在他們可輕松地找到工作任務並查看所有關聯的變更集。
此外，開發人員可使用 Rational Team Concert 同時處理同一個工作區中的多個變更。他們不需要創建源代碼存儲庫的多個本地副本，記住哪些本地副本與哪次變更相關聯。開發人員只需選擇要暫停或恢復工作的工作項，Rational Team Concert 可以使用這些變更自動配置本地沙盒。
基於流的配置管理
Rational Team Concert 基於流的 配置管理提供了一種更簡單、更強大的方法來管理產品線變更。圖 5 顯示了選擇一個變更，然後查找和合並所有相關文件的挑戰。Rational Team Concert 自動識別必須合並到傳入的流（產品變體）中的所有文件變更。
查看本欄目
這裡的一個局限性是，Rational Team Concert 在不按順序交付變更時使用了一種補丁 解決方案。補丁機制的挑戰在於，我們失去了一個通用變更的可跟蹤性（不過，本文後面將提供這一局限性的一個解決方案）。Rational Team Concert 團隊認識到他們需要一個更好的解決方案，而且 Rational Team Concert 積壓目錄中有多個解決此問題的工作項。
幫助處理復雜的合並
Rational Team Concert 以多種方式幫助解決復雜合並。首先，它提供了將變更合並到一個新流（產品變體）的所有必要因素的視圖。因此，不會錯誤地確定哪些文件需要合並。如圖 8 所示，Rational Team Concert 列出了每個變更集的文件，指明了合並過程中何處存在潛在的沖突。
開發人員也可以在執行復雜合並之前獲取其個人工作區的快照。在合並過程中，Rational Team Concert 自動將所有合並相關的變更存儲在一個獨立的變更集中。如果合並不順利，開發人員可通過暫停或丟棄變更集來恢復到快照狀態。
跨產品線的多個鏈接的工作任務
開發人員可復制 一個工作項，創建一個引用了原始工作項的獨立副本。復制的工作項對固件團隊很有用，可以使用這些工作項創建跨多個產品線執行的工作。獨立（但鏈接）的工作項可分開計劃和開發。您可以快速查看原始工作項上的鏈接，以查看其他哪些產品變體將擁有此變更，以及它們是否已交付。
在圖 10 中，故事 174 被創建為故事 57 的一個副本。當開發人員開始在故事 174 上工作時，他可以訪問相關的故事 57 的鏈接（已在故事 174 中突出顯示），然後在其工作區中接受故事 57 的變更集（已在故事 57 中突出顯示並顯示為紅色變更集）。如果接受以前的故事的變更集，則會自動將所有文件區別放入開發人員的工作區中。合並所需的新變更會自動將這些變更放入到一個新變更集中，並與故事 174 關聯，如圖所示。
流程支持
固件團隊還使用 Rational Team Concert 流程控件。破壞的構建版本會大大減緩使用持續集成實踐的敏捷團隊的進度。Rational Team Concert 使團隊能夠鎖定向各個流的交付，以便只有當前計劃發布給客戶的工作是可交付的。盡管有人可能會想，任何工作軟件都可以在一次迭代期間進行交付，但嵌入式軟件對時間和空間問題很敏感，不是為當前迭代規劃的軟件可能與未來的版本相分離，從而破壞構建版本。
但是，固件團隊還希望使工程師能夠合作探索未來工作的實施解決方案。解決方案是為客戶流執行一個嚴格的交付策略，然後使用更加寬松的交付規則創建一個 Rational Team Concert 沙盒 團隊。沙盒團隊中的開發人員可使用限制更少的規則，為協作創建額外的流。
電子表格計劃具有許多限制。它難以管理和跟蹤跨產品線的重復工作，很難調整優先級，而且人們一般不願意創建詳細的工作任務，因為創建和移動它們很困難。結果，許多與一個變更有關聯的工作任務（對硬件測試台的更新，對開發工具的修改）都未跟蹤，因此可能丟失它們。
子工作項
Rational Team Concert 是第一批簡化工作項之間的關系的問題跟蹤系統之一。該軟件使得創建關系並然後浏覽和查詢它們變得很簡單。嵌入式系統開發可能需要在執行固件變更後執行下游任務，比如更新測試台、客戶開發工具、用戶文檔等。當然，您不希望缺少這些任務。
這些任務不會出現在電子表格計劃中，所以它們存在丟失的風險。Rational Team Concert 在工作項之間建立的關系使得工程師能夠定義這項額外的工作並跟蹤它，確保它在交付前已完成。
跨產品線的計劃
跨多個產品線的計劃太過龐大，無法在電子表格中完成。CPL 和固件團隊需要采用一種機制來顯示為哪些迭代計劃了哪些工作，支持在迭代之間輕松地轉移工作。
Rational Team Concert 敏捷計劃功能解決了許多這樣的問題。工作可在多種自定義的計劃模式下查看，這使得 CPL（產品所有者）能夠查看單個產品線的工作。新產品安裝一周後，CPL 和固件團隊領導使用 Rational Team Concert 計劃工具（而不是電子表格）來幫助執行一周兩次的計劃會議，並取得了巨大成功。
盡管取得了成功，但使用 Rational Team Concert 進行跨多個時間線的計劃有一些挑戰。該計劃基於敏捷原則。時間線分解為嵌套的迭代（版本-沖刺），並且在任何層級上只有一個迭代是最新的（2.1 版，沖刺 3）。敏捷團隊處理單一的時間線。為了支持這些敏捷實踐，這些計劃選擇了單一的團隊（或團隊的團隊）和單一的迭代（版本、沖刺）來計劃和跟蹤工作。在產品線系統中，一個團隊處理多個產品線，每個產品線擁有自己的時間安排。
在單個團隊（固件團隊）處理多個積壓目錄，一個目錄對應一個客戶產品變體時，存在一個問題。要查看針對不同客戶的工作，固件團隊需要不斷更改計劃的 Planned For 屬性。敏捷提倡者會說，CPL 應在內部跨不同客戶確定其工作的優先級，向固件團隊提供單一、統一的積壓目錄。但是，這不是合理的請求，而且有一些要求在單個計劃上選擇多個時間線的 Rational Team Concert 增強請求。
這家組織選擇讓 CPL 來跟蹤分開的時間線中的工作。當敏捷團隊希望看到他們的工作時，可以更改其計劃所引用的時間線。盡管更改計劃時間不是一個理想的解決方案，但也是一個不錯的解決辦法，而且總體解決方案比電子表格好得多。
為了報告工程狀態和執行情況，工程經理在 Excel 中編寫了 Visual Basic 腳本，以便從以前的問題跟蹤系統中拉取數據。Rational Team Concert 工作項查詢和包含的儀表板為跟蹤進度提供了一個輕松的解決方案。工程經理在 Rational Team Concert 部署後的第一周就開始配置其儀表板。
本文介紹了一家跨多個產品線開發嵌入式產品的電信提供商如何應用敏捷實踐。隨著企業客戶群的不斷增大，由於以下因素，固件團隊很難滿足交付時間表：
Excel 難以跨產品線規劃和跟蹤工作。當他們嘗試跨產品線來管理和優先化變更、隨後嘗試理解已對哪些產品變體做了哪些變更以及何時將對一個產品變體執行特定變更的時候，該過程會迅速土崩瓦解。
基於分支的配置管理軟件無法滿足他們的敏捷、持續集成需求。無法簡單地將代碼變更與電子表格計劃中的工作任務相關聯，所以很難看到其他人在以前的產品變體中做了哪些變更。配置管理工具對復雜的合並愛莫能助，這導致需要一個集成人員角色來執行合並。集成人員成為了瓶頸，延遲了變更的交付。
工程經理需要浪費一些時間在 Excel 電子表格中創建 VB 宏，以便連接到狀態更新的開發存儲庫。
Rational Team Concert 通過下表中所示的變更，解決了幾乎所有這些問題。
有趣的是，第一次與這個客戶交談時，他們討論的問題是基於分支的集成。但他們很快認識到，Rational Team Concert 工作項和計劃功能是一個好得多的產品線計劃和跟蹤解決方案。
