第五章范围管理

要说明做什么和不做什么。
定义清楚验收标准。

项目范围的完成是靠项目管理计划来衡量的。
产品范围的完成是靠需求来衡量的。

工作分解结构是对可交付成果的分解。
确保项目做且只做成功完成项目所需得全部工作。
定义和控制哪些工作包含的在项目内，哪些不包含在项目内。
确保项目做且只做所需的全部工作，以成功完成项目的各个过程。定义和控制那些工作应该包括在项目内，哪些不在项目内。

预备

• 范围管理强调：不镀金、预防范围蔓延
• 产品范围：是具体产品、服务或成果具有的特性和功能。是物体本身的属性。根据产品需求衡量产品范围的完成情况。
• 项目范围：为交付具有规定特性与功能的产品服务或成果而必须完成的工作。强调的是工作。根据项目管理计划来核实项目范围完成情况。

• 项目范围有时候包括产品范围。
• 范围管理计划于范围说明书的区别
• 范围管理计划：How 如何去做
• 范围说明书：What 是什么

规划范围管理

创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。
如何定义/确认/控制项目范围的过程。

输入 工具和技术 输出 1、项目管理计划（体现渐进明细性） 1、专家判断 1、范围管理计划 2、项目章程 2、会议 2、需求管理计划 3、事业环境因素 4、组织过程资产

项目章程中的高层次需求能够帮助制定范围和需求管理计划

范围管理计划（如何防止范围蔓延）

有助于降低项目范围蔓延的风险
定义如何完成如下过程：

• 制定详细项目范围说明书
• 根据详细项目范围说明书创建WBS
• 维护和批准WBS
• 正式验收以完成的项目可交付成果
• 处理对详细项目范围说明书的变更

需求管理计划（如何给需求排序）

需求是干系人提出的，是发散的状态
记录如何分析、记录和管理需求
生命周期各阶段间的关系对如何管理需求有很大影响
定义如何完成如下过程：

• 如何规划，跟踪和报告各种需求活动
• 配置管理活动的要求
• 需求优先级排序
• 产品测量指标
• 例如跟踪矩阵的项

收集需求

为实现项目目标而确定、记录并管理干系人的需要和需求的过程。
定义并记录干系人的需求的过程。
需求包括发起人、客户和其他干系人的已量化并记录下来的需要和期望
需求时工作分解结构，成本/进度/质量规划的基础

输入 工具和技术 输出 1、范围管理计划 1、访谈 1、需求文件 2、需求管理计划 2、焦点小组 2、需求跟踪矩阵 3、干系人管理计划 3、引导式研讨会 4、项目章程 4、群体创新技术 5、干系人登记册 5、群体决策技术 6、问卷调查 7、观察 8、原型法 9、标杆对照 10、系统交叉图 11、文件分析

干系人登记册：姓名、角色、主要需求、立场，没有干系人的排序
干系人管理计划中：提现排序
项目章程：高层次的需求

需求分类：

• 业务需求
  
  • 干系人需求
  • 解决方案需求
    
    • 功能性需求
    • 非功能性需求：性能
  • 过渡需求：临时性的，培训的需求
  • 项目需求：商业需求、项目管理需求、交付需求
  • 质量需求

收集需求的工具（焦点访谈引二群问观原）

访谈：

• 通常一对一，面对面交谈
• 可能获取机密信息
• 问问题顺序：1、问答题；2、选择题；3、判断题

焦点小组：受过专业训练的主持人

   可分成不同小组和主题

（跨职能）引导式研讨会

   研讨会是快速定义跨职能需求和协调干系人差异的重要技术   联合应用设计/开发（JAD）   质量功能展开（QFD）   用户故事：对所需功能的简短文字描述，京城产生于需求研讨会，用于敏捷开发

（快速）头脑风暴：

   优点： 快、发散；缺点：容易受影响   速度快、但容易受影响   本身不包含投票、排序，分类等过程，常与其他群体创新技术共同使用

（投票排序）名义小组技术（Nominal Group Technique，NGT）

投票排序

思维导图：

将放射性思考（头脑风暴的结果）图形化的方法

（分组分类展示）亲和图：

头脑风暴法会议、分成小组

（发散）群体创新技术小结

头脑风暴法、名义小组技术、感念/思维导图、亲和图、多标准决策分析

群体决策技术：

• 群体创新技术：识别项目和产品需求
• 群体决策技术：对多个方案进行评估，达成某种结果
  

