本文通过对如何在 Rational Team Concert 2.0（RTC 2.0）为任务的协同处理提供了强大的功能，无论是开发人员，测试人员或者产品经理都可以通过 RTC2.0 提供的 Scrum 对象，视图等方便的处理任务，监督产品计划的进展和健康度，实现协同工作。

一个 Scrum 项目的顺利进展，离不开产品中不同角色的协同工作，RTC2.0 为任务的协同处理提供了强大的功能，无论是开发人员，测试人员或者产品经理都可以通过 RTC2.0 提供的 Scrum 对象，视图等方便的处理任务，监督产品计划的进展和健康度。

User Story 在一个 Sprint 中的生命周期

在前面的文章中，我们已经规划好 Sprint Plan 并了解应该如何创建 User Story 和 Task。接下来，各个 Team 按照规划好的任务进行开发和测试。

在实际的产品研发阶段， User Story 根据不同的角色和需求主要分为以下几个类别：

• Feature story –这种 User Story 主要从产品的功能角度划分，需要开发和测试人员协同工作完成开发和测试任务。
• Engineering story –一般来讲，这是一个只针对开发角色的 Story 种类，开发人员将一些不需要测试人员参与，但是又必不可少的开发工作创建为这种 Story。
• FVT story –这是一种和 Engineering Story 恰恰相反的 Story，一般只由测试人员参与，例如一些 Automation 和测试用例管理的任务。
• GVT story –相对于普通的 FVT（功能测试）测试来说，一般产品也会有特殊的专门针对 Globalization 的测试任务，即为 GVT User Story。
• Documentation story –文档类的 Story 例如产品的帮助文档，用户手册，Release Notes 等都属于 Documentation Story 的范畴。

对于不同种类的 User Story 来说 , 其生命周期也不尽相同。

以 Feature Story 为例，它的生命周期包含了由 New,In Process, Implemented, Done, Deferred 等几种状态。当开发人员开始工作，则将 User Story 置为 In Process，一旦开发工作完成，则设置为 Implemented，如果所有 Acceptance Test 通过，则测试人员将 User Story 设置为 Done，如果不能在规定的 Sprint 内完成，则置为 Deferred，延迟到下一个 Sprint 继续工作。在 User Story 完成后，如果发现新的问题，可以 Reopen，这时 Story 将回到 In Process 状态。

以 UserStory 为核心展开测试

在一个典型的 Agile 产品研发阶段，一个 Feature Story 是最为常见的 User Story 种类。当开发人员创建一个 Feature Story 时，将详细阐述这个 Story 主要实现的产品功能，对于测试人员来说，除了和开发人员对这一功能达成共识，另一个重要的任务就是对这个功能展开测试。因此，测试人员将在 Feature Story 创建完毕后，根据具体功能给出详尽的 Acceptance Test 内容。

Acceptance Test 是针对一个 Feature Story 具体的功能而展开的基本测试，它不应超越该 story 包含的功能。在一个 Sprint 结束时，所有 Acceptance Test 产生的 Defect 都必须被修复，否则这个 User Story 不能被认定为完成。换言之，所有 Acceptance Test 的标准和条目必须完全通过才能标志着一个 User Story 的结束。Acceptance Test 可以添加在 User Story 的 Acceptance Tab 下。

在 Sprint Plan 会议上，开发和测试人员可以共同指定 Acceptance Test 的标准和涵盖范围。以下面的一个 Jack 在 Sprint 1 创建的 User Story 为例：

那么 Acceptance Test 应该包含以下内容：

1. 查找单个单词
2. 查找多个单词并以空格分开
3. 输入除英文外的其他字符，如中文，日文
4. 不输入任何字符，直接点击 Search

但不应包括对应的 User Story 没有涉及的功能，如查找文件名等。

当 Acceptance 创建完毕后，这个 User Story 的开发由 Calvin 负责 (Owner)，而测试工作由 Simon 负责。于是 Simon 在这个 User Story 下创建了一个子 Task，用来记录测试工作，而 Calvin 则建立了一个子 Task 用来记录开发进展：

而一个 QA 任务只有在开发人员将 User Story 的状态置为“Implemented”后才可以正式开始，这表明开发人员已经完成了开发任务，该功能可以进入测试阶段。

