在超過一年多的時間裡，我們一直在使用 IBM® Rational Team Concert™ 來支持我們的 Scrum 團隊，享用它的特性，與它的缺點共存，並發展它的下一個版本。使用 IBM Rational Team Concert V2，Jazz 和 Rational Team Concert 團隊可以向 Scrum 和敏捷評估、規劃支持交付顯著的改進（更不要去提更加改進的 Web 客戶端以及許多其他新的特性）。
Sprint 規劃
正如我們在本系列文章第一部分使用 IBM Rational Team Concert V2 管理 Scrum 項目，第 1 部分：創建項目、團隊及計劃章節中討論的那樣，每一個 Sprint 階段將項目從 Product Backlog 引入到迭代階段開始，然後直到開發團隊需要完成的 Sprint Backlog 任務。盡管 Sprint 規劃的結果，是估計任務的集合，這些任務有很大的可能會分配給各個團隊成員，但是有一點很重要，那就是記住 Sprint 規劃的目的，就是督促團隊成員完成事例的收集工作，以及向產品添加新的和可交付的功能。規劃和估計可以幫助團隊決定滿足 Sprint 的需求需要多大的工作量。
創建 Sprint Backlog
創建一個 Sprint Backlog 迭代計劃（見於圖 1）：
與前面創建 Product Backlog 迭代計劃的指南相類似，在 Team Artifacts 視圖的 Plans 節點上右擊 Sprint 1 （1.0），選擇 New 然後選擇 Plan 。
在對話框窗口中，輸入 Sprint Backlog 作為名字。
對於 Plan Type，選擇 Sprint Backlog 然後將其與 Havannah Team 區域聯系起來。
圖 1. 創建一個維持 Sprint Backlog 的迭代計劃
在 Sprint Backlog 的概述頁面上，記錄 Sprint 的目標（圖 2）。
圖 2. 記錄 Sprint 階段的目標
點擊 Save 。
將事例分配給 Sprint 階段
Product Backlog 窗口打開之後，選擇相關的事例，然後右擊並選擇 Plan For 再選擇 Sprint 1.0 （見於圖 3）。您還可以選擇，切換至 Iterations 視圖，並將事例從版本中拖拉到迭代中（圖 4）。
圖 3. 將事例分配給迭代
圖 4. 將事例拖拉到迭代中
這將會將事例分配給 Sprint Backlog。初始狀態下，左邊邊緣裡的一些小星號意味著更改得到了暫停（在 Rational Team Concert V1 中，實際上事例已經從 Product Backlog 移動到 Sprint Backlog，但是在 Rational Team Concert 2.0 中，它們停留在 Product Backlog 以方便追蹤。在 2.0 版本中，您使用 Iterations 視圖以監視事例被分配給哪一個迭代了）。
點擊 Save 以完成移動操作。
點擊 Sprint Backlog 項已將其帶到前台。
圖 5 顯示出了結果。
圖 5. 分配給迭代的事例
向事例添加任務
接下來的一步，是分解向 Sprint 階段添加的事例。這意味著為每一步所創建的任務需要得到執行，以讓事例處於“完成”狀態（“完成”的特定 Scrum 定義意味著特性已經得到完全的完成，並且如有需要可以立即得到使用）。
在輸入任務之前，您要創建一個快捷方式以讓這個工作變得更加容易：右擊第一個事例，並將事例添加到 Work Item （方法與您添加事例相同），但是記住，您是從下拉菜單中選擇的 Set Default 選項。
將 Default for new work items 設置成 Task 。這樣不論何時您在點擊 Ctrl+Enter 時，它都會自動添加這種類型的一項了（任務）。
點擊 OK 。
圖 6. 為新工作項設置默認的類型
在開始輸入任務時，您可以選中相應的事例然後點擊 Ctrl+Enter 。
為任務輸入總結。
在選中的任務下面會創建一項任務。但是，注意現在它與事例位於同一縮進層次上（見於圖 7）。
因為這項任務“屬於”該事例，所以點擊 Tab 一次以將其移動到事例之下。
圖 7. 創建一個新任務
隨後添加到該事例中的任務，將會自動被認為是“子代”，或者子事例。
提示：
確保您使用的視圖中項目顯示在樹形視圖之中。假如您選擇的視圖項目是以平面方式顯示的，那麼您就不能識別任務了。 當創建一個 Sprint 任務以在樹形視圖中顯示時，默認條件下會打開 Work Breakdown 視圖。
在一個典型的 Sprint Planning 會議中，團隊成員會調出所有需要完成的任務。現在將它們全部記錄下來已經足夠了。時間估計和分配會在隨後的會議中得到執行。
繼續為其添加任務以及其他的事例。
提示：
因為 Sprint 規劃的迭代和交流性本質，可能一次為一個事例執行這些步驟也許會更好，然後完成接下來的步驟以提供任務的估計和所有者會更好。返回至本段以規劃下一個事例。保持對 Team Load 指示器的關注以了解什麼時候停止。
估計任務並分配所有者
現在是時間估計為事例輸入的任務了。但是，有一些團隊更喜歡首先為每一項任務分配所有者，以便能夠根據團隊成員的技能情況進行估計。
您可以按照滿足您所在團隊需要的順序，來完成下列的工作。
為了向任務輸入估計，您可以通過在 Sprint Backlog 中點擊眼鏡圖標，來打開 Preview 編輯器。然後對每一項任務輸入估計，一個接一個。
選擇： 您也可以通過從下拉菜單中進行選擇，以輸入估計。如果您的時間估計值沒有出現在下拉菜單中，那麼您可以選擇 More ，就可以得到一個小的輸入界面，您可以在裡面輸入您的估計值。以日期和時間的格式輸入這個估計值，例如：10 h 或者 2 d。
圖 8. 駛入時間估計值
當您完成所有估計值的工作之後，您可以看到每一個事例的總體估計值，以及整個 Sprint 階段的時間估計值。
圖 9. 從列表中輸入時間估計值
一般來說，Scrum 團隊成員會簽署任務，而分配工作會在同一時間內完成。因為不同的團隊成員也許會采用不同的時間計算方式以完成工作，所以您需要在完成分配之後，總結一下估計的時間。
在 Sprint Backlog 中，列表內，將任務拖拉到分配給 Havannah 團的成員。
圖 10. 分配所有者
項目左邊的箭頭意味著這些項目已經分配給了某個人或者某個地方。一般來說， 任務 會分配給某個團隊成員，但是 事例 仍然尚未分配，而團隊或者 Product Owner 會決定什麼時候完成一個事例。這個方法有個優點就是事例的中斷，總是可以從同時顯示事例（頂級的工作項）和任務（一般不是頂級的工作項）的視圖中看到。
同樣向每一位團隊成員顯示的是工作負荷量。團隊工作負荷量可以像估計任務那樣得到監視。為了平衡工作負荷量和監視的進程，所有的團隊成員必須輸入他們所分配的工作，以及日程安排中的缺席情況。
注意 Rose 由於有限的出勤率和假期時間的存在，只有 54 個可用的工作時。您需要不停地估計任務，直到團隊成員沒有可用的時間為止。scrum 團隊要想走向成功，就需記住在每一個人的工作負荷中都需要留一些空間，以調整不合理以及中斷的估計。其意圖就是不管發生了什麼事情，所有計劃好的工作都需要完成，所以選擇空間百分比以滿足團隊這個需要。為了確保團隊能夠獲取成功，在早期階段要留更多的空間：隨著您對團隊活動節奏和功能越來越了解，您就可以相應的縮小這個值了。
Team Central 視圖
另外一種顯示團隊工作負荷的方法，是 Team Central 視圖中的 Team Load 部分。如果積壓工作尚未打開的話，該視圖可以與其他另外的視圖一起打開。當不是 Sprint Backlog 的其他視圖占據了主編輯器視圖時，這種方式將會是監視團隊工作負荷的方便方法。
圖 11. Team Central 視圖
注意：
如果 Team Load 視圖是空白的或者標記為“未鏈接”，那麼您需要配置它：點擊 Team Load 視圖右邊的 downward white triangle icon ，以使用它的下拉菜單，並選擇 Configure 。
在迭代階段分配和追蹤工作
Rational Team Concert 提供了 My Work 視圖以幫助每一位團隊成員跟蹤他們自己的工作狀態。如果在您的工作區內不能看到 My Work，那麼您可以選擇 Window > Show View > My Work 。它一般會在左邊窗格中打開，同時打開的還有 Team Artifacts 和 Team Central 視圖。在 Sprint 階段規劃之後，大多數的用戶在他們的框中會有新的任務，等待接收。
My Work 視圖
在圖 12 中，Prasad 打開了他的 My Work 視圖，然後使用鏈接來接受所有的工作。
圖 12. My Work 視圖
不像 Rational Team Concert Version 1 那樣，它將會將所有接受的工作標記為“Imprecisely Planned”狀態，Rational Team Concert 2.0 會向您的 Current Work 添加項目，默認條件下會按照它們添加至視圖的順序來進行排序。所有的用戶應該評審這個順序，並將任務拖拉到執行任務時實際規劃的順序上（如有需要以後可以隨時排序）。
使用 My Work 視圖一個非常重要的原因，是支持團隊工作的追蹤和規劃。
規劃好的 Time 視圖
為 Sprint Backlog 使用 Planned Time 視圖，可以有效地執行追蹤操作（見於圖 13）。
圖 13. 規劃好的 Time 視圖
規劃的 Time 視圖使得查看剩余的工作，以及所有者什麼時候計劃操作它變得更加容易。在團隊浏覽這個視圖時，他們可能想要找到更好重排任務的方式，以更好地支持他們的同事。 Planned Time 視圖也可以用於支持 Daily Scrum 會議，因此討論完成了什麼工作，以及接下來要做什麼就更加容易。
為了支持上面討論到的視圖，團隊成員應該開始加工它們，規范地報告還有多少剩余的工作要做，並最終解決剩余的問題。既然 Scrum 方法強調的是完成的工作，而不是剛剛開始的工作，所以在將項目移動到另一個項目之前就啟動並完成一個項目會更好。團隊就能夠更快地完成事例，並達到 “Set Implemented”的狀態。
為了幫助追蹤直到事例完成時仍然未盡的工作量，應該在每一天為每一項任務重新記錄 剩余的時間 。
剩余的時間是一個簡單的文本區域；因此，如果一項任務已經進行了很多天，那麼每一個團隊成員每一天都需要根據他們剩余的工作情況，來更新 Time Remaining 區域。
為了幫助團隊成員追蹤估計任務中的歷史記錄以及成功情況，一旦發現原始的估計不夠用，就應該立即輸入估計的校正值（見於圖 14）。
圖 14. 調整估計和剩余的時間
提示：
如果您想報告花在某項任務上的時間，那麼您可以根據需求配置 Project Area 。
打開您的 Project Area ，並在 Process Configuration 項上，展開 Configuration Data 和 Planning ，然後選擇 Work Item Progress Mode 。
在這裡，您可以切換至 Time Spent 。
使用 Discussion 特性來記錄進程，或者獲取關於任務的信息。所有的團隊成員都可以更新這個區域內的信息，而這正是獲取工作項歷史的良好方式。
事例進程應該通過開始處理它來進行追蹤。通常來說，沒有特定的團隊成員會為整體的事例負責，因此，一旦事例下的任務完成，crum 管理員就應該將事例設置為“Complete Development”（見於圖 15）。
圖 15. 准備 Sprint Review 的事例
開發員的任務板視圖
另外一種分配和監視工作的方法就是 開發員的任務板 ，它顯示了列中分配給個人的任務，它意味著有哪些任務已經開始，哪些已經完成。它還在最左列顯示了任務對父項目的關系 。Scrum 管理員或者團隊成員可以通過將項目拖拉給另一個團隊成員，來輕松將其重新分配。通過將項目拖拉到合適的列中，他們開始處理項目或者將其設置為 已完成 。
圖 16. 開發員的任務板
追蹤並報告進程
通過使用查詢來監視工作
對於團隊成員來說，使用查詢來監視工作的進展狀況是一種十分靈活的方法。已經有很多可用的預定義查詢，而且您還可以輕松創建您自己的查詢。因為使用查詢就像雙擊查詢名一樣容易，所以我們將會向您展示，怎樣構建自定義的查詢。如果已經有存在的查詢能夠匹配您的需要，那麼您可以使用與之類似的步驟來編輯它，然後用新名字來保存它。
在 Team Artifacts 視圖中（圖 17），右擊 My Queries 並選擇 New Query 。
在 Query editor 窗口中，點擊 Start from scratch 。
在窗口的右邊點擊 plus sign 並添加一個新狀況。
完成以下設置：
Type： Task
Planned for： [select]
Name： Sprint 1
Status： Unresolved
圖 17. 創建一個新查詢
在 Result Layout 項下，選擇以下這些列：
ID
Summary
Priority
Owned By
Estimate
Corrected Estimate
Time Spent
根據 Owned By 和 Priority 分類（圖 18）。
圖 18. 配置查詢結果的布局
點擊 Save 。
點擊 Run 以運行查詢。
查詢結果顯示在 Work Items 視圖中。
從 Work Items 視圖中，使用下拉菜單可以開始處理一個項目。您還可以打開一項任務來更改它的狀態（圖 19）。
圖 19. 開始處理一項任務
最近更改的查詢
准備 Daily Scrum 會議的一種更加簡單地方式，是使用 Recently Modified 查詢（一種預定義的查詢），來識別昨天或者更晚一些時間更改過的任務（圖 20）。您可以通過使用查詢來將小時數配置為“最近”。默認的數值是 12 小時。
該列表將會快速顯示出誰執行了該操作。它幫助決定誰最近沒有報告任何進展（注意 Rose 的名字並沒有出現在列表之中）。
圖 20. 運行最近編輯過的查詢
進展條
為了快速查看進展和狀態信息，在 Rational Team Concert 中許多位置處都能看到進展條。這些進展條為一次迭代、特定事例的進展、某個團隊成員的工作負荷等等提供了進展當前狀態的一個很好的視圖。對於項目團隊的積極成員來說，這些負荷條顯示了某個 Sprint 階段追蹤進展情況所需的全部信息。
Burndown 報告
團隊還可以使用 burndown 報告來了解工作的進展情況，並查看進展的歷史記錄。他們可以使 Product （Release）Burndown 報告來追蹤項目的進展情況，並使用 Sprint Burndown 報告來查看 Sprint 階段內工作的進展狀況。
Product Burndown 報告
可以從 Team Artifacts 視圖中輕松訪問某個報告（圖 21）。
通過打開視圖中的 Reports 節點，然後打開 Shared Reports 和 Work Items 文件夾，來打開 Release Burndown 報告（在 Scrum 術語中，這叫做 Product Burndown 報告）。
雙擊 Release Burndown 報告。
您可能需要注冊到團隊服務器中。
圖 21 中的報告顯示了每一個 Sprint 階段中剩余的 Story Points ，以及規劃工作的總量。在本例中，規劃的工作在前三個 Sprint 階段中一直是個常量。在第三個 Sprint 階段，另外會有些工作會添加到 Product Backlog 中，這將會導致剩余工作的稍微減少，直到第四個 Sprint 階段開始為止。
圖 21. 打開一個 burndown 報告
提示：
為了追蹤歷史性報告中的趨勢， Rational Team Concert 使用數據倉庫來收集並壓縮大量的數據，甚至對相對來說較小的項目來說也執行相同的操作。如果您一邊查看報告，一邊學習本文並找到文章中沒有任何數據，您並沒有犯什麼錯誤。圖 21 中的報告是在監視五個 Sprint 階段的項目進展之後創建的。當您開始執行操作時，也許數據倉庫“快照”收集尚未運行。這個進展一般是在 Jazz 服務器時間區域中的中期開始運行的，所以您需要有一個服務器能夠在任何時間為進展服務。快照收集可以從 Web UI 獲得，盡管在產品環境下並不推薦這樣做，因為進展可能會占用大量資源，並在正常的工作時間內影響到用戶所做的響應。
圖 22. 無數據可用時的 Product Burndown 報告
注意：
Rational Team Concert 提供有多種報告。您還可以使用 Business Intelligence 以及 Reporting Tools （BIRT），以及一個基於 Eclipse 的報告系統，來創建您自己的報告。
圖 23. 報告的范例
提示：
您可以添加報告到您的收藏夾中，例如 burndown 報告，以及查詢，例如“Open Assigned to Me”和“Recently Modified” 。右擊您想要添加的報告，並選擇 Add to Favorites 下拉菜單項。這將會使訪問變得更加容易。
Sprint Burndown 報告
Sprint Burndown 表格為問題“我們是否已經步入正軌以完成所有需要完成的工作？”提供了一個直接的答案。假設所有的團隊成員都合理地更新了工作項，那麼隨著工作的完成，圖中趨勢線接近於零（剩余工作量）。任何時間所有的團隊成員都應該能夠輕松看到 burndown 率。
顯示 Sprint Burndown 報告最簡單的方式是：
打開 Sprint Backlog （迭代計劃）。
切換至 Charts 項。
Sprint Burndown 報告類似於圖 24 中的報告，您必須更新並注冊由各個團隊成員在一段時間內完成的工作 。
提示：
Select Report 按鈕能夠使您更加輕松地訪問其他的報告，在一次 Sprint 階段這些報告也許會引起監視的興趣。
圖 24. Sprint Burndown 報告
提示：
如果團隊成員在每一天的結尾沒有更新 他們的數據，那麼他們工作項的當前狀態就不會在報告中得到合適的反映。盡管更新任務的狀態有助於幫助趨勢線接近於下一個處理點，更新歷史記錄仍然沒有方法。每當一天結束時，任務都會顯示成已作（完成），不管實際上工作是否真的完成。
Jazz 在點線圖中並沒有跳過非工作日，因為對於一個全球分布的團隊來說，很難預先設置哪一天是非工作日。因此，平線通常意味著周末，但是也可以看做是缺乏進展的標志（或者只是沒有更新進展）。
安排 Sprint Review 和 Retrospective 會議
Scrum 過程的一個重要部分便是 Sprint Review 會議。會議的第一個部分，便是向投資者進行性能演示。使用 Rational Team Concert 也許並不是其中的一部分，因為重要的一點是展示軟件的性能，而不是任務的列表。但是，來自評審會議的回饋和注釋應該得到收集，要麼在 Sprint 階段中的 Overview 頁面進行，要麼作為對頁面的附件收集。
Sprint Review 會議的下一部分，是 Retrospective （有時也叫做 Reflection ）。這為團隊討論什麼進展順利，什麼進展受阻，接下來要做什麼提供了一個機會。 Scrum Process 模板定義了一個 Retrospective 工作項類型（圖 25），該類型可用於確保會議的舉行，以及追蹤團隊的注釋和計劃。
圖 25. Retrospective 的工作項
為下一個 Sprint 階段執行相同的操作
一個健康的 Scrum 團隊的生命充滿了成功的節奏。規劃一會，工作一會，交付，然後重復。
現在您已經完成了第一個迭代，所以現在該開始下一個迭代了。
為 Sprint 2 創建一個計劃。按照您為 Sprint 1 所做的規劃那樣執行相同的規劃。
在 Overview 頁面上記錄 Sprint 階段的目標
然後使用與 Sprint 1 相同的方法來向該 Sprint 階段添加項目。
如果在當前的 Sprint 階段並沒有完成某個事例，那麼解決這個問題有很多種方法。一個選項就是將其拖拉到新的迭代上。您必須將其拖拉到新的 Sprint 階段，以移至新的 Sprint 階段，或者您可以一次選擇所有的項目。使用下拉菜單僅僅重新分配事例（右擊並選擇 Plan for ）將不會去掉子代，或者子任務。
執行下拉操作：
為 Sprint 2 Backlog 點擊一項並將其拖拉到屏幕的前台，這樣您就可以一次看見兩個計劃了。
然後將事例從一個移動到另一個上。
當您被詢問是否想要重新分配子代時，選擇 Yes 。
事例和子任務現在已經移動到下一個 Sprint 階段。當任務被分配給某個所有者時，該團隊成員的工作負荷會立即得到調整。
圖 26. 規劃下一個迭代期
事例左邊的星號，意味著更改現在尚未得到保存。Sprint 1 窗口中指向左邊灰色區域的灰色箭頭，意味著項目的移動現在已經暫停。
在您點擊 Save 之後，移動將會完成。
選擇下一個 Sprint 階段作為“當前”
就算您為 Sprint 階段創建了日期，Rational Team Concert 並不會自動切換以把 下一個 Sprint 階段當做當前的 Sprint ，因為時間還在增加。您必須手動校准哪一個 Sprint 階段作為當前值。
打開 Havannah 項目，並在右邊的 Overview 項下，選擇 Sprint 2 ，然後點擊小藍色三角形圖標（見於圖 27），以將當前的設計器移至新的迭代上。
圖 27. 設置當前的迭代
添加更多的迭代
當您需要為項目添加一個新的迭代時，您可以再一次打開項目。
在項目的 Overview 項之下，要麼點擊 Create Iteration 以添加一個新的迭代，或者選擇一個已存在的迭代，然後點擊 Duplicate 。為了保持標示符並顯示名字常量，您可以使用 duplicate 方法。在本例中，為產品創建第三個迭代：點擊 Sprint 2 然後選擇 Duplicate （同樣見於圖 28）。
除掉“Copy_of_”文本，然後更改合適的部分以命名新的迭代。
調整日期並點擊 OK 。
保存 Project Area 更改。
圖 28.復制一次迭代
學習更多內容並考慮以下選項
就算您已經從本文中學到了很多內容，但是對於 Rational Team Concert 和 Jazz 來說，除了基於 scrum 的靈活開發來說，您還有很多工作要做，除了這裡所做的討論，對於敏捷開發您還有很多可以做的。首先就是：
考慮一下使用 Jazz 源控制以及 Jazz 構建引擎來增強持續性的集成效果。
對於那些不是開發員的團隊成員來說（或者那些不想安裝 Eclipse 客戶端的團隊成員），可以向他們介紹 Web UI 以檢查工作項以及項目狀態。有了 Rational Team Concert 2.0，Web UI 會隨著 Eclipse 客戶端得到動態性的改善。甚至基於 Eclipse 或者 Microsoft®Visual Studio®得開發員，在一些情況下都更加傾向於使用 Web UI，例如操作板（您的管理員將會非常樂於使用 Web 操作板）。試著使用各種不同的報告，以找到哪一個最能夠匹配團隊管理員管理進程的需要。
本文附件
