我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。
——伍德罗·威尔逊，美国第28任总统（1865—1924）

只要是具备一定规模的项目，就必然需要一个团队。靠单打独斗在自家车库里面开发出一个完整产品的时代早已不再。然而，在团队中工作与单兵作战，二者是完全不同的。任何一个人的行为都会对团队以及整个项目的生产效率和进度产生影响。

项目的成功与否，依赖于团队中的成员如何一起有效地工作，如何互动，如何管理他们的活动。全体成员的行动必须要与项目相关，反过来每个人的行为又会影响项目的环境。

高效的协作是敏捷开发的基石，面对面的会议是最有效的沟通的方式。每日例会（Daily Scrum）是最早引入并被极限编程所强调的一个实践。它是将团队召集起来，并让每个人了解当前项目进展状况的一种会议。它是一个快速的会议，每个参与者只能被给予很少的发言时间（大约两分钟）来介绍自己的项目进展概要。为了保证会议议题不会发散，每个人都应该只回答三个问题：

• 昨天有什么收获？
• 今天计划要做哪些工作？
• 面临着哪些障碍？

Daily Scrum 有诸多好处：

• 让大家尽快投入到一天的工作中来。
• 如果某个开发人员在某一点上有问题，他可以趁此机会将问题公开，并积极寻求帮助。
• 帮助团队带头人或管理层了解哪些领域需要更多的帮助，并重新分配人手。
• 让团队成员知道项目其他部分的进展情况。
• 帮助团队识别是否在某些东西上有重复劳动而耗费了精力，或者是不是某个问题有人已有现成的解决方案。
• 通过促进代码和思路的共享，来提升开发速度。
• 鼓励向前的动力：开到别人报告的进度都在前进，会对彼此形成激励。

总之，Daily Scrum 能帮助所有的团队成员全心投入到项目中，并且一起向着正确的方向努力。IBM® Rational® Team Concert （RTC）对于团队来说，已经被证明是一种在软件开发过程中进行协作的高效方式。RTC 实现了源代码管理与工作项管理的完美集成。它能够帮助进行敏捷计划、并生成报告，方便管理工作项，并且它还提供了一种有效的框架来支持每日例会（Daily Scrum）。下面，本文将介绍三种使用 RTC 进行 Daily Scrum 的方式。

在 RTC 里使用默认的 sprint backlog 进行 Daily Scrum

双击打开项目当前所处于的 sprint backlog（sprint 是 scrum 中的术语，指敏捷开发周期中的一个迭代计划），如图 1 所示，在窗口底部选择“Planned Item”标签，在窗口右侧选中 Schedule Risk 单选按钮，窗口将呈现将列出当前 sprint 中的所有工作任务项 story 和 task。在进行 Daily Scrum 时，团队成员可以根据这个窗口，逐一更新这些任务的状态。

用户可以展开任务项来显示其各个子任务，了解子任务是由谁负责，进展等详细信息。如图 2 所示。

这种召开 daily scrum 的方式非常简便。它能够展示整个项目的进展和最近的变化，但是任务项不是按照团队成员分组的，不太适应于了解各个团队成员状态。为了解决这个问题，本文下一章介绍另一种用 RTC 进行 daily scrum 的方式。

在 RTC 里定制 sprint backlog 进行 Daily Scrum

定制的 sprint backlog 又称为“开发者任务一览表”。一览表按照团队成员展示任务，每一行表示一个正被开发的任务。任务显示在第一列，其余几列显示其子任务的开发状态：ToDo（将要做），In Progress（正在做）和 Done（完成）。并且，各任务根据其当前状态，分别用不同的颜色显示，一目了然。定制 sprint backlog 的具体步骤如下：

1. 打开项目所在的当前 sprint backlog，点击 Copy 拷贝这个计划的模式。如图 3 所示：

2. 修改某些选项的值。比如修改定制 sprint backlog 的名字为“Developer's Taskboard”，风格选择“Taskboard”，分组选择“Owner”，排序选择“Creation Date”，进度条选择“Progress”。如图 4 所示：

3. 修改视图的布局。从窗口底部选择“View Layout”标签，从左侧列表中选择“Effort Tracking”和“Owner”到右侧列表。如图 5 所示：

4. 为 sprint backlog 添加色彩。从窗口底部选择“Colorize”标签，根据自己的需要添加、修改、删除各种颜色。如图 6 所示：

5. 保存所做的修改，用户将得到自己专属的 sprint backlog。显示的效果如图 7 所示：

当工作任务项不是很多的时候，这种方式非常适合进行 daily scrum。但是，如果当迭代计划中的工作任务项很多时，这种方式就不再适合了。为了解决这个问题，下一章将介绍最后一种用 RTC 进行 daily scrum 的方式。

在 RTC 里创建自定义的查询进行 Daily Scrum

一般在进行 daily scrum 时，项目管理者需要查询出最近正在被修改的任务，这包括状态是“New”和“In progress”的任务。创建这种自定义的查询具体步骤如下：

1. 在“Work Items”下的“My Queries”上点击鼠标右键，选择“New Query…”，如图 8 所示：

在打开的窗口中点击“start from scratch”，如图 9 所示：

2. 在打开的窗口底部选择“Conditions”标签，在窗口右上角点击加号，选择“Add Conditions…”添加查询条件，如图 10 所示：

根据需要选择一些查询条件，为这个查询取一个名字，保存。如图 11 所示：