除了 Acceptance Test，还可在 QA 的 Task 中适当添加 Additional Test。Additional Test 主要包含边界测试，安全性测试，负面测试等。虽然负面测试测试系统是否不执行它不应该完成的操作，但是可以检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束，系统是否处理了用户的异常操作以及检查系统的错误提示是否清晰且充分。这些对于一个产品的健壮性和用户易用性来讲也是十分重要的。

此外 ,Simon 在 QA Task 中预测工作量，并在每天测试工作结束后，更新 Time Remaining 和测试结果。当测完一项 Acceptance Test 或 Additional Test 时，应在该项后面注明测试结果，例如 Pass 和 Fail：

当所有测试工作结束后，如果所有 Acceptance Test 中的测试项都通过，测试人员应该首先关闭 QA 的 task，然后将 User Story 的状态设置为 Done，标志这个 User Story 正式结束。

除了以上所述和 User Story 相关的 Task，还有一部分 Task 有可能不和任何 User Story 相关联。例如，在一个 Sprint 中，测试人员要进行 Automation 的开发和执行，测试用例的添加和整理，以及 Regression Test。这些任务也是很大的工作量，需要事先规划和追踪状态。这时，创建一个独立的 Task 并将其归类在不同的 Folder 下将是一个合理的选择。

3. 如何处理 Defect

如果测试人员在测试过程中发现问题时，应及时的创建 Defect。一般来说，根据 Defect 的种类将其创建在 RTC 里或是其他缺陷管理跟踪系统中，具体如下：

• 如果发现的 Defect 是和当前 Sprint 的 User Story 中 Acceptance Test 相关联的，则应在 User Story 下创建 Defect，当一个 Sprint 结束时，这类 Defect 必须完全被修改完毕并验证，否则该 User Story 不能被认为完成：

当 Simon 创建 Defect 时，他注明了缺陷严重程度，负责的开发人员（Calvin），优先级，所属 Sprint，并给出详细的重现步骤，这样有助于开发人员及时的收到通知邮件并定位问题：

如果有必要，可以在 Links 下添加截屏和 log 文件等附件。

当开发人员定位并 Fix 该 Defect 后，将 Defect 的状态设置为 Resolved，如果中间有无法重现或者需要更多详细信息的情况，可以通过 Discussion 域来和测试人员沟通：

而测试人员则经过又一轮的测试来 Verify 这个 Defect，或者 Verify 成功，关闭 Defect; 或者问题依旧存在，将 Defect 的状态设置为 Reopen，返回给开发人员。

• 如果发现的 Defect 是和当前 Sprint 的 User Story 中 Additional Test 相关联的，则应在 User Story 下创建 Defect，当一个 Sprint 结束时，这类 Defect 不作为该 User Story 在一个 Sprint 结束时是否完成的标准，创建和处理过程同上。
• 如果 Defect 不和当前 Sprint 的任何一个 User Story 相关联，属于 Regression Defect 或者之前 Sprint 的 Feature 产生的问题，则应在其他缺陷管理和跟踪工具如 IBM 的 Clear Quest 中创建该 Defect。

4. 项目追踪并报告进度

从 User Story 和 Task 的创建到完成，Team member 应每天更新分配给自己的任务的状态、并报告已花时间及预期结束时间。Team Leader 或 Scrum Master 应每天检查各项任务的进展情况，从而了解整个项目的最新状态 .

例如，各类 Task 的 Owner, 无论是开发人员还是测试人员 , 都要每天实时更新 Time Remaining 域 , 当任务没有开始时 ,Time Remaining 应等于 Estimate 时间 , 随着任务的开展 ,Time Remaining 逐渐减少 , 直至任务结束时减至 0。时间可以简单的用 1w 2d 3h 4m 来分别代表周，日，小时和分钟。默认以小时为单位。

用户还可以在 Current Work 视图中，通过选取菜单“Show Work Time”查看自己当前任务的工作时间统计。

在一个 Sprint 结束时，由于变化以及各种原因，并不总会恰好完成了所有的 User Story 和 Task。我们需要在下一个 Sprint 开始之前，做一下 Review，来决定未完成的 User Story 和 Task 需要做什么处理。

在 RTC2.0 中，user story 和 task 都可以随意指定到任何一个 Sprint 中去，我们只要修改”Planned For”属性到希望的 Sprint 并保存即可。这一步仅仅完成了 RTC2.0 工具中的计划改变。在实际项目中，我们还需要总结这些 User Story 和 Task 为什么会没有完成，它们的推迟会不会影响后面的计划，甚至整个产品的完成。

