6.4 变更管理学习 文档 参考.pptVIP

6.4 控制需求变更 6.4.1 需求变更的原因 (1) 问题发生了改变 (2) 环境发生了变化 (3) 需求基线存在缺陷 (4) 用户变动 (5) 用户对软件的认识变化 (6) 相关产品的出现 问题改变 相关产品出现 需求变更 用 户 认 识 变 化 基线存在缺陷 环 境 变 化 用户变动 6.4.2 需求变更的应对策略 在需求开发之后冻结需求是不恰当的做法 正确的做法是在形成需求基线之后，进行需求的变更控制。 需求变更控制并不是要限制甚至拒绝需求的变化，它是以一种可控制的严格的过程方式来执行需求的变更。 通过需求的变更控制，项目负责人可以在面对需求的变化是做出周全的业务决策、这些决策在控制产品生命周期成本的同时，还可以提供更高的客户价值和业务价值。 6.4.3 变更控制的典型过程 变更控制的一个典型过程是： 需求的提请者需要以正式的渠道提请需求的变化要求，例如通过双方建立的协商机制，或者通过联系开发人员、项目管理人员、市场人员或者技术支持人员等。 提交的需求变化请求都会被交给请求的接受者，可能是以书面形式，也可能会以电子文档的格式。 评估需求变化可能带来的影响，项目可能会指定固定的评估人来执行评估。需求变更评估的内容要以正式文档的方式固定下来，并提交给变更控制委员会。 变更控制委员会依据需求变更评估的信息作出批准或者拒绝需求变化的决定。 经过变更控制委员会批准的变更请求会被通知给所有需要修改工作产品的团队成员，由他们完成变更的修改工作。可能会受到影响的工作产品包括需求文档、设计文档模型、用户界面、代码、测试文档和用户手册等。 为了确保变更涉及的各个部门都得到了正确的修改，通常还需要执行验证工作。 验证工作完成之后修改者才可以将修改后的产品付诸使用，并重新定义需求基线以反映这一变更。 6.4.3 变更控制的典型过程 变更控制的一个典型过程是： 6.4.4需求变更控制过程中的注意事项 1. 认识到变更的必要性，并为之制订计划 项目团队必须认识到系统需求的变更是不可避免的，甚至还是必需的。认识到将会有一定数量的变更发生并为之制定变更控制计划是成功进行变更控制的关键。 计划的内容应该包括： (1) 定义明确的变更控制过程，建立变更控制的有效渠道。所有的需求变更都应该遵循这一控制过程。如果提交变更请求的过程与此过程不符，则不于考虑。 (2) 所有提交的需求变更请求都要进行仔细的评估。 (3) 是否进行变更的决定应该由变更控制委员会统一作出。对于未获批准的变更除可行性研究之外，不应再做其他的设计和实现工作。 (4) 必须对变更的实现结果进行验证。 (5) 需求的变化情况要及时的通知到所有会受到影响的项目涉众。 6.4.4需求变更控制过程中的注意事项 2. 维护需求基线升级变更记录 (1) 要更新需求基线，保证项目涉众可以访问到最新的需求。 (2) 保留需求变更表单的记录，尤其是对批准或者否决的每一个变更请求的理由都要进行记录。 (3) 绝不能删除或者修改变更请求的原始文本。 需求基线的维护工作可以让所有涉众都能了解需求基线的变更情况，使得团队能够区分已知需求、旧需求、新需求以及曾经被增加、修改或者删除的需求。 3. 管理范围蔓延 在需求变更的过程中，对合理和不可避免的需求变化要进行有效变更，但是对不合理的变更请求也要敢于说不。范围蔓延就是一类最为常见的不合理的需求变化请求。 范围蔓延是指在需求基线确定之后，再行大幅度增加新的特性、功能和需求，而且这些新增部分是不符合预期的项目前景或者超出预期的项目范围的。因为超出了原来的预算范围，所以范围蔓延的变更请求会消耗额外的项目资源，使项目失去控制。对范围蔓延的管理，要根据业务目标、产品前景和项目范围，评估每一项提议的新增需求和特性。当然管理范围蔓延并不意味着要绝对拒绝任何的范围蔓延，如果涉及非常重大的业务目标调整和市场机遇变化，也可以考虑进行灵活的应对。  4. 灵活应对变更请求 如果需求变更的请求，尤其是范围蔓延的请求对项目的影响过于重大，原则上是需要拒绝的。但是如果变化的要求对客户意义重大，可以为他们取得巨大的利益，那么拒绝的做法也未必正确。在此情况下，一个更加灵活的做法是和客户重新协商原先的项目协定，可能包括： (1) 推迟产品的交付时间。 (2) 要求增派人手，当然这个做法只在有限的情况下有效，因为很多情况下，增加人手只会使得项目更加落后。 (3) 要求员工加班工作，一段时期的加班会耗尽员工的储备精力，加班不能是长期的工作状态，一般以三十天为限，否则会产生很多消极影响。因此这个做法只能适度使用。 (4) 推迟或者去除尚未实现的优先级较低的需求。 (5) 容许产品质量的降低，当然这个做法是最不提倡的，因为低质量的产品会伤害整个