3. 共享刚刚创建的这个查询，供每个团队成员使用。如图 12 所示，在窗口底部选择“Details”标签，在窗口右上角点击“Share”，选择“Team or Project Area…”。

在弹出的窗口中选择共享这个查询给哪个团队，如图 13 所示，然后点击 OK，保存。

4. 根据需要定制查询结果的布局，包括选择显示哪些列，按照哪些列排序等，如图 14 所示：

5. 显示查询结果。如果按照上述配置，查询结果将在“Work Items”标签下显示，如图 15 所示：

这种召开 daily scrum 的方式能够列出在最后一天工作任务项的变化，以及哪些工作任务项还没有完成。但是它们都是以列表的方式显示出来，界面友好性和可读性不是很好。

结束语

本文介绍了 daily scrum 在团队项目开发中的重要性，以及三种用 IBM Rational Team Concert 进行 daily scrum 的方式：默认的 sprint backlog，定制 sprint backlog，和创建自定义查询。这三种方式各有其优缺点:

1. 当团队人员比较少，一般小于 5 人，并且只是关注当前 sprint task 时，比较适合采用第一种方式进行 daily scrum。使用它可以清楚的看到 Task 与 User Story 之间的层次关系，以及 User Story 的开发进度。
2. 当团队人员比较多，规模比较大，有自定义的 RTC Task 或者有子 Scrum Team 时，比较适合采用第二种方式进行 daily scrum。使用它与第一种方式一样，也是只关注当前 sprint task，但它还可以按照自定义的方式分组显示，更清楚的了解每个团队成员的 task 状态。
3. 当希望关注团队中所有 Task，而不仅仅是当前 sprint task 时，前两种方式都无法满足 sprint plan 的显示需求，可以考虑使用第三种方式自定义创建查询，进行 daily scrum。与前两种方式相比，它更加灵活，建立查询的条件非常丰富，可以根据需要创建多个查询同时使用。

请用户根据自己的需要选择不同的方式进行 daily scrum，进行高效的团队项目开发。

1 介绍 Rational Team Concert

Rational Team Concert 是建立在 Jazz 技术平台上，支持若干种 Agile 开发模型。Jazz 技术平台使软件开发更加灵活，支持团队成员分布在不同地理位置，提供从小型团队到大型企业的可扩展的软件开发解决方案。Rational Team Concert，有时简称 RTC，具有如下特性 :

• 贯穿整个软件开发生命周期的协作和集成

使用 Rational Team Concert，在软件开发中，能够实现信息的交换和信息集成，如果某个需求变化了，团队成员就会自动收到通知，团队成员也可以通过多种方式了解这种变化。Rational Team Concert 中的各种视图可以让你更详细地了解信息，跟进团队的开发进度和活动。

• 流程配置和定制

Rational Team Concert 使开发团队能够轻松和有效地执行和定制流程，这个流程是角色、实践活动、规则、权限的集合。

• 变更管理

Rational Team Concert 中，变更管理的主要特点是用工作项跟踪和协调各种任务，这些任务包括故事（story）、缺陷（defect）、计划项（plan item）、以及普通任务（task）等。工作项和工作流程是灵活可定制的，工作项也可以与其他的变更管理系统进行整合和集成。

• 计划

Rational Team Concert 中提供了工具来保证计划管理能力，对于项目团队，这些工具能够计划、跟踪、平衡项目的工作量，以反映团队的实际状态。对于 Scrum，可以创建和管理迭代计划。

• 软件配置管理

Rational Team Concert 内置的源代码控制管理系统是基于组件的和建立在 Jazz 平台上的，它支持并行和敏捷开发，支持分布在不同地理位置的团队开发，同时它紧密地集成了缺陷跟踪、构建、和以流程为中心的自动化。

• 构建自动化

对于开发和测试团队，Rational Team Concert 提供了自动地构建识别、构建控制和构建可追溯性。团队成员可以跟踪构建的进度，查看构建的警告信息和结果，提交构建请求，并跟踪构建过程。

• 仪表板和分析报告

Rational Team Concert 的报告组件能够显示项目的进展和项目状态，可以容易地分析某些可能被隐藏的趋势；软件开发过程中的可视化数据和各种分析报告，能够支持有效的决策。

• Eclipse 客户端，Visual Studio 客户端和 Web 界面

这些客户端界面为开发者提供了一个灵活的集成开发环境。

2 Rational Team Concert 与 Scrum

Rational Team Concert 是个非常优秀的 Agile 敏捷开发管理工具，内置了几个过程模板，可以用来支持一些敏捷开发方法，比如 Scrum 过程、OpenUP 过程和 Eclipse Way 过程等等。本文分享一些使用 Rational Team Concert 实现 Scrum 敏捷开发的使用经验。

Scrum 由以下几个部分组成：

• 角色（Roles）
  • 产品负责人（Product owner）
  • Scrum 负责人（Scrum master）
  • 团队成员（Team member）
• 各种仪式和会议（Ceremonies）
  • 每天 Scrum 例会（Daily Scrum meeting）
  • Sprint 计划会议（Sprint Planning meeting）
  • Sprint 评审会议（Sprint Review meeting）
  • Sprint 回顾会议（Sprint Retrospective meeting）
• 工件（Artifacts）
  • Product Backlog
  • Sprint Backlog
  • Burndown Chart
  • Impediments List