结束语

RTC 2.0 是一个非常有效的 Agile 项目管理工具。它内置的过程模板支持数个 Agile 方法，其中也包括 Scrum。

Scrum 作为一种 Agile 软件开发模型，近年来很受关注。Scrum 假设开发软件无法一开始就能定义软件产品的最终形态，需要在开发过程中不断地尝试、改变。在 Scrum 方法中开发团队具有高度的自主权，需要紧密的沟通合作，确保每天、每个阶段都能有新的进展。开发团队需要每天用 15 分钟开会，检查进度和计划，了解困难并安排解决方案。它是一个典型的迭代开发模型。

Scrum 的定义并不复杂，而到了具体的项目实施中，如何真正的去实现它们却没有非常明确细致的指导。每个项目都有各自不同的需求和具体情况，究竟该如何实现 Scrum，RTC2.0 在这个方面会提供非常灵活和全面的支持。这也意味着如何使用 RTC2.0 没有一定之规，只有使用者能够进行有效的沟通，对于如何进行 Scrum 开发有着高度的共识，才能充分的利用 RTC2.0 去帮助团队进行更加有效的支持和管理。毕竟如同 Scrum 一样，RTC2.0 只是一个工具，如何使用好这个工具，还要看团队对 Scrum 和 RTC2.0 的理解。

这一系列 RTC2.0 项目实战的文章，介绍了 RTC2.0，以及在具体的项目中，RTC2.0 是如何在一个 Scrum 开发模型中得到应用的。本文以及本系列文章的目的，是为那些计划使用 RTC2.0 来进行 Agile 开发管理的用户提供一个从安装配置到项目应用，相对完整的视图，希望能够帮助用户很快的进入到 RTC2.0 的使用中去。

免责声明

本文包含解决方案。IBM 授予您（“被许可方”）使用这个解决方案的非专有的、版权免费的许可证。然而，解决方案是以“按现状”的基础提供的，不附有任何形式的（不论是明示的，还是默示的）保证，包括对适销性、适用于某特定用途或非侵权性的默示保证。IBM 及其许可方不对被许可方使用该软件所导致的任何损失负责。任何情况下，无论损失是如何发生的，也不管责任条款怎样，IBM 或其许可方都不对由使用该软件或不能使用该软件所引起的收入的减少、利润的损失或数据的丢失，或者直接的、间接的、特殊的、由此产生的、附带的损失或惩罚性的损失赔偿负责，即使 IBM 已经被明确告知此类损害的可能性，也是如此。

参考资料

• 访问 developerWorks 中国网站的 Jazz 技术空间，这里汇集了丰富的 Jazz 平台中文技术资源。您可以通过这里了解更多关于 Jazz 平台和 Jazz 技术发展趋势的最新信息。
• 访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
• 阅读 Rational Edge 中文版，获取软件开发领域的最佳实践。
• 订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
• 学习 Hello World 系列教程，这是学习 IBM 软件工具的快速通道。在每一篇教程中，都会有快速入门产品演示动画。您可以通过其中的动画演示快速浏览如何使用 IBM 软件完成开发任务。
  　

• 访问 Rational Team Concert 产品专题，了解 Rational Team Concert 产品家族的产品特性，并下载 RTC 的免费版和试用版。
• 下载 Rational Team Concert Express Edition （易捷版） 的免费试用版，体验面向部门级开发团队和中等规模开发团队的全新协作软件交付平台。
• 下载 Rational Team Concert Standard Edition （标准版） 的免费试用版，体验面向企业级和大型开发团队的全新协作软件交付平台。
• 免费版的 RTC 2.0 的 Express-C 版本可以在 Jazz.net 站点下载，注册 Jazz.net 用户后，登录访问下面链接即可下载：RTC 2.0 Express-C。
• 获取免费的 Rational 软件工具包系列，了解最新的 IBM Rational 软件开发工具技术文档和资源。
• 下载免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。
• 获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

• 访问 Jazz.net 上的 Jazz 社区。并注册成为 Jazz.net 用户，您可以随时了解 Jazz 项目开发的最新进展，获取免费的 Jazz 平台软件及相关试用版软件下载。
• 参加 Rational 大学，与 IBM Rational 专家一起分享 Rational 产品最佳实践。
• 查看 developerWorks 博客 并加入 developerWorks 社区。