Millard Ellingsworth, 软件开发人员, IBM
2008 年 8 月 19 日
敏捷计划工具与 IBM® Rational® Team Concert的集成，提供了更大的可操控性、合作的空间和可跟踪性，及过程意识性，并且所有这些都集中于一个平台下，从而有利于提高开发效率。
IBM Fellow Grady Booch 曾讲过，IBM® Rational® Team Concert 与 IBM® Rational® Jazz 平台，通过降低并减少团队中的许多日常行为，有助于提供一个“无阻力的开发平台”。应用 Rational Team Concert 与 Scrum Process 模板，能克服许多困难的一个方面，就是它能将敏捷计划与追踪开发工作进行融合。目前，如果您正使用当下流行的敏捷计划工具，您就不得不在工具与 IDE（集成开发环境）之间不断切换，以定位工作，完成它并报告它的进度。通过融合这些操作及其他的一些活动，Rational Team Concert 、Jazz 的集成，提供了更大的可操控性、合作的空间、可追踪性以及过程意识性，并且所有这些都集中于一个平台下，从而有助于提高开发效率及软件交付。
术语 scrum 来源于橄榄球活动，是 scrummage 或者 Scrimmage 的缩写。在软件开发背景下，并列是一种灵活开发过程中项目管理的方法，它致力于，在尽可能短的时间内，向项目投资者提供最有效的商业信息。并列过程有助于确保，最有价值的剩余结构将在下一步得以创建，并且它强调工作总是在可传递的地方完成。工作在两到四周的 sprints 或迭代中构建好，在每个冲刺点的末端，软件作品产生出来。
为了学习怎样运用 Scrum Process 模板与 Rational Team Concert, 您可以先建立一个项目然后追踪其第一步迭代。例子项目中的数据，来源于 Mike Cohn 写的《 Agile Estimating and Planning》中所举例子的扩展（Prentice Hall，2005， 它描述了 Bomb Shelter Studios 工作室 Scrum 团队致力于开发一个名为 Havannah 的电脑游戏，例子中的数据既来源于相关文件“Rational Team Concert Scrum sample data”（参见 下载）。
本篇文章假设，您已在 jazz.net 网上注册过，并按照那里的指示下载安装了软件。您必须设置一个 Rational Team Concert 用户可以链接您的 Jazz库的地方。在对 Scrum 过程进行一番简短介绍后，我们将开始创建一个基于 Scrum 的 Rational Team Concert 项目。
 |
