田海立

2012-9-14

 

软件工程绝不仅仅是书面的理论的学科，是实践性很强的。软件工程源自于西方管理科学理论与知识，并在很多西方的公司得到实践。笔者有十余年的工作经历，服务 过全球领先的巨头公司，也服务过占绝大多数的国内公司。软件工程出身，看到学校里学习的理论知识在西方公司确实能实际执行，且效果良好；而国内很多公司做 事几乎还是毫无章法，并且状况还将一直持续。改变这个状况是一个系统过程，而我辈所能做的是从点滴做起，逐步改善。

 

本文从RUP(RationalUnified Process)推荐的变更管理出发，看实际工作中如何定制适合自己团队与项目的变更管理策略与工作机制。

 

一、RUP中的变更请求（Change Request / CR）管理

 

下面两个图是RUP中实例中的变更管理的活动图（图一）与CR的状态图（图二）。

图一、RUP中的变更管理活动示例

 

 

图二、RUP中的变更请求的状态图

 

这两个图描述的信息很明确，这里不做阐述。

 

二、变更管理实战

 

下面体现了RUP中变更管理的精髓。但是恰恰很多组织在实际定制时给定制掉或削弱了。

 

1) 所有涉众都可提交变更请求（CR）

 

所有项目相关的人员应该都能提交CR。因为项目中的任何人员都可能会对项目有自己的看法，这应该有出口，把这个想法提交CR，而CR可以是新的需求也可以是BUG。新的CR也不一定需要在当前迭代周期中去实现，需要经过CCB审核决定。

如果CR的提交者不是测试人员，在CR的后续跟踪过程中，需要测试经理指定测试人员来Verify。

 

所有项目相关的人员都提交CR，不应停留在允许，而应该建立机制来鼓励这种行为。

在实际执行过程中，往往会有其他非测试人员提交CR的行为不被重视与执行，到后来就会发现除了测试人员提交CR，其他人不再提交，这样可能漏过了很多好的想法，改进项目的机会。

 

2) CCB及CCB复审会议

 

RUP中有CCB (Change Control Board) 变更控制委员会。该委员会监督变更流程，由所有利益方包括客户、开发人员和用户的代表组成。在小型项目中，项目经理或软件构架设计师一人即可担当此角色。

CCB 复审会议 - 此会议的作用是复审已提交的 变更请求。在该会议中将对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重 性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。此会议一般每周开一次。如果变更请求量显著增加或者发布周期临近结束时，该 会议可能每天开一次。CCB 复审会议的成员一般是测试经理、开发经理和营销部门的一名成员。将根据“需要”适当增加与会者。

 

CCB及CCB复审会议着重的几点：

•  所有与会方特别是实现阶段的开发与测试人员进行交流，对CR讨论，能让他们对项目/产品的定义、风格以及项目进度做进一步的沟通，使目标更一致。今后所提交的CR更有针对性，质量更高。
•  CR后续的状态变化是与会方讨论的结果，CR的分配不容易出现相同的问题分配给不同的人员；或者很多无效的或产品定义不明确的CR指定给开发人员，而他们又是无法做出决定的，再反过来assign给其他人这样反复的周转。这些问题在CCB这里分配之前就已经得到解决。
•  CR所提的粒度经过CCB复审会议后会比较一致。在项目不同阶段，所提的粒度是不一致的。比如，刚项目的起始阶段，实现还不完整，粒度就很粗；到了项目后期，问题可能提交的就很细。这做不到完全一致，但是经过不断沟通交流，某个阶段不同人提交CR的粒度会趋于一致。
•  无论什么样的CR，都被同样被复审，以确认变更是否有效，并评估优先级、时间表、资源、风险和严重性。
•  一次会议可能不是处理完所有的CR（包括新提交的CR/补充更新过信息的CR/本迭代周期要考虑的上周期中Postponed的CR）。所以会议之前CCB可委托一个代表要这些CR大致基于优先级或者严重等级做一个列表，按照这样的次序来处理这些CR。

 

这是很多组织没有做到的，会经常遇到：

