RTC 簡介
IBM Rational Team Concert（RTC）作為軟件協同開發工具，被逐漸應用在大型項目的生 產過程中，維系著規模龐大的項目組織團隊，有條不紊地管理每一項開發任務，從而為創造高質量的軟件產品 打下堅實基礎。
RTC 提供了貫穿整個開發過程的集成環境，包括：需求定義、迭代計劃、源碼控制、 自動構建、缺陷跟蹤、變更管理以及統計報表等功能。本文將通過三個層次，自下而上地詳細闡述如何使用 RTC 跟蹤和管理項目的開發任務。首先，介紹 scrum 方法中不同種類工作項的功能和特征，幫助項目中各個 角色的成員建立與之對應的工作項類型。然後，介紹如何通過檢索和查詢，從海量的工作項中快速准確地定位 特定的工作項，獲取個人和團隊的工作項內容。最後，介紹 RTC 中報表和儀表板的使用，統計匯總項目中的 工作項，展現項目的整體狀態，以及預測未來的進展趨勢。
開發活動的基石——工作項
工作項 （Work items）是 RTC 中進行項目開發和管理的基本單位，用於記錄開發任務，關聯開發成果，管理開發進 度，實現協同工作。為了滿足不同的軟件項目開發過程，RTC 中內置了多種軟件開發過程模板，每種模板的工 作項設置也不盡相同。本節以敏捷開發中的 Scrum 開發管理方法為例，介紹 RTC 中常用的工作項內容和結構 特征。
Scrum 是一種靈活的軟件項目管理方法，它通過一系列的迭代，增量實現軟件產品的功能。為 了有效管理迭代中的開發任務，RTC Scrum 方法模板中常用的預置工作項包括：史詩（Epic），用戶故事 （Story）、任務（Task）、缺陷（Defect）。它們的關系通常可以用圖 1 表示。
圖 1. Scrum 方法 模板工作項關系圖
Epic：通常指的是項目整體目標。 這類需求由決策管理層提出，作為軟件項目的總體戰略規劃。其描述比較簡潔，僅從高層次指定項目的方向， 並未闡明如何實現及具體要求。例如，圖 2 舉例說明如何用 Epic 表示一個項目的整體要求。
圖 2. 目中的 Epic 實例
在圖 2 中，Epic 的摘要為"客戶需要使用辦公自動化系統（OA）"。並在描述欄裡貼出相關文 檔的鏈接地址。Epic 的主要服務對象為項目干系人（stakeholder），因此並不會直接包含需求的細節信息， 而是將其作為子任務，關聯在下一級參數中（Children）。項目干系人可以借助此工作項的狀態和進度顯示， 了解項目的總體工作量以及進展程度。
Story：為了實現 Epic 中的總體目標，需要把整個需求進一步 細化為可以實現的一系列具體需求。業務分析師（Business Analysis）將這些可以實現和測試的需求記錄在 用戶故事（Story）中。根據 Scrum 開發方法要求，每個用戶故事應當保證在一次迭代（Sprint）中完成，以 便使每個迭代開發的成果可以向客戶演示。
圖 3. 用戶故事實例
圖 3 為實現 Epic 的一個用戶故事實例，名為"實現系統中共享文檔的功能"。故事點數 （Story Point）用於度量其規模和復雜程度，由團隊成員共同評估得出，表示不同用戶故事之間相對工作量 的比較。計劃（Planned For）指定用戶故事將要在哪一次迭代開發中實現。接受規則（Acceptance）則約定 該用戶故事開發工作完成之後的驗收標准。業務分析師在開發任務結束之後根據接受規則驗證開發成果，並將 這個成果在迭代完成後演示給最終客戶。
Task：具體的業務需求確定之後，接下來將由開發人員編程 實現。他們把 Story 中的要求進一步細分為多個功能模塊，並創建任務（Tasks）跟蹤管理這些模塊的代碼開 發工作。Task 的創建標志著軟件開發過程進入代碼實現階段。
圖 4. 任務實例
圖 4 為實現 Story 需求的一個開發任務實例，用於記錄開發文檔文件的存儲模塊。開發任務中使用所有 者（Owner）表示分配的開發人員，使用估計時間、修正時間和剩余時間管理任務的工作量和進度狀況。使用 變更集（Change Sets）記錄每次提交的源代碼文件，以及構建包含（Included in Builds）統計被納入構建 活動的次數。細節內容欄可以靈活地記錄技術概要和相關鏈接等信息。鏈接（Links）標簽模塊列出了所有與 任務相關的鏈接，如父任務、子任務、附件地址、文檔鏈接等等。批准（Approvals）標簽模塊則用於跟蹤代 碼的評審過程及結果。
Defect：為了保證軟件產品的質量，測試環節必不可少。缺陷（Defect）用來 記錄測試過程中發現的問題，以及對問題的修改和驗證。由測試人員創建缺陷工作項，記錄問題描述，並分配 給開發人員。開發人員研究問題根源，設置在工作項中（Root Cause），進行修復工作。最後，通知測試組對 此缺陷進行回歸測試，並在測試通過後將其關閉。
圖 5. 缺陷工作項實例
圖 5 為缺陷工作項實例。由測試人員在發現問題之後創建名為"文檔審查頁面的左導航未被翻譯為日 文"的缺陷工作項。開發人員認領此工作項，開始研究其導致根源，設置在工作項中（Root Cause）。然 後進行缺陷的修復開發工作，並以此工作項作為提交代碼和參與構建的依托。其後，通過改變此工作項的狀態 ，由 RTC 自動通知相關測試人員進行測試驗證，從而將整個缺陷工作流程串聯起來。
上述四種工作項 是 Scrum 開發方法中最基本的預置類型。它們的功能、特征以及適用角色可以通過表 1 進行對比。
為了滿足不同種類項目和團隊類型的需要，RTC 同時提供了自定義工作項的能力，以便進行個性化 定制，從而更貼切地支持項目開發工作。圖 6 為自定義類型工作項舉例。
圖 6. 提問工作項實例
圖 6 為自定義類型工作項提問（Question）實例。當項目組成員分布在異地或者不同時區，溝通工作尤其 是書面溝通必不可少，對整個項目組的運轉效率有著深刻的影響。為了提高項目組成員之間的溝通效率，實現 溝通內容管理，作者所在項目團隊創造並且定義了提問類型的工作項。其使用流程為：提問者創建工作項，填 寫問題摘要和詳細信息，將解答人設置為此工作項的所有者，並可附加優先級（Priority）和截止日期（Due Date）。解答人即可回復評論（Comment）或參與討論（Discussion）。當問題解決後，工作項的狀態設置為 關閉（Close）。在問題的提出和討論過程中，每次更新均由 RTC 自動實時地發郵件通知相關人員。項目組成 員也可以根據 RTC 提供的查詢功能，快速過濾出需要作答的問題，方便高效。有關查詢功能的細節將在下一 節具體介紹。
本節詳細介紹了 RTC 為 Scrum 開發方法預置的四種工作項：史詩（Epic），用戶故事 （Story）、任務（Task）、缺陷（Defect），通過具體實例，講解其功能點設置和使用方法。並對它們進行 總結比較以便讀者更好地理解。同時，介紹對 RTC 中自定義類型工作項的使用，舉例說明如何根據項目特點 定制團隊需要的工作項類型。所有這些基本的工作項組成了 RTC 開發任務管理的基礎。
快速找到任務 ——檢索與查詢
隨著項目的開展和團隊的擴張，工作項的數目迅速膨脹。如何方便快捷地從海量工作 項中獲取與自己和團隊相關的工作項，成為管理項目任務的挑戰。本節中，將詳細介紹 RTC 提供的兩種迅速 獲取工作項的方式：檢索與查詢。
在檢索功能中，用戶可以通過關鍵字進行搜索，找到並返回一個或 多個結果。例如，在圖 7 的搜索框中填入任務編號，可以輕而易舉地查到並打開工作項內容。也可以使用關 鍵字匹配查找，圖 8 為查找關鍵字"document"而得到的相關工作項結果列表。
圖 7. 快捷 檢索搜索框
圖 8. 關鍵字搜索結果列 表
檢索功能輸入框位於用戶操作的主界面，優點是便於用戶方便快捷地隨需查找工作項。其不足之處有兩 點：第一，查找方式過於簡單，僅僅提供基於單一條件的搜索；第二，檢索條件無法保存，每次查找需要重新 輸入，無法重復使用。為了解決這個難題，RTC 提供了另外一種更加強大的查詢方式。
查詢功能中， 用戶可以自行組合篩選條件，並將此查詢定義保存，便於日後重復使用。根據執行權限范圍不同，查詢定義通 常劃分為個人查詢和共享查詢兩類。前者僅允許當前用戶使用，後者可在項目組中共享使用。
圖 9 為 設置查詢條件的實例。根據需求，查找項目組成員名下正在進行中的開發工作項，以及一天之內結束的工作項 。此需求常常用於 Scrum 開發的每日站立會議中。
圖 9. 設置查詢條件
在圖 9 所示查詢實例中，第一個條件篩選出那些尚未完成的工作項，後兩個條件篩選出一天之內完成的工 作項。通過並操作（OR）將它們連接起來。接下來，還可以進一步定制結果列表的展示。設置包含在展示結果 中的列，以及按照何種屬性進行排序。最終通過執行此查詢，獲得相應結果列表。如圖 10、11 所示。
圖 10. 設置結果列表的展示
圖 11. 結果列表
查詢定義創建完成之後，可以將其 放在項目組成員共享的目錄下，為相同項目組內所有成員所用。如圖 12 所示。
圖 12. 共享查詢目錄
本節主要介紹如何使用 RTC 提供的檢索和查詢功能，方便快捷地獲取用戶所需的工作項。檢索功能位於 用戶操作主界面，便於隨需查找。查詢功能可以保存篩選定制條件，便於用戶和項目組共享執行使用。它們為 有效定位和管理開發任務提供了保證。然而，檢索和查詢功能只幫助獲取相關工作項，並未對這些數據進行分 析和處理。下一節將介紹 RTC 如何使用報表和儀表板功能，實現工作項數據內容的整理和展現工作。
項目進展晴雨表——報表與儀表板
RTC 中內置報表功能，對工作項的數據進行分析、統計和展示。報 表將查詢得到的相關工作項列表作為輸入，經過分析處理，按照用戶要求，以特定的方式展示出來，如數據表 格、直方圖、趨勢圖等。
儀表板用來向用戶呈現多個數據報表。目前，RTC 包含 Eclipse 客戶端和 Web 客戶端兩種，僅 Web 客戶端支持儀表板的功能。按照創建者權限不同，儀表板可分為個人儀表板和項目 儀表板。個人儀表板可由用戶自行創建並配置使用。項目儀表板被用於展示項目的狀態信息，只有少數有權限 的成員可以編輯，其他組員僅能浏覽。
圖 13. 項目儀表板的實例
圖 13 為項目組儀表板的實例圖。 儀表板又分為多個標簽檔（label），用來展現項目統計結果的不同方面。在每個標簽檔中，分布了形形色色 的報表項，展示項目狀態的統計數據。這些報表項有：展示項目中工作進展情況的趨勢圖，結束工作項標簽（ Tags）類型的數據表，匯總各類查詢定義的列表集合，以及工作量進展情況的結果視圖等等。
用戶可 以根據自身要求，在儀表板中加入新的報表項，對其進行配置，得到期望結果。首先，選取合適的報表項類型 。RTC 中內置了多種報表項類型，用戶只需將合適的類型添加到儀表板中，即可完成報表的創建工作。圖 14 為 RTC 中內置的候選報表類型。
圖 14. RTC 報表類型的選取
接下來，通過關聯特定的查詢定義 ，為新創建的報表指定數據來源。並且，選擇期望的展示方式和分組依據。如圖 15 所示。
圖 15. 報 表的參數配置
圖 15 所示的實例中，對新建的報 表項進行參數配置。選擇指定的查詢定義作為數據輸入的來源，配置"標簽（Tags）"作為結果的分 組依據，對各個分組進行內容篩選和重新命名，最後指定表格作為報表項結果的展示方式。
為了統一 儀表板中各個報表項的顯示風格，使儀表板更加清晰，可以對報表的標題和外觀顏色進行個性化定制，如圖 16 所示。
圖 16. 報表的外觀配置
保存儀表板配置，即可完成新報表 項的創建和配置工作。隨著儀表板的刷新，報表項將開始獲取數據，並將處理結果展現出來，如圖 17 所示。
圖 17. 報表的展示結果
本節介紹了 RTC 中報表和儀表板的 特征及使用步驟。報表對項目任務數據進行分析、歸納和總結，以不同圖形方式展示給用戶，便於用戶及時了 解項目的進展情況以及未來發展趨勢。儀表板則提供鑲嵌多個報表的用戶操作平台。報表和儀表板的使用，使 得項目團隊成員有機會配置和獲取開發任務的統計結果，從而對所參與的項目有了更好地整體了解。
結束語
RTC 為大型軟件項目和開發團隊的管理提供強有力的支持。本文從工作項、檢索查詢，以及統 計報表三個層次，介紹了如何在 RTC 中自下而上地進行開發任務的跟蹤和管理。工作項是任務管理的基礎， 查詢為聯系工作項的紐帶，報表則進行更高層次的分析處理。使讀者一步一步地理解 RTC 項目表示和任務管 理的精髓。當然，不同的項目，不同的團隊，在項目任務管理中的需求也不盡相同。這就需要讀者在理解掌握 RTC 的基礎上，不斷進行定制改進，最終打造適合自己特色的任務管理體系和風格。
