简介： 本文介绍一个基于 Rational ClearQuest 的企业变更管理系统（Enterprise Change Management，ECM）系统。通过对该系统的介绍和应用，讲解了 ECM 如何成为项目开发中统一的变更管理资源，如何满足多团队、多项目成员参与，多版本开发同时进行时的变更管理。ECM 系统提供了强大的跟踪、协作功能。如何满足项目开发中对变更的高效管理，作者分享及讨论了其在项目中实践。

1. 企业变更管理（ECM）系统介绍

企业变更管理实践跟踪系统是设计用来提供一个统一的产品变更管理资源系统。基本上我们把变更分为缺陷和需求变更两种类型。文中的变更如无特定说明代表两种类型。系统确保所有开发小组遵守一个通用的工作流程来进行缺陷和需求变更管理。它提供了一套通用的术语、协定和流程。

在此我们介绍的 ECM 系统的基本功能和产品体现的对于变更管理的理念。文中没有对系统所具有的所有功能进行描述，也没有对系统的部署进行描述，主要描述了系统的版本信息、变更的定义、系统用户的角色和规则、变更状态和处理流程。

1.1 系统基本功能

ECM 系统是一个客户定制的 IBM Ration ClearQuest 版本。根据公司项目需求进行了定制，来满足公司多部门对变更管理的需求。我们使用的 IBM Ration ClearQuest 版本是 7.1.1.5。

系统的集成、定制和日志功能

Rational ClearQuest 可以容易的集成到用户系统中。系统提供了完整的 API 来支持集成到第三方应用中。还提供变更查询的 REST API 封装，方便用户将定制的变更查询集成到浏览器模式的系统中。

系统提供用户操作记录功能，记录所有用户操作信息，包括时间、操作人、变更状态以及内容的变化。此功能可以方便变更的参与人了解变更状态变化的历史信息。同时系统提供后台日志功能，支持 LDAP 用户认证集成方式。

多客户端和多站点布署

系统支持客户端应用程序，集成到用户开发环境和浏览器三种使用方式，所有方式均需要服务器的部署。

在多点部署的情况下，不同地域的开发人员可以使用相同的数据集，一个数据集可以是一个规则集和与其关联的用户。系统支持根据组织结构和用途的不同支持多数据集部署。

对于 Rational ClearQuest 每一个部署可以拥有自己的数据集副本以满足用户对性能的要求。在任何时间副本的改动可以更新到其他副本。

设计器

Rational ClearQuest 提供了设计器，来满足用户需要定制变更管理属性的需求。用户可以定义如变更事件类型、用户角色类型等系统属性，以满足用户对变更管理的特殊要求。

1.2 变更的通知、查询、共享和导出

邮件通知

任何对变更的操作系统都会自动发送邮件统治相关人员。相关人员可以是与此变更有关的开发人员、测试人员、项目经理和客户代表。

查询

在满足变更的协作管理的基础上，如何能够让不同的用户查询的需要关心的变更数据显得尤为重要。系统提供强大查询功能来满足不同人员对变更的管理。系统提供以任意属性查询我们关心的变更。例如，以产品或版本为分类查询变更来获得特定时间段内未解决变更的数量、新提交的变更的数量、解决的变更的数量；了解产品缺陷或变更的状态和开发计划之间的匹配关系。

查询的共享

系统内置必要的公共查询，同时用户可以定义自己的变更查询，私有查询。任意查询可以导出为 REST API，方便集成到其他系统中。同时用户也可以通过邮件共享私有查询。

系统支持公共查询来共享常用查询给其他用户的功能。用户可以自定义查询并保存在系统中，方便以后使用。系统支持根据变更标识（变更的一个特定属性，唯一标识一个变更）和文本快速查找一个变更。

结果导出

用户可以把查询结果导出为文本文件等格式，以方便用户在其他文档中引用变更信息。系统支持以图表方式显示变更的查询结果，以方便用户在其他文档中引用。

