使用 IBM Rational Team Concert V2 管理 Scrum 项目，第 2 部分
规划和管理 Sprint
Jazz 技术帮助您实现自动化的敏捷规划和管理
系列内容：
此内容是该系列 # 部分中的第 # 部分： 使用 IBM Rational Team Concert V2 管理 Scrum 项目，第 2 部分
此内容是该系列的一部分：使用 IBM Rational Team Concert V2 管理 Scrum 项目，第 2 部分
敬请期待该系列的后续内容。
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 操作板）。试着使用各种不同的报告，以找到哪一个最能够匹配团队管理员管理进程的需要。
致谢
我们想要感谢 Dirk Baeumer、Jazz Agile Planning Team Lead 对本文所做的技术性支持，以及 David L. Schmidt、Technical Lead、Tivoli Software Engineering 对本文所做的总体评审、注释和鼓励工作。
下载资源
- Rational Team Concert Scrum 示例数据 (ScrumSampleData.pdf | 54 KB)
相关主题
- 查看本系列的第一部分：“使用 IBM Rational Team Concert V2 管理 Scrum 项目，第 1 部分：创建项目、团队及计划”。
- 获得 Jazz 和 Rational Team Concert 下载和更新，并在 Jazz.net 上参与讨论区的讨论。 （需要注册，其是免费的。） 这也是您可以输入和评审增强请求和缺陷报告的地方。
- 学习了解更多有 scrum 项目管理的内容：
- 通过 “IBM Rational Self Check for Software Teams 入门简介”了解 IBM Rational 工具进行持续实践改进。
- 学习了解 Mike Cohn 的书，User Stories Applied: For Agile Software Development (Addison-Wesley Professional, 2004) 和 Agile Estimating and Planning (Prentice Hall, 2005)，并浏览他的 Web 站点。
- 阅读 Carl Kessler 和 John Sweitzer 的 Jolt大奖书籍中有关 Stakeholder Goals 的内容： Outside-in Development（IBM Press，2001）。
-
查找有关 IBM Rational Team Concert 的特性和好处：
- 在 IBM Rational 软件交付平台 中了解其它应用程序，包括适用于并行开发和地域分布式团队的协作工具，以及用于架构管理、资产管理、变更和发布管理，集成需求管理、过程和组合管理，和质量管理。 您可以在 IBM Rational 在线文档中心 查找产品手册、安装指南以及其它文档。
- 访问 developerWorks 上的 Rational 专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
- 订阅 IBM developerWorks 时事通讯，获得有关最佳的 developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
- 浏览 技术书店，获得有关这些和其它技术主题的书籍。