Rational Team Concert Express (RTCE) 入門簡介
軟件開發已經從單純追求個人效率進展到追求團隊效率的時代。默契的團隊協作和協調的開發步調是 提高軟件生產效率的關鍵。IBM Rational 推出的 Jazz 技術是一個創新的團隊協作平台，它將成為下一 代軟件開發平台的基本框架。Rational Team Concert Express (RTCE) 是基於 Jazz 技術的第一個產品 。
開始之前
預備知識
需要您具備基本的軟件開發過程相關知識。
目標
在學完本教程之後，您將能夠使用 RTCE 進行團隊協作開發。
必要條件
本教程適用於項目經理、開發人員、測試人員、構建人員，或對實現高效團隊協作感興趣的人員。
系統要求
您需要安裝配置 RTCE 服務器和客戶端程序，您可以在 Jazz 官方網站 Jazz.net 上下載最新版本。
本教程基於 RTCE Beta 2 編寫，文中的界面截圖與最新版本可能會有少許不同。
團隊效率的問題與 Jazz 的出現
隨著開發工具的不斷升級，軟件開發的個人生產效率已經得到了極大的提高。然而軟件開發的個人英 雄時代已經過去，商業軟件的開發需要高效的開發團隊，怎樣提高團隊生產效率也成為了新的問題。
軟件開發中，即使較小的團隊，也會需要各種不同的角色共同協作來完成一項開發任務。用一個需求 變更做例子。1）業務人員需要把變更的需求告訴開發人員，2）開發人員完成編碼後需要交給測試人員驗 證，3）測試完成後業務人員需要知道變更會被包含在哪個新版本中。從上面的步驟中我們可以發現，不 論變更的大小，團隊都要完成一系列的活動和協作。這期間，不同開發角色之間需要緊密協作，保持一致 的步調才能產生最大的團隊效率。好團隊和普通團隊的差距往往就體現在這裡。
IBM Rational 推出的 Jazz 技術是一個可擴展的團隊協作平台，它能夠整合軟件開發整個生命周期中 的各種活動，幫助團隊協同工作，最大限度地提高團隊效率。Jazz 的名稱來源於 IBM 發現軟件開發在某 些方面和樂隊演奏很相似，既需要娴熟的個人技巧也需要默契的團隊協作。像配合默契的樂隊一樣來享受 協作的樂趣大約是軟件開發團隊的最高境界吧。IBM 已經開發了 jazz.net 社區，關於 Jazz 技術的所有 信息都可以在 jazz.net 上找到。任何感興趣的人都可以注冊成為成員，了解 jazz 技術的最新動態，下 載試用版本。圖 1展示了 Jazz 平台所包含的主要功能，關於各個部件的詳細的資料可以在 jazz.net 找 到，在稍後的實例中您也可以了解它們的基本用法。
圖 1. Jazz 平台體系結構圖
基於 Jazz 的第一個產品：Rational Team Concert Express (RTCE)
Rational Team Concert Express(RTCE) 是基於 Jazz 技術的第一個產品。做為一個完整而緊湊的開 發平台，RTCE 特別適合於敏捷開發團隊，不論是單獨的團隊還是大公司中的一個開發小團隊。除了內建 的 Jazz 核心的協作功能，RTCE 還提供了任務支持 (work item)，版本管理 (version control) 和構建 管理 (build management)。並且，在使用 RTCE 的同時，團隊自然而然地開始采用被反復驗證了的開發 最佳實踐和協作最佳實踐。
RTCE 的客戶端 IDE 是基於 Eclipse 的。對於任何一個已經在試用 Eclipse 的團隊，遷移到 RTCE 是一個非常自然的過程。
RTCE 是基於 Jazz 技術的第一個開發工具，目前也是惟一的一個，所以很多時候我們提到 Jazz 時往 往是指 RTCE。在不久的將來，會有更多的基於 jazz 技術的開發工具出現。弄清楚 Jazz 和 RTCE 是兩 個不同的名詞是有助於我們理解問題的，即使現在我們仍舊習慣混著用。
我們的實例：時鐘項目
在進入繁忙的開發工作前，先來了解一下我們的實例。
我們的客戶 Good Company 需要一個小應用（客戶在開始的時候總是會說“小”）來幫助他們的員工 更好的管理工作時間，我們把這個項目命名為“時鐘”。客戶給出了一個不錯的需求文檔
時鐘項目需求文檔
客戶（ Good Company ）希望員工能夠更好的平衡工作時間和休息時間，最近過多的加班已經讓一些 員工開始抱怨了。 Good Company 需要一個能夠顯示時間的桌面應用。在工作時段，這個程序用綠色來顯 示時間；在下班時段，這個程序用紅色來顯示時間以提醒員工該休息了。員工通過運行程序能夠知道現在 是不是該下班了。
目前 Good Company 的規定工作時間是早上９點到下午６點。
午飯時間雖然屬於非工作時段，但是仍然用綠色顯示。
接下來我們會介紹怎樣在 Jazz 中開發這個項目，每一個章節都會重點介紹 Jazz 的一個功能，把它 們放在一起差不多就是軟件開發的整個過程了。
第一部分：敏捷的規劃和設計
項目經理接到需求後迅速在 Jazz 系統中創建了“時鐘”項目空間和團隊設置，並且錄入了需求。團 隊中資深的開發人員做了簡單的設計後把“時鐘”項目分解成小的任務並且分配到了每個程序員。本部分 將介紹 Jazz 的 project area, team area, planning 以及 work item 功能。
第二部分：編碼
程序員在 Jazz 中編寫代碼，並且提交到 Jazz 版本管理工具中。本部分介紹 Jazz 的版本控制，以 及怎樣把 work item 和 change set 相關聯。
第三部分：構建
Jazz 的構建功能每天自動地做構建應用，運行單元測試，並給出報表。本部分將介紹 Jazz 的構建功 能，以及和構建相關的各種報表。
第四部分：缺陷管理
所有的開發完成後，我們在測試中發現了一些問題。Jazz 的缺陷管理很好地管理了缺陷的發現，解決 ，驗證等流程。本部分將介紹 Jazz 的缺陷管理功能。
一切都完成後，我們把穩定的構建版本發布給了客戶。客戶很滿意！
第一部分 敏捷的規劃和設計
規劃項目時間和組織開發團隊是首要解決的問題。Tony 是我們的項目經理，在開始工作之前，Tony 首先在 RTCE 中創建了 Project Area “時鐘”用來作為接下來所有工作的容器。
什麼 , 還沒有安裝 RTCE？沒關系，您可以先看完本文的實例，得到整體的概念後再去實際嘗試。動 手的時候，您可以在 jazz.net 找到很多有用的文檔，比如安裝介紹之類的。
規劃開發階段
Tony 打算采取敏捷開發過程以應付可能的需求變化，作為經驗豐富的項目經理，他從不相信客戶會一 次說清楚需求。和客戶溝通後，Tony 決定兩周為一次迭代，並承諾在第一個迭代後拿出一個可運行的時 鐘軟件。然後在第二個迭代時根據用戶的反饋，來完善軟件功能。Tony 在“時鐘”Project Area 中創建 了如下圖所示的開發流程和迭代定義
圖 2. 項目開發結合
規劃團隊
現在該來看看我們的開發團隊了。還不錯，一個資深的高級程序員 Joe 和兩個程序員 Max 和 Goshen 。因為人手不夠，Tony 需要兼做測試工作。Tony 在 Jazz 中創建了 Team Area 來描述這個小小的團隊 ，看起來就像下圖。
圖 3. 團隊組成
您一定注意到了名字前面的小圖標，它們看起來是不是有點像即時聊天工具中的圖標？對了，Joe 是 黃色的，表示他不在計算機邊上。Tony 和 Max 是灰色的，他們不在線。Goshen 是綠色的，好樣的，他 正在工作呢。用鼠標右鍵點擊他們的名字就可以即時聊天。
事實上，你在 Jazz 中任何時候看到團隊成員的名字，它們幾乎都是用這種方式顯示的，不論是在一 項任務的定義中還是在項目計劃裡，還是在一個報表裡。任何一個名字都是可以直接顯示狀態和直接開始 即時聊天的。溝通無極限是嗎？
項目計劃和分配任務
開發階段和團隊都確定後，我們要開始分配任務了。大家討論後一致認為，一份詳細的項目計劃有助 於項目的成功。Jazz 中的項目計劃不是冗長難懂的文檔，它由一些簡短的描述，以及一系列相關的任務 構成，Jazz 會跟蹤任務進度，項目計劃的執行情況因此一目了然。這是一個動態的，隨時變化的項目計 劃。我們稱這個功能為 Agile Planning。
Tony 創建了我們的項目計劃，根據對用戶需求的理解，Tony 寫下了他認為我們需要完成的工作（似 乎就是直接把需求搬了過來，哦，他還加了一句振奮人心的口號！）。至於具體該細化成多少開發任務， 誰該做什麼，則要由開發團隊來定了。目前的計劃看起來差不多是這樣的。
圖 4. 第一階段開發計劃
Joe 認為我們可以把工作細化成三個任務，編寫界面代碼，編寫業務邏輯代碼，編寫編譯腳本。他在 計劃中加上這些任務的描述，並且生成了三個相應的 Jazz work item，只要選中項目計劃中的文本，右 鍵點擊就可以直接生成 work item。並且，這些 work item 的完成狀態會實時顯示在項目計劃中（比如 ，完成的工作會被打勾並用刪除線標記）。現在我們的計劃看起來是這樣的。207，208 和 209 是 work item 編號，每個 work item 都有唯一的編號。
圖 5. 帶有 work item 的項目計劃
在 Planed Item 標簽頁中可以看到這個計劃中所有的 work item，可以用不同的方式來顯示，Tony 最喜歡按狀態排列 work item。這樣他就知道所有工作的完成情況。Joe 通常喜歡按人頭排，這樣他可以 看到哪個開發人員有麻煩了需要幫助。
圖 6. Planed Item 標簽頁
來看看一個具體的 work item 是怎麼樣的吧，work item 是 Jazz 實現團隊協作的重要元素。Work item 有不同的類型，可以是一個需求變更，一項開發任務，一個需要解決的缺陷或者是任何一種自定義 的工作。開發人員的信息交流和協作就圍繞 work item 展開。
Task 209 是 Joe 剛剛定義的一項開發任務，它是一個任務類型的 work item，用來記錄編寫編譯腳 本這項工作。Joe 在右上角的文本框中輸入了他對這項工作的描述，並且指派了 Max 來負責這項工作。 Task 209 被創建後 Max 會收到郵件通知。
圖 7. Work item
新的工作來了。開始新任務前浏覽一下關於這個任務的所有討論是 Max 的好習慣。哦等等，看右下角 的討論區中有什麼？Joe 寫了一條信息
1.Joe, 2008-3-27, 下午 1:52
Tony,
寫編譯腳本會浪費我們兩天時間，但是如果項目會持續兩周以上的話我認腳本帶來的好處是值得我們 花費兩天時間的。你覺得怎麼樣？
Max, 請等 Tony 確認後再開始編寫腳本。先忙別的吧！
原來如此，我們需要先和項目經理溝通一下，畢竟編譯腳本不是我們用戶需要的，看看我們的投入是 不是值得吧。
在 Joe 添加這條信息時，Tony 和 Max 都會收到郵件通知。簡單的協作，不是嗎？跟打電話比起來， 至少不用擔心 Tony 會忘掉，也不必再費心把商量的結果轉告給 Max。所有對這個 work item 感興趣的 人都可以看到我們圍繞這項工作有過哪些討論。跟開會比呢？哦，程序員都討厭開會。
第二部分開工啦！開始編碼
有了“Jazz”這股東風，可就不再是萬事開頭難了！快速敏捷的創建好項目規劃和團隊規劃，將“繁 重”的工作任務分解並按計劃分配到各項目成員，項目順利進入到編碼工作階段。
查看工作任務
和傳統的 Eclipse 平台一樣，RTCE 提供了同樣強大的 Java 開發工具，其功能乃至使用習慣完全傳 承自 Eclipse 開放平台，對於 Java 程序開發人員學習成本非常低。並且因為有 Jazz 的團隊支持、協 同工作、流程管控，工件追蹤等核心特性的支持，為開發人員提供了更多更方便的流程控制管理，團隊協 作等手段。下面就跟隨 Goshen 一起開始在 Jazz 上的編碼工作，看看可以體驗哪些新特性。
早上到公司 Goshen 的第一件事情就是收郵件，查看相關的工作任務安排：
圖 8. 關於工作項的郵件
躍入眼簾的就是我們的第一個任務——“創建時鐘顯示窗口”。
圖 9. 查看工作任務
好吧，看來今天的工作很輕松，想著可以很快搞定，Goshen 拿起咖啡杯到茶水間調制了一杯香濃的咖 啡回到座位准備開始今天的工作。這時，屏幕上彈出了一個即時聊天工具對話框：
圖 10. 即時通訊
原來是 Joe 想知道任務執行狀況，這個家伙還真是心急啊。為了 Joe 不再擔心，也讓團隊其他成員 知道這項工作已經開始了，需要改變一下這項工作任務的狀態。點擊“task 207”鏈接，並在彈出菜單中 點“Start working...”：
圖 11. 更改工作任務狀態
這樣任務狀態變成了“In Process...”，哈哈，這下大家都知道我在工作啦。
圖 12. 任務狀態為 In process
Jazz 上的第一段代碼
和在 Eclipse 上一樣，下面我們需要切換到 Java 視圖，在 ClockUI 這個 Java 項目中創建一個新 的 Java 類：ClockMain，用來生成時鐘顯示的窗口。可以看到編程的操作方式以及很多的人機界面和 Eclipse 平台完全一樣：
圖 13. RTCE 中的 Java 視圖
完成時鐘顯示窗口的編碼工作，需要和時鐘顯示控制程序進行聯調了，所以我們需要把代碼提交到團 隊工作流。
右鍵單擊 ClockMain.java，在彈出菜單中展開 Team 菜單並點擊 Chek-in，這時 Pending Changes 窗口會打開：
圖 14. Pending changes 視圖
我們可以看到我們對 ClockMain 的改動已經被自動關聯到任務“創建時鐘顯示窗口”上，相關的代碼 修改都被放到了對應的 Change set 中。現在右鍵點擊該 Change set，在彈出菜單中點擊 Deliver，我 們的代碼就最終被提交到團隊工作流中了。
因為 RTCE 將代碼改動和工作任務作了綁定，現在我們就可以在當前的工作任務中查看剛才我們的那 些改動被關聯了。打開工作任務，如下圖所示，我們可以有個看到一個 Change-set 已經被關聯到了這項 任務上：
圖 15. 工作項與 Change-set 相關聯
點擊 Change-sets(1) 這個鏈接，會打開如下圖所示的詳細說明，顯示具體有哪些修改和該項任務有 關：
圖 16. 工作項中所關聯的 Change-sets
結束第一個編碼工作
大功告成！時鐘程序窗口顯示的任務已經完成，讓我們回到“Work Item”視圖，右鍵點擊該任務，並 把狀態設置成 Resolve，這樣其他成員就知道已經可以從工作流中獲取這個功能了。
圖 17. 將工作項的狀態標記為 Resolve
看看時間還早，Goshen 起身再去調制一杯咖啡小小慶祝一下，這時候相關工作項的工作人員還有項目 經理可能都已經收到一封 Jazz Server 自動發出的郵件，告訴他們“創建時間顯示窗口”的任務已經完 成了。當然，下一個給 Goshen 的工作任務也可能很快就要送到 Goshen 的郵箱了，誰知道呢？“哦，對 了”，Goshen 想起來剛才 Joe 非常心急，還是趕緊在即時聊天工具上告訴他這個好消息吧。
第三部分 構建項目
項目進行到第二周時，大家覺得可以開始做 daily build。Max 也已經完成了 ANT 編譯腳本的開發。 我們終於有機會體驗 Jazz 的 build 機制。在 Jazz 中，build 不在是一個孤立的事件，他和團隊的開 發工作是緊密結合的。
Build 過程中可以自動運行單元測試從而確保質量。你可以通過察看 build report 裡單元測試的通 過率來大致了解到當前 build 的穩定情況。甚至可以包括測試覆蓋率如果你有興趣看。
Build 與 work item，change-set 是緊密關聯的，這有效地提高了任務和代碼改動的可追蹤性。每個 build report 裡都會顯示包括在該 build 中的 work item 以及與此相關的 change-set。你甚至可以直 接比較兩個 build 看它們之間的差異。這對於傳統的開發環境來說是一個需要做許多額外工作才能達到 的效果。
在 Jazz 中配置 build 需要一些步驟，一旦配置好，他就可以定期運行，或者根據開發人員的要求隨 時運行。如果你對 Jazz build 的機制有興趣的話，下圖可以大致解釋這個問題。關於配置 build 的細 節可以在 jazz.net 上找到資料。
圖 18. 角色與構建的關系
運行構建
下圖是配置好的 Build，直接選“Request Build”就可以運行了。
圖 19. 運行項目構建
查看構建結果
在 Builds 視圖中，可以查看所有 build 的記錄，如 圖 20 所示，在 build 列表中有些是成功的 ，有些是失敗的
圖 20. 查看構建狀態
打開一個 build 結果可以察看詳細信息。你能看到構建的狀態，有沒有編譯錯誤，單元測試結果，與 這個 build 相關聯的 work item，build 的下載次數等信息。
圖 21. 構建的詳細信息
圖 22. 代碼編結果
圖 23. 單元測結果
圖 24. 查看構建記錄
下載構建
從 build 結果中可以直接下載最終的軟件產品。讓我們來下載運行一下我們的時鐘吧。看起來很不錯 是吧，紅色的，它在提醒我們該下班了。
圖 25. 下載構建
圖 26. 運行時鐘應用
第四部分第一個缺陷（defect）
在自動的 daily build 開始運行後，Tony 就能不時地下載軟件做些簡單的測試。很快，他發現了一 個問題。那是個周末的白天，但是時鐘還在顯示綠色，顯然我們的時鐘把周末也算作工作日了，這是不能 接受的。Tony 在 Jazz 中提交了一個缺陷，也就是一個 defect 類型的 work item。
圖 27. 創建 defect 工作項
應該把現場的截圖也帶上，讓我們的程序員看看他們都做了什麼。RTCE 已經為我們想到了這點，在 work item 的 Links 標簽中有添加附件和屏幕截圖的功能。
圖 28. 用 RTCE 來截屏
這看來像是業務邏輯的代碼有問題，那就把這個 defect 分配給 Joe 吧。他周一有事干了！
圍繞 defect，開發人員，測試人員需要協作來共同解決，我們期望這個 defect work item 會被 Joe 輕松解決，並且包含在下周一的 build 中。Tony 只需再次下載並驗證，然後就可以關閉這個 defect work item 了。
第一個 release
第一個迭代就要結束了，今天的 build 看來比較穩定，發現的問題也都解決了，明天會用它來給客戶 做演示。我們都知道客戶肯定會提點什麼新東西出來，不過沒有什麼可怕的。Jazz 帶來的默契團隊協作 和良好開發流程讓我們有充分的信心來擁抱改變。
結束語
通過上面的實例我們可以看到，Jazz 不僅在軟件開發流程的各個階段為我們提供良好的功能支持，更 重要的是提供了一個一致的團對協作平台，極大地提高了團隊協作的效率，特別是在這個 Agile 的世界 中，Jazz 能使我們變得更加 Agile。