1.3 变更管理

变更信息的组织

系统通过产品包（suit）、产品（product）、功能（feature）和发布（deliverable）来对所有变更事件进行分类和管理。

单独的产品可以由于关联关系组织进一个产品包中。每个产品可以含有多个功能，每个产品也可以对应多个版本。同一产品的多个版本之间可以有功能的不同。每个版本和特定的发布日期关联，此日期是由产品经理确定。技术支持组可以基于此信息，与用户交流关于特定功能或者特定缺陷修复的交付日期。

图 1. 变更的分类

变更的操作及相应的状态

对变更的基本操作可以分为，创建变更、修改变更、分配变更、解决变更、验证变更、拒绝变更、推迟修复变更和设置为重复的变更。

每个操作对应的状态为，提交的、分配的、已解决的、已验证的、被拒绝的、推迟处理的和重复与其他变更的等状态。

重复与其他的变更表示某变更事件于其他的变更描述相同的内容。

系统中的用户角色和权限

系统根据变更管理中不同角色的职责设定了质量保证人员、开发人员、项目经理和超级用户四类用户角色。质量保证人员、开发人员、项目经理的角色可以针对产品进行分配。每个用户可以分配多个角色。

质量保证人员主要进行变更的提交、验证和拒绝等操作。变更的创建一般由质量保证人员进行但不限于质保人员。系统把变更创建权限赋予了系统中的所有人员。

项目经理进行变更的分配、级别评定、目标版本设定，或者设定变更为重复状态以及决定推迟对变更的处理。

开发人员对变更进行修改、调查和解决。变更有一个变更责任人的属性，它的取值是具有对应产品的具有开发人员角色的用户。

超级用户可以定义产品、功能、版本，对系统中用户的角色进行管理，以及对系统中的属性进行自定义。对于系统中用户管理和产品包创建由系统管理员进行。

变更的生命周期

变更是由变更提交人发起，进行从变更提交到变更解决的全生命周期管理。系统的引入可以使开发团队、客户支持团队以及相关开发团队之间使用统一、高效的平台进行变更管理。每一变更状态和特定的变更行为关联，而特定的变更行为和用户角色关联。

图 2. 变更的生命周期

每当系统中的用户对变更执行任何操作，系统会通过邮件通知变更相关人。相关人可以是上述用户角色中的任意一种，他们是和此项变更相关的质量保证人员、开发人员和项目经理。通过邮件通知或者主动查询我们可以进行不同用户见的的协作。

变更的其他信息

除了上述变更信息，变更还包括了变更提交人、责任人、依赖此变更的变更、依赖的变更、变更操作的行为及日期、对用户的影响严重程度、变更的目标版本、是否用户提出的变更等信息。

2. 系统在多版本开发中的应用

实际开发中我们面临着多个版本同时进行开发的需求。这要求我们能够根据产品包、产品、版本（发布）来查询变更的状态，以决定产品是否达到发布的要求。对于一个产品可以有多个版本同时开发，一个变更事件可能存在于多个版本中。

2.1 版本信息定义

开发团队可以在 ECM 系统中定义版本管理字段，比如 Version Found In, Build Found In, Target Version, Build Fixed In, Version Fixed In。这些版本相关字段将被用于创建变更，变更分配，变更解决，以及变更验证等不同阶段中。

1.发现变更的版本（Version Found In）

这里我们用三个数字来标识版本信息。比如产品 A 的版本可以是 1.1.0。

2.发现变更的开发版本（Build Found In）

通常开发版本仅为开发团队可见，一个版本对应很多的开发版本。例如产品 A 1.1.0 版本的开发版本可以从 1.1.0.1 开始标记，一直到产品发布的版本，例如 1.1.0.100。

目标版本（Target Version），即变更需要解决的目标版本，通常需要为目标版本设定发布时间，系统通过比较当前时间和目标版本发布时间，来避免变更被分配到已经发布的版本上。如果当前时间晚于目标版本发布时间，则此变更不能被分配到这个目标版本上。