在 Scrum 中，产品功能或项目的需求会列在 Product Backlog 中。Product Backlog 是一个项目所需的所有需求或功能的优先级列表，这个列表条目常常以用户故事（user story）的形式体现。产品负责人（product owner）维护这个列表，根据项目的进展和商业环境的变化修改优先级列表。产品负责人对产品的成功负责，定义产品特性和产品发布时间表，负责确定各种功能的商业价值，不断完善和优化 Product Backlog。

Scrum 负责人（Scrum master）管理 Scrum 过程，确保 Scrum 的做法是正确的，并且让团队成员理解 Scrum 的价值，消除项目进展中遇到的障碍，并保护团队成员不受外界干扰。

在每个 Sprint 开始的时候，小组举行 Sprint Planning 会议。在 Sprint Planning 会议上，产品负责人为即将到来的 Sprint 展示最想要实现的产品功能或项目需求，让团队成员把握和分析需要实现的功能，产品负责人和团队成员在本次 Sprint 中的目标达成一致，确定未来 2 周到 4 周的工作重点。然后团队成员决定如何完成这次 Sprint 的目标，并分解成所需的任务，这些任务就组成了 Sprint Backlog 的任务列表。在 Sprint Backlog 中，每个任务按小时预估完成时间，团队成员确定是否可以按时完成开发任务，如果没有足够的时间完成某个功能，可以将该功能从当前的 Sprint Backlog 中返回到 Product Backlog。Sprint Backlog 中列出了团队成员已经承诺在本次 Sprint 期间完成的工作。根据团队经验来评估工作量，而不是由 Scrum 负责人或产品负责人决定，这是 Scrum 的一个特点。

在每个 Sprint 结束，需要召开 Sprint Review 会议，评审已经完成的工作。Sprint Review 会议是一个简短和非正式的会议，任何感兴趣的人都可以参加，并从参与者得到一些反馈。

团队成员可以举行 Sprint 回顾会议（Sprint Retrospective），分析项目的经验。通过本次 Sprint 回顾会议，不断改进团队工作方式和不断提高工作效率，为下一个 Sprint 做好准备。

Rational Team Concert 中提供了 Product Backlog 和 Sprint Backlog 的功能，它们同 Scrum 敏捷开发中的重要工件 Product Backlog 和 Sprint Backlog 一致。

在 Rational Team Concert 1.0 中，如果创建 Product Backlog，切换至 Team Artifacts 视图，并在项目区域中，选择 Release 1.0，然后选择 New > Plan。在 New Plan 窗口中，输入 Product Backlog 作为名字。选择 Product Backlog 作为 Plan Type。

在 Rational Team Concert 3.0 中，在 PlansAll plansMain DevelopmentBacklog 下，有默认的 Product Backlog。打开 Product Backlog，点击 Planned Items 项，可以为 Product Backlog 添加工作项，这些工作项的类型为 Epic 和 story，对于 Scrum，类型为 story 和 epics 的工作项，描述了 Agile 中的用户故事，包括项目需求或产品功能。

在添加所有的工作项之后，产品负责人要为工作项设置优先级，优先级属性有 High、Medium 和 Low，这可以定义实现工作项的优先级顺序。

图 2 大图

在 Rational Team Concert 中，Sprint Backlog 中包含了来自于 Product Backlog 相关的具体工作项。RTC3.0 含有默认的 Sprint，例如 Sprint1，Sprint2，并且有默认的 Sprint Backlog，对于有多个 Sprint 的项目，如果要创建新的 Sprint Backlog，首先需要创建 Sprint，然后才能为该 Sprint 创建 Sprint Backlog。打开 Sprint Backlog，在 Sprint Backlog 的 Notes 页面上，能够填写 Sprint 的目标，在 Planned Items 页面上，可以为 Sprint 添加工作项，然后，详细分解工作项，定义任务。

还有另外一种方法为 Sprint 添加工作项，在 RTC 中，打开 Product Backlog 窗口，选择相关的工作项，然后右击并选择 Plan For，把这个工作项指定给某个 Sprint。

图 4 大图

在 Sprint Planning 会议中，团队成员分析需要完成的任务，为每个任务估计时间，

当估计完所有的工作项之后，可以看到每一个故事的总体估计值，以及整个 Sprint 阶段的总体时间估计值。

一般来说，Scrum 负责人分配任务给团队成员，团队成员也可以主动领取，在 Sprint Backlog 的列表内，可以实现将任务分配给团队成员。

图 5 大图

在每个 Sprint，团队成员要每天更新 Sprint Backlog 中的工作项状态和时间估计，这样，根据更新后的工作项，RTC 便可以产生一个 Sprint Burndown 图表，这个 Sprint Burndown 图表以图形方式显示剩余的工作项和工作量，显示项目的进展，预测项目的未来情况。

3 使用 Rational Team Concert 有效地进行每天的 Scrum 会议

Agile 敏捷开发实践中，强调团队的自我管理。在 Scrum 中，自我团队管理体现在每天的 Scrum 会议中和日常的协同工作，在每天的 Scrum 例会中，团队成员一般回答一下几个问题 :

• 昨天完成了什么？
• 今天要做什么？
• 项目进展中，遇到了什么障碍和问题？

整个会议应该少于 15 分钟。这种经常性的沟通，让团队成员能够了解每个人都在做什么，他们正面临着什么问题，有什么事情需要其他团队成员帮助解决，提高团队成员的协作。

