9.2.2 裁剪考虑的因素

因为每个项目都是独特的，所以项目经理可能根据需要裁剪项目范围管理过程。裁剪时应考虑的因素包括：
（1）知识和需求管理：项目经理应建立哪些指南?为了在未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系?
（2）确认和控制：组织是否有正式或非正式的与确认和控制相关政策、程序和指南?
（3）开发方法：组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
（4）需求的稳定性：项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确?
（5）治理：组织是否拥

9.2.3敏捷与适应方法

1、对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间。
2、采用敏捷或适应型生命周期，旨在应对大量变更，需要干系人持续参与项目。因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完成项),通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。在一个迭代开始时，团队将努力确定产品未完成项中，哪些优先级高的未完成项需要在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：⊚ 收集需求；⊚ 定义范围；⊚ 创建WBS
3、在预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和相应的WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完成项（包括产品需求和用户故事）反映 当前需求。

1、范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划用于指导如下过程和相关工作：
（1）制定项目范围说明书； (在描述定义范围)
（2）根据详细项目范围说明书创建WBS (在描述WPS)
（3）确定如何审批和维护范围基准 (在描述控制范围)
（4）正式验收已完成的项目可交付成果。根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。 （在描述确认范围）

2、需求管理计划

需求管理计划的主要内容包括：
⊚ 如何规划、跟踪和报告各种需求活动
⊚ 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告以及变更审批权限
⊚ 需求优先级排序过程
⊚ 测量指标及使用这些指标的理由
⊚ 反映哪些需求属性将被列入跟踪矩阵等。

收集需求

让干系人积极参与需求的探索和分解工作并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目执行开始后对其进行测量。需求将作为后续工作分解结构（WBS ）的基础，也将作为成本、进度、质量和采购规划的基础

2、需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。
最后，需求跟踪矩阵还为管理产品范围变更提供了框架。跟踪需求的内容包括：⊚ 业务需要、机会、目的和目标；⊚ 项目目标；⊚ 项目范围和WBS可交付成果； ⊚ 产品设计；⊚ 产品开发；⊚ 测试策略和测试场景；⊚ 高层级需求到详细需求等。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。

2、需要检查的问题

项目干系人进行范围确认时，一般需要检查以下6个方面的问题：
（1）可交付成果是否是确定的、可确认的。
（2）每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
（3）是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。
（4）审核和承诺是否有清晰的表达：项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须清晰，并取得一致的同意。
（5）项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
（6）项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响。