3.变更解决的版本（Version Fixed In）

4.变更解决的开发版本（Build Fixed In）

2.2 版本信息与变更的生命周期

如图 3 所示，用户在创建变更的时候首先提交“发现变更版本”以及“发现变更的开发版本”的信息。项目经理根据严重程度评定变更级别，评定变更优先级。并确定“目标版本”。对于复杂的，不确定风险的变更，可以通过经理会议讨论确定“目标版本”。当开发人员在解决问题后需要更新“变更解决版本”和“变更解决的开发版本”。最后质量保证人员在相应的版本上验证变更，若验证成功结束变更，若验证失败，则需要拒绝此修改或解决方案，需要对变更进行重新分配，继续变更的管理。

图 3.版本信息与变更的生命周期

因此，多版本变更管理的关键点和难点是确定“目标版本”。

2.3 如何确定目标版本

项目经理需要综合多种因素来决定“目标版本”。包括确定“变更级别”，用户影响，解决问题的成本，引发新问题的风险，升级版本的变更原则。下面将列举一些分析这些因素的原则和方法以供参考。注：根据产品以及项目的不同，方法也需调整以适应本项目 / 产品的特点。

变更的级别

“变更级别”可根据对用户或系统的影响分为一下 4 个级别：

变更级别：

严重级别 1 - 严重

系统，应用程序，功能，组件或接口不能工作。客户或内部用户不能使用产品，严重影响正常业务运营，开发或者测试活动，需要立即解决或修复。

严重级别 2 或较严重（Major）

主要产品或者功能不稳定，给业务运营，开发或者测试活动带来不便。但是严重程度有限。

严重级别 3 或一般（Normal）

非关键领域的基本功能失效。客户或者内部用于能够继续使用，不影响业务运营，开发或者测试关键业务。

严重级别 4 或较小（Minor）

一个非常用的功能偶尔失败，容易饶过问题，对业务运营，开发或者测试影响很小。虽然不能稳定重现问题，但是需要记录下来。

变更的优先级

项目经理在分配变更时，需要在变更系统中确定严重级别。但是仅依靠严重级别不足以决定需要在哪个目标版本上解决变更。通常还需要结合解决成本，引发新问题的风险来综合评定变更的优先级。优先级不一定会记录在变更系统中。但是无论有没有在系统中记录优先级的信息，项目经理都需要做到心中有数，为合理分配变更提供重要依据。

如图 4 所示，是一个如何判定优先级的原则的示例。纵轴表示变更的严重程度，高（严重级别 1，2）低（严重级别 3，4）。横轴表示解决成本大小，引发新问题的风险高低。

对于图中优先级 1 的变更，由于解决变更需要的资源少，而且引发新问题的风险较低。所以可以立即解决。对于优先级 2 的变更，虽然严重级别高，用户影响也较大。原则上需要尽快解决。但是当产品处于发布前期，为了避免引发严重的新问题，从而影响产品正常发布时间，这些变更是可以考虑被推迟到下个发布中去解决。

对于优先级 3 的变更，如果在产品开发的初期或中期可以在本版本中以较低的优先级去解决。如果是在临近发布阶段提交的变更，则考虑推迟到下一版本中去解决。

对于优先级 4 的变更，如果产品开发的资源有限，则可以推迟到下一版本中去解决。对于缺乏足够商业论证支撑，影响极小，且解决成本和风险高的变更，可以在通过经理会议审核后关闭 / 取消变更。

图 4. 变更优先级评定分析

基于不同的产品开发策略，一种被选的方式是早前发布的版本中发现的变更，在后续的所有计划版本中解决。另一种方式是基于对变更的风险、严重级别这个进行判断。下面的案例分析作具体的说明。

3. 在项目中的实践