在 Scrum 中，要坚持举行每天的 Scrum 会议 , 了解团队成员的工作进展和遇到的问题，Scrum 负责人要维护一个障碍列表（Impediments List），帮助解决团队成员遇到的阻碍和问题，保证项目顺利进行。

每天的 Scrum 会议可以增加团队成员之间的沟通，并帮助团队成员更有效地工作。

在 Rational Team Concert 中，通过集成的视图，团队成员能够了解各种任务、计划、工作项，也可以查看当天需要完成的工作项，当团队成员更新每日的工作项时，其他成员也可以看到。

在 Rational Team Concert 中，通过持续跟进工作项，团队成员可以更好地了解工作项的优先级，集中精力在优先级高的工作项上，保证项目的正常进展。团队成员还可以规划自己的工作内容和更新剩下的工作项。例如，在 Rational Team Concert 的迭代计划编辑器中，团队成员可以直接看到今天或本周的工作项。这些都有助于每天的 Scrum 会议，了解每天的 Scrum 会议中的问题。

Team Central 视图中的 Team Load 部分也可以显示团队工作负荷，在每天的 Scrum 会议之前，Scrum 负责人可以监控团队成员工作负荷。

Rational Team Concert 提供了 My Work 视图以帮助每一位团队成员查看和跟踪自己的工作项状态。在 Sprint 阶段，团队开发人员可以在 My Work 视图中看到任务和工作项。

Planned Time 视图可以查看工作项的剩余时间，支持 Daily Scrum 会议，团队成员可以根据 Planned Time 视图讨论哪些已经完成和哪些还没有完成。为了帮助跟进每个工作项的工作量，团队成员应该在 RTC 中每一天更新每个任务的剩余时间。

图 7 大图

开发员的任务面板也可以分配和监视工作项，它显示了每个团队成员的任务。

团队成员可以使用查询来监视工作的进展状况，Rational Team Concert 已经有很多可用的预定义查询，还可以轻松创建新的查询。预定义的查询，预定义了一些查询条件，可以直接用来查询工作项，比如，'Open assigned to me'，'Recently modified'等，这些预定义的查询可以用于每天的 Scrum 会议，团队成员和 Scrum 负责人可以快速了解每个工作项的进展。

对于地理位置上分散的团队，每天的 Scrum 会议有时通过电话或视频会议进行。Rational Team Concert 可以更好地辅助管理每天的 Scrum 会议，可以很快捕捉和处理阻碍项目的事情，然后，通过团队成员的协作，完成这些工作项或重新分配这些工作项。

4 在 Scrum 中，用 Rational Team Concert 进行软件源代码控制管理

在 Agile 敏捷开发最佳实践中，持续集成和自动化构建可以保证高质量的软件开发，持续地交付有价值的软件产品来提高客户的满意度。作为软件开发项目，需要一个高效和协作的软件源代码控制管理系统。Rational Team Concert 就是这种源代码控制管理系统，可以进行变更管理和配置管理，帮助开发团队管理源代码、管理文档、跟踪代码和共享代码的各种变化，并保持整个开发团队的高效协同工作；同时，Rational Team Concert 提供了自动地构建增量可交付物的功能，实现了软件开发的持续集成和自动化构建，实现高效的敏捷开发。

下图显示了在 Rational Team Concert 中源代码控制流转过程，开发人员把变更的源代码检入到存储库工作空间；然后提交到共享的开发流中，其他开发人员接受这些变更的源代码，并且装载到存储库工作空间中。

在 Rational Team Concert 中进行源代码检入（check in）和检出（check out），需要连接存储库和项目区域，下载源代码到本地存储库工作空间中。首先把源代码从开发流装载到本地存储库工作空间，然后，在本地存储库工作空间修改源代码，提交变更的源代码到开发流中。开发人员在 Pending Changes 视图中，展开 Unresolved 节点，检入源代码，加上一些注解，然后，在 Outgoing 节点下，通过提交（Deliver）的功能，就可以把变更的源代码提交到开发流中。

当开发人员提交了变更的源代码到开发流中，团队中其他成员就可以接受这些变更，把变更的源代码同步到自己的本地存储库工作空间中。开发人员在 Pending Changes 视图中的 Incoming 节点下，选择变更集，然后，接受（Accept）这些变更，这些变更的源代码就进入了自己的存储库工作区。

5 在 Scrum 中，灵活使用 Rational Team Concert 的工作项

在 Agile 敏捷开发中，以用户故事（user story）的形式定义各种需求，Rational Team Concert 为 Agile 敏捷开发提供了类型为故事（story）和历史（Epic）的工作项，可以定义用户故事，定义的工作项会显示在 Product Backlog 中。在每个 Sprint，Sprint Backlog 中的任务也是一种类型的工作项，同时，工作项也是跟踪、协调开发任务和工作流转的基本机制，它是各种部件和元素之间的联系枢纽。

在 Scrum 过程中，Rational Team Concert 提供了一些常用的预定义工作项类型，这些类型的工作项全面支持 Scrum 敏捷开发。

• 缺陷（defect）：定义缺陷和跟踪缺陷。
• 回顾（retrospective）：记录先前正常但在最近完成的迭代中不再正常的内容。
• 故事（story）：描述用户故事和需求。
• 历史（Epic）：用户故事或需求很大而需要在多个迭代（Sprint）中完成，或者由于未知情况过多而无法估计工作量的用户故事。
• 任务（task）：描述特定的工作任务。
• 障碍（impediment）：跟踪导致无法取得进展的因素。

