IBM RTC 是一个软件协作交付环境，它包含了计划制定及管理，工作项集成管理，代码版本控制管理，以及构建管理等诸多功能，这些功能使得Jazz环境的协作能力非常强大。在RTC中，用户可以通过工作项对工作内容进行信息更新和任务分配，借助工作项和人员之间的联系方便地进行信息的交流和展示，并可以从不同的层面和角度了解整个Team的工作进行情况。
当软件开发团队开始使用一个刚创建的RTC项目来支持软件开发活动时，需要对该RTC项目作一些基础设置，以使RTC项目适应团队需要，下面就对这些基础设置作简要的说明：
角色定义了一个团队中成员的不同职责，并决定了团队成员在RTC项目区域中所具有的的权限。
每个项目区域(Project Area)和每个团队区域(Team Area)都有角色的设置。这两层的角色权限设置是相互独立的。可以通过两层的角色权限设置实现复杂的权限控制。
以Scrum模板为例，该模板提供了如下几种预定义的角色，项目管理员可以根据需要添加自定义的角色。
▲图1.RTC的角色设置
通过对项目权限的设置，使得不同角色拥有不同水平的权限，规定了角色可以做和禁止的操作，对角色功能做了很好的区分
在项目中，可以对某些操作的前置条件(Preconditions)或者跟进操作(Follow-up actions)进行设置：
例如，我们可以设置所有人在执行Deliver操作之前，必须要有相关的工作项和注释。这样可以使每次的Deliver都有确切的根据和记录。
RTC具有计划制定和管理以及强大的工作项管理的功能，可以很好的实现项目管理支持。下面介绍RTC在项目管理方面的应用。
RTC的Product Backlog是一种特殊类型的Plan，可以将它视作一个需求池，它在产品开发的初期生成，以列表形式描述用户的需求，作为产品的待办事项，并在开发过程中不断更新完善。由Product owner负责管理。
项目经理可以根据时间线划分，制定Release Level和Iteration Level的开发计划。开发计划可以明确该阶段的工作目标。可以从Backlog中将需求拖拽到Plan中，作为这一阶段的开发目标。项目成员可以方便的在Plan视图下查看该阶段的工作项状态。
工作项用来描述某一项具体任务，根据粒度的不同，可以划分为Epic，Story，Task这些不同层级的工作项。Epic是位于顶层的工作项，它描述某个大的方面的工作。Story则描述一个具体的事务性的可追踪工作，Task则细化到daily的工作任务，可以直接由完成与否来衡量。工作项的owner确保工作项的执行，可以添加工作项的subscriber，使得工作项有任何的状态更新都会通知subscriber列表中的项目成员。各个工作项可以建立联系，例如父子关系，验证关系等等，通过这些关联关系，我们能从整体上把握目前的工作状态以及工作之间的依赖关系，从而更好地发现对工作进度造成影响的问题并有效解决问题。
我们从以下几个方面来介绍RTC的代码管理和版本控制功能。首先当我们要使用RTC管理Source Code时候，应明确如何将Source Code划分为不同的Component存放，并根据具体的开发，测试，构建需求划分Stream。在开发人员进行开发活动，并将自己的对当前代码的变更上传至服务器时，需要理解RTC进行代码变更的工作模式并正确操作。3.2.2节介绍了RTC代码管理的三重工作空间模式，3.2.3节则介绍了如何理解视图中变更集的标记意义并执行相应的操作。在这一小节最后将介绍RTC强大的代码历史记录功能：基线和快照，可以方便地对代码历史进行追溯和恢复。
Stream可以视作某个版本的代码集合，一般情况下，我们要为当前release建立一个主开发Stream。我们可以借助RTC的快照和Flow Target功能方便的复制一个stream的当前状态成为另一个Stream，使其成为主开发team的一个分支。出于对构建(Build)的需求，我们还可以建立一个集成stream，用来将开发stream中的内容作一些整合，用来进行构建。
当代码按我们划分好的stream和component存放于RTC的工作空间时，我们就可以在RTC的代码管理和版本控制功能支持下进行协作式的代码开发活动了。下面将介绍RTC代码管理的三重工作空间模式。
RTC的代码存在于三重相互关联的工作空间，如图所示：
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！