通过以上的文章，我们初步了解了产品缺陷管理的工具，流程以及一些理论知识。在这一章里，我们将结合自己的一些工作经验，着重分享一些产品缺陷管理中的一些常用的实践。ECM 系统仅仅是一个变更管理的工具。只有将它系统，有效并充分的利用到现实的工作中，它才能够成为增强团队凝聚力，降低管理成本以及提升产品质量的法宝。

以下便是我们分享的有效的实践，它包括四点，后面做详细描述：

统一的缺陷管理标准；

关于必须修复缺陷的定义；

相互依赖产品间缺陷跟踪原则；

客户提交的缺陷处理及最佳实践；

3.1 统一的缺陷管理标准

大型软件项目的开发，通常是由不同的项目组所构成。而各个项目组之间通常会有相互交互的关系。特别是那些存在依赖关系的项目组。如果各个项目组之间使用不同的缺陷管理标准，那将会在实际的工作过程中引入更多的培训成本，更多的交流成本以及更多的管理成本。所以，为了解决这个问题，我们需要一个简单的并且标准的缺陷严重程度定义。在标准的缺陷严重程度定义引入之前，我们通常会遇到这样的问题。在同一个团队中内部，我们的缺陷严重程度有十级不同的定义，一级为最高，十级为最低。在现实的工作过程中，我们发现由于级数太多，大部分的经理很难将相近级数所代表的意义分清，导致个人对伊缺陷严重性的级数认定个不相同。这种不同将会在缺陷修复的资源调配上产生不小的影响，于是会出现我们花费很多资源在影响较小的缺陷上，却没有能够修复更严重的问题。另外，将十级不同定义的缺陷标准归纳整理本身就不是一项非常高效的活动。在另外一个不同的团队中，如果遵循另外一套缺陷严重程度标准，那么当这两个团队共同开发某项功能的时候，便会出现由于标准的不同而产生的误解，大大降低工作效率并增加管理以及交流成本。于是简单并且标准的缺陷严重程度定义便显得给为重要了。我们的实践是将多级的标准的缺陷严重程度定义简化为最少的四个级别以及两个附加属性：

一级：严重的缺陷，影响大并需要立即处理

二级：较严重的缺陷，有一定影响，需要及时处理

三级：一般的缺陷，影响小或发生概率小，不需要及时处理

四级：较小的缺陷，一个非常用的功能偶尔失败，容易饶过问题。

客户属性：缺陷还是隶属于以上的级别，但是由于它是客户发现的问题，于是会对客户的工作产生影响，在下一个版本发布的时候，应该及时修复。

阻碍属性：缺陷还是隶属于以上的级别，但是由于它的阻碍属性，会影响到某些功能的使用或者会阻碍的测试的进行，需要立即处理

通过一段时间的实践，我们发现在团队内部，新的缺陷严重程度定义的标准，统一了经理们对于缺陷的认知，并且大大的简化了他们定级以及分派的活动。在团队和团队的合作中，新的缺陷严重程度定义的标准使合作开发的缺陷管理更为清晰，易于传递以及复制，并大幅降低了交流的成本。

3.2 关于必须修复缺陷的定义

对于一个大型产品来说，明确产品发布时必须修复缺陷的定义并不容易。每一个人都有自己的评判标准。于是如何让大家能够认可同一种标准并有效的进行沟通是缺陷管理的一种挑战。这里我们分享以下我们针对这种挑战的一些做法。首先要设定缺陷修复优先级以及修复目标。由于任何产品开发的目标都是服务于客户。于是缺陷管理中客户缺陷的属性便成为了另一个面向客户的缺陷严重级的指标。不管发布的产品中还有多少缺陷需要修复，所有客户发现的缺陷永远是属于高优先级的。当我们明确这个优先级以后，设定修复目标就变得简单了。其次要定义客户缺陷最后接受的时限。由于客户问题的上报是不用时间控制的偶然事件。于是在每一个发布的周期里，我们需要另外定义一个客户缺陷最后接受的时限，在这个时限前报告的问题我们将要求在在这次发布的周期中修复，对于那些上报时间超出了规定时限的缺陷，我们将定义在下一个发布周期中修复。对于特别严重的客户缺陷，我们会以单独缺陷修复包的形式发布，而不会囊括在这次的发布中。这是因为如果没有客户缺陷最后接受的时限，发布的时间会被客户问题所打乱从而无法在规定的时间里发布产品。基于以上的想法，以下是我们的做法：

