Rational Team Concert 是一個建立在可伸縮，可擴展平臺上的團隊協作開發工具，提供了很多功能，整合了軟件開發項目生命周期的所有任務，包括計劃、迭代、流程定義、變更管理、缺陷跟蹤、源代碼控制和源代碼管理、產品構建自動化，和各種各樣的分析報告等。
1 介紹 Rational Team Concert
Rational Team Concert 是建立在 Jazz 技術平臺上，支持若干種 Agile 開發模型。Jazz 技術平臺使軟件開發更加靈活，支持團隊成員分布在不同地理位置，提供從小型團隊到大型企業的可擴展的軟件開發解決方案。Rational Team Concert，有時簡稱 RTC，具有如下特性 :
使用 Rational Team Concert，在軟件開發中，能夠實現信息的交換和信息集成，如果某個需求變化了，團隊成員就會自動收到通知，團隊成員也可以通過多種方式了解這種變化。Rational Team Concert 中的各種視圖可以讓你更詳細地了解信息，跟進團隊的開發進度和活動。
Rational Team Concert 使開發團隊能夠輕松和有效地執行和定制流程，這個流程是角色、實踐活動、規則、權限的集合。
Rational Team Concert 中，變更管理的主要特點是用工作項跟蹤和協調各種任務，這些任務包括故事（story）、缺陷（defect）、計劃項（plan item）、以及普通任務（task）等。工作項和工作流程是靈活可定制的，工作項也可以與其他的變更管理系統進行整合和集成。
Rational Team Concert 中提供了工具來保證計劃管理能力，對于項目團隊，這些工具能夠計劃、跟蹤、平衡項目的工作量，以反映團隊的實際狀態。對于 Scrum，可以創建和管理迭代計劃。
Rational Team Concert 內置的源代碼控制管理系統是基于組件的和建立在 Jazz 平臺上的，它支持并行和敏捷開發，支持分布在不同地理位置的團隊開發，同時它緊密地集成了缺陷跟蹤、構建、和以流程為中心的自動化。
對于開發和測試團隊，Rational Team Concert 提供了自動地構建識別、構建控制和構建可追溯性。團隊成員可以跟蹤構建的進度，查看構建的警告信息和結果，提交構建請求，并跟蹤構建過程。
Rational Team Concert 的報告組件能夠顯示項目的進展和項目狀態，可以容易地分析某些可能被隱藏的趨勢；軟件開發過程中的可視化數據和各種分析報告，能夠支持有效的決策。
- Eclipse 客戶端，Visual Studio 客戶端和 Web 界面
這些客戶端界面為開發者提供了一個靈活的集成開發環境。
2 Rational Team Concert 與 Scrum
Rational Team Concert 是個非常優秀的 Agile 敏捷開發管理工具，內置了幾個過程模板，可以用來支持一些敏捷開發方法，比如 Scrum 過程、OpenUP 過程和 Eclipse Way 過程等等。本文分享一些使用 Rational Team Concert 實現 Scrum 敏捷開發的使用經驗。
Scrum 是一個典型的迭代式增量的敏捷軟件開發過程。整個開發過程由很多次迭代組成，每一次迭代是一個 Sprint，每個 Sprint 的周期一般是 2 周到 4 周。在 Scrum 中，用 Product Backlog 來管理產品功能或項目的需求，用 Sprint backlog 管理每個 Sprint 的任務。在每個 Sprint 中，Scrum 產品負責人從 Product Backlog 中挑選最高優先級的需求，在 Sprint planning 會議上由團隊成員討論，估算工作量，確定 Sprint backlog 任務列表。在項目進行中，每天要舉行 Scrum 例會（Daily Scrum meeting）。在每個 Sprint 結束時，Scrum 團隊提交增量的可交付物。每個 Sprint 結束時，團隊成員進行總結和回顧，吸取本次 Sprint 的經驗教訓，為下一個 Sprint 做準備。請參考圖 1 Scrum 模型。
圖 1. Scrum 模型
Scrum 由以下幾個部分組成：
- 角色（Roles）
- 產品負責人（Product owner）
- Scrum 負責人（Scrum master）
- 團隊成員（Team member）
- 各種儀式和會議（Ceremonies）
- 每天 Scrum 例會（Daily Scrum meeting）
- Sprint 計劃會議（Sprint Planning meeting）
- Sprint 評審會議（Sprint Review meeting）
- Sprint 回顧會議（Sprint Retrospective meeting）
- 工件（Artifacts）
- Product Backlog
- Sprint Backlog
- Burndown Chart
- Impediments List
在 Scrum 中，產品功能或項目的需求會列在 Product Backlog 中。Product Backlog 是一個項目所需的所有需求或功能的優先級列表，這個列表條目常常以用戶故事（user story）的形式體現。產品負責人（product owner）維護這個列表，根據項目的進展和商業環境的變化修改優先級列表。產品負責人對產品的成功負責，定義產品特性和產品發布時間表，負責確定各種功能的商業價值，不斷完善和優化 Product Backlog。
Scrum 負責人（Scrum master）管理 Scrum 過程，確保 Scrum 的做法是正確的，并且讓團隊成員理解 Scrum 的價值，消除項目進展中遇到的障礙，并保護團隊成員不受外界干擾。
在每個 Sprint 開始的時候，小組舉行 Sprint Planning 會議。在 Sprint Planning 會議上，產品負責人為即將到來的 Sprint 展示最想要實現的產品功能或項目需求，讓團隊成員把握和分析需要實現的功能，產品負責人和團隊成員在本次 Sprint 中的目標達成一致，確定未來 2 周到 4 周的工作重點。然后團隊成員決定如何完成這次 Sprint 的目標，并分解成所需的任務，這些任務就組成了 Sprint Backlog 的任務列表。在 Sprint Backlog 中，每個任務按小時預估完成時間，團隊成員確定是否可以按時完成開發任務，如果沒有足夠的時間完成某個功能，可以將該功能從當前的 Sprint Backlog 中返回到 Product Backlog。Sprint Backlog 中列出了團隊成員已經承諾在本次 Sprint 期間完成的工作。根據團隊經驗來評估工作量，而不是由 Scrum 負責人或產品負責人決定，這是 Scrum 的一個特點。
在每個 Sprint 結束，需要召開 Sprint Review 會議，評審已經完成的工作。Sprint Review 會議是一個簡短和非正式的會議，任何感興趣的人都可以參加，并從參與者得到一些反饋。
團隊成員可以舉行 Sprint 回顧會議（Sprint Retrospective），分析項目的經驗。通過本次 Sprint 回顧會議，不斷改進團隊工作方式和不斷提高工作效率，為下一個 Sprint 做好準備。
Rational Team Concert 中提供了 Product Backlog 和 Sprint Backlog 的功能，它們同 Scrum 敏捷開發中的重要工件 Product Backlog 和 Sprint Backlog 一致。
在 Rational Team Concert 1.0 中，如果創建 Product Backlog，切換至 Team Artifacts 視圖，并在項目區域中，選擇 Release 1.0，然后選擇 New > Plan。在 New Plan 窗口中，輸入 Product Backlog 作為名字。選擇 Product Backlog 作為 Plan Type。
在 Rational Team Concert 3.0 中，在 Plans?All plans?Main Development?Backlog 下，有默認的 Product Backlog。打開 Product Backlog，點擊 Planned Items 項，可以為 Product Backlog 添加工作項，這些工作項的類型為 Epic 和 story，對于 Scrum，類型為 story 和 epics 的工作項，描述了 Agile 中的用戶故事，包括項目需求或產品功能。
在添加所有的工作項之后，產品負責人要為工作項設置優先級，優先級屬性有 High、Medium 和 Low，這可以定義實現工作項的優先級順序。
圖 2. Product Backlog
圖 2 大圖
在 Rational Team Concert 中，Sprint Backlog 中包含了來自于 Product Backlog 相關的具體工作項。RTC3.0 含有默認的 Sprint，例如 Sprint1，Sprint2，并且有默認的 Sprint Backlog，對于有多個 Sprint 的項目，如果要創建新的 Sprint Backlog，首先需要創建 Sprint，然后才能為該 Sprint 創建 Sprint Backlog。打開 Sprint Backlog，在 Sprint Backlog 的 Notes 頁面上，能夠填寫 Sprint 的目標，在 Planned Items 頁面上，可以為 Sprint 添加工作項，然后，詳細分解工作項，定義任務。
圖 3. Sprint Backlog
還有另外一種方法為 Sprint 添加工作項，在 RTC 中，打開 Product Backlog 窗口，選擇相關的工作項，然后右擊并選擇 Plan For，把這個工作項指定給某個 Sprint。
圖 4. 給 Sprint 添加工作項
圖 4 大圖
在 Sprint Planning 會議中，團隊成員分析需要完成的任務，為每個任務估計時間，
當估計完所有的工作項之后，可以看到每一個故事的總體估計值，以及整個 Sprint 階段的總體時間估計值。
一般來說，Scrum 負責人分配任務給團隊成員，團隊成員也可以主動領取，在 Sprint Backlog 的列表內，可以實現將任務分配給團隊成員。
圖 5. 給工作項分配所有者
圖 5 大圖
在每個 Sprint，團隊成員要每天更新 Sprint Backlog 中的工作項狀態和時間估計，這樣，根據更新后的工作項，RTC 便可以產生一個 Sprint Burndown 圖表，這個 Sprint Burndown 圖表以圖形方式顯示剩余的工作項和工作量，顯示項目的進展，預測項目的未來情況。
3 使用 Rational Team Concert 有效地進行每天的 Scrum 會議
Agile 敏捷開發實踐中，強調團隊的自我管理。在 Scrum 中，自我團隊管理體現在每天的 Scrum 會議中和日常的協同工作，在每天的 Scrum 例會中，團隊成員一般回答一下幾個問題 :
- 昨天完成了什么？
- 今天要做什么？
- 項目進展中，遇到了什么障礙和問題？
整個會議應該少于 15 分鐘。這種經常性的溝通，讓團隊成員能夠了解每個人都在做什么，他們正面臨著什么問題，有什么事情需要其他團隊成員幫助解決，提高團隊成員的協作。
在 Scrum 中，要堅持舉行每天的 Scrum 會議 , 了解團隊成員的工作進展和遇到的問題，Scrum 負責人要維護一個障礙列表（Impediments List），幫助解決團隊成員遇到的阻礙和問題，保證項目順利進行。
每天的 Scrum 會議可以增加團隊成員之間的溝通，并幫助團隊成員更有效地工作。
在 Rational Team Concert 中，通過集成的視圖，團隊成員能夠了解各種任務、計劃、工作項，也可以查看當天需要完成的工作項，當團隊成員更新每日的工作項時，其他成員也可以看到。
在 Rational Team Concert 中，通過持續跟進工作項，團隊成員可以更好地了解工作項的優先級，集中精力在優先級高的工作項上，保證項目的正常進展。團隊成員還可以規劃自己的工作內容和更新剩下的工作項。例如，在 Rational Team Concert 的迭代計劃編輯器中，團隊成員可以直接看到今天或本周的工作項。這些都有助于每天的 Scrum 會議，了解每天的 Scrum 會議中的問題。
Team Central 視圖中的 Team Load 部分也可以顯示團隊工作負荷，在每天的 Scrum 會議之前，Scrum 負責人可以監控團隊成員工作負荷。
Rational Team Concert 提供了 My Work 視圖以幫助每一位團隊成員查看和跟蹤自己的工作項狀態。在 Sprint 階段，團隊開發人員可以在 My Work 視圖中看到任務和工作項。
圖 6. My work 視圖
Planned Time 視圖可以查看工作項的剩余時間，支持 Daily Scrum 會議，團隊成員可以根據 Planned Time 視圖討論哪些已經完成和哪些還沒有完成。為了幫助跟進每個工作項的工作量，團隊成員應該在 RTC 中每一天更新每個任務的剩余時間。
圖 7. Planned Time 視圖
圖 7 大圖
開發員的任務面板也可以分配和監視工作項，它顯示了每個團隊成員的任務。
團隊成員可以使用查詢來監視工作的進展狀況，Rational Team Concert 已經有很多可用的預定義查詢，還可以輕松創建新的查詢。預定義的查詢，預定義了一些查詢條件，可以直接用來查詢工作項，比如，'Open assigned to me'，'Recently modified'等，這些預定義的查詢可以用于每天的 Scrum 會議，團隊成員和 Scrum 負責人可以快速了解每個工作項的進展。
圖 8. 創建一個新查詢
對于地理位置上分散的團隊，每天的 Scrum 會議有時通過電話或視頻會議進行。Rational Team Concert 可以更好地輔助管理每天的 Scrum 會議，可以很快捕捉和處理阻礙項目的事情，然后，通過團隊成員的協作，完成這些工作項或重新分配這些工作項。
4 在 Scrum 中，用 Rational Team Concert 進行軟件源代碼控制管理
在 Agile 敏捷開發最佳實踐中，持續集成和自動化構建可以保證高質量的軟件開發，持續地交付有價值的軟件產品來提高客戶的滿意度。作為軟件開發項目，需要一個高效和協作的軟件源代碼控制管理系統。Rational Team Concert 就是這種源代碼控制管理系統，可以進行變更管理和配置管理，幫助開發團隊管理源代碼、管理文檔、跟蹤代碼和共享代碼的各種變化，并保持整個開發團隊的高效協同工作；同時，Rational Team Concert 提供了自動地構建增量可交付物的功能，實現了軟件開發的持續集成和自動化構建，實現高效的敏捷開發。
下圖顯示了在 Rational Team Concert 中源代碼控制流轉過程，開發人員把變更的源代碼檢入到存儲庫工作空間；然后提交到共享的開發流中，其他開發人員接受這些變更的源代碼，并且裝載到存儲庫工作空間中。
圖 9. 源代碼控制流轉過程
在 Rational Team Concert 中進行源代碼檢入（check in）和檢出（check out），需要連接存儲庫和項目區域，下載源代碼到本地存儲庫工作空間中。首先把源代碼從開發流裝載到本地存儲庫工作空間，然后，在本地存儲庫工作空間修改源代碼，提交變更的源代碼到開發流中。開發人員在 Pending Changes 視圖中，展開 Unresolved 節點，檢入源代碼，加上一些注解，然后，在 Outgoing 節點下，通過提交（Deliver）的功能，就可以把變更的源代碼提交到開發流中。
當開發人員提交了變更的源代碼到開發流中，團隊中其他成員就可以接受這些變更，把變更的源代碼同步到自己的本地存儲庫工作空間中。開發人員在 Pending Changes 視圖中的 Incoming 節點下，選擇變更集，然后，接受（Accept）這些變更，這些變更的源代碼就進入了自己的存儲庫工作區。
5 在 Scrum 中，靈活使用 Rational Team Concert 的工作項
在 Agile 敏捷開發中，以用戶故事（user story）的形式定義各種需求，Rational Team Concert 為 Agile 敏捷開發提供了類型為故事（story）和歷史（Epic）的工作項，可以定義用戶故事，定義的工作項會顯示在 Product Backlog 中。在每個 Sprint，Sprint Backlog 中的任務也是一種類型的工作項，同時，工作項也是跟蹤、協調開發任務和工作流轉的基本機制，它是各種部件和元素之間的聯系樞紐。
在 Scrum 過程中，Rational Team Concert 提供了一些常用的預定義工作項類型，這些類型的工作項全面支持 Scrum 敏捷開發。
- 缺陷（defect）：定義缺陷和跟蹤缺陷。
- 回顧（retrospective）：記錄先前正常但在最近完成的迭代中不再正常的內容。
- 故事（story）：描述用戶故事和需求。
- 歷史（Epic）：用戶故事或需求很大而需要在多個迭代（Sprint）中完成，或者由于未知情況過多而無法估計工作量的用戶故事。
- 任務（task）：描述特定的工作任務。
- 障礙（impediment）：跟蹤導致無法取得進展的因素。
在 Rational Team Concert 中，Product Backlog 中的用戶需求或產品需求是通過工作項來描述，在 Scrum 的每次迭代中，用戶需求或產品需求會被分解成為足夠小的類型為任務的工作項，放在 Sprint Backlog 里，并且每一個任務是被賦予了優先級。
在工作項中有很多屬性，充分和準確使用這些屬性，Rational Team Concert 可以讓 Scrum 敏捷開發更有效率。
圖 10. 工作項屬性
摘要（Summary）字段是一個工作項的簡短總結和標題，可以讓 Scrum 成員和 Scrum 負責人快速理解工作項內容。
工作項的類型（Type）定義了工作項的特性，包括缺陷（defect），任務（Task），故事（Story）等，不同的類型有不同的屬性和不同的狀態變化。類型為故事（story）的工作項，可以描述 Scrum 的 Product backlog 中的用戶需求或產品需求。類型為任務（task）的工作項可以定義 Scrum 中每一次迭代（Sprint）的任務。類型為缺陷（defect）的工作項可以記錄每個 Sprint 中測試驗證階段的缺陷，跟蹤缺陷的修復狀態和進展。
嚴重級別（Severity）定義了工作項的嚴重等級。
描述（Description）字段詳細描述了工作項的目標和相關信息，描述 Scrum 中的需求和任務。
所有者（owner），顯示這個工作項當前的擁有者或執行者。在 Scrum 中，團隊成員可以通過這個字段知道自己負責的任務，Scrum 負責人可以分配任務和了解團隊成員的任務情況，在每天的 Scrum meeting 時，可以監控 Sprint 的進展。
優先級（Priority）屬性指定這個工作項的重要性和優先順序。高優先級的工作項將會被優先開發并確保完成。低優先級的任務有可能被轉入下一個迭代（Sprint）周期繼續開發。
計劃目標（Planned for）屬性指定這個工作項屬于某個 Sprint。
狀態 / 解決（State/Resolution），顯示這個工作項的當前狀態。
在 RTC 中，靈活使用工作項，可以提高 Scrum 的執行效率，下面介紹一些使用工作項的技巧：
在摘要（Summary），描述（Description）和討論（Discussion）字段中，支持粗體（"bold"）和斜體（"italic"），也可以創建與其他工作項的鏈接。在工作項中，可以選擇一些文本，使用上下文菜單中提取工作項的功能（Extract Work Item），提取相關的工作項內容。
在討論（Discussion）字段中，添加評論，也可以和評論的作者進行聊天會話或發送郵件。
在快速信息（Quick Information）部分 , 可以通過上下文菜單添加訂閱者、附件、鏈接到其他工作項，也可以附加屏幕截圖。
可以使用"查找"對話框，搜索包括摘要（Summary），描述（Description）和討論（Discussion）部分的內容。
在編輯器的工具欄中，可以使用'尋找潛在的重復工作項'（Find Potential Duplicates），發現可能重復定義的工作項。
6 總結
Rational Team Concert 是一個建立在可伸縮和可擴展平臺上的團隊協作開發工具，整合了軟件開發項目生命周期的所有任務，包括計劃、迭代、流程定義、變更管理、缺陷跟蹤、源代碼控制和源代碼管理、產品構建自動化，和各種各樣的分析報告等。Rational Team Concert 有力地支持了一些 Agile 敏捷開發方法，利用 Rational Team Concert 進行 Scrum 敏捷開發，能夠開發出高質量的產品和項目，能夠進行高效率的協同工作，持續的集成和自動化構建交付物。
@import url(http://www.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);