在 Rational Team Concert 中，Product Backlog 中的用户需求或产品需求是通过工作项来描述，在 Scrum 的每次迭代中，用户需求或产品需求会被分解成为足够小的类型为任务的工作项，放在 Sprint Backlog 里，并且每一个任务是被赋予了优先级。

在工作项中有很多属性，充分和准确使用这些属性，Rational Team Concert 可以让 Scrum 敏捷开发更有效率。

摘要（Summary）字段是一个工作项的简短总结和标题，可以让 Scrum 成员和 Scrum 负责人快速理解工作项内容。

工作项的类型（Type）定义了工作项的特性，包括缺陷（defect），任务（Task），故事（Story）等，不同的类型有不同的属性和不同的状态变化。类型为故事（story）的工作项，可以描述 Scrum 的 Product backlog 中的用户需求或产品需求。类型为任务（task）的工作项可以定义 Scrum 中每一次迭代（Sprint）的任务。类型为缺陷（defect）的工作项可以记录每个 Sprint 中测试验证阶段的缺陷，跟踪缺陷的修复状态和进展。

严重级别（Severity）定义了工作项的严重等级。

描述（Description）字段详细描述了工作项的目标和相关信息，描述 Scrum 中的需求和任务。

所有者（owner），显示这个工作项当前的拥有者或执行者。在 Scrum 中，团队成员可以通过这个字段知道自己负责的任务，Scrum 负责人可以分配任务和了解团队成员的任务情况，在每天的 Scrum meeting 时，可以监控 Sprint 的进展。

优先级（Priority）属性指定这个工作项的重要性和优先顺序。高优先级的工作项将会被优先开发并确保完成。低优先级的任务有可能被转入下一个迭代（Sprint）周期继续开发。

计划目标（Planned for）属性指定这个工作项属于某个 Sprint。

状态 / 解决（State/Resolution），显示这个工作项的当前状态。

在 RTC 中，灵活使用工作项，可以提高 Scrum 的执行效率，下面介绍一些使用工作项的技巧：

在摘要（Summary），描述（Description）和讨论（Discussion）字段中，支持粗体（"bold"）和斜体（"italic"），也可以创建与其他工作项的链接。在工作项中，可以选择一些文本，使用上下文菜单中提取工作项的功能（Extract Work Item），提取相关的工作项内容。

在讨论（Discussion）字段中，添加评论，也可以和评论的作者进行聊天会话或发送邮件。

在快速信息（Quick Information）部分 , 可以通过上下文菜单添加订阅者、附件、链接到其他工作项，也可以附加屏幕截图。

可以使用"查找"对话框，搜索包括摘要（Summary），描述（Description）和讨论（Discussion）部分的内容。

在编辑器的工具栏中，可以使用'寻找潜在的重复工作项'（Find Potential Duplicates），发现可能重复定义的工作项。

6 总结

Rational Team Concert 是一个建立在可伸缩和可扩展平台上的团队协作开发工具，整合了软件开发项目生命周期的所有任务，包括计划、迭代、流程定义、变更管理、缺陷跟踪、源代码控制和源代码管理、产品构建自动化，和各种各样的分析报告等。Rational Team Concert 有力地支持了一些 Agile 敏捷开发方法，利用 Rational Team Concert 进行 Scrum 敏捷开发，能够开发出高质量的产品和项目，能够进行高效率的协同工作，持续的集成和自动化构建交付物。

Stream（流）是 Jazz 源代码管理系统中的重要成员，体现项目开发中的一个版本，由一个或者多个 component（ 组件）构成。流的建立使得团队成员在不同的版本之间进行代码的共享与管理，满足项目迭代开发中代码管理的需要，促进团队成员之间更好的协作。组件是代码共享与管理的基本单位，由一个文件或者文件夹所构成，团队成员可以通过使用流中的组件进行代码的共享。

多个 stream 的应用场景

目前，软件开发中迭代开发非常普遍，项目的开发经常涉及两个或多个版本。即在一个版本尚未发布就需要进入下一个软件版本的开发，这样使得项目开发人员需要同时维护多个软件版本。特别是一个缺陷需要在多个版本上解决，这样在这些不同的软件版本上进行代码同步就成为团队开发人员日常的工作内容。如何简化代码同步的流程，提高多个软件版本代码同步的效率以及减少在多个软件版本中由于代码同步引起的缺陷数，对于降低软件开发成本和提高软件质量具有重要的意义。

RTC 对多 stream 代码同步的支持

源代码管理与共享是项目开发中的重要内容，而 RTC 作为主流的源代码管理工具，对项目的源代码的管理与共享提供了很好的机制。在实际的项目开发过程中，项目拥有者需要在远程 Jazz 服务器上创建 stream，项目开发人员在远程 Jazz 服务器上基于此 stream 创建自己的版本库工作空间。除此之外，开发人员还需要在本地的机器上创建自己的本地工作空间。开发人员通过 Check-in 操作将本地工作空间的改动同步到远程 Jazz 服务器上的自己的版本库工作空间，通过 Deliver 操作将远程版本库工作空间的代码同步到团队共享的 stream 上。其他团队人员则通过 Accept 操作将代码从 stream 同步到自己远程的版本库工作空间，并通过 Load 操作将版本库工作空间的源代码下载到本地的工作空间。依此类推，RTC 就可以同时管理多个 stream 并进行有效的共享，其具体的源代码管理与共享机制如图 1 所示：