在主要版本发布的计划中，规定在缺陷最后接受的时限前，所有客户提交的优先级为一级以及二级的缺陷必须修复。对于非客户报告的缺陷，所有一级缺陷必须修复。二级以及三级缺陷用于预先设定的质量计划来控制。

在小版本发布的时候，规定在缺陷最后接受的时限前，所有客户提交的优先级为一级以及二级的缺陷必须修复，另外，所有非客户报告一级缺陷必须修复。为了更好的控制工作量，在小版本上报告的非客户提交的二级以及三级缺陷将会顺延到下一个主要版本发布前进行修复。

为了明确这要的目标并更好的管理，我们通常在 ECM 系统中建立公有的查询并与所有开发以及测试人员分享。

3.3 多版本中缺陷修复的案例分析

某公司产品以 1 年为周期发布产品，在今年年初发布了产品 A1.0 版本。每半年都会为产品做升级。当前公司研发部门正在同时开发产品 A2.0 版本以及 A1.0 版本的升级版本 A1.1。

图 5. 版本周期示意图

图中“升级版本”指 A1.0.0 版本的升级版本 A1.1.0

“下一个主版本”指 A1.0.0 版本的下一个升级版本 A2.0.0

图为如何决定目标版本的流程，由于升级版本由于开发周期相对较短，通常只针对严重性高地变更解决。主版本上发现的变更，通常不会在升级版本中解决，如果用户影响大，严重级别高地变更，需要通过经理会议通过后，方可在升级版本中解决。

3.4 相互依赖产品间缺陷跟踪原则

面向对象甚至是面向服务的软件开发理念其中一项优点是能够更好的重复利用已经开发的软件功能而不是对同一功能在不同环境中的应用进行重复而且低效的开发。大型软件的开发更是如此。于是，在大型软件中，我们会将不同团队开发的功能模块整合到软件里来实现类似的功能，这种低成本的集成似乎很有效，但它也会引入以下相互依赖的问题。这里我们着重描述对于缺陷依赖关系的处理以及对应在 ECM 里的一些实践。首先，这些实践是基于我们对以上所述的缺陷严重程度的统一定义以及产品发布必须修复缺陷定义的操作。如果缺乏以上的定义，这些操作将无法落到实处。以下是我们的做法：

确定产品的依赖关系。我们会通过现有的依赖管理工具 Clearing House 以及 ECM 中定义出所有其他产品和主产品的依赖关系，不仅仅是依赖的信息，包括各个依赖产品的负责人，发布信息以及支持信息都会在工具中体现。

明确依赖关系负责人以及其职责。我们需要定义出每个依赖产品接口的责任人，他将是 ECM 系统中依赖产品相关缺陷的负责人。他负责定义缺陷的归属以及对于依赖产品的交流。也就是说当他查明这是一个依赖产品的缺陷，他来负责在 ECM 系统中将缺陷克隆到依赖产品相应的项目中并跟踪依赖产品的修复情况。

设定缺陷修复时间要求。由于主产品和依赖产品各自有自己的发布周期，所以如果没有一个明确的缺陷修复时间要求，很有可能引来产品的缺陷的修复会由于依赖产品发布周期的不同从而被拖延。于是最终给主产品带来风险。为了应对这种风险，当我们在复制缺陷到依赖产品中时应明确给出主产品定义的缺陷修复时间要求。如果这种要求和依赖产品发布周期冲突，这种问题必须被及时地反馈到产品的管理者做出决断。通常情况下如果冲突无法解决，依赖产品将被要求提供单独缺陷修复包。

