核心概念：
在项目环境中，“范围”这一术语有两种含义：
1、产品范围。某项产品、服务或成果所具有的特征和功能。
2、项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
3、项目范围的完成情况是根据项目管理计划来衡量的。
4、产品范围的完成情况是根据产品需求来衡量的。
项目范围管理的目的
1、项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
2、管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
3、不镀金。确保 ---- All and Only
a、项目包含了：为了成功完成项目所需的全部工作。
b、项目不包含：与成功完成项目没有关系的其他工作。
范围蔓延（Scope Creep）：
未经控制的产品或项目范围的扩大（未考虑对时间、成本和资源的影响）被称为范围蔓延。
范围蔓延，将挤压项目的成本、时间和资源，将把项目推向失败的边缘。
镀金和范围蔓延区别：
都是不好的事情，镀金是客户没要，是你主动得瑟，范围蔓延是被动的，人家找你做你就答应了。
项目范围管理的发展趋势和新兴实践：BA
需求的重要性：组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。
需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现和维持效益。
注重与商业分析专业人士的合作，以便：
1、确定问题并识别商业需要；
2、识别并推荐能够满足这些需要的可行解决方案；
3、收集、记录并管理相关方需求，以满足商业和项目目标；
4、推动项目集或项目的产品、服务或最终成果的成功应用
管理范围的不同模式：
| 生命周期模型 | 预测型生命周期 | 适应型/敏捷型生命周期 |
| 总体模式 | 在项目开始时对项目可交付成果进行定义，范围变化要走正式变更流程 | 每次迭代开始时定义和批准详细的范围。因此，整体范围被分解成一系列的未完成清单 |
| 何时定义范围 | 在项目开始时收集需求、定义范围、创建WBS，变更需要走正式流程 | 每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建WBS |
| 范围基准是什么 | 根据预先定义的范围基准来确认范围和控制范围 | 使用未完成清单（包括产品需求和用户故事）来反映当前需求。 |
| 何时确认范围和控制范围 | 在每个可交付成果生成时或在阶段审查点时确认范围，而控制范围是持续的过程。 | 每次迭代中，都会重复开展两个过程：确认范围和控制范围。 |
| 基本特征 | 需求稳定，技术成熟。 | 应对大量变更，相关方持续参与 |
项目范围管理的过程：
5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划 的过程。
5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。
5.3 定义范围 — 制定项目和产品详细描述的过程。
5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。
5.6 控制范围 — 监督项目和产品的范围状态，管理范围基准变更的过程。
5.1-5.4 都是在制定计划，5.5 是为了验收、5.6是为了变更做准备。
裁剪时需要考虑的因素：
因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括（但不限于）：
1、知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系？为了在未来项目中重复使用需求，项目经理应建立哪些指南？
2、确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南？
3、开发方法。组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？
4、需求的稳定性。项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确？
5、治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南？
在敏捷或适应型环境中需要考虑的因素：
对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项。
扫一扫
2320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