用于生成产品需求，并对产品需求进行归类和优先级排序
包括：

• 一致同意
• 大多数原则（超过50%，投票者微奇数）
• 相对多数原则
• 独裁

问卷调查：

设计书面问题，向众多受访者快速收集信息
适合于：受众多样化，快速完成，地理位置分散，开展统计分析

（不能说）观察（工作跟踪）：

难以说或不能说
工作跟踪
旁观式观察、体验式观察

（渐进明细）原型法

故事版：通过一系列图像或图示展示顺序或导航路径
敏捷开发中：可将故事版分为三列：

• To Do：还没做的
• Doing：正在做的（关注点）
• Done：做完的

标杆对照（Beanchmarking）

• 概念：实际项目实践与可比项目实践对比（两个项目）
• 使用范围：组织内部或外部，同一或不同领域
• 两个目的：识别最佳实践，为绩效考核提供基础
• 只要有可比性都可以作为标杆
• 不同领域不同行业都可以作为标杆
• 同一个时间点一般直选一个标杆

系统交互图

• 对产品范围的可视化描述
• 显示业务系统及其与人和其他系统之间的交互方式
• 显示：系统输入，输入提供者，系统输出，输出接受者
• 建立了参与者和系统之间的本质关系

文件分析

• 分析文档，挖掘需求
• 文件分析技巧：头脑风暴+焦点小组会议

需求文件

描述各种单一的需求将如何满足于项目相关的业务需求
包括：

• 可跟踪的业务目标和项目目标（业务需求）
• 干系人对沟通和报告的需求（干系人需求）
• 功能要求：非功能性要求；质量要求（解决方案需求）
• 验收标准（项目需求）
• 对支持和培训的需求
• 与需求有关的假设条件和制约因素

一开始概括性的需求，然后逐步细化

敏捷开中的需求（Story）

• INVEST原则
  
  • Independent：独立的
    一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。
  • Negotiable：便于沟通的
    一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。
  • Valued：有价值的
    每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
  • Estmable：可估计的
    开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
  • Small：短小
    一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。
  • Testable：可测试的
    一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。

需求跟踪矩阵RTM:监控需求是否已经完成

需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值
为在整个项目生命周期中跟踪需求提供了一种方法
为了管理产品范围变更提供了框架
包括：

• 从需求到业务需要、机会、目的和目标
• 从需求到项目目标
• 从需求到项目范围/WBS中的可交付成果
• 从需求到产品设计
• 从需求到产品开发
• 从需求到测试策略和测试场景/脚本
• 从高层次需求到详细需求

定义范围

制定项目和产品详细描述的过程。

输入 工具和技术 输出 1、范围管理计划 1、专家判断 1、项目范围说明书（ss） 2、项目章程 2、产品分析 2、项目文件（更新） 3、需求文件 3、备选方案生成 4、组织过程资产 4、引导式讨论会

用于确定项目范围边界的文件叫做项目范围说明书
范围管理计划、需求文件、项目章程（假设条件、制约因素）

工具

产品分析

价值（V）=功能（F）/成本(C)（价值工程和价值分析核心公式）

针对以产品为可交付物的项目

包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析

备选方案生成

包括头脑风暴、横向思维和备选方案分析等

项目范围说明书

详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作

包括：
1. 产品范围描述
2.验收标准
3.可交付成果
4.项目的除外责任
5.制约因素
6.假设条件

表明项目干系人之间就是项目范围所达成的共识

最详细描述制约因素和假设条件的文件时范围说明书

创建WBS（work breakdown structure）

将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
工作分解结构组织并定义项目的总范围
WBS最底层的组成部分叫工作包
WBS不表示逻辑关系和历时，只表示范围
WBS强调层次的分解，只表示范围，不表示逻辑和历史

输入 工具和技术 输出 1、范围管理计划 1、分解 1、范围基准 2、项目范围说明书 2、专家判断 2、项目文件（更新） 3、需求文件 4、事业环境因素 5、组织过程资产

创建WBS时输出范围基准，定义范围时输出项目范围说明书。

创建工作分解结构（100%分解原则）