Scrum 框架由以下相关方面构成：
- 角色
- 产品负责人
- ScrumMaster
- 团队成员
- 形式
- Sprint 规划
- Sprint 评审
- Sprint 总结
- 每日 Scrum
- 工作成果
- Product Backlog
- Sprint Backlog
- Burndown Chart
- Impediments List
Scrum 项目中的需求是作为一个项目存在的，它位于 ProductBacklog 中。 它是一个 Scrum 项目中，最重要的一方面，也是项目所有预期产品或功件的一个优先表。 当项目进程和商业环境发生变化时，ProductOwner能保持这份表不变，并且修改项目的优先级。理想条件下，Product Owner 中的项目，在包含有对投资者有商业价值的项目中被设定好。
Product Owne 对产品的成功负责。他或她定义功件、公布进度安排表，并对决定不同功件的商业价值负责。Product Owner 不断地精简和重新定义 Product Backlog 的优先级。
ScrumMaster 管理Scrum进程，确保 Scrum 行为被合适地执行，并且队员们正确地理解了 Scrum 内容。 他或她通过减少阻碍、保护队员不受外界干扰，确保团队高效运作。（至少在一个迭代内）
Scrum 团队应该是多功能的，混合了各种技能以完成项目（例如：开发员、测试者、交流设计师、打字员）Team members应该全天候投身于 Scrum 团队。
在每一个迭代的开始，团队都要举行一次 Sprint Planning 会议。在会议中， Product Owner 展示本迭代所需要的功件， 描述它们，从而队员们能得知预期要得到什么产品。Product Owner 和团队，对迭代的目标达成一致，特别是对未来两到四周工作的描述。 然后团队决定怎样完成 Sprint Goal 并将功件分解组成任务所需要的。
任务表成为 Sprint Backlog。 Sprint Backlog 中的项目以小时进行估计，以便允许团队决定，项目是否能够准时完成。如果时间不够，能从 Sprint Backlog 中去除一个功件，并返回到 Product Backlog 重新设置。估时作为一种团队行为被执行，并且不由 ScrumMaster 或者 Product Owner 决定。Sprint Backlog 意味了团队必须在项目反复期间全力投身于该工作。
在 Daily Scrum 会议期间，团队回答以下三个问题：
- 昨天我干了什么？
- 今天我干了什么?
- 如果有事情阻碍了我的进程，我该干些什么?
这不是一个状态会议，而是一个规划和分配任务会议，整个会议耗时不超过15分钟。对诸如每个人正在忙什么、他们正面临着什么难题之类问题的规律性交流，可减少开其他会议的需要，并有助于团队成员更有效地一起工作。
在每一个冲刺点的结尾，团队可展示在 Sprint Review会议期间完成的工作。这是一个所有有兴趣团体都可以参加的简短及非正式会议。它的目的是展示正在开发的软件（或其他有价值的产品，如对未来软件产品结构的概述），并从参入者及投资者那里，得到对正在开发之中软件的回馈信息。
在 Sprint Review 之后,团队自觉开会以进行 SprintRetrospective（有时也称作一次 Reflection）。在会议期间，他们将讨论，什么按预期进行 ， 什么进行受挫 ，回顾项目及它们的进程。 这种会议应该在他们接下来的迭代工作安排上，进行某些调整与改变。所以该会议能不断提高开发团队的工作效率。
因为 Product Backlog 的项目已挑选完成， 它们成为 Sprint Backlog 的一部分。 Sprint Backlog 包括了 Product Backlog 中功件相联系的特定任务。在迭代期间， Sprint Backlog 工作项目的状态每天都在更新。更新后的状态，使产生一个Sprint Burndown表成为可能。完成表以图形的样式显示项目中剩余的工作量。 通常它也包含一个“理想”行，以指示迭代从开始到结束工作的顺利进展。
当工作遭受挫折和阻碍时， ScrumMaster 可以制作一个 Impediments List（或Blocks List），以成为 Scrum 的副产品。所有的 Scrum 产物，都应该保存在队员们能轻松找到的地方。
Jazz Scrum Process 模板，支持所有重要的 Scrum 部件、聚会以及产品。因为该模板基于 Eclipse™的客户用户界面（UI）及网络UI ，所以 Rational Team Concert 能轻松访问这些组成，以及其他许多部分。
在我们观察 Rational Team Concert 及 Jazz Scrum Process 怎样支持 Scrum 团队以前，我们需要掌握创建基本项目的方法。 我们使用 Beta 3 of Rational Team Concert 和 Jazz plus（Scrum Process Template 的一个早期版本）来创建该例子，所以它们看起来非常像公布的产品。
- 确定您的 Jazz 服务器已启动， Rational Team Concert 客户机是运行着的，并且您已登录 Repository Connection。
- 现在创建一个新的 Project Area，在 Team Artifacts 视图下右击 Repository Connection（图 1），然后选择New > Project Area。
新 Project Area 向导有两个控制面板 （图 2）。
- 首先，输入项目的名字（本例中是
Havannah）， 然后点击 Next。 - 在 Available Process Templates 下，选择 Scrum 模板，然后点击 Finish。（在已发布的软件中， Scrum Process 模板名字将不包含“Early Draft”后缀）。
服务器可能要花多达数分钟时间，去初始化 Project Area，当初始化完成以后，您会看到一个类似于图 3 的屏幕。
图 3. All Team Areas 中现在显示的 Havannah 项目
在 Team Artifacts 视图的左栏中，您可以看到带有 Builds， Reports， Streams（源控制）， Work Items（查询）， 以及 Plans（最后一个是本篇文章所关注的）。 在 Project Area 编辑器中，有一个可产生项目描述的地方。在右下角，您可以看到一个可添加附件的控件，它是用来支持 Scrum Process 模板的，但它并不是您放置项目附件的一个理想的地方。
作为 Project Area 的创建者，您就是初始管理员（Admin）。但是，大多数对 Scrum Process 模板中项目结构修改的权利，是控制在 ScrumMaster 或者 Product Owner 手上的。因此， 您需要做的第一件事，就是向项目添加成员，并设置它们各自的角色（至少对 ScrumMaster 和 Product Owner 是这样的）。通常，Project Area 会员权赋予会员以管理权利，随后，其他的队员可加入队伍中。
- 点击 Members 左侧的箭头以展开控制面板 （图 4）。
如果您用外部用户库（例如您的联合 LDAP 服务器）设置了 Jazz，您可以直接引进用户条目，而无需创建它们。但是，让我们假设，您使用的是默认的 Tomcat 应用服务器，从而您必须在项目区域中创建用户。
- 点击Create（图 4 ）以启动 New Member 向导。
- 选择 Create a new user（图 5 ）然后点击 Next。
- 输入用户信息， 如果条件允许的话添加一张照片（如图 6 所示）。E-mail 是必填项，因为 Jazz 可以发送团队活动的电子邮件信息。
- 点击 Next。
- 选择为用户准备的 Jazz 安全组（如图 7 所示）。
- Jazz Users 在 Project Area 有默认的访问权。通常他们可以向视图报告创建和添加工作项 。并且可以使用，其他被项目安全设置所定义的其他部件。
- Jazz Admins 可以进行与 Jazz 服务器，以及项目相关的各种设置。例如创建附加的 Project Areas。
- 点击 Next。
- 选择对用户合适的许可证种类（图 8 ）。
- Developer 许可证适合于那些写代码并运行项目的队员。
- 例如，Build 和 ClearCase Connector 许可证只颁发给管理员用户。
- Contributor 许可证对所有其他所有队员都适合。
图 8 . Client Access License 选项
- 点击Finish。
- 既然在 Members area 中已有一个用户，那么 Process Roles 按钮（可见的，但在此之前是不可使用的），在您从成员表中选择Sasha时是可使用的。
- 点击 Process Roles （图 9 ），并选择 ScrumMaster，将它添加到 Assigned Roles 列表中然后点击Finish。
- 添加 Frank 作为 Product Owner。
图 10 显示了例子项目中完整的 Members 列表，包括 ScrumMaster，以防以后在许可权问题上发生分歧。
注意：
ScrumMasters 并不是不可缺少的队员。
图 10 .完成 Team Member 列表
- 为了保存设置，在 Havannah Project Area 编辑器的右上角点击 Save。
在保存完成以后，您将得到一份新队员的名单，并被询问，是否向名单上的人发送一封邀请他们加入项目的电子邮件。如果您设置了 E-mail 支持 （在您建立服务器时），该操作将向您的项目队员，发送一封电子邮件的邀请函，随之发送的，还有联系该项目的链接及相关信息。
- 因为这些用户是虚构的，所以关闭该对话框。
应用 Scrum Process 模板，还有另外一种推荐的安装方式，这是您作为一个 Administrator 而不是 ScrumMaster 或者 Product Owner 可以完成的。
- 将工作项的默认目录名改为
Product Backlog（图 11），以和添加到产品中的 Scrum 管理项保持一致（但是此步对于要发布的产品来说，是不必要的）。
目录也可用作管理功件、任务、缺陷以及等等此类。例如，这里可以有，应用于各种 UI 部件、不同服务的目录，应用于 Web UI 的不同目录 ，只要是便于理解产品组织结构的就行。但是现在，Product Backlog 就能满足这个要求。
图 11 . 将目录名改为 Product Backlog
- 使用 Project Area 编辑器的底部标签， 选择Work Item Categories，然后在项目名下选择第一目录 （目前只有这一个），然后在拉下菜单的底部通过选择 Edit来编辑它。
- 将名字改为
Product Backlog，点击 OK，这样就保存了 Project Area 做出的变化。
Jazz模型通过多重开发方向，以及分队可以轻松支持较大的团队结构。在 Project Area 中，有组织队员的 Team Area 区域。只有 Team Area 队员有权利得到与团队相关的分配工作。尽管本例中只有一个团队，这点也适用于队员们。
- 在左部面板上点击 Team Organization 项（图 12 ）。 如果它没有展开，使用 Window > Show View > Team Organization 以打开它。
- 双击 Havannah Team 文件夹（随 Project Area 创建时被自动创建）以打开 Team Area 编辑器。
- 在编辑器界面内，点击 Add 以启动向导，来选择 Project Area 成员，并将他们添加到这个团队中。
- 将 Sasha 添加为 Team Member 和 ScrumMaster：
- 在用户名文本区域输入
s（字母S） ，以搜寻与之相匹配的名字 （图 13）。 Sasha 将出现在匹配的用户名列表中。 - 点击 Select 以将他移动到被选择的用户名列表中。
- 点击 Next 以向他赋予 ScrumMaster 和 Team Owner 的角色。
- 点击 Finish。
- 在用户名文本区域输入
- 目前系统中还没有其他成员，使用 Create 按钮，除了 Frank 和 Sasha ，向团队成员添加其他队员。
最终的成员表与图 14 中的看起来类似。
图 14. 更新成员列表
- 同样的，打开 Administrators 段并将 Sasha 添加为 Project Area 管理员。随后，如果顺利的话，团队的 Project Area 管理员可以去掉您作为一名管理员的身份。
在开始规划新的实际项目时，您需要以 ScrumMaster 或 Product Owner 的身份登录，因为他们是唯一的拥有改变方案特权的角色。修改方案后，如果不这样做，在试着保存修改时，您将遇到许可权错误这种情况。而当您建立自己的项目时 （是本例）， 如果您是 ScrumMaster 或者 Product Owner，就能完成。您需要按以下步骤来退出或者重新进入。
Repository Connection 的拉下菜单中（如图 15 所示），包含了登录及退出的选项。
图 15. 不同用户的登录及退出
- 作为
Sasha，使用您登录及退出时相同的拉下菜单（默认的密码与用户的 ID 相同，因此密码也是Sasha，直到它被改变时）。因为 Project Area 是一个顶级节点 ，您就需要用到它的拉下菜单（图 16），然后选择 Open（双击只能展开或缩小它）。
Project Area 编辑器 再次被打开后，当您创建 Project Area 时，您可以看到过程模板建立的默认占位符。（图 17 ）。
- 在 Process Iterations 后选择 Release 1.0，然后点击EditProperties。
- 标示符必须是独一无二的，但是您可以把它改作与您的产品相匹配。
- 设置发布的开始及终止时间（见注意），确保复选框 “A release is schedule for this iteration” 被选中，然后点击OK。
- 同样的，您可以为已存在的迭代编辑属性。
注意：
因为追踪工作与时间有较大关系，日期是基于您投身于范例的时间。在今天或随后的某一天，开始发布版本与第一次迭代。每次迭代应该持续两周 （通常是从星期一到下一周的星期五，在最后再略去非工作日）。
Release 1.0 和 Sprint 1 的图标中的小蓝色三角形符号指示着，他们是当前的 Release 和 Iteration。
- 为了添加一次迭代，既不能点击 Create Iteration 以添加一个新的，也不能选择一个已存在的迭代然后点击Duplicate（图 18）。为了保持标示符与显示的名字相符合，您可以使用复制方法。
- 在本例中，为产品创建第三次迭代：点击 Sprint2 然后选择 Duplicate。
- 去掉 “Copy_of_” 文本，然后改变分配段落以命名新的迭代。
- 调整日期然后点击OK。
- 保存 Project Area 的变化。
Scrum 方法中一种最重要的产品，就是 Product Backlog。
- 本例中为了创建一个 Product Backlog，切换到 Team Artifacts 视图 （图 19） ，然后通过选择Release 1.0 > New > Iteration Plan 向公布版本添加一个迭代方案。
提示：
要想看到 Release 1.0 迭代，您将不得不打开一个或更多的树节点，附加的公布版本及迭代计划（如果可以得到的话）， 在发展线以下（在本例中， Main Development）， 但是为了便于访问，目前的公布版本及迭代在 Plans 线是可见的。
图 19. 创建一个产品未完成工作表
- 在已打开的 New Iteration Plan 向导中，输入一个
Product Backlog名字然后点击Finish。
Product Backlog 迭代方案，将打开一个多页的编辑器 （图 20 ）。
- 在 Overview 篇（见下部突出部分），您可以通过使用 wiki 形式的信息，来输入您产品的信息。这将作为 Web UI 中您的项目 Web 页面的部分而展示出来。
- 编辑器视图下部的 Attachments 区域，是一个很适合添加任何必要部件，以及其他与公布版本相关的普通文件的地方 ，这样，这些信息就能很容易地为所有的队员们看到 。
|
|
- 点击 Planned Items 以开始添加 Backlog 项目。
- 使用在右边面板的 Group by 拉下菜单 （图 21 ） 以切换到 Folders视图（如果它不是目前已选择的视图）。当添加许多新的 stories 时，它是最早投入使用的视图。
如果您愿意，您可以添加文件夹 （将默认的名字进行重命名）。这是一种组织工作项目的简单机理。例如，您可以向Top Items文件夹，添加作为 Stories 的所有 Product Backlog 项目。
- 右击 Top Items 文件夹，选择 Add Work Item（图 22 ） ，然后是 Story 以添加第一个项目。
向文件夹添加新的项目，然后打开一个合适的文本区域，以进入 Story Summary （图 23 ）。
图 23.进入 Story 摘要
这是进入一个新 Stories 的便捷方式。
- 使用拉下菜单以添加附加的 Stories （您也可以使用 Ctrl+Enter 快捷键，来打开 Work Item 文本，然后将向下的箭头移到第一个项目上， Story，接着选择 Enter）。
- 随时在 Iteration Plan 的右上角点击 Save 以保存您的作品。
在 Stories 被添加后， Product Owner 的下一步工作，是设定它们的优先级，只有1-10 的优先级范围是可使用的。系统记忆用户的拖放指令（或者使用 Alt+Cursor Up 及 Down 快捷键）。因此，如果您用这种方式安排它们的优先级，无论何时您从Group by下拉菜单中选择User defined order,您将会看到，它们以您安排的方式出现。您可以通过使用嵌在列表项的下拉菜单，来早点分配优先级 ，如图 24 所示。
图 24. 排定场景优先级
当然，如果我们拥有的都是 Story Summaries 时，它也称不上 Product Backlog 。
- 双击一个 Story，以打开 它的编辑器（在本例中，Story 显示“As a player, I can play against a weak engine that recognizes rings”如图 25 所示）。
- 在底部点击Acceptance Test，然后在那里添加 Stories。
提示：
另一种在创建表时，处理添加的详细资料的好方法是，在迭代规划编辑器中打开 Preview 模式。点击工具栏中的眼镜图标 （图 26 ），编辑器将分开以显示 Iteration 方案，然后一起选择项目。
图 26 . Previewing Stories
如前面在 Scrum 过程概述部分讨论过的，每一个迭代方案或者 sprint, 开始于从 Product Backlog 中将工作项目拖到 Iteration ，然后产生一个，需要团队完成目标的 Sprint Backlog 。
- 首先，创建一个 Sprint Backlog 迭代方案。
- 与前面的创建一个 Sprint Backlog 迭代方案的指示相类似，在 Team Artifacts 视图的 Plan节点上的 Sprint 1 （1.0）右击，选择 New 然后选择 Iteration Plan。
- 在向导中，输入
Sprint Backlog的名字。 - Product Backlog 窗口打开时，选择需要的 Stories，右击并选择Plan For，然后选择 Sprint 1.0。
这将 Stories 移到 Sprint Backlog 。 最初，它们将在左边缘部分显示一个小箭头，表示它们正等待被移动。
- 点击 Save 以完成移动。
- 点击 Sprint Backlog 以把它拖到前面。.
现在 Stories 添加任务
- 首先，建立一个捷径以方便操作，在第一个 Story 上右击以添加一个 Work Item （与您添加一个 Stories 相似），然后从下拉菜单中选择 Set Default 选项（图 28 ）。
您将遇到一个类似于图 29 显示的对话，结果是，无论何时您按下 Ctrl+Enter，它将自动创建一个默认种类的项目。您可以利用接下来的对话，来移除，或重新分配默认的 Work Item 种类。
图 29 . 设置默认的 Work Item 种类
现在点击 OK。
- 为了开始进入工作，选择第一个 Story 然后点击 Ctrl+Enter。
在选择的 Story 下面将会创建一个任务。但是，注意它是和 Story 有相同的缩进水平（图 30 ）。
- 因为本任务“属于”Story，按下 Tab 一次以将它移到 Story 下面。
注意：
Rational Team Concert 将 Flag 该任务，因为目前还没有进入摘要区域的必要，但是在添加摘要后警告将消失。如果您愿意，您可以先进入摘要以避免产生警告。
图 30 .切割一项任务
子项目或 Sub-stories 将自动引用添加到 Story 的任务。
在一个典型的 Sprint Planning 会议上，队员们将讨论需要完成的工作。会议随后可进行时间预测及分配的议程。
- 接下来为这个及其他的 Stories 添加任务。
注意：
一次性完成本 Story ，因为为了进行预测，需要进行对队员们的工作负荷进行追踪，规划没有时间去做的方案是没有意义的。
当第一个 Story 的任务被确定后，现在该为团队做时间预测了。
精确计算团队的工作负荷量，可调整队员们的适应性。可能一名队员，有脱离队伍影响参入或休假的机会，这些都要在用户部分做出调整。
- 在 Team Artifacts 视图下，打开 My Team Areas 节点，然后打开 Havannah Team 文件夹。
- 在Rose名字上双击以打开她的详细资料（图 31 ）。
Rose 在队伍中的时间只占总时间的 75% 。
- 在底部点击 Work Environment，然后在 Work Assignment 段，点击 Havannah Team 行，然后点击 Change 按钮（图 32 ）。
- 将她的工作量降低到 75%。
- 点击 OK。
这可以将分配的工作时间，调整到 Rose 可以 投入到工作中的时间。注意她还有一个即将到来的假期。
- 切换至 Scheduled Absences，在列表的右边点击 New，然后进入她的假期的日期 （图 33 ）。
- 点击 OK 和 Save 以更新 Rose 的详细资料。
Rose 是在本段时间内，唯一脱离队伍的队员，所以您现在就可以开始评估任务。
- 回到 Sprint Backlog（打开 Plans 节点，如有需要，在 Sprint Backlog 上双击）。
- 因为是团队决定，评估应该是什么样的，所以通过点击如图 34 所示的小钟表图标来打开拉下菜单，可以很容易地完成评估。（您也可以在每项任务上双击来打开它，但是上述操作要更容易一些）。如果您的时间评估不在下拉菜单中，选择 More，在进入您的评估方案的地方，会出现一个小输入框，用天数及小时数的方式来输入评估结果，例如：
10 h或者2 d。
- 为了让团队的工作负荷更加的合理，您还需要分配一下任务。
注意：
通常的， Scrum 团队成员得到任务列表，与此同时可以完成分配方案。因为不同的队员，完成一项任务所用的时间是不同的，所以在没有一项分配方案的情况下，很难合理地完成一次时间评估。因此，一个简单的，列出分配给 Havannah 团队的队员名单的下拉菜单是可以利用的（图 35 )。
图 35. 向用户分配任务
因为任务得到评估，团队的工作负荷量可以被监控。最简单的方式是使 Team Organization 视图可见（图 36 ），随着评估方案的完成，它也将得到更新。这个视图可以随着 Sprint Backlog 视图一直打开着。
图 36. Team Organization 视图
注意，由于她有限的报告率及假期的存在，Rose 只有 54 个工作小时数。您可以一直评估任务，直到队员们没有了工作的时间。为了让 Scrum 团队取得成功，记得要在每个人的工作负荷中留一些空余，以适应不充足或中断的评估。
注意：
如果 Team Load 视图是空的，或显示“无连接”，您需要设置它： 在 Team Load 视图右边下面，白色三角形上点击以使用拉下菜单（图 37 ），然后选择 Configure。
图 37. 设置 Team Load 视图
- 在随后的对话中，选择Project Area（Havannah 应该已经被显示出来） 然后选择Team Area (Havannah Team)。
- 点击 OK 两次，然后队员们的工作负荷量应该就可以看到了，如图 38 所示。
队员们最简单的追踪他们工作的方式，是使用 My Work视图下，默认条件下这是在左边面板中打开的。您第一次使用它的时候，可能需要设置它 。如果是这样，假设您已作为 Prasad 登录，接下来的三个屏幕（图 39， 40， 和 41）显示了设置视图的一些步骤。
- 在图 39 中显示的第一个区域中，点击链接以选择 ProjectArea 来设置视图。对话显示了所有可使用的 Project Areas。
- 选择 Havannah 然后点击 OK。
- 因为这是 Prasad 第一次使用该视图，所有的工作都在他的收件箱中。根据指示，点击链接以接受工作。
工作然后就移到 Current Work 面板中。
图 39. 设置 MyWork 视图
注意到目前的工作面板（图 40 ）显示工作是“Imprecisely Planned” ，现在它是以小时估计并分配给每个人的。
图 40 . 接受被分配的工作
- 在本视图下，您可以使用鼠标指针来拖拉项目（或使用 Alt + 向上或向下的游标），来为工作项目设置一个命令 （Jazz 将会记忆这些指令）。
以那种方式，除了随机的一些任务， My Work 的视图将会显示出，队员们准备完成的指令中的工作。同样的，当在 Planned Time 下 Iteration Plan’s Group 浏览作品时，未来工作的时间线，将会被全体用户所看到。
图 41 显示了观察已分配工作的两种方式：
- 在 Work Items 文件夹下，打开 Shared Queries 和 Predefined 文件夹然后双击Open assigned to me查询，这将会打开图 41 显示的查询视图。
- 同样的，在 Sprint Backlog 视图下，您可以通过右边面板中的下拉菜单，来改变 Group 为 Group by Owner。这将显示出，与每一个用户相联系的 Stories，当一个 Story 被展开时，它将显示出与该 Story 相联系的用户任务。
不管是从 Query 视图还是 My Work 视图（见图42）。
图 42. 处理一项任务
队员们应开始完成任务、报告所花时间并解决它们。 Scrum 方法注重已完成的工作，而不是刚开始的工作，在移到下一个项目之前，就开始并完成一个工作是更好的 。这使他们很快地完成 Stories，并将它们移到 “Ready for Sprint Review” 状态。为了帮助队员们追踪他们的历史，并成功的完成评估任务，花费的时间应记录在每天人们完成任务之下 （见图 43 ）。 Time Spent 是一个简单的文本区域，如果完成一项任务花费了很多天，每一个队员每天都要更新 Time Spent 区域，以包含前面内容及额外的时间。
图 43. 记录花费的时间
使用讨论专题，来记录进程或获取关于任务的信息。任何一名队员都可以在该区域更新信息，并且它是获取工作历史记录的不错的方法。
Story 进程也应通过开始处理它而被追踪。通常，没有专门的队员，来将 Story 作为一个整体负责。因此，位于 Story 之下的任务被完成，在 Daily Scrum 会议期间，ScrumMaster 可设置 Story 为 “Ready for Sprint Review” （见图 44）。 这个 Story 状态报告见于 Project Area Dashboard。
图 44. 准备就绪用于 Sprint 评审的场景
一种早点准备 Daily Scrum 会议的方式，是使用 Recently Modified 查询，来鉴别在过去最近几天被更新的任务（图 45）。 标为 “最近”的小时数，是作为一个查询论据而可设置的，其默认值是 12 小时。
图 45. 进行 Recently Modified 查询
这个表将很快显示，什么人最近正在干什么。它可以帮助看出，谁最近没有报告任何进展 （注意 Rose's 的名字并没有出现在列表中。）
团队使用 Sprint Burndown Report ，来观察工作的进展情况。团队每天都使用该报告 ，因为它为以下问题提供了一个快速的答案 “我们是不是正在完成我们要做的工作？”因为工作一旦完成 ，线就逼近于零（剩余的工作）。完成率应该在任何时候，都能被所有队员方便的看到 。
- 通过在 Team Artifacts 视图下打开 Reports 节点进入 Sprint Burndown Report，然后打开Shared Reports and Work Items 文件夹。
- 双击 Burndown Report。（因为 Burndown Report 与图 46 中的相似，您必须通过不同队员更新并记录，完成的工作时间。）
注意：
您可以向您的文件夹添加报告，例如 Burndown Report 及 查询，例如“向我打开分配的工作”与“最近修改的”， 通过在它们上面右击并选择 Add to Favorites 下拉菜单项进行添加。该操作将使它们更加容易被访问。
 |
