概述
在您開始之前
在您開始為 Scrum 開發使用 IBM® Rational® Team Concert™ 之前，您要確保對 Scrum 的基礎知識有了一個通透的理解，並理解諸如 Product Backlog， Story Points 等等之類的術語。在本系列第一部分“創建項目、團隊和計劃”的開始部分，有對 Scrum 項目管理的簡單介紹。
關於本系列
IBM® Rational Team Concert™ 協作功能的廣度，使得快速理解它並且使用起來得心應手，變成一項十分具體挑戰性的工作。本系列文章可以幫助 Rational Team Concert 初學者，對如何使用它來提高團隊功能提供了一個機會。
第一部分介紹了關於“創建項目、團隊和計劃”的內容，第二部分進一步介紹了“規劃和管理 Sprint”方面的內容。
關於本教程
在大多數的時候，scrum 團隊一直使用 Rational Team Concert 以進行規劃並追蹤他們的工作進度。它提供了一些 UI 選項。例如，開發員可能更喜歡客戶端一些，例如 Eclipse 或者 Microsoft® Visual Studio。許多其他的涉眾不想在他們的系統上安裝別的軟件，所以他們更喜歡使用網絡版一些。有了 V2 版本，IBM® Rational® Jazz™ 及 Rational Team Concert 團隊向他們的 Web 界面交付了動態的改進，這樣它就提供了日常工作所需要的所有特性了。Eclipse 界面在本系列第一部分“創建項目、團隊和計劃”中進行了描述。
目標
本專題提供了怎樣只使用 Rational Team Concert Web 界面，而不是 Eclipse 版本來創建和管理 Scrum 項目，提供了一個實時的指南。
前提條件
為了完全執行本專題的所有步驟，您需要一個 Jazz 服務器，1.0.0.2 版本，安裝有 Rational Team Concert 功能。對於一些步驟，您還需要對服務器的管理員權限。如果您想要更多的細節信息，那麼您可以查看 jazz.net。
系統需求
本文使用的是從 jazz.net 上下載的 Rational Team Concert 2.0.0.2 標准版，並使用標准配置安裝在一個已經安裝有 Apache Tomcat 程序服務器與 Apache Derby 數據庫的本地系統之上。您必須擁有一個服務器許可協議，並安裝有至少七個開發員許可協議，還需要完全的管理員權限，去執行本文所描述的所有操作。您的 Jazz 服務器還必須安裝在後綴層次 2 上（例如，1.0.0.2），而且您必須使用 Rational Team Concert 2.0.0.2 提供的 Scrum 模板。如果您使用的是 Rational Team Concert 的早期版本的話，那麼有些事可能不太一樣或者不能得到。
為了遵循這篇指南進行操作，您可能使用的是 Rational Team Concert 的 Express-C 下載版，它包含了您需要的所有事情，包括 10 個免費的開發員許可證協議，已經完成服務器和客戶端安裝的容易遵循的指南。jazz.net 上的 wiki.net 顯示了一個協調性矩陣，它演示了什麼客戶端軟件可以與特定的 IBM® Rational® Jazz™ Team Server 版本一起使用。
簡介
在 本系列 的早期文章中介紹如何使用基於 Eclipse 的客戶端界面，來與 Rational Team Concert 一起協調工作，但是這篇文章關注的是 Web 界面。對於那些不想為工具安裝客戶端的項目涉眾，以及那些遠離自己的辦公地點，只能通過浏覽器與網絡連接的員工來說，這是十分有用的。
有了 Rational Team Concert 2.0 版本，Web 界面得到了改進，所以現在它幾乎為敏捷開發提供了 Rational Team Concert 的全部功能。在以前，許多功能只能通過使用客戶端界面來得到。有了 2.0 版本之後，就只有工作項類別與一些項目配置必須使用客戶端界面來定義了。
注意：
貫穿全文，我們都將 Web 界面（使用浏覽器來訪問）與客戶端界面（Eclipse 或者 Microsoft Visual Studio）區別對待。
本文向您展示了怎樣創建工具，以及怎樣使用 Rational Team Concert 2.0.0.2 Web 界面來創建一個初始的項目。
本文基於 Mike Cohn 在他名為 敏捷估計與規劃 一書中所討論的用例研究。它描述了一個小型團隊，正在開發一個名為“Havannah”的新型電腦游戲。本文展示了怎樣創建 Rational Team Concert 以反映這個團隊及項目，以及團隊怎樣創建規劃並向這些規劃添加工作項。
創建 Rational Team Concert 存儲庫與用戶
在您執行本文所描述的步驟之前，您需要安裝一個 Jazz 團隊服務器（擁有 Rational Team Concert 功能）並且能夠使用（查看系統需求）。本文假設您已經安裝了自己的 Jazz 服務器並從頭開始。如果情況不是這樣的，那麼您實際經歷的，可能與這裡所描述的有所出入。
登錄到 Jazz 服務器之上
確認您的 Jazz 服務器已經啟動了。
將您的浏覽器指向 Jazz 服務器的 URI。
當您使用本地系統之上 Jazz 服務器的安裝版時，例如，URI 可能會是 https://localhost:9443/jazz/。
輸入用戶 ID 與相應的密碼。
新安裝 Jazz 服務器的初始用戶 ID 是 ADMIN，密碼是 ADMIN （兩個都是用例敏感的），除非您凍結了 ADMIN 並且在創建過程中激活了一個不同的管理員用戶 ID。
注意：
注意 URI 的“https”中有一個小寫的字母“ s”，這意味著 Jazz 使用一個安全連接。根據浏覽器的情況，如果您忘了加入小寫字母 s ，那麼就會發生一些奇怪的事情。同樣，注意安全許可證是自己分配的，而且假如您使用的是火狐浏覽器，那麼您就必須接受該許可證。
圖 1 中所示的界面看起來可能有微小的差別，這取決於您所使用的浏覽器 （查看 jazz.net 以得到支持浏覽器的列表 ）。
圖 1. 登錄到 Jazz 服務器上
當您首次登錄到 Jazz 服務器上時，您可以進入到服務器管理員區域（參見圖 2）。在那裡，您可能需要執行一些許可協議活動，並添加一個服務器許可協議以及客戶端活動協議，並完成其他的管理性任務。這些任務並不是本專題的一部分（盡管在軟件文獻中對其有詳細的描述 ）。
圖 2. 首個界面
添加或者導入用戶
怎樣從 LDAP 目錄中導入用戶數據
用戶還可以從一個已存在的用戶存儲庫中導入（例如您的集團 LDAP 服務器）。如果您想要得到怎樣將團隊服務器連接至 LDAP 目錄的更多信息，那麼您可以按照 LDAP Configuration for Newbies 進行操作。
接下來的操作是在 Rational Team Concert 中創建用戶。用戶數據存儲在 Jazz 存儲庫之中；因此，它們可以參與到不止一個項目區域中，並且可以使用服務器上基於 Jazz 的工具。如果您使用外部性用戶存儲庫來配置 Jazz （例如您的 LDAP 目錄），那麼您可以導入用戶，而不用創建它們，正如邊欄中所解釋的那樣。但是，這裡，讓我們假設您使用默認的 Tomcat 程序服務器，而且您需要在該新存儲庫中創建用戶。
為了創建一個新用戶，您可以選擇窗口頂部的 User Management 選項。
圖 3. 創建一個新用戶
為了添加第一個用戶，您可以點擊 Create User 按鈕。
為第一個用戶輸入用戶信息。
因為現在我們學習的是 Mike Cohn 的范例，所以 Sasha 就是第一個用戶。
您可以選擇，如果有的話您可以為他添加一個照片。
電子郵件地址是必須填寫的信息，因為 Jazz 可以發送團隊許多活動的電子郵件通知。對於 Sasha，輸入 [email protected]。
用戶的初始密碼自動設置為與用戶 ID 相同，正如界面頂部所示的那樣（參見圖 4）。
為用戶選擇適當類型的許可證協議。
對於創建或者部署進程模板的用戶需要 開發員 許可協議，創建項目區域或者規劃，並創建或者本級附屬的頁面。對於那些將要編寫代碼並運行構築的團隊成員來說，也需要開發員許可協議。
Build 與 IBM® Rational® ClearCase® Connector 許可協議一般會分配給管理性的用戶。
參與者 許可協議適用於那些最多需要訪問存儲庫的所有用戶。有了參與者許可協議，用戶就可以創建工作項了。
點擊 Save。
圖 4. 指定用戶細節
提示：
為了使用本文簡化工作，Sasha 也被分配給了 Jazz Admins 組。這就允許他為所有的用戶編輯環境。但是，一般來說，用戶沒有 Jazz Admin 權限。
注意：
用戶需要輸入他們的日程安排缺席情況，並配置他們的工作環境（查看編輯器窗口上面），這樣他們花在項目上的時間可以得到適當的計算。稍後我們將會展示這個范例。
對於本例中所用到的 Havannah 項目，需用按照與 Sasha 相同的方式添加更多的用戶。
創建將會組成 Havannah 團隊的其他用戶，也就是叫做 Allan、Delaney、Frank、Prasad 與 Rose 的用戶。為了達到這個目的，您可以切換回活動用戶的列表，點擊 Create User，並添加相應的用戶信息。
將他們分配給擁有 開發員 許可協議的 JazzUsers group with 開發員 licenses.
圖 5. 用戶列表
您還可以選擇為其他的涉眾創建用戶賬戶，例如 Laura，作為 CFO，或者 Phil，作為 CEO，它不會對項目作出什麼貢獻，但是卻需用訪問 Rational Team Concert ，以查看進度與狀態信息。
注意：
如果這些用戶只需要對 Jazz 進行讀取訪問，而不需要更新工作項或者計劃，那麼您就不需要向他們賦予客戶的許可權限。
在界面的右上角點擊 Log Out 來完成操作（參見圖 6）。
圖 6. 注銷
現在您已經完成了作為默認 ADMIN 用戶的條目。Jazz 安全模型賦予了這些用戶在 Jazz 中基本的管理特權，但是沒有給定項目區域內特定的權限。例如，ADMIN 用戶不能部署項目模板或者在項目區域中創建並保存計劃，因為這是這是 Scrum 管理員或者產品擁有者的工作。
再次登錄，但是是作為 Sasha 登錄，使用他的登錄權限（sasha 以及 sasha，因為默認的密碼與用戶 ID 相同 ）。
圖 7. 再次登錄到 Jazz 服務器上
當您點擊 Log In 時，您就可以作為 Sasha 登錄回去，他就是 Bomb Shelter Studio 的 Scrum 管理員。
創建一個項目區域
接下來的部分就是創建一個項目區域，它會作為所有計劃、工作項，以及與創建項目相關其他事情的容器。
為了創建一個新的項目區域，您可以在窗口的頂部選擇 項目區域管理 。
在活動項目區域的列表（參見圖 8），來點擊 創建項目區域 。
圖 8. 項目區域的空白列表
輸入項目區域名，並且您還可以選擇，輸入一個簡單的描述。
當您首先創建一個項目區域時，您並沒有定義的進程模板。如果是這種情況，您可以點擊 部署預定義的進程模板 （參見圖 9）。將進程模板部署到存儲庫中需要花費一些時間。
圖 9. 部署進程模板
選擇 Scrum 進程模板 因為范例顯示了怎樣使用 Scrum 方法來管理項目。
注意：
有了 Rational Team Concert 2.0.0.2 版本，就引入了一個新的 Scrum 模板。還有一個舊的（丟棄的）Scrum 模板。確認您選中了新的模板。
點擊 Save。
圖 10. 使用 Scrum 模板來創建一個項目
服務器的項目區域初始化可能需要花費數分鐘。當這個過程完成之後，您將會看到類似於圖 11 的界面。
圖 11. Havannah 項目的項目區域
在該窗口的右邊，您可以看到與該項目相關的團隊區域層級結構。因為 Havannah 團隊規模非常小，所以 Rational Team Concert 2.0.0.2 中引入的新特性得到了開發，不需要再創建清晰的團隊區域。
提示：
大型的團隊一般都由若干個團隊及子團隊組成。Jazz 技術支持擁有多個時間段和子團隊的大型團隊。您可以定義對項目合適的盡可能多的團隊及子團隊，來反映團隊的結構。
添加成員並指定他們的角色
在這裡的范例之中，Sasha 創建了項目區域，所以他就成為該區域的初始管理員，並且可以對項目區域作出一些變更了。
圖 12. 初始的管理員
但是，Scrum Process 模板中編輯項目結構的大多數許可證，屬於 Scrum 管理員與產品擁有者。作為管理員，Sasha 可以將這些角色分配給適當的團隊成員。
Havannah 團隊的其他成員現在也可以進行添加了。對於小型團隊，您只需要向項目區域添加項目的所有成員。
點擊“Members”行的右邊的 Add （參見圖 13）。
因為對於本例向存儲庫只添加了少量的用戶，所以您可以輸入一個星號（ *）來顯示所有可用的用戶。
選擇 Allan、Delaney、Frank、Prasad、Rose 與 Sasha，因為他們都會在該項目中工作。
點擊 Add & Close。
圖 13. 向項目區域添加成員
點擊成員列表底部的 Show All 圖標 
以顯示完整的列表。
將鼠標移動到每一個用戶上面。在行的右邊，選擇圖標以設置 Process Roles （兩個小人）。
圖 14. 添加進程角色
為每一個用戶選擇進程角色，並將其添加至選擇角色的列表中。
Frank 是項目的產品擁有者。Sasha 是 Scrum 管理員但只是一個程序員 ，因此，也被作為一個團隊成員添加。其他所有的用戶都是 Havannah 項目的團隊成員。
點擊 Finish。
點擊 Save 以再次保存項目區域。
在保存您所做的更改之後，您就會看到一系列的新團隊成員，並被詢問是否想要向他們發送一封電子郵件的邀請信。如果您配置了電子郵件支持（當您在創建服務器時所做的設置）並且同意了這一點，那麼項目成員將會收到一封歡迎加入的電子 郵件的信息，以及鏈接至項目的地址與信息。
因為這些用戶都是您所虛構的，所以您可以刪除所有的選中號。否則，您可以選擇您想要發送邀請函的用戶（參見圖 15）。
點擊 OK。（該對話框只適用於發送電子郵件邀請函，所以如果您不想要發送，您可以將其安全得取消掉）。
如果您想要發送電子郵件邀請函，那麼您可以看到下一步的對話框，去指定電子郵件的內容（參見圖 15）。
圖 15. 發送團隊邀請函
總結發布的時間線
接下來的一步是規劃項目的時間線，這意味著您要指定發布與沖刺階段的起始與終止時間。當您在創建自己的項目區域時，您可以將日期調制適應自己的需要。在未來選擇一個起始日期是很明智的。
定義時間線與迭代
對於地理分布十分分散的團隊來說，讓迭代從本周日到下周六持續下去，以利用所有可能浪費的時間是一種不錯的選擇。
提示：
您應該得到授權去對項目區域作出更改。創建項目的用戶擁有管理員權限，並且可以作為上節所描述的更改。當您在創建您自己的項目時，您必須確保您是項目區域的管理員，或者要麼是 Scrum 管理員或者產品的擁有者。否則，在您試著保存對時間線的設置時，將會遇到一個拒絕通過的錯誤。
在項目區域窗口中的 Timelines 項上（參見圖 16），您可以看到默認的占位符迭代，當您在創建項目區域時進程模板將會將其創建。
點擊項目區域編輯器上的 Timelines 項。
在 Defined Timelines 下面，展開 Main Development，然後展開 Release 1.0。
對於項目有一個 Main Development 時間線。每一個時間線都可以包含一個活動迭代。Release 1.0 圖標與 Sprint 1 圖標上的小藍色三角形修飾符，意味著它們是當前的版本與迭代。
另外，同時創建的還有 Backlog 版本。它沒有特定的日程安排，並且位於時間線的末端。添加它是為了創建一個日程安排獨立的 Product Backlog ，包含了開始時沒有分配的項目（或者從不會被分配）。
注意：
Havannah 項目只是一個簡單的項目，用於產品的首個發布階段。因此，默認創建的時間線對於當前已經夠用了。如果項目變得過於復雜（例如，如果後續的版本與前面的版本進行協同開發及維護），那麼時間線定義就會變得也過於復雜。
選擇 Release 1.0 並點擊 Edit Properties 按鈕以打開如圖 16 所示的 Edit 窗口。
圖 16. 指定時間線
保持 Iteration Type 為默認值不變。
Identifier 必須是獨一無二的，但是您可以根據自己的需要對其進行更改。
為發布設置起始與截止日期（查看 Note），然後確定“A release is schedule for this iteration”的復選框已經被選中了，並點擊 OK。
與之類似編輯迭代的屬性，以反映沖刺階段的起始與終止時間。
點擊 Save。
找到自動分配給您的任務
當您在創建項目區域時，有些任務會自動創建並分配給您。
為了列出這些任務，通過選擇窗口左上部的 Project Area 來保持 Admin 界面不變。
然後選擇 Havannah 項目。這將會把您帶到項目的操作板處，並更改窗口頂部的菜單欄（對操作板的討論超出了本文的范圍）。
點擊該菜單欄中的 Work Items。
在這裡，運行預定義的“Open assigned to me”查詢。您可以遵循這些任務來定義您的項目區域，完成操作後將其關閉掉。
注意：
因為追蹤工作對於時間是非常敏感的，所以創建項目區域時，Rational Team Concert 所輸入的原始日期，基於您處理該范例的時間。今天或者最近未來的某一天啟動發布或者首次迭代。為最近至少六周設置發布及日期。每一次沖刺都持續兩到四周。在我們的范例之中，我們定義了一個從周一到下周五的為期兩周的沖刺階段，非工作日則不在考慮之列。
提示：
稍後您可以對項目區域做一些更多的更改。為了將其打開，您可以切換至 Project Areas 頁面並選擇頁面最右邊的 Manage Project Areas （圖 17）。或者，如果您擁有管理員的權限（正如 Sasha 一樣），那您您可以點擊菜單右邊的 Admin 來回到 Admin 界面。這將會再次更改菜單欄，並提供一個 Project Area Management 選擇。
圖 17. 管理項目區域的鏈接
這項選擇總是可以得到的，就算用戶沒有管理員權限也是一樣。但是，這樣的用戶不能保存團隊區域。
隨著您對 Rational Team Concert 有了一個大致的了解，您可能就想讓項目區域進一步地適應團隊的進程和需要（例如，在 Reflections 會議討論期間的結果）。項目區域在很大的程度上都是可配置的；但是，這是少數幾個只能在 Eclipse 客戶端界面上執行的任務。
指定團隊成員的到勤率
為了讓團隊的工作負荷計算更加精確，團隊成員需要調整他們的到勤率以及工作日長度。團隊成員在工作之外也許還有其他的事情會分散他們的精力，或者安排的假期使之不能百分百地參與團隊事務。其他人，比如說產品擁有者，不能積極地參與團隊事務。對於地理分布比較分散的團隊來說，當團隊成員添加他們的公共假期以及其他特定的活動安排時，這點是非常有益的。
這些到勤率數據在用戶的頁面上會進行調整。一般來說，用戶可能會希望自己維護這個領域，但是因為它是正確估算團隊工作負荷的非常重要的一部分，所以我們將會在這裡對其進行演示。
為了編輯當前用戶的環境，您可以點擊窗口頂部的用戶名。
圖 18. 編輯一個用戶的配置
選擇 Work Environment 項（圖 19）。
調整時間區域以及區域性設置。
調整工作日與標准的工作時間。
在右邊，將鼠標移動至 Main Development 並點擊 Edit。
調整用戶的到勤率。
圖 19. 為用戶編輯工作環境
一般來說，每一個團隊成員都有責任去調整他們的配置。在這裡的范例中，因為 Sasha 擁有 Jazz Admin 存儲庫許可權，所以他可以為其他的用戶調整配置。
點擊窗口右上部的 Admin。
圖 20. 切換至 Jazz Admin 界面
點擊 User Management。
從活動用戶的列表中，選擇 Frank。
在 Work Environment 項之內，將 Frank 的到勤率調整至 0%，因為他就是產品擁有者，並且不會對工作產品作出什麼貢獻。
點擊窗口左邊的 Active Users 切換回活動用戶的列表（參見圖 21）。
Rose 說她有兩天時間不能上班。一般來說，Rose 將會在 Scheduled Absences 下面輸入自己的情況。但是在本文中，我們安排 Sasha 替她完成此項操作，所以他來點擊加號（+）來添加缺席時間。
圖 21. Rose 的用戶編輯
在對話框中，輸入兩天的假期時間。
點擊 OK。
這就調整了即將到來的迭代期間，Rose 可以出席工作安排的時間數量。
點擊 Save 來保存所做的更改。
為項目創建 Product Backlog
Scrum 方法中最重要的一個工件就是 Product Backlog。因此，項目規劃期間所創建的事例現在會填充到 Product Backlog 之中。在項目區域創建時，已經自動創建了三個計劃：
一個 Product Backlog
Product Backlog 就是目前為止該產品所收集的所有工作項的完整列表。
一個 Release Backlog
Release Backlog 就是為發布而規劃的項目優先級列表。一般來說，應該進入到發布之中的項目會從 Product Backlog 中進行選擇，並移動到 Release Backlog 之中。
兩個 Sprint Backlogs
當創建項目區域時，會為自動定義的每一個沖刺創建一個 Sprint Backlog。Sprint Backlog 包含了為沖刺階段所規劃的項目列表。
有好幾種方法都可以得到與一個項目相關的規劃。
注意：
菜單欄會隨著您在 Rational Team Concert 中的背景不同而改變。盡管 Project Areas 選項一直是可用的，但是它在菜單欄上的位置可能一直是變化的，這取決於您上一個操作。
訪問 Product Backlog 的一種方法是從菜單欄的 Project Areas 開始。另外一種方法是從窗口右上角的 Select a Project Area 下拉菜單中選擇項目區域。
圖 22. 項目區域的列表
選擇 Havannah。
注意：
您將會看到項目的操作板。定制操作板不是本文討論的一部分。
從菜單欄中選擇 Plans 以查看當前規劃的列表（參見圖 23）。
當使用默認的 Scrum Process 模板初始化項目區域時，會自動創建一些規劃。注意到目前為止所有的規劃都是空白的。
圖 23. 項目規劃的列表
注意規劃有不同的代表。對於 Product Backlog，不能追蹤其進度。這是因為 Product Backlog 想要成為所有想法與工作項的容器，不管這些想法和工作項隨著時間是否有可能進入到產品之中。實際成為下一個版本一部分的工作項將會放到 Release Backlog 之中。
因為一個 Release Backlog 一般包含有 epics 和 stories，所進度按照點進行追蹤。最終，對於一個包含有處理中工作的 Sprint Backlog 來說，這些任務一般都是按照小時進行估算，進度是用小時進行追蹤的。
將鼠標移動到 Product Backlog 之上並點擊它的名字。
圖 24. Product Backlog
開始時，一個計劃包含有三個頁面（或者項），您可以使用 wiki 形式以及 Planned Items 頁面與 Charts 頁面的格式來在 Overview 頁面上輸入關於產品的信息。圖表現在可能尚不可用，因為在 Jazz 數據倉庫中尚沒有可用的項目。
查看一個計劃有好幾種方法，叫做 查看模式。例如，對於一個 Release Backlog 計劃，默認條件下，從“View as”下拉菜單中有四種預定義的查看模式。為了從視圖中排除掉特定的項目，您可以使用窗口右邊的 Exclude 圖標。您還可以編輯已存在的查看模式，或者創建您自己可定制的查看模式。為了完成這項工作，您可以使用 Edit 或者 Copy 圖標。但是，您要意識到對於項目的所有用戶所有的更改都是有效的。
圖 25. 查看模式
提示：
假設您還想要在備份規劃中看到任務（它是執行項目），請確保選中了 Always load all Execution Items。對於擁有大量執行項目的非常大的備份，由於性能問題的存在它可能是不受歡迎的。
為了更改規劃的配置，您可以點擊所有計劃中的 Edit 圖標（參見圖 23，如前面所示）。
圖 26. 編輯計劃配置
使用初始實例來填充 Product Backlog
在備份的 Planned Items 項中，開始添加備份工作項。對於 Scrum 項目管理，Product Backlog 中的項目叫做“事例”，如果它們更大，那麼就叫做“巨著”。在 Havannah 范例中，所有的項目都叫做事例，所以您可以使用 事例 來填充您的備份。
點擊計劃右邊的加號（+）來開始添加備份項目。
注意：
您可以使用“點擊這裡以創建一個工作項”鏈接（參見以前的圖 24）來為該規劃創建默認工作項的一個新項目。對於備份規劃，默認的類型一般是事例。
為新項目輸入總結，如圖 27 所示。
圖 27. 在備份中添加項目
點擊窗口右上角的 Save 與 Close 以保存您的工作。
按照產品擁有者的要求來添加所有的項目。
提示：
為了添加已存在項目之上或者之下的工作項，您可以使用 Add Work Item Above 或者 Add Work Item Below 圖標。
在事例添加以後，團隊的下一步就是估計它。使用如圖 28 所示的下拉菜單來輸入 Story Points。
圖 28. 事例備份
注意：
列表視圖中的更改會立即得到應用。不需要清晰的“保存”操作，不像在客戶端界面那樣，需要您去在作出更改之後進行清晰地保存備份。
將工作項填充到備份之中
盡管您可以使用 Web 界面來完成大多數的活動，但是有一些操作還是在 Eclipse 客戶端界面中完成更加方便。盡管本文有意地描述了使用 Web 界面描述所有的活動，一次性添加許多的項目，就像它在發布規劃階段完成。稍後項目進行期間，應該一次性添加一個或者兩個的項目，Web 界面很適合完成這種操作。
然後，產品擁有者就得為他們設置優先級。Priority 屬性擁有 High、 Medium 與 Low 三種屬性。對於估計而言，您可以使用一個下拉菜單來分配優先級（參見圖 29）。
然後您還可以為項目分配優先級。通過拖動項目可以將它們進行排序，從而為項目進行排序。系統成員通過拖拉操作來完成排序工作。如果您拖動一個事例，例如一個中等優先級的事例，到不同的分組，並將其在不同優先級的兩個事例之間進行拖動，那麼 Rational Team Concert 會自動重新分配優先級值以匹配它附近的事例。
圖 29. 為工作項設置優先級
提示：
在 Rational Team Concert V2 的早期版本中，巨著與事例是一個 Product Backlog 唯一的工作項類型。隨著 2.0.0.2 版本中新 Scrum Process 的推出，這種限制也隨之消失。
如果您想要在備份中以一種層級結構來組織和查看項目的話，那麼您必須使用一種視圖模式來在樹形視圖中查看您的工作項。Work Breakdown 模式以樹形模式顯示了工作項，但是您可以據此配置其他任意的模式。查看前面的圖 25，以觀察它是怎麼做到的。
當然，如果我們擁有的只有 Story Summaries，那麼它就不會是 Product Backlog 了。
點擊一個事例以打開它的快速編輯器（在本例中，如圖 30 所示，事例上顯示“As a player, I can play against a weak engine that recognizes forks”）。
在 Description 區域之中，提供了關於事例預期的詳細信息（當然，您可以在開始向規劃添加事例時添加一個描述）。在這裡的情況下，它的引用（想象的）文獻附屬於項目區域。
在 Acceptance Test 區域（圖 30）中，添加團隊與產品擁有者識別的 Criteria of Acceptance ，作為事例成功完成的證據以及達到了涉眾的要求。
圖 30. 一個項目的細節信息
在更改一個事例之後選擇 Save 或者 Save and Close。
在沒有做出更改時為了簡化關閉事例，您可以再次點擊列表項目。點擊列表項目基本上會引起項目編輯器的可視性。
提示：
為了在 Work Items 編輯器中打開一個項目，您可以從快速編輯器視圖中點擊項目成員（例如，上面的事例就是號碼 17）。在 Work Item 編輯器中，您可以訪問工作項的完整內容。例如，項目的創建會自動激發它。假如您不需要這樣做，那麼您可以點擊 Work Item 編輯器中的 Links 項，並從激發者的名單中刪除掉用戶。
圖 31. Work Item 編輯器
規劃發布與沖刺
盡管 Product Backlog 是所有尚未規劃事例的容器，清晰規劃活動的進行，去決定什麼事例會進入到版本或者迭代之中。對於擁有大量涉眾的團隊來說，這一點十分有用；每個人可能都有權利去將事例填充到 Product Backlog 中，而產品擁有者可以決定向版本添加什麼項目。
當您使用新的 Scrum Process 模板去創建一個項目區域時，會為版本自動創建規劃以及前兩個沖刺。您可能會在早期訪問它們，在創建項目區域之後，我們會調整發布的時間線日期。
填充 Release Backlog
在發布規劃期間，項目會從 Product Backlog 進入到發布期間。根據產品擁有者基於產品調查提供的分類信息，有盡可能多的事例可以進入到發布之中，只要它們能夠在安排的時間內完成即可（基於團隊的速度）。發布計劃可以進行輕松的修整，而且項目可以返回至 Product Backlog 之中。反過來，其他的項目也可以基於涉眾的反饋來進入到發布版本之中。
如果 Product Backlog 規劃尚未打開，那麼現在就將其打開。
選擇最後的兩個事例。
在選擇第 18 個復選框之後，將鼠標移動到右邊並選擇 Modify，然後為 Release 1.0 規劃所有選擇的項目（參見圖 32）。
更改會得到立即的保存，而所有移動的項目都顯示為未激活狀態（灰色）。
刷新規劃以只顯示剩余的兩個項目。
圖 32. 發布的規劃項目
打開 Release Backlog 規劃。
如果項目尚未顯示，您可以刷新規劃。
注意：
假如您想要移動擁有子項目的項目，那麼請確定選擇並移動了子項目。否則，只有選中的上一級項目被移到了發布版本之中。
Release Backlog 的優勢在於，您可以將這些項目維持在實際上進入到版本之中的規劃中。發布流水表（稍後將會進行討論）反映了移出及移入的項目，這就允許您去精確地監視是否滿足了發布的目標。
填充 Sprint Backlog
迭代規劃開始時，會使盡可能多的事例從 Release Backlog 進入到沖刺中。第二步是為團隊需要完成的每一個事例都開發任務。盡管沖刺規劃的結果是估計任務的收集體，它最有可能分配給不同的團隊成員，記住沖刺規劃的目的對於團隊來說十分重要，以完成事例的收集，因此向產品添加新的及可傳遞的功能。規劃與估計可以幫助團隊去決定，沖刺階段需要有多大的工作量。
為 Sprint 1 打開 Sprint Backlog 計劃。
選擇 Overview 項。
在 Overview 頁面上，點擊 Edit Page 並記錄沖刺的目標（參見圖 33）。
圖 33. 記錄沖刺的目標
點擊 Save。
從 Release Backlog 分配事例給 sprint
，選擇相關的事例，並對於 Sprint 1 進行規劃。對於發布規劃，執行與“填充 Release Backlog”章節中所描述相似的操作（參見圖 32）。
還有一種選擇。在 Release Backlog 的 Iterations 視圖中，將事例從版本中拖拉到一個迭代之中（圖 34）。
圖 34. 向迭代分配事例
這將會向 Sprint Backlog 分配事例。更改會立即得到應用（在 Rational Team Concert 1 版本中，事例實際上是從 Product Backlog 移動至 Sprint Backlog 的，但是在 Rational Team Concert 2.0 之中，在 Product Backlog 中對於更早一點的追蹤也是可見的。在 2.0 版本之中，您使用 Iterations 視圖來監視事例所分配的迭代）。
圖 35 與圖 36 顯示了結果。
圖 35. 分配給一個迭代的事例（發布備份）
圖 36. 分配給一個迭代的事例（Sprint Backlog）
提示：
您可能需要刷新 Sprint Backlog 以查看新規劃的事例。
向事例添加任務
接下來的一步是分解添加至沖刺的事例。這意味著對於每一個步驟都會創建任務，執行這些步驟是為了使事例處於“完成”狀態（“完成”的特殊 Scrum 定義，意味著特性真正完成了而且如有需要可以得到具體化）。
將鼠標移動到項目左邊的矩形上，以打開操作選擇菜單。
將鼠標移動到右邊，直到您看到“Add Work Item Below”操作標簽為止（圖 37），並點擊操作。
圖 37. 向事例添加任務
選擇 Task。
為任務輸入總結。
圖 38. 添加一項任務
點擊 Save and Close。
在事例下面將會創建一項任務。注意它是與事例在相同的識別層次上創建的。
注意：
如果您在計劃中沒有看到新創建的任務，那麼您要確定 Execution 項目沒有排除在計劃之外（參見圖 39）。
圖 39. 篩選菜單
因為這項任務“屬於”事例，所以您可以為任務打開操作菜單並選擇 Demote 以將其移動到事例之下。作為一個選擇，您可以將其拖拉到事例之上，這也是將其置於事例“之下”。
圖 40. 使任務降級
提示：
確定您使用了一個視圖，項目在這個視圖中以樹形結構的方式顯示。假如您選擇了一個視圖，項目在這個視圖中是以扁平的方式顯示的，那麼您就不能識別任務了。當沖刺計劃得到創建以在樹形視圖中顯示項目時，Work Breakdown 視圖默認條件下會打開。
在一個典型的 Sprint Planning 會議中，團隊成員會調用需要完成的任務。將它們全部記錄下來，現在已經足夠了。時間估計與分配在會議的稍後階段才會進行。
繼續為它添加任務以及其他的事例。
提示：
因為沖刺規劃的迭代性與交互性本質，對於一個事例執行這樣的操作，然後完成下面的步驟以向任務提供估計與擁有者也許會最好。然後您可以返回至這個部分以規劃下一個事例。在停止時您要時刻關注一下 Team Load 指示符。
估計任務並分配擁有者
現在是時候估計為事例所輸入的任務了。您可以按照適合您團隊的方式執行以下的操作：
為了向任務輸入估計，您可以點擊任務以打開 Quick 編輯器。然後輸入估計值。對於每一個任務都執行這種操作，一個接著一個。
選擇： 您還可以從下列菜單中選擇以輸入估計值。如果您的時間估計值不在下列菜單中，那麼您可以選擇 More 以打開一個小型的輸入界面，您可以在這個界面中輸入您的估計值。
圖 41. 輸入時間估計值
當您輸入所有的估計值之後，您就可以看到每一個事例的總體估計值了，以及整個沖刺的總體估計值了。
一般來說，scrum 團隊成員會協商好任務，而分配工作也在同一時間內完成。因為不同的團隊成員也許需要不同的時間來完成相同的任務，所以在分配完成之後，您也需要對時間做一個最終的總結。
在 Sprint Backlog 之中，從列表之中，將任務拖拉到分配給 Havannah 團隊的成員。在向團隊成員分配一些任務之後，Sprint 規劃也許如圖 42 所示。
圖 42. 分配擁有者
項目左邊的箭頭指示了這些項目應該分配給某人。一般來說， 任務 會分配給團隊成員，但是 事例 仍然是未分配的，而團隊或者產品擁有者會決定什麼時候完成一個事例。這種方法的一種優勢在於，這種既顯示事例（頂級工作項），又顯示任務（通常都不是頂級工作項）的視圖中對於將一個事例分解為任務總是可見的。
同樣，工作負荷會顯示給每一個團隊成員。團隊工作負荷可以作為估計的任務來監視。為了平衡工作負荷並監視進程，所有的團隊成員都必須輸入他們的工作負荷，以及他們的到勤率缺席情況。
注意 Frank 沒有工作時間，而 Rose 只有 54 個可用的工作時間，因為假期或者其他方面的原因。您應該繼續估計任務，直到團隊成員不再擁有剩余的時間為止。對於成功的 Scrum 團隊來說，記住在每一個人的工作負荷重要留一些余地，以適應估計不充分或者誤差等方面的情況。目的就是讓所有安排的工作最後都能完成，不管發生什麼也是這樣。所以您要選擇一個適合團隊的余地范圍。為了確保成功，在開發的早期階段要留較高的余地值；隨著您對團隊的工作節奏和效率有了越來越深入的體會，您可以隨之降低余地值。
沖刺階段監視工作與進度
在沖刺階段，團隊成員會接受分配給他們的工作，開始處理任務，有規律地報告任務中還剩余多長的時間，並最終解決掉問題。同樣，他們會追蹤對於一項特定的任務，已經完成了多少的工作。
它的完成是為了適當地顯示迭代期間剩余的工作量。既然 Scrum 強調的是完成的工作，而不是開始的工作量，所以它更傾向於在進行到下一個項目之前，啟動並完成一個工作項。
使用開發員的任務板視圖
分配及監視工作的一種非常重要的方法是 開發員的任務板，它顯示了分配給私人的任務，指示了開始的工作量以及完成的工作量。同樣，在最左邊它還顯示了任務與上級項目的關系。Scrum 管理員或者團隊成員可以通過將項目拖拉到另一個團隊成員之上，來輕松將項目進行重新分配。它們可以啟動對項目的處理，或者簡單地將項目拖拉到適當的列上，來將它們設置為 已完成。
圖 43. 開發員的任務板
為了追蹤直到事例完成仍然打開的工作量， 剩余時間 應該為人們所處理的每一項任務都記錄下來。編輯一個工作項有很多種方式。為了打開一個快速編輯器窗口，您可以點擊項目文本（參見圖 44）。
圖 44. 快速編輯器窗口
剩余時間是一個簡單的文本區域；因此，如果團隊處理一個任務很多天了，那麼每一個團隊成員都需要根據特定任務剩余的工作量，來更新剩余時間區域。
提示：
為了幫助團隊成員去追蹤他們在估計任務方面的歷史與成功，一旦發生原始的估計值不夠，就應該立即對估計值進行校正。
為了打開工作項編輯器，您可以點擊任務 ID。使用 Discussion 特性來記錄進度或者獲取關於任務的信息。任意的團隊成員都應該更新這個區域內的信息，而這是獲取工作項歷史的一種比較好的方式。
圖 45. 工作項編輯器窗口
事例進度可以啟動工作來進行追蹤。通常來說，沒有團隊成員會為事例的整體負責；因此，隨著事例之下的任務完成了（開發完成），scrum 管理員就會將事例設置為“未實施”（參見圖 46）。
圖 46. 為 Sprint Review 准備事例
使用 Planned Time 視圖
追蹤可以使用 Planned Time 視圖來得到有效地完成（參見圖 47）。團隊成員可以移動任務，例如，從收件箱移動到每周計劃之中。同樣，缺席情況還顯示在該視圖之中。
圖 47. 規劃時間視圖
Planned Time 視圖使得查看剩余工作以及擁有者計劃什麼時候更改它變得更加容易。團隊在查看該視圖時，也許會找到重排任務的方式，以更好地支持團隊成員。Planned Time 視圖還可以用於支持日常的 Scrum 會議，因此使得討論什麼工作完成了以及接下來該做什麼變得更加容易。
追蹤以及報告進度
團隊成員追蹤工作的一種非常靈活的方法，是使用查詢。有很多現成可用的預定義查詢，而且您可以輕松創建自己的查詢。為了使用一個預定義的查詢，您可以切換至 Work Items 並點擊查詢。
使用查詢來監視工作
為了構建自己的通用查詢，您可以從頭開始，或者編輯一個已存在的查詢。如果一個已存在的查詢幾乎能夠滿足您的需求，那麼您可以使用與之類似的方式來編輯它，然後用一個新名字來保存它：
在 Work Items 視圖（圖 48）之中，您可以點擊 Create Query。
點擊窗口中部的 加號 來開始添加狀況。
在 Add Condition 窗口中，點擊 Type 然後點擊 Add attribute condition。
對於 Type，例如，您可以選擇 Story。
添加另外一個狀況以選擇 Planned For 並輸入 Backlog。
圖 48. 創建一個新查詢
您還可以選擇，配置查詢結果顯示的方式。
在 Result Layout 項之上，添加或者刪除列並制定其顯示的順序。
圖 49. 配置查詢結果的布局
給新查詢起一個名字，例如，All stories in Product Backlog, 並點擊 Save。
點擊 Run 以運行查詢並查看結果。
監視活動
輕松准備 Daily Scrum 會議的一種方法是使用預定義的 最近編輯過的 查詢，來識別最近幾天更改過的任務（圖 50）。您可以使用查詢句來配置被判斷為“最近”的時間。默認的值是 12 小時。
該列表將會快速顯示誰做了操作。它有助於決定誰最近報告了進度。
圖 50. “最近編輯的”查詢
查看什麼事情正在發生的另外一種方法就是 項目事件 視圖，它可以添加至項目的操作板之中。通常來說，操作板是監視活動及顯示狀態的一種比較好的方法。有一些操作板可以使用不同的視圖來進行配置，以處理涉眾與團隊的需要。圖 51 顯示了這樣一個視圖的范例，以包含項目的事件。對於該視圖的設置可以得到編輯以顯示關注的重點。
圖 51. Project Events 視圖
進度條
為了快速查看進程以及狀態信息，可以在 Rational Team Concert 的許多位置處查看進度條。這些進度條已經為迭代進度當前狀態，特定事例的進度，團隊成員的進度等等，提供了一個很好的視圖。對於項目團隊的活動成員，這些負載條可能顯示所有的信息，他們需要這些信息去追蹤沖刺內的進度。
Burndown 報表
團隊還可以使用剩余報表來追蹤工作的完成情況，並查看進度的歷史。他們可以使用 Product（Release）Burndown 報表來追蹤總體的項目進度，而且他們可以使用 Sprint Burndown 報表來查看工作在沖刺中的進展狀況。
Release Burndown 報表
報表要通過 Reports 菜單選擇進行訪問（圖 52）。
通過從菜單欄中選擇 Reports 然後展開 Work Items，以打開 Release Burndown 報表（在 Scrum 術語中，它也叫做 Product Burndown 報表）。
點擊 Release Burndown 報表。
圖 52 之中的報表顯示了每一個沖刺階段的剩余階段中的 Story Points ，以及規劃工作的總體數量。在這個范例中，規劃的工作量在第一個沖刺階段內一直保持不變。在第四個沖刺階段中，其他的工作也會添加至 Product Backlog。
圖 52. 打開一個發布剩余報表
提示：
為了追蹤趨勢以及歷史性的報表，Rational Team Concert 會使用數據倉庫技術，來收集大量數據的壓縮體，對於一個相對來說小型的項目來說也是如此。如果您試著在學習本文的同時，查看報表，並找到其中沒有數據，那麼您沒有做錯什麼。圖 52 中的報表會在監視六個沖刺階段的項目進度之後得到創建。當您開始操作時，好像數據倉庫“快照”尚未運行的收集一樣。該進程一般會在 Jazz 服務器時間區域內的午夜時分運行，所以您需要擁有一個占用所有時間的服務器，以讓進程自動運行。一個擁有管理員權限的用戶可以從網絡 UI 處收集一個快照（參見圖 53），盡管在產品環境下不推薦這樣做，因為進程可以占用大量的資源，並且在正常的工作時間內影響用戶的反應。
圖 53. 更新所有的快照數據
注意：
Rational Team Concert 提供有不同的報表工具。您還可以使用 Business Intelligence 和 Reporting Tools（BIRT），一種基於 Eclipse 的報表系統，以創建您自己的報表。圖 54 顯示了一些范例。
圖 54. 報表的范例
Sprint Burndown 報表
Sprint Burndown 圖表對“我們是否正在向完成應該完成任務的方向前進”這個問題提出了一個即時的回答。假設所有的團隊成員都適當地更新他們的工作項，那麼線趨勢隨著工作的完成會接近於 0（剩余的工作）。所有的團隊成員隨時都能輕松看到截止的日期。
按照下面的方法來顯示 Sprint Burndown 報表：
打開 Sprint Backlog （迭代計劃）並切換至 Charts 項。
您還可以選擇，切換至 Reports 並選擇 Burndown （參見圖 55）。
對於與圖 55 中報表相類似的 Sprint Burndown 報表，您必須 更新並登陸其他團隊成員所完成的工作。
圖 55. Sprint Burndown 報表
提示：
如果團隊成員在每天結尾並沒有更新他們的數據，那麼工作項的狀態就不會如實反映在報表之中。盡管更新任務的狀態，將會幫助趨勢線獲取接下來的進程點，還是沒有方法去更新歷史。任務會顯示為已完成，不管這項任務是否真的已經完成。
Jazz 並不會忽略計劃中的非工作日，因為對於那些全球范圍內分布的團隊來說，要想顯示哪幾天是非工作日是很困難的。因此，平線通常代表了周末時間，但是可能也是缺乏進度的一種表現 （進度更新）。
圖 56. 沖刺結尾處的 Sprint Burndown 報表
提示：
您可能需要編輯報表，以顯示您此時所感興趣的沖刺。
安排 Sprint Review 與 Retrospective 會議
scrum 進程的一個非常重要方面就是 Sprint Review 會議。它的第一部分是向涉眾進行演示。使用 Rational Team Concert 可能並不是它的一部分，因為重點是顯示工作的軟件，而不是任務的列表。但是，來自評審會議的回饋與評論應該收集到，要麼是在沖刺的 Overview 頁面，要麼是頁面的附件。
Sprint Review 會議的下一步是 Retrospective（有時也叫做 Reflection）。對於團隊討論什麼進行良好，什麼不是，以及他們決定做什麼來說，是一個機會。scrum 進程模板定義了一個 Retrospective 工作項類型（圖 57），它可以用以確保反映會議的召開，並追蹤團隊的評論與計劃。
圖 57. Retrospective 會議的工作項
對於下一個沖刺再次執行操作
一個健康 Scrum 團隊的生命充滿了成功的節奏感。計劃一會，工作一會，交付，然後重復。
現在您已經完成了您的第一個沖刺了，所以現在是時候開始下一個沖刺了：
在使用新 Scrum 進程模板創建項目區域時，會為 Sprint 2 創建計劃。
在 Overview 頁面上記錄沖刺的目標。
然後使用與沖刺 1 相同的方法，開始向沖刺添加項目。
如果在當前的沖刺中一個事例尚未完成時，可以有不同的操作方法去解決這個問題。一種選擇是將一個項目完全移動到新的沖刺之中。
打開 Release Backlog 計劃並選擇 Iterations view 模式。
將有問題的項目移動到下一個沖刺。
您可以選擇將所有的項目拖拉到下一個沖刺之中，一個項目接著一個項目（確定您沒有從計劃中篩選執行項目），選擇應該移動的所有項目。打開操作菜單並按照將它們移回沖刺時相同的操作方式來編輯它們。確定您移動所有的項目（例如，事例與它的子事例）。僅僅重新分配事例，不會移動子事例或者子任務。
圖 58. 規劃下一個迭代
選擇下一個沖刺作為“當前的 ”
就算您為沖刺創建了日期，Rational Team Concert 不會隨著時間的增長，自動從當前的階段移動到下一個沖刺。您必須手動調整什麼沖刺是當前正在考慮的。
從窗口頂部的選項欄中選擇 Project Areas 。
在窗口的右邊中，選擇 Manage Project Areas。
選擇 Havannah 項目。
點擊 Timelines 項。
展開 Main Development 行。
選擇 Sprint 2。
點擊 Set the Selected Iteration as Current。
點擊 Save。
圖 59. 設置當前的迭代
添加更多的迭代
當您需要為項目添加一個新的迭代時，您是在與選擇當前迭代相同的窗口中完成的（參見上面的圖 59）。
選擇您想要創建新迭代的版本。對於這裡的范例，您可以選擇 Release 1.0。
點擊 Create Iteration。
為新迭代填進一個 Identifier 和一個 Display Name。
調整日期並點擊 Finish。
注意默認條件下時間被設置為了 12:00 a.m。為了確保迭代的最後一天得到了適當的包含，您可以將日期設置為迭代末尾接下來的一天，或者，舉個例子，將時間更改為 11:59 p.m。
保存 項目區域所做的更改。
圖 60. 創建一個新的迭代
記住您還要為新迭代創建一個新計劃。
切換至 Havannah 項目區域並選擇 Plans
點擊 Create Plan（參見圖 61）。
輸入 Sprint Backlog 作為名字，Havannah 作為擁有者，並將其與 Sprint 3 迭代聯系起來。
注意：
當一個新計劃得到創建時，默認條件下它是與當前的迭代相聯系的。所以如果您在將新迭代設置為當前之後，只是創建了計劃，那麼您並不需要將值更改。
在 Advanced Options 之下，確保您選擇了 Always load all Execution Items。Plan Type 被設置為了“自動分配”，這將會導致計劃類型被設置為 Sprint Backlog。
保存 新計劃
圖 61. 創建含有 Sprint Backlog 的迭代計劃
學習更多，並考慮以下的選項
就算您學到了本文中所提到的各種技巧，但是與基於 Scrum 的敏捷開發規劃相比，Rational Team Concert 與 Jazz 還有更多的內容需要學習，對於這裡討論的敏捷開發而言，要學習的內容更多。對於初學者而言：
考慮一下使用 Jazz 源控制與 Jazz 源構建引擎，以增強您的持續性集成效果。
考慮一下對快速信息和狀態轉換使用操作板，而您的老板也會迷上網絡操作板的。試著使用各種的報表，以查看哪一個最能適合管理進程的方式。