通过 RTC 中对源代码的管理与共享机制可以看出，如果不进行任何修改与配置，在多个 stream 上，开发人员只能通过单独维护每个 stream 上的源代码，并在这些 stream 上进行代码的来回复制达到多 stream 上的源代码同步，这样无疑增加了维护和同步多个 stream 上的源代码成本。事实上 RTC 可以通过更改相应的 flow target（目标流指向）来简化多 stream 上的源代码同步，有效的提高项目开发的效率。

总的来说，RTC 对多 stream 上源代码的同步提供了三种方式：各 stream 单独同步，stream 由低版本向高版本同步及 stream 由高版本向低版本同步，具体操作如下图所示（图中以两个 stream 为例，多个 stream 可以依此进行类推）：

从图 2 可以看出，同步 stream1 和 stream2 上的源代码需要在每个 Local workspace 上 Check-in 相应的代码，在同步第二个 stream 时需要从一个 Local workspace 上拷贝源代码到另一个 Local workspace 上，这样加大了开发人员的工作量，并且增加了一些由拷贝源代码所造成的缺陷。图 3 与图 4 的同步机制没有多大差别，图 3 所示的为源代码从低版本（stream1）向高版本（stream2）同步，开发人员先将代码提交到 stream1，然后改变 stream2 的目标流指向，接受之前提交到 stream1 上的变更集，最后通过 Jazz Server 上的 Repository workspace 将变更集提交到 stream2 上。图 4 所示为源代码从高版本（stream2）低高版本（stream1）同步，具体过程与低版本（stream1）向高版本（stream2）同步相反。由于高版本往往会包含低版本没有实现的功能，所以对于多 stream 的源代码同步，采用从低版本向高版本同步的方式遇到的潜在的源代码冲突相对较少，开发人员解决这些冲突并合并变更集所付出的成本也随之降低。因此，在实际项目开发中，对于多 stream 的源代码同步，采用低版本（stream1）向高版本（stream2）同步的方式最佳。

RTC 中多 stream 代码同步的示例

由于多 stream 从低版本中向高版本同步时潜在的冲突最少，因此本文将以这种同步方式作为示例说明如何在两个 stream 实现源代码的同步。对于三个或三个以上 stream 的代码同步，读者可以依此类推。在示例中，我们拥有两个 stream，6.3.1.1 和 6.3.2。并且我们已经创建好两个 stream 上对应的两个我们自己的版本库工作空间。

无代码冲突情况下的代码同步

打开 Pending Changes 视图，在 6.3.1.1 版本库工作空间上有个新的可交付变更集，右击选择 deliver 对其进行交付，具体操作如图 5 所示：

打开更新版本的 6.3.2 版本库工作空间，更改其 Flow Targets 到 6.3.1.1 stream。如图 6 所示，将 6.3.1.1 stream 置成当前 flow target 且是默认 flow target，然后确认保存。

保存后结果如图 7 所示。

如图 8 所示，此时再次查看 Pending Changes，6.3.2 版本库工作空间已经指向 6.3.1.1 stream，刚才在 6.3.1.1 版本库工作空间中交付的变更集出现在 6.3.2 版本库工作空间的可接受变更集中。此时该变更集与 6.3.2 版本库工作空间中代码不存在冲突，可以直接选择接受。

接受后，将 6.3.2 版本库工作空间的 flow target 改回 6.3.2 stream ，如图 9 所示：

从图 10 中可以看出，在 Pending Changes 中，6.3.2 版本库工作空间中有了新的可交付变更集，该变更集正是 6.3.1.1 版本库工作空间之前交付的变更集。由于不存在冲突，我们可以直接将该变更集交付到 6.3.2 stream 中，从而实现两个 stream 上针对该变更集的源代码同步。在下一节中我们将给出存在代码冲突的同步示例，为了模拟这种情况，我们暂且不交付此变更集。

有代码冲突情况下的代码同步

同样，打开 Pending Changes 视图，在 6.3.1.1 版本库工作空间提交一个新的变更集模拟代码冲突，右击选择 deliver 对其进行交付，具体操作如图 11 所示：

更改 6.3.2 版本库工作空间 flow target 到 6.3.1.1 stream。从 Pending Changes 视图中可以看到 6.3.1.1 版本库工作空间中新提交的变更集。该变更集前出现橙色高亮，说明该变更集和 6.3.2 版本库工作空间中可交付的变更集存在代码冲突。具体操作如图 12 所示：

选择接受该变更集，此时会弹出是否自动解决冲突的对话框如图 13，我们这里建议选择 Resolve Later，以防止出现代码合并错误的情况发生。下面我会给出具体的情况说明在接受冲突变更集后如何 Resolve。Resolve 有两种方法：自动合并和手动合并。什么时候选择自动合并，什么时候需要手动合并，这对于维护代码的同步和准确性十分重要。

选择 Resolve Later 后，将 6.3.2 版本库工作空间的 flow target 改回 6.3.2 stream。如图 14 所示，出现未解决代码冲突。双击打开冲突比较视图。

如果视图中仅有蓝色标识，说明没有严重冲突。如图 15 所示，可以选择 Auto Merge 自动合并代码。

图 15 大图