•  不同现象所描述的相同的问题被不断的提交或者被不同的人反复提交；
•  新 提交的CR直接分配给了开发人员。开发人员理解认知不同，对不明确或者根本不需要做变更的CR，对项目整体有Sense的人会reassign给相关人做 决策，而有些人会不管三七二十一直接做变更。并且一般是根据现象判断在那个模块而assign给了相应的模块，但其原因可能是相同的。这样就不可避免的出 现，不同人在做同一个变更而他们彼此却不知道。

 

这无关乎个人的理解和知识认知水平，作为一个组织需要用制度和机制策略来保证。

CR是作为人员考评的重要依据。如果机制有问题，对人的评价体系建立在不客观的数据基础上，显而易见对团队人员的工作积极性和士气就会是个打击。

 

3) 重复的（Duplicate）/拒绝（Rejected）的CR的处理

CCB 认定重复的/拒绝的CR应该有机会让提交者补充信息。CCB认定重复的/拒绝的CR也不一定就是无效的，这要提交者来确认，可能是提交的信息不明确而被错 认为是重复的/拒绝的。提交者更新CR之后，该CR还会被CCB复审，确定是否有效，并评估优先级、时间表、资源、风险和严重性。。

被提交者确认重复的/拒绝的CR才可以被关闭。

 

4) 推迟（Postponed）的CR的处理

所谓的推迟的CR是指CR是有效的而只是当前迭代版本中不做变更。所以，到下一个迭代周期开始时，上一周期被认为推迟的CR会与新提交的CR以及更新过的CR一起被CCB复审，确定是否有效，并评估优先级、时间表、资源、风险和严重性。

 

5) 已解决（Resolved）与已验证（Verified）的CR

RUP中有测试版本和正式发布版本两个版本，所以针对CR有两个状态Resolved和Verified。

在对Artifacts（不仅限于代码，还可能是需求、分析设计、实施、制作用户支持材料、设计测试等）进行所请求的变更，并被经过Review和单元测试活动之后，CR被确认并标识为Resolved。

在测试版本中，如果已经包含了Resolved的CR，该CR会在该测试版本中被验证，验证通过将该CR标识为Verified，并可以正式发布了。

Verified的CR在发布版本中得到确认才可以关闭（Close）。

 

根据组织的规模和版本发布的频率以及对发布版本质量的要求，不一定所有组织都会有两个版本发布。不过这样确实能对发布出去版本的质量做进一步确认，在制定变更管理策略时，根据需要来定制。

不过不管最后定制的结果如何，最好要有类似上面的两个图，并在组织内部被充分理解并执行！

 

三、工具的选择与定制

变更管理关键的是理念并定制适合自己组织和项目的策略，工具不是最重要的，但是好的适用的工具的选取却是提升效率和增进交流的利器。现在很多免费或商业的变更管理工具中都可以定制做到，只要基本满足下列要求：

 

用户管理

    变更管理工具应该能基于角色配置对用户进行用户管理，这是基本的需求，一般工具都能满足。

CR的状态和相应的转换可定制

    一般工具里都可根据定制增加或改变CR的状态；

    并且从某一个状态到另一个状态转换过程的路径就那么几条，要根据转换图给出可能的下一状态的选择；

    最好CR的状态转换之后，根据转换到的新状态能自动更改相应的Owner。

Email通知

    变更管理工具应该具有基本的Email通知机制。在CR做任何改变时，都能及时通过Email通知该CR感兴趣的相关人。感兴趣的相关人的邮件列表应该可以手动新增加。

报表

    方便功能强大的报表功能对项目CR跟踪和数据分析至关重要。

与配置管理结合

    变更管理工具如果能与配置管理工具无缝结合是最佳的组合。Rational的ClearCase与ClearRequest分别是配置管理工具和变更管理 工具，它们能很好的无缝结合，不过做为商业软件，价格也是很很多公司不能接受的。不过这也不是必须的，在变更管理工具里如果能增加一个字段指向配置工具里 变更的信息也可以了。

分布式Web访问

    这点虽然不是绝对要求的。但是如果你所在的公司有多个办公地点，或者需要在家办公之类的需求的话，这点就是必须的了。