PMI变更管理与WWPMM变更管理之比较.docx

PMI 变更管理和 WWPMM 变更管理之比较如何利用 Rational ClearQuest 进行变更管理张 颖, 软件工程师, IBM简介：本文阐述了变更管理的重要性，WWPMM 和 PMI 的变更管理流程，以及如何利用 Rational ClearQuest 进行变更管理。希望给相关人员提供参考。本文的标签： best_practices, process_management, rational_clearquest, 变更管理, 团队开发, 软件开发生命周期标记本文！发布日期：2011 年 6 月 30 日 级别：初级 访问情况743 次浏览 建议：0(添加评论) 您的评分跳转到主要内容 登录 (或注册) 中文PMI 变更管理和 WWPMM 变更管理之比较如何利用 Rational ClearQuest 进行变更管理张 颖, 软件工程师, IBM简介：本文阐述了变更管理的重要性，WWPMM 和 PMI 的变更管理流程，以及如何利用 Rational ClearQuest 进行变更管理。希望给相关人员提供参考。本文的标签：best_practices,process_management,rational_clearquest,变更管理,团队开发,软件开发生命周期标记本文！发布日期：2011 年 6 月 30 日级别：初级访问情况743 次浏览建议：0(添加评论)平均分 （共 0 个评分 ）下载Rational ClearQuest 试用版|Rational ClearQuest ALM Appliance（预配置系统）下载更多的IBM 软件试用版，并加入IBM 软件下载与技术交流群组，参与在线交流。1 引言要理解变更管理的重要性，首要要理解两点：首先：变更是不可避免的。一个项目从开始就处于不停的变化中，用户需求的改变需要调整设计或者计划，测试阶段发现的 bug 也需要对代码进行相应修改，甚至市场或者商业竞争环境的改变也会导致项目计划产生一定的改变。因此，项目和变更是密不可分的。其次：任何项目都处于一个约束的环境中。我们知道项目具有临时性，也就是说项目是有一定的时间限制，并且受到资源的约束，如进度、成本、质量要求的限制等。而任何变更的发生都不可避免的会对成本、时间、资源、风险等其他项目要素产生一定的影响，从而导致项目的输出迥异。因此需要在不可避免的变更和项目现在的限制因素之间找到一种平衡，从而保证变更朝着项目有利的方向发展，使其处于受控和可控状态，并可随时跟踪回溯到某个历史状态，这就需要对变更进行管理。有计划的变更管理是项目成功的一个保证。系统性的变更管理能给项目带来以下好处： 改善可交付成果的质量，提高客户满意度； 更利于项目的沟通，提高项目的可跟踪性和可审计能力。项目中不同的角色都会被定义，项目成员和项目干系人能够明确变更是如何被管理的； 确保所有变更都被授权，保证项目成员所从事工作和变更请求的一致性，从而避免范围的蔓延，成本的超支以及进度的延迟等，减少项目失败的可能性，避免不必要的损失。回页首2 WWPMM 和 PMI 变更管理的相关过程，输入以及输出变更管理过程由一系列相互迭代的步骤组成来管理变更。其主要目的是确保每一项变更请求都被相关干系人理解、评估、记录并进行相应的处理，如接受、拒绝或者推迟变更；确保被接受的变更请求按计划执行，保证项目范围的可控和可追踪性。变更管理主要用于解决以下问题：需要做什么；什么时候做；谁来完成；如何完成；需要记录什么。PMI 和 WWPMM 的知识领域中都涉及了变更管理，但是两者在子过程定义、输入、输出上存在一定的区别和联系。本文将对二者进行比较和分析。在 WWPMM 中变更管理由四种要素组成： 变更管理流程； 变更控制委员会； 变更管理文档； 变更请求。1. 变更管理流程：包括四个子过程：评估变更请求，分析变更的影响，批准变更请求，对变更单进行跟踪。评估变更请求的主要目的是快速决定如何处理变更请求：如拒绝，接受或者在作出决定之前进一步进行分析。分析变更的影响过程能为 CCB(Change Control Board，也称变更控制委员会 ) 或者高层管理人员提供更为详细的关于变更影响的信息，以便为进一步决策提供依据。影响分析涉及到如何实现变更以及对应的成本和收益分析。批准变更请求通过对经过变更影响分析后的变更请求做进一步处理，此过程需要 CCB 或者高层的支持以便获得相应的资源，与此同时，对变更的决策权需要事先定义在变更管理计划中，项目经理在此过程中要负责该类变更得到及时的处理和沟通。对变更单进行跟踪则是通过修订项目管理计划和过程以便及时反映批准的变更请求，同时周期性的来检查变更的状态来确保变更的实施进展。以上每一个子过程都有自己对应的输入输出，列表如下：表 1. WWPMM 变更管理子过程输入输出列表子过程输入输出评估变更请求变更请求变更请求（更新）变更日志变更日志（更新）工作产品列表分析变更的影响变更请求和变更日志变更请求（更新）合同操作进度沟通管理计划成本和人力资源计划OBS、PBS、WBS 等里程碑列表、项目进度计划操作流程质量和风险管理计划批准变更变更请求变更请求（更新）变更日志变更单追踪变更单变更请求变更请求（更新）变更单变更单（更新）沟通管理计划沟通管理计划（更新）人力资源计划成本计划（更新）财务计划可交付成果定义（更新）可交付成果定义人力资源计划（更新）里程碑里程碑（更新）OBS/PBS/WBS操作进度质量和风险管理计划项目流程描述2. 变更管理文档：主要包含变更日志和变更单。其中变更单用于指导变更的实现过程，而变更日志则用来记录所有的变更信息，包括所有者、日期、状态等，并为以后对变更作出决策提供依据。3. 变更请求：主要来自三个方面：技术的变更、市场的变更以及合同的变更。 技术的变更：指技术的改变或者技术可交付成果的改变。这类变更通常出现在项目的执行阶段，由项目内部成员提出，如用于提高质量的自动化测试要求等。此类变更通常需要记录、分析和批准，但不需要告知客户。 市场变更：指为了应付市场环境或条件的变化或者出于竞争因素需要提高产品或者服务的质量而提出的变更。市场变更通常是外部的并且属于项目范围之外。 合同变更：与客户或者供应商之间正式的合同变更。包括关键的可交付成果、价格、质量需求等。合同变更通常会影响进度成本范围等，合同变更由于涉及法律相关知识，其变更过程更为复杂，除了必须遵循变更管理流程外还需要额外的文件记录这些变更。在 PMI 中，变更管理是项目整合管理的一个环节，属于项目的监控过程组。PMI 中实施整体变更控制是为了审查所有的变更请求，批准变更并对可交付成果，组织过程资产，项目文件和项目管理计划的变更的过程。其主要目的是通过否决或者批准变更确保只有经批准的变更才能纳入修改后的基准中。其输出输出以及相关工具与技术列表如下：表 2. PMI 变更管理输入输出输入工具与技术输出项目管理计划专家判断变更请求状态（更新）工作绩效信息变更控制会项目管理计划（更新）变更请求项目文件（更新）：包括变更请求日志或其他受影响文件事业环境因素组织过程资产上表中输入的变更请求主要来自于项目管理知识领域的其他项目过程，包括核实范围和控制范围、成本控制和进度控制、实施质量保证和控制以及管理项目团队、监控风险等过程产生的变更请求。而工作绩效信息是在指导与管理项目执行过程中收集的，关于为完成项目工作而正在进行的项目进度活动的状态信息和数据，包括可交付成果的状态、纠正措施、预防和补救措施、完工估算等。而项目管理计划作为输入则为对变更决策提供基线参考。从 WWPMM 和 PMI 的变更管理过程的输入来看，两者都强调基于以往项目进展以及项目计划的情况之上结合具体的变更请求来考虑变更的具体决策，从输出上都强调对变更的任何决定和信息都必须加以记录并反映到相应的文档中去，从而做到有章可循。回页首3 WWPMM 和 PMI 变更管理流程的比较变更请求是对处于控制过程中的项目的某些文档或者某些方面所提出的进行变更的请求。它将影响正在进行或者将要执行的工作，改变项目的计划或者过程，甚至合同的内容。对于任何提出的变更请求，都必须进行相应的评估和分析，以供后续决策。WWPMM 和 PMI 定义了各自的变更管理过程。WWPMM 的变更流程：图 1. WWPMM 变更流程上述流程中，任何项目干系人都可以在必要的时候提出变更请求，变更请求可以口头提出，但必须以书面的形式记录下来并提供相关的文档以便更好的理解。在上图步骤二中对 CR 进行评估的时候，项目经理和项目管理团队需要对变更做初步的分析和评估，并决定由哪些 CCB 的成员对接受的 CR 进行进一步分析。在对变更作出分析和决策的时候需要考虑以下因素： 影响的层面：如严重、中等、以及细微；较严重的影响通常会影响到项目的某个里程碑或者项目的结束日期或者波及项目的成本。 优先级：紧急的、较高的、中等的、以及低优先级的；通常紧急的变更需要很快解决，而中等优先级的变更需要在下一个 release 之前解决，而低优先级的变更则可以推迟到下一个阶段。 变更的类型：简单和重大的变更。对于简单的变更，不一定要遵循上述所有流程，只需要遵循步骤一、二、五、七、九这几个步骤即可。相对于 WWPMM，PMI 的变更流程要稍微简单，它将变更的执行过程体现在各个具体九大管理知识领域的执行和控制阶段中。PMI 的具体变更管理流程如下：图 2. PMI 变更管理流程PMI 中变更请求包括纠正措施，预防措施和缺陷补救三种。预防措施通过实施某项活动来降低项目风险消极后果的发生概率的书面指令。纠正措施则是为使项目工作的未来期望绩效与项目管理计划保持一致而对项目执行工作下达的书面指令。其中预防和纠正措施不会影响项目的基准，而只是对基于基准的具体实施工作产生影响。相比较 PMI，WWPMM 因为其具体流程是根据实际项目经验总结，对变更管理的流程更为详细和细致。而 PMI 对该过程的定义是一个指导性的框架。但两者过程都包含了基于实际情况根据具体变更请求具体分析后再作决策的思想，WWPMM 是对 PMI 所包含框架的进一步细化。回页首4 变更管理中的角色和职责变更管理需要所有项目干系人的参与，包括项目经理、项目团队成员、CCB 的成员以及客户等。但不同的角色在变更管理中所承担的责任和职责不一样。根据其职责，在变更管理中可以分为以下几种角色：项目经理、客户、变更发起人、评估人、验证人、项目控制委员会等。1. 项目经理：其主要职能是设计和制定项目管理过程，保证项目成员或者被影响的项目干系人能够遵循项目变更管理过程；管理变更控制过程以及相应的文档，能够批准小范围的变更请求；在项目成员和项目干系人中沟通变更请求的完成情况，包括变更的状态、CCB 的决定、变更完成的情况等。2. 客户：参与变更管理过程，提出变更请求或者参与变更影响的分析，在特定的情况下批准变更。任何影响项目的可交付成果、客户的资源、项目或者产品的成本，项目进度的变更都需要客户的批准。3. 变更发起人（Originator）：提交变更请求的人员，该人员可以是项目组成员、客户或者其他项目干系人。4. 评估人（Evaluator）：对提出的变更的影响进行分析的人员，可以是 CCB 的成员，项目成员等。主要是评估变更来源、变更理由、变更影响、变更代价等。5. 验证人（Verifier）：负责验证和判断变更是否被正确执行的人员。6. 项目控制委员会 CCB：CCB 由项目双方项目管理人员（部门领导、高层经理、项目经理）、技术人员（开发人员、测试负责人、质量保证负责人 QA）、商务人员等成员组成，一般在变更管理过程正式执行前成立，对于大型项目可以有多个 CCB。其主要作用是负责评估那些被提交上来的变更请求，针对这些变更的目的、要求和影响来决策，确保所有提出的变更都进行了相应的影响分析，对批准了的变更请求进行优先级分析，确保所有的变更请求都被恰当的记录，一边跟踪和审计。对已经同意实施的变更请求，安排相关的变更实施负责人和相关联的协作组织。回页首5 利用 IBM Rational ClearQuest 进行变更管理上面讲述了 WWPMM 和 PMI 变更管理的基本知识，并对两者作了对比和分析，下面将具体结合 IBM Rational ClearQuest 来展示如何实现变更管理流程的定制。在介绍定制过程之前，先对 Rational ClearQuest 作基本的介绍。IBM Rational ClearQuest 是一个可定制、跨平台的变更管理系统，它通过对软件开发生命周期中的各种变更请求的跟踪与管理，为按时交付高质量软件产品提供保障。其特点是： 高定制性，可根据项目的大小完全定制界面和工作流机制，适合各种开发环境，同时它支持多种行业标准数据库（Microsoft Access、SQL Anywhere、SQL Server、DB2、Oracle），可跨越多种数据空间； 能有效的记录，管理和追踪变更请求，并控制变更请求之间的关系。可以捕获的变更请求包括测试阶段的 bug，需求阶段的需求扩展等。所有的变更请求的信息统一存储与数据库中，并提供状态追踪机制。同时不同的变更请求之间还可建立联系，如父子关系、关联关系等，便于集中管理和控制。 提供客观的统计功能，随时了解项目状态。ClearQuest 提供了各种形式的报表，查询以及统计指标，使得项目管理人员可以更为科学的管理、规划、监控和调配，及时了解项目现状。 方便项目团队的沟通和协作。ClearQuest 中完善的电子流管理系统可以和企业现有邮件服务系统结合，当 CR 发生变化的时候，可自动通知相关人员，从而提高了沟通的效率，促进团队之间的沟通协作。利用 ClearQuest 中的 ClearQuest Designer 可以定制变更管理流程。一般定制一个变更管理流程需要经过以下几个过程： 定义数据：定义用户需要在 ClearQuest 中收集和管理的数据，主要是记录类型和每个记录类型的数据项。 定义状态模型：每个记录类型都有自己的状态模型，状态模型由状态、状态类型、操作和数据项行为等构成。 建立记录表单：提供表单给用户输入、查看或处理数据。 添加必要的 Hook：通过 Hook 代码来做权限控制、数据关联处理或其他相关业务处理。由于本文篇幅有限，本文主要阐述如何建立状态模型。其余步骤读者可以查看用户手册。定义状态模型ClearQuest 使用一系列状态来跟踪变更的过程，用户在进行相关操作时，往往会伴随状态的变化。在 ClearQuest 中一个变更在其生命周期中状态转换过程如下：图 3. 变更的状态转换ClearQuest 使用状态转换矩阵来记录状态间的转换，即状态转移。状态转移包含一个源状态、一个目的状态和将记录从原状态转移到目的状态的操作。通常，记录当前的状态是源状态。打开 ClearQuest Designer 的工作区间，选择 Record Types 要查看的记录类型 States and Actions 双击 State Transition Matrix 即可看到图四所示的状态转换矩阵。图 4. 状态转换矩阵通常完成状态模型需要经过“添加状态”，“添加行为”以及进行“映射”三个步骤。用户在状态转换矩阵中右键单击，选择“Add State”菜单项；或选择菜单 Edit Add State。在新状态对话框中输入新状态的名称，点击“OK”按钮即可创建一个新的状态。图 5. 添加新状态选择 Record Types 要查看的记录类型 States and Actions Actions，在右侧列表中右键单击，选择“Add Action”中输入要添加的 Action 的名称，同时设置 Action 的操作类型，如“Change_State”。每一个 Action 有几组相关属性，操作名称，操作类型，权限控制以及 Hook Code。如图六所示。图 6. 添加 ActionAction 添加完毕后，需要和状态进行映射。在 Action 中选择一个 CHANGE_STATE 类型的操作，鼠标右键单击该操作并选择“Action Properties”单项，弹出操作属性对话框。在操作属性对话框中选择“State”签页，再选择源状态和目标状态。图 7. 为状态设置转换在这里设置完毕过后，如果再打开该记录类型的状态转换矩阵，可以看见刚才在操作属性对话框中设置的状态转换。即如图四所示。每个变更管理流程常用的用户有以下三类。 管理组成员，主要指测试小组的领导或开发部门项目经理，管理组成员主要进行决策判断活动。 测试组成员，指具体的测试人员，测试缺陷记录主要由测试组成员提交。 开发组成员，主要是开发部门负责修改测试记录的程序员。这三类用户有不同的操作权限对变更进行处理，变更的状态会随着不同的操作而发生转换。在一个操作定义完毕后需要为不同的用户设置不同的操作权限。选择菜单“Tool”-”User Administrator”添加三组用户，如下图。图 8. 添加用户组添加完毕用户组后选择某个 Action，在 Access Control 列中选择“User Group”，如设置 manager 组的权限为“Assign”。如图九所示。图 9. 设置操作权限要定义一个完整的变更管理过程还需其他操作，如定制记录属性等。由于篇幅有限，读者可查阅相关文档。回页首6 总结变更管理是项目管理中必不可少的一个环节，良好的变更管理不仅仅需要完善的流程作为指导，更离不开优秀的变更管理工具的辅助。本文对 WWPMM 和 PMI 的变更管理过程进行了阐述和对比，并结合 Rational ClearQuest 讲述如何利用工具进行变更管理，特别是 Rational ClearQuest，作为一款较为成熟的管理工具，其产品理念融合了变更管理的思想，能够较为有效的对变更进行管理。希望文章相关内容可以给项目管理人员提供一定的参考。参考资料学习 查看本文的姐妹篇：“PMI 风险管理和 WWPMM 风险管理之比较”，了解风险管理的基本知识以及 WWPMM 和 PMI 风险管理过程的比较和分析。 通过developerWorks 图书频道 : 组织级项目管理体系规划构建与 IBM 全球实践了解更多关于全球项目管理方法论的知识。 通过WWPMM Home获取更多 WWPMM 相关资料。 通过PMI 官网了解更多 PMBOK 相关的项目管理知识。 通过PMBOK 知识体系指南了解 PMI 项目管理框架的信息。 查看如何准