如果视图中有红色标识，说明存在严重冲突，自动合并代码将导致代码错乱。如图 16 所示，将红色部分右侧代码拷贝覆盖到左侧，手工完成覆盖后，选择 Resolve As Merge 完成合并。

图 16 大图

在弹出的对话框中选择 OK 确定手动合并操作，如图 17 所示：

这样合并完成后，6.3.2 版本库工作空间可交付变更集如图 18 所示。此时可看到被合并的原变更集后出现 1 merged 字样，合并操作完成。对其交付后，6.3.1.1 stream 和 6.3.2 stream 在该变更集存在冲突的情况下实现了代码同步。

撤销已交付的错误代码

在同步两个或多个 stream 的时候，很可能误将不属于本 stream 的代码 deliver 到 stream 上。如果错误交付的代码过多的话，手动去删除错误交付的代码将会需要花费很大的工作量来将代码还原到原来的状态。而且，还会带来代码被错误修改的风险。而 RTC 提供了一种回退（Reverse）的功能，将错误交付的代码自动清除掉，并恢复到原来的状态。

回退（Reverse）功能的具体操作步骤如下：

1. 右击错误提交的代码所相关的 work iteam，并单击弹出的 Reverse 菜单。

2. 点击 Reverse 菜单后，会弹出如下图 20 所示的窗口，指示修改前的文件将会在 Pending Patches 以 patch 的形式显示出来。然后，点击 OK 按钮。

3. 如图 21 所示，在 patch 中你可以通过双击 java 文件来查看原来文件里的内容和错误交付代码后的文件的差异，来查看是否是你想要恢复的结果。

4. 将这个 patch 添加到现有的 workspace 上面，从而将原有的变更集先恢复到本地的 workspace 上。

5. 原有的文件将会作为未提交的文件显示出来。

6. 通过将原有的代码重新 check-in 和 deliver，从而将被错误修改的代码从项目组共享的 stream 上删除出去。

如果将代码错误提交到 stream 后，有其他开发人员提交了自己的代码，这个时候要进行回退的时候，需要查看需要回退的文件是否和其他开发人员修改的文件有冲突。如果有冲突，可以通过前面提过的方法进行代码冲突的整合；或者把错误提交代码以后其他开发人员提交的代码先回退回去，在把错误提交的代码从 stream 上删除以后，重新将其他开发人员提交的代码 deliver 到 stream 上。

致谢

衷心的感谢钱巧能工程师在本文大纲方面的讨论所提供的意见和支持。

结束语

本文详细介绍了 RTC 代码同步的原理，并且比较了目前 RTC 中多 stream 上代码同步的几种方法，最后以具体示例说明了如何在 RTC 中进行多 stream 的代码同步，解决代码同步中出现的冲突及如何撤销错误的代码同步。读者可以通过阅读本文，掌握各种在 RTC 中多 stream 代码同步的方法，并根据项目实际情况选择，灵活运用，提高项目开发的整体效率。

本文介绍了 IBM Rational Team Concert（RTC）的代码评审功能（Code Review）。这一功能可以使代码评审流程变得更加规范，完善代码提交流程；对于不同区域的成员可以更高效的协同工作，在代码提交前发现到潜在的问题，尽快修复，提高代码质量，有效减少缺陷数。

代码评审的重要性

多数情况下，评审者能够发现开发人员自身不能发现的问题或潜在问题，毕竟思维方式和考虑的点等会有差异

• 优秀的评审者通过评审，不仅可以发现开发人员的不足，更可以通过开发人员的代码学到很多知识
• 对团队而言，通过评审以及互相评审，了解到其他团队成员负责的任务，必要时互相帮忙，互为后援，提高项目开发效率，降低项目风险

代码评审的规则

• 从逻辑上讲，本次修改是否符合需求，是否有类似的地方需要修改
• 可读性上，是否有足够的解释说明，以便以后维护
• 就代码规范而言，是否符合公司代码规范，以保持代码风格一致性
• 从代码性能上讲，是否有更有效的方案可以实现
• 单元测试（如果必要），测试用例是否能覆盖本次的修改

RTC 对代码评审的支持

作为目前主流的代码管理工具，RTC 对代码评审的功能已经有了很好的支持，比如利用邮件作为代码提交者与评审者通信的工具，代码评审过程中各个角色的划分，代码提交的权限设置等等，本节将具体介绍 RTC 在代码评审过程中所涉及的概念及详细配置。

对邮件的支持

在整个代码评审过程中，邮件是作为代码提交者及其他相关人员之间的重要通信工具，比如在代码评审前提交、对代码添加修改意见，团队相关人员都应收到相应的邮件提醒，用户可以通过如下配置是否启用邮件支持：

1. 打开 Repository Connections 界面并连接

2. 打开用户编辑窗口，如图 2 所示：

3. 找到 Mail Configuration 页面，进行相应的配置并保存，如图 3 所示：

代码评审中所涉及的角色的划分

在整个代码评审过程中，RTC 将会涉及到如下几种角色

• Submitter：代码提交者，由实现新功能的开发者自己担任，可执行的操作有 Submit for review、Check-in，Deliver、Add Approver 等等。
• Review：代码审查人员，负责代码提交前细粒度的代码审查工作，排除潜在的缺陷，一般由团队中对所要修改的代码比较熟悉的人员担任。可执行的操作有 Add comment、Rejected、Approved 等。
• Approver：代码评阅者，负责代码提交前粗粒度的代码审查工作，一般由资深开发人员及 tech lead 担任，可执行的操作有 Add comments，Rejected、Approved 等。
• Verifier：功能的验证者，对功能的实现作一些单元测试等等。