|
安排 Iteration Retrospective 会议的时间表
Scrum 过程重要的一部分，是 Sprint Review会议。会议的第一部分是向投资者进行展示。Rational Team Concert 可能不是它的一部分，因为重点是展示运行的软件而非任务的列表。但是，从会议中得到的回馈及评论，应该被记录，既不是在 Iteration’s Overview 篇也不是作为该篇的附属物。
Sprint Review 会议的另一部分是 Iteration Retrospective （有时也称作 Reflection）。这对团队来说，是一个讨论什么进展顺利，什么受挫，以及他们准备去做什么的良好机会。Scrum Process 模板定义了 Retrospective 工作项目类别 （图 47 ），它们被用于确保回顾的进行，并评估了团队的评论及计划。
图 47. 分析一个 Retrospective Work 项目类别
一个良好的 Scrum 团队的生命周期，带有成功的节奏感 。规划一些，工作一些，传递，并重复。当到了开始下一个迭代的时候，使用同样的方法，为 Sprint 1 创建一个迭代计划以创建 Sprint 2 ，然后开始为了规划，将 Product Backlog 项目移到它里面 。
如果一个 Story 没有在当前的迭代内完成，将它拖到新的 Sprint 中（参见注意）：
- 通过点击 Sprint 2 Backlog，并将其拖至屏幕的下部，您可以一次形成两个方案。
- 然后拖到 Story，从一个到另一个。
注意：
您必须为它的子计划，将其拖至新的迭代中，或者您可以一次选择所有的项目。仅仅再分配 Story，将不会移动它的子计划或自任务。
图 48. 规划下一个迭代
重要点：
Story 左边的星号，意为所做的变化尚未保存。在 Sprint 1 窗口中，指向灰色复制件左边的灰色箭头，意为该项等待被移动。当您点击 Save 时，将完成移动操作。
尽管您已为迭代创建了日期， Rational Team Concert 不会自动从当前的迭代转向下一个迭代，因为时间在前进。您必须手动调整。现在考虑哪一个迭代：
- 打开 Havannah 项目。
- 在 Process Description 章，点击 Sprint 2（当前的 Sprint），然后点击带蓝色三角箭头的按钮，以将当前的设计器转向新的 Sprint。
Rational Team Concert Web 用户界面
不是每个队员都想安装一个 Eclipse-based 客户端。大多数 Rational Team Concert 功件，都可以通过网络用户界面得到。有一些功件， 例如 Project Area Dashboard，是网络用户界面所独有的。 Dashboards 可以被用户定做，它们存在微小的设置差异，取决于安装的过程模板。 图 50 显示了 Havannah project 的 Scrum Dashboard （公布版本的显示界面可能不一样）。
图 50. Scrum Dashboard
本界面应用了许多的 Web 2.0 技术，类似与当您把鼠标移到Sprint 栏以上时，您将得到进程报告一样 。如果您的鼠标移到底部的一个查询上时，一个相似的弹出视窗，至少显示了部分的查询结果。因为这是 Scrum Dashboard， 公开的妨碍列表显示在中间以及页面的首部。
什么正在丢失？当然是 Scrum 完成图（作为 RC5， 有一个带完成图的Trends Tab ，与 Iteration 报告的 Story Points 一起，但是图 51 中的例子， 同样解释了怎样去定制显示界面。），这是一个关键的产品，并且是工作进展如何的一个重要指示剂，添加它是很容易的。
- 点击首部的位于 General 旁的 downward arrow（图 51 ）。
- 选择Add Viewlet。添加的 Viewlet 控制面板将在页首打开（图 51）。
- 滚动到 Viewlets 表的下部，打开 Trend Reports 和 Work Items 文件夹，然后选择Burndown（图 52）。 右边的面板显示了，被选中时 Viewlet 的描述。
- 点击 Add Viewlet，然后在显示界面上，添加 Burndown Report（图 53 ）。
图 53. Dashboard 中的 Burndown Report
目前您在显示界面的顶部，已有两种最重要的产品。搜索 Reports 条，将打开其他一些有趣的值得添加的报告，但是这已经足够保持监控了。如果使用 Rational Team Concert 和 Jazz ，您正在寻找支持项目的其他方面的方法，您可以向显示界面添加 Build Health 和 Code Coverage以及 TestFailure报告。希望队员们将这个页面设为浏览器的主页是不现实的。
显示界面的 Summary 项目，也包含了对详细细节的链接。在靠近底部处点击 Recently Modified 查询链接 （图 54 ）， 将移到 Work Items tab 并显示查询的全部结果。
图54. 查看最近修改后查询的结果
在 Daily Scrum 之前，这可能对概述有用， 对于刚刚休假归来，以及要快速赶上商业旅程的一些人来说，也是一种很有效的方式。同时注意，通过使用左栏顶部的链接，从 Work Items 项可创建工作项。因此，所有能访问您的 Project Area 的人，可以轻易的添加 Defects 、User Stories 或者 Enhancement Requests 。
队员们也可以从本视图中，更新他们的进程，并向他们的工作项添加评论。 在 Work Item 上点击，以打开浏览它的信息（参见图 55）。
图 55. 查看一个 Work Item
Iteration Plans 项提供一个不同的视角，它将重点放在Stories 和 队员上：点击 Iteration Plans > Sprint Backlog > Planned Items > Group By Owner。
在官方公布的 Rational Team Concert 中，您可以为团队成员们显示 Progress 栏，或者 [work] Load 栏（图 56 ）。
图 56. 查看迭代计划
尽管已经学习了本文，但是您要了解，与基于 Scrum 的 敏捷计划相比，在 Rational Team Concert 和 Jazz 中的知识是如此之多，而且与这里介绍的相比，敏捷计划又有更多的知识点。例如，考虑使用源控制，以及 Jazz 构建引擎，来提高您的持续开发效率。对不是开发员的队员来说，可以为了检测工作项目和项目状态，而向公司引进网络用户界面。那样，您的老板将认识并享受于网络显示界面。试着用不同的报告，来检查哪一种适合您的团队来管理进程。
当走进这个宝库，四处观望时，您可能一次又一次被震惊。
要感谢的人是如此之多，以至于不知道该感谢谁，Mountain Goat 软件的 Mike Cohn，以及在 2002 年一同创立 Scrum Alliance 的 Ken Schwaber，对 Jazz.net 的 Scrum 章节做出了很大的贡献，还有在此之前 Jeff Sutherland 和 Ken Schwaber 也为本文做了大量工作。 衷心感谢 Erich Gamma，Dirk Baeumer 和 Scott Malabarba 阅读并提出了对本文有益的建议。
此文由scrum中文网翻译，转载请注明