• WBS具有层次结构，有团队成员共同完成制作
• 账户编码COA（Code of Account）：每个组成部分分配唯一的编码，识别所在的层次和位置。
• 控制账户（Control Account）是一种管理控制点，用于挣值分析（高低决定控制粗细，控制账户的位置越高控制监控的力度越粗糙，控制账户的位置越低控制监控的力度越精细）
• 每一个控制账户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制账户
• 规划包（Planning Package）：在CA之下，工作包之上，知道工作内容，但暂时不确定详细工作分解。是一个中间态，最后变成工作包。
• 工作包（Work Package）：位于工作分解结构每条分支最底层的可交付成果或项目工作组成部分

WBS对于项目的意义

1、了解项目的范围层次结构
2、进行挣值分析的基础
3、明确责任人

WBS分解原则

• 100%包含原则：WBS分支的上下包含关系，WBS整体包含了项目所需的所有工作。
• MECE(Mutually Exclusive Collectively Exhaustive 互斥，完全穷尽)。
• 不可再分：最底层必须有相对独立的属性，不可再分。
• 信息透明：分解到可以充分估算完成该成果所需的时间、费用、资源。
• 80小时：（IT行业）工作包可以在80小时（10工作日）完成（行业经验）。
• 独立责任：分解到可以安排一个责任者（个人或团队）负责。
• 滚动式规划：远期工作或信息暂时不足的可交付成果，可暂时不分解，等信息充分继续分解。

分解

• 目的：便于控制。
• 程度：能够可靠的估算工作费用和持续时间。
  

工作包是工作分解结构的底层;能够可靠地估算和管理工作成本和活动持续时间的位置。
可作为分解第二层：项目生命周期各阶段，主要的可交付物，子项目。
不能分解：很远的将来要完成的成果（WBS也是渐进明细的定义）

WBS词典&范围基准

工作分解结构词典（WBS词典）对工作分解结构组成部分（包括工作包和控制账户）进行更详细的描述。
内容：账户编码标识号；工作描述；负责的组织；进度里程碑清单；相关的进度活动；所需的资源；成本估算；质量要求；验收标准；技术参考文献；合同信息；
WBS词典是最详细的范围描述。
范围基准包括：项目范围说明书，WBS,WBS词典。
在整个项目中有三个基准：

• 范围基准：项目范围说明书、WBS、WBS词典， 一个项目有一个范围基准，有三分文件（项目范围说明书、WBS、WBS词典）
• 进度基准：经过批准的进度模型
• 成本基准：按时间分段经过批准的预算

确认范围

正式验收已完成的项目可交付成果的过程。

输入 工具和技术 输出 1、项目管理计划 1、检查 1、验收的可交付成果 2、需求文件 2、群体决策技术 2、变更请求 3、需求跟踪矩阵（用于监控） 3、工作绩效信息 4、核实的可交付成果 4、项目文件（更新） 5、工作绩效数据

项目管理计划和工作绩效数据做比较，经过检查 ，输出工作绩效信息

• 正式验收已完成的项目可交付成果的过程。
• 确认可交付物带来商业价值，满足项目目标，满足干系人预期的使用需求。
• 确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户与发起人的正式验收。
• 如果项目提前终止，确认范围也要做，要查明并记录完成的水平和程度。

确认范围与控制质量的区别

• 确认范围：可交付成果的验收
• 控制质量：可交付成果是否正确、是否满足质量要求
• 控制质量通常先于确认范围进行，也可同时进行

需求跟踪矩阵&检查

I需求跟踪矩阵

需求跟踪矩阵用于范围管理的两个监控过程，不多不少的完成。

T检查Inspection

很多同义词：审查、产品审查、审计、巡查（review，product review，audit，walkthroughs）。
确认范围和控制质量，用到了检查。控制质量是团队内部检查，确认范围是项目团队和客户一起审查。

O验收的可交付成果

怎样证明验收过了：签字的文件。

控制范围

监督项目和产品的范围状态，管理范围基准变更的过程。

输入 工具和技术 输出 1、项目管理计划 1、偏差分析 1、工作绩效信息 2、需求文件 2、变更请求 3、需求跟踪矩阵 3、项目管理计划（更新） 4、工作绩效数据 4、项目文件（更新） 5、组织过程资产 5、组织过程资产（更新）

项目管理计划与工作绩效数据通过偏差分析形成工作绩效信息

• 监督范围状态，管理范围变更
• 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延
• 范围蔓延和镀金不可取，即便能使客户满意
• 范围蔓延是客户发起的，镀金是团队主动的
• 变更不可避免，每个项目都必须强制实施某种形式的变更控制