事实上对于以上这些角色，Submitter，Reviewer 和 Approver 是必须，Verifier 是可选的，用户可以根据团队实际情况决定在代码评审过程中是否需要 Verifier。

代码提交前的权限控制

RTC 在代码提交时有了较好权限配置的支持，用户（一般由 Project owner 或团队的 tech lead 配置此权限）可以根据如下步骤进行配置：

4. 连接自己所在的项目并打开，如图 4 所示：

5. 切换到 Project Area 中的 Process Configuration 页面，如图 5 所示：

6. 双击 Team Configuration 中的 Operation Behavior 选项，如图 6 所示：

7. 从右边列表中选择 Source Control 中的 Deliver（server）选项，双击对应 Everyone(default) 图标，并双击 Add ... 按钮添加代码提交时的 Preconditions. 如图 7 所示：

8. 在弹出的 Add Preconditions 对话框中选择 Require Work Item Approval 选项，如图 8 所示：

9. 双击 Required approvals 栏中 new ... 按钮添加代码提交时的 Required Approval，针对不同的 Approval 类型选择相应的 Approvers，单击 ok 按钮，最后保存所有配置。如图 9 所示：

经过上述一系列配置后，代码提交者必须先取得相应的 Approval 之后才能提交代码，从而达到代码提交时的权限控制，保证代码的质量。

RTC 代码评审使用示例

在 RTC 中，代码评审的流程大致如下，各个团队可以根据实际情况进行优化。

下面我将以一个简单的实例来说明在 RTC 中是如何进行代码评审的：

1. Check in 变更集

修改源代码，在 RTC 客户端中找到 Pending Changes 视图，并将这些变更集 check in 到在 Jazz repository 上的 workspace，如图 11 所示：

2. 关联 work item

在 Pending Changes 视图中，将 check in 的变更集关联到相应的 work item(story 上的 task work item 或者是 issue 类型的 work item) 上。

3. 提交代码给相应的 approver review

在 Pending Changes 视图中，找到相应的 Outgoing 变更集，点击右键菜单中的 Submit for Review... 选项。

4. 添加注释和相应的 Approver

在弹出的 submit for review 的对话框中添加相应的注释及添加相应的 Approver 类型（具体类型请参考 RTC 中对代码评审章节）。

5. 确定需要评审代码关联的 work item

Approver 将会根据 RTC 中关于代码评审的邮件找到相应的 work item，并从 work item 中找到链接页面。

6. 查找对应的变更集

Approver 从链接页面中找到需要评审的变更集，双击此变更集，变更集将会在 RTC 客户端的变更视图中显示。

7. 给出评审结果及意见

每个 Approver 根据代码评审的实际情况给出相应的修改意见和评审意见，如对于哪一行代码需要修改或者同意提交等等，具体操作如图 17 所示：

如果给出的评审结果为同意提交，则 submitter 直接进入代码提交阶段。如在此阶段给出的评审结果为拒绝，则 submitter 需要从 work item 的 overview 视图或 RTC 邮件中查看 Approver 添加的修改意见，并根据意见进行代码修改，重新提交代码评审。

8. 代码提交

代码 Submitter 在 Pending Changes 视图中找到相应的 Outgoing 变更集并提交。

RTC 代码评审的注意事项

一次代码评审和所提交的一个变更集是一一对应的关系，当对一个变更集提交代码评审后，这个变更集就被冻结，此后对其中任何文件的修改都将通过另一新的变更集来跟踪。所以，对于新的修改，需要再次提交代码评审。

评审者在应用被评审者的变更集进行代码评审时，有时会和评审者本地的变更集产生冲突，此时只要将产生冲突的本地变更集暂停（Suspend），就能暂时避免冲突从而继续进行评审。

RTC 代码评审的不足及展望

虽然 RTC 已经能够支持完整的代码评审功能，但在实际使用中还有一些改进之处。比如无法动态嵌入或链接到评论所涉及的代码中的指定行，方便被评审者阅读修改意见。而且评审的粒度较大，基于每个评审者的修改意见无法针对每条评论进行接收或拒绝。此外，如果加入代码静态分析功能，就能更快的找到问题，避免人为的疏漏。

1. PROJECT AREA
   根据计划来，不同的计划建立不同的PROJECT AREA。
   
2. TIME LINE FOR PROJECT AREA
   定义起尺和结束时间，也指一组ITERATION和TEAM AREA的组合。
   一个PROJECT AREA可以搞几个TIME LINE。
   
3. ITERATION FOR TIME LINE
   一个TIME LINE可以分若干个ITERATION阶段去完成。
   
4. TEAM AREA FOR TIME LINE
   这段时间的TIME LINE的PROJECT 是需要人来完成，先定义TEAM AREA。就是USER的组合。
   
5. USER FOR TEAM AREA
   就是TEAM AREA的组织成员。
   
6. CATEGROY FOR TEAM AREA
   CATEGORY就是WORK ITEM的类型，但要和TEAM AREA关联。
   
7. PLAN FOR ITERATION
   在上面的时间段ITERATION增加PLAN，也是一组WORK ITEM的组合。
   
8. WORK ITEM FOR ITERATION，USER
   工作内容，父类是ITERATION，USER等。