相互依赖产品间缺陷跟踪是一个基于 ECM 系统的管理的方法认知。在 ECM 系统中我们常用到克隆以及建立缺陷之间的联系的方法来跟踪。当然，相应的查询也必须很好的建立起来从而更好的捕获缺陷间的关联关系。

3.5 客户提交的缺陷处理及最佳实践

相信大家都有这样的认知，客户提交的缺陷是高优先级的缺陷，需要我们及时的处理。但是这些缺陷又是很难预知的。然而，对于任何一个大型产品的开发，产品发布本身是由一系列的计划组成的。从而，把随时可以发生的客户提交的缺陷很好的集成到有计划的产品开发中去便是一个不小的挑战。对于 ECM 系统来说，我们可以利用它来辅助我们很好地进行客户提交的缺陷和产品开发的集成，但是我们最需要的却是一个管理的方法论而并不是软件工具本身。这里是我们对于客户问题的处理流程的一些实践。

定义修复原则

当客户提交的缺陷袭来时，最基本的问题是：它的影响力有多大？我们什么时候需要修复它？在产品的哪一个发布时发布？是否需要发布给用户修复包？而当你能够回答这些为题时便同时定义出了修复的范围。当让，对于每一个缺陷的个体，我们可能会根据其特殊情况来用不同的方式处理，但是，总体的原则是：对于客户提交的缺陷，在下一个最近的产品发布时需要包含对它的修复。对于要求修复包的客户提供发布包。

确定修复计划

基于以上的原则，当客户提交的缺陷报到 ECM 系统里时，缺陷的分配人便需要定义出它的修复时间，基本上我们使用下一个最近的产品发布的日期来定义它，当然，我们也需要考虑到下一个最近产品是否来得及包括这个修复。这里我们便会利用客户缺陷最后接受的时限来确定，如果超过了这个时限，我们则必须将他计划到下下一个软件发布的周期中。

跟踪修复合并

我们常常遇到这样的情况。大型软件产品的一个主要版本发布不仅仅是一次。通常我们会在两个主要版本发布的期间进行小版本以及合并修复包的发布。为了更好的控制小版本以及修复包的范围以及针对性，开发团队会根据不同的需求建立不同的源代码分支，因此如何将客户提交的缺陷和不同代码分支联系起来也是一个通常遇见的问题。不过基于以上定义的修复原则，我们通常要求工程师在修复缺陷时，将修复的代码合并到以后发布版本所有的分支中。这样就会避免同一问题在不同的分支中出现。关于 ECM 系统在这里的使用。我们要求工程师在 ECM 的缺陷记录中除了描述缺陷的修复的方法，更重要的是在哪些分支中进行了合并。它将能够帮助质量保证人员在不同的分支中对它进行验证。

进行修复验证

为了保证相同的缺陷不会在不同的软件发布版本中出现。对于质量保证人员，进行客户提交的缺陷修复验证也是一项具有挑战的活动。同样，基于定义修复原则，质量保证人员需要在缺陷发现版本及以后所有发布的新版本中进行验证。从而，在 ECM 系统中，当质量保证人员发现客户提交的缺陷已经被修复后，需要仔细审核开发人员的纪录，审视这个缺陷是否已经合并在所有发布的新版本中。如果没有发现相关纪录，这个缺陷的修复将被拒绝并发回到开发工程师那里重新修复或更新。如果有相关纪录，质量保证人员需要在不同分支最新的开发版本上进行验证并记录自己验证的版本信息。在所有验证完全前保持缺陷的修复状态，只有当所有验证完全后才去将状态改为验证状态。

在客户提交的缺陷处理流程中，ECM 系统可以起到非常好的辅助作用。但是，明确的缺陷修复原则定义以及修复计划的确认才是这个流程的关键。另外，对于开发以及质量保证人员的培训令其明确原则从而提升意识，也是这个流程中极其重要的一环。