IBM Rational Team Concert（RTC）作为软件协同开发工具，被逐渐应用在大型项目的生产过程中，维系着规模庞大的项目组织团队，有条不紊地管理每一项开发任务，从而为创造高质量的软件产品打下坚实基础。
RTC 提供了贯穿整个">开发过程的集成环境，包括：需求定义、迭代计划、源码控制、自动构建、缺陷跟踪、变更管理以及统计报表等功能。本文将通过三个层次，自下而上地详细阐述如何使用 RTC 跟踪和管理项目的开发任务。首先，介绍 scrum 方法中不同种类工作项的功能和特征，帮助项目中各个角色的成员建立与之对应的工作项类型。然后，介绍如何通过检索和查询，从海量的工作项中快速准确地定位特定的工作项，获取个人和团队的工作项内容。最后，介绍 RTC 中报表和仪表板的使用，统计汇总项目中的工作项，展现项目的整体状态，以及预测未来的进展趋势。
开发活动的基石——工作项
工作项（Work items）是 RTC 中进行项目开发和管理的基本单位，用于记录开发任务，关联开发成果，管理开发进度，实现协同工作。为了满足不同的软件项目开发过程，RTC 中内置了多种软件开发过程模板，每种模板的工作项设置也不尽相同。本节以敏捷开发中的 Scrum 开发管理方法为例，介绍 RTC 中常用的工作项内容和结构特征。
Scrum 是一种灵活的软件项目管理方法，它通过一系列的迭代，增量实现软件产品的功能。为了有效管理迭代中的开发任务，RTC Scrum 方法模板中常用的预置工作项包括：史诗（Epic），用户故事（Story）、任务（Task）、缺陷（Defect）。它们的关系通常可以用图 1 表示。
图 1. Scrum 方法模板工作项关系图
Epic：通常指的是项目整体目标。这类需求由决策管理层提出，作为软件项目的总体战略规划。其描述比较简洁，仅从高层次指定项目的方向，并未阐明如何实现及具体要求。例如，图 2 举例说明如何用 Epic 表示一个项目的整体要求。
图 2. 目中的 Epic 实例
图 2 大图
在图 2 中，Epic 的摘要为"客户需要使用办公自动化系统（OA）"。并在描述栏里贴出相关文档的链接地址。Epic 的主要服务对象为项目干系人（stakeholder），因此并不会直接包含需求的细节信息，而是将其作为子任务，关联在下一级参数中（Children）。项目干系人可以借助此工作项的状态和进度显示，了解项目的总体工作量以及进展程度。
Story：为了实现 Epic 中的总体目标，需要把整个需求进一步细化为可以实现的一系列具体需求。业务分析师（Business Analysis）将这些可以实现和测试的需求记录在用户故事（Story）中。根据 Scrum 开发方法要求，每个用户故事应当保证在一次迭代（Sprint）中完成，以便使每个迭代开发的成果可以向客户演示。
图 3. 用户故事实例
图 3 大图
图 3 为实现 Epic 的一个用户故事实例，名为"实现系统中共享文档的功能"。故事点数（Story Point）用于度量其规模和复杂程度，由团队成员共同评估得出，表示不同用户故事之间相对工作量的比较。计划（Planned For）指定用户故事将要在哪一次迭代开发中实现。接受规则（Acceptance）则约定该用户故事开发工作完成之后的验收标准。业务分析师在开发任务结束之后根据接受规则验证开发成果，并将这个成果在迭代完成后演示给最终客户。