项目范围计划 周 立 新 博士 北京大学软件与微电子学院

内容提纲 1. 项目范围与产品范围 2. 范围管理 2.1 制定项目范围计划 2.2 范围定义 2.3 创建 WBS

1.1 产品范围 刻画一个产品、服务或结果的特点和功能 刻画某项产品、服务或结果的那些特性和功能

1.2 项目范围 成功的交付一个具有特定需求和功能的产品、服务或结果的任务 为交付某项具有特定特征和功能的产品、服务或结果所必须完成的工作。

项目范围与产品范围 项目范围的定义要以其组成的所有产品的范围定义为基础，但是又不限于产品范围，它还包括为了实现这些产品范围内的工作必须要做的管理工作（进度管理等）。 有可能一个产品的范围很大，我们只是将其中的一小部分作为项目，这时，项目范围与产品范围就是交叉关系。

2. 项目范围管理 项目范围管理是确保项目包括成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。 目标：成功完成给定的项目 办法： 确保已经包括了为完成该 项目所需的所有工作； 且仅仅只包括那些工作 目标：成功完成给定的项目

项目范围管理 项目范围管理 5.1 范围规划 5.2 范围定义 5.3 创建 WBS .1 输入 .1 企业环境因素 .2 组织的过程资产 .3 项目章程 .4 初始项目范围说明书 .5 项目管理计划 .2 工具和技术 .1 专家判断 .2 模板，表格和标准 .3 输出 .1 项目范围管理计划 .1 输入 .1 组织的过程资产 .2 项目章程 .3 初始项目范围说明书 .4 项目范围管理计划 .5 已批准的变更请求 .2 工具及技术 .1 产品分析 .2 可选方案识别 .3 专家判断 .4 项目干系人分析 .3 输出 .1 项目范围说明书 .2 请求的变更 .3 项目范围管理计划（更新） .1 输入 .1 组织的过程资产 .2 项目范围说明书 .3 项目范围管理计划 .4 已批准的变更请求 .2 工具及技术 .1 WBS 模板 .2 分解 .3 输出 .1 项目范围说明书（更新) .2 工作分解结构 .3 WBS 字典 .4 范围基线 .5 项目范围管理计划（更新） .6 变更请求

项目范围管理 5.4 范围确认 5.5 范围控制 .1 输入 .1 输入 .1 项目范围说明书 .1 项目范围说明书 .2 工作分解结构 .2 WBS 字典 .3 项目范围管理计划 .4 可交付物 .2 工具及技术 .1 检查 .3 输出 .1 已接受的可交付成果 .2 变更请求 .3 推荐的纠正措施 .1 输入 .1 项目范围说明书 .2 工作分解结构 .3 WBS 字典 .4 项目范围管理计划 .5 绩效报告 .6 批准的变更请求 .7 工作绩效信息 .2 工具和技术 .1 变更控制系统 .2 偏差分析 .3 重新计划 .4 配置管理系统 .3 输出 .1 项目范围管理计划(更新) .2 工作分解结构 (更新) .3 WBS 字典(更新) .4 范围基线 (更新) .5 变更请求 .6 推荐的纠正措施 .7 组织的过程资产 (更新) .8 项目管理计划 (更新)

2.1 范围规划 输入 输出 工具和技术 .1 企业环境因素 .2 组织过程资产 .3 项目章程 .4 初始项目范围说明书 .1 企业环境因素 .2 组织过程资产 .3 项目章程 .4 初始项目范围说明书 .5 项目管理计划 .1 专家判断 .2 模板, 表格, 和标准 .1 项目范围管理 计划

项目范围管理计划 项目范围管理计划是项目管理团队确定、记载、核实、管理和控制项目范围的指南。

项目范围管理计划的内容 根据项目初步范围说明书编制详细项目范围说明书的过程； 能够根据详细的项目范围说明书制作工作分解结构，并确定如何维持与批准该工作分解结构的过程； 规定如何正式核实与验收项目已完成可交付成果的过程； 控制详细项目范围说明书变更请求处理方式的过程，该过程同整体变更控制过程有直接联系。

5.2 范围定义 输入 工具和技术 输出 致力于对项目的目标产品更好地理解：运用系统分析、价值工程、价值分析、功能分析等技术 头脑风暴法 .1 组织过程资产 .2 项目章程 .3 初步项目范围说明 书 .4 项目范围管理计划 .5 已批准的变更请求 .1 产品分析 .2 可选方案识别 .3 专家判断 .4 项目干系人分析 .1 项目范围说明书 .2 变更请求 .3 项目范围管理计 划 (更新) 致力于对项目的目标产品更好地理解：运用系统分析、价值工程、价值分析、功能分析等技术 头脑风暴法 横向思维

横向思维 横向思维运用于企业管理过程之中，变成了通过管理中的横向思维课程。借鉴、联想、类比，充分利用其它领域中的知识、信息、方法、材料，和自己头脑中的问题或课题关联起来，从而提出创造性的设想和方案。按创始人爱德华的观点，纵向思维者依赖于前提、概念、逻辑，具有相当的局限性，而横向思维者是对问题本身提出问题，重构问题，它倾向于观察事物的所有方面——“纵向思维是在挖深同一个洞，横向思维是尝试在别处挖洞。”

横向思维 这种方法的特点是：一、不是过多地考虑事物的确定性，而是考虑它的多种选择的可能性；二、关心的不是怎样在旧观点；三、不是一味地追求正确性，而是追求它的丰富性；四、不拒绝各种机会，尽可能去创造和利用机会。经培训后，企业高层人士可以将横向思维作为一种突破固有模式的思维方式，从而运用于企业的管理之中。

项目范围说明书： 项目初步组织 项目目标 产品范围说明书 初步确定的风险 项目需求说明书 进度里程碑 项目边界 资金限制 项目可交付成果 成本估算 项目配置管理要求 项目技术规定说明书 批准要求 项目目标 产品范围说明书 项目需求说明书 项目边界 项目可交付成果 产品验收准则 项目制约因素 项目假设

目标制定的 SMART 原则 S （Specific results)：即规定一个具体的目标 M (Measurable)：即目标可以用数量、质量和影响等标准来衡量 A（accepted )： 即设定的目标应该被管理人员和员工双方接受 （Attainable & Challengeable） R（relevant ）：即设定的目标应该是与工作单位的需要和员工前程的发展相关的 T （time）：即目标中包含一个合理的时间约束，预计届时可以出现相应的结果 (Traceable)

项目目标示例 IE4.0 浏览器项目的项目前景和目标 此次计划推出的IE浏览器软件，它可以为企业项目干系人和最终用户端提供高速、稳定、总体拥有成本最低的使用体验，可以与微软的Office软件有效集成，这一产品的市场目标是在1998年将IE的市场占有率扩大到65%。

项目目标 演练：写出自己项目的目标： 举例：在150万元的预算内，根据1月15日的楼面布置图纸和说明书，在8月2日建成北京大学软件学院大兴校区的宿舍楼供9月份来报到的新生住。 各组写出自己项目的目标，派一名代表上台讲述。

2.3 创建WBS 输入 工具与技术 输出 .1 组织过程资产 .2 项目范围说明书 .3 项目范围管理计划 .4 批准的变更请求 .3 项目范围管理计划 .4 批准的变更请求 .1 WBS 模板 .2 分解 .1 项目范围说明书 (更新) .2 WBS .3 WBS 字典 .4 范围基线 .5 项目范围管理计划 .6 变更请求

创建WBS 变更 创建WBS 把主要的项目可交付成果分解成较小的、 更易管理的单元，以达到如下目的： 提高对成本、时间及资源估算的精确度。 为绩效测量与控制定义一个基准。 便于进行明确的职责分配。 创建WBS 变更 工期拖延 成本上升 质量缺乏保障

工作分解结构 — WBS WBS 是面向可交付成果的对项目元素的分组，它组织并定义了整个项目范围；未列入工作分解结构的工作将排除在项目范围之外。 可交付成果 可交付 WBS的组件表示产品、成果和服务的正确性

美国国防部防御军品项目WBS模板之一 工作包 工作过程或内容 任务承当者 工作对象 完成工作所需的时间 完成工作所需的资源

示例：一个企业内部网项目的WBS 项目管理 按产品进行组织 项目管理 ？

制作WBS字典 支持 按项目阶段组织 用表格形式表示 概念 2 站点设计 1.1 评价现有系统 3 站点开发 1.2 确定要求 4 投入使用 1.1 评价现有系统 1.2 确定要求 1.2.1 确定用户要求 1.2.2 确定内容要求 1.3 确定特定功能 1.4 定义风险和风险管理方法 2 站点设计 3 站点开发 4 投入使用 5 维护 用表格形式表示 制作WBS字典

WBS示例 家庭项目 美化院落 修理屋顶 购买食品 列清单 开车到商店 将货物装进购物车 付款 …… 活动

WBS示例 0级 1级 2级 3级 新设备安装运行 1000 设备调试 1400 设备安装 1300 布局设计 1200 总体设计 1100 厂址 分析 1110 选择 设计 1120 机器 布局 1210 工艺流 程设计 1220 加工 1310 装配 1320 安装 设备 1330 测试 1410 试生产 1420 建筑 物 1323 组装 部件 1322 把零件 运往工 地 1321 0级 1级 2级 3级

WBS示例 表示预算和责任的WBS编码 WBS编码 预算/万元 责任者 1000 1100 1110 1120 1200 1210 1220 1300 1310 5000 500 700 300 2000 王新建 设计部门 李岩 张德伦 设备部门 钱江林 宋晓波 基建部门 纪成 1320 1321 1322 1323 1330 1400 1410 1420 200 600 400 齐鲁生 金震 乔世明 陈志明 陈志安 生产部门 秦益明 徐青

工作分解结构的特点 常用于建立或确认对项目范围达成共识 通常以图表形式表示 WBS中的每一项元素通常被赋予唯一的标识， 形成编码系统

工作包编码举例： 编码不仅把不同的项目单元区别开，而且要保留它所有特征，如所属的子项目，所属区域、专业功能、要素等。在项目实施过程中的网络分析，成本管理、数据的储存、分析、统计都靠编码识别。

建立WBS的常用分解方式 层 逻辑流(功能) 生命周期 组织 管理层 大型项目 项目 任务 子任务 工作包 活动层次 系统 子系统 人 项目干系人指定 向管理层做状态报告 大型项目 项目 任务 子任务 工作包 活动层次 系统 子系统 人 事业部 部门 组 技术层 承包商为内部控制而设计

建立WBS的指导原则 一个单位工作任务只能在WBS中出现一次 一个WBS项的工作内容是其下一级各项工作之和 每项工作由一个人负责 工作包的80小时原则 WBS具有一定的灵活性，以适应变更的需要

建立WBS的方法 1）遵循指导方针 2）类比法 3）从上至下或从下至上方法 DOD 的项目范围说明中明确指出项目的WBS

利用工作分解结构模板(类比) .1 工作分解结构模板—WBS templates 以前项目的工作分解结构（ work breakdown structure，简称WBS）常常被用作新项目的模板： 相同或类似的项目生命周期 每个阶段有相同或类似的可移交项

.2 分解 确定项目的主 要可交付成果 确定可交付成 果的组成元素 核实分解的正确性 确定每个可付成果的详细 程度是否已经达到了足以编制出 恰当的成本和历时估算 确定可交付成 果的组成元素 核实分解的正确性 YES NO

分解技术 第一步：确定项目的主要可交付成果，包括项目管理。主要可交付成果总是依据项目的实际管理方式进行定义的，例如： 项目生命周期的各个阶段可能作为分解的第一层次，而项目可交付成果可能作为分解的第二层次。 WBS各个分支中的组织原则可能会不同 YES NO

分解技术 第二步：确定每个可付成果的详细程度是否已经达到了足以编制出恰当的成本和历时估算。 Yes！第四步 No! 第三步 YES NO

分解技术 第三步：识别可交付成果的组成元素 可以是服务或产品 能以切实的、可校验的语言加 以描述，以方便进行绩效测量 在每个组成元素上重复步骤2 能以切实的、可校验的语言加 以描述，以方便进行绩效测量 能对该项目工作实际上将如何 被完成进行描述 YES NO

分解技术 第四步：对分解的正确性进行校验 下一层的元素是否对于完成上一层工作是必须的且足够的？ No  增减或重新定义 是否每一项元素都已被清楚且完整地定义？ No  对说明进行修改 是否对每一项元素都能进行成本和进度估算，并且将此项工作分配给某个组织单元（如：部门、团队、个人等），以使其承担完成该项工作的责任，以及实施足够的管理控制？ No  需要进行修改 YES NO

几种不同的分解结构 合同工作分解结构 (CWBS)：用于界定销售者提供给购买者的产品报告级别。内容比WBS的少，用于卖方管理买方的工作。 组织分解结构（OBS）：用以展示工作要素已经分配给了具体的组织单位 资源分析结构 (RBS)：是OBS的一个变种，常 在将工作元素分配给个人时使用 工料清单 (BOM)：制造业中对生产某种产品的原材料的结构化表述 风险分解结构 (RBS)：Risk Breakdown Structure

项目的管理工作 作为项目的领导，业务性的工作也与你有关。在软件项目中，项目领导在做技术工作之余，也要承担项目的管理工作，根据我们提出的拇指法则（rule of thumb），你应当有6％－8％的精力用于项目管理：对于小项目，比如，6人或6人以下的项目，6％就可以了，而对于大项目，比如说，超过12个人，就需要8％的精力了。 尽管在这里考虑了项目团队成员承担的工作，但事实上，大部分工作（75％－80％，或者更多）是由项目经理或团队领导承担的。

项目的计划活动，包括进度安排、估计和基于计算机的工具文件的更新。 记录进程或者设定目标的项目会议。 项目报告。 日常工作安排。 所有项目团队成员的人员问题，包括人员鉴定和评审。 日常问题的解决。 与供应商的沟通，包括内部和外部。 与管理层的沟通。 与客户的沟通。 与相关／依赖项目的联络。 正常工作过程中的人员招募。 质量。 质量计划／配置管理计划。

软件开发项目WBS范例 1. 产品需求阶段 1.1 产品需求文档 研究 编写 分发 个人评估 评审会议 更新/修改文档 重新分发 第二次评审 1. 产品需求阶段 1.1 产品需求文档 研究 编写 分发 个人评估 评审会议 更新/修改文档 重新分发 第二次评审 签署 1.2 结束产品需求阶段 2. 软件需求阶段 2.1 软件需求文档 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 2.2 软件验收测试计划 2.3 结束软件需求阶段

3.体系结构设计阶段 3.1 体系结构设计文档 3.2 软件集成测试计划 3.3 结束体系结构设计阶段 4.详细设计阶段 3.1 体系结构设计文档 研究 编写 分发 个人评估 评审会议 更新/修改文档 重新分发 第二次评审 签署 3.2 软件集成测试计划 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 3.3 结束体系结构设计阶段 4.详细设计阶段 4.1 详细设计文档 4.2 软件单元测试计划 4.3 结束详细设计阶段

编写代码单元 编译代码单元 链接代码单元 走查代码单元 代码单元文档 5. 编码阶段 5.1 生成代码单元 为走查做准备 进行走查 5.1 生成代码单元 编写代码单元 编译代码单元 链接代码单元 走查代码单元 为走查做准备 进行走查 更新修改代码 签署走查结果 代码单元文档 5.2 结束编码阶段 6. 单元测试阶段 6.l 单元测试代码 准备测试计划和测试案例集 测试代码 修正代码 重新测试代码 准备单元测试文档 6.2 结束单元测试阶段

7.集成测试阶段 7.1 代码集成测试 系统集成测试计划没有覆盖到的任何测试计划和测试案例集都属于代码集成测试 测试代码 修正代码 重新测试代码 准备集成测试文档 7.2 结束集成测试阶段 8.系统测试阶段 8.1 执行内部软件验收测试计划 8.2 结束系统测试阶段 9.发布阶段 9.1 安装 计划；活动；测试；记录结果 9.2 数据转换 9.3 评审 9.4 软件发布 9.5 结束发布阶段

10. 操作和维护阶段 10.1 评价 10.2 设计评审 10.3 支持和维护 10.4 审计 评审 用户（不同类型） 管理者 发行简介 10. 操作和维护阶段 10.1 评价 10.2 设计评审 10.3 支持和维护 10.4 审计 11. 项目生命周期中的其他可能用到的WBS元素 11.1 培训 项目人员的互相熟悉；项目人员的培训；用户培训 11.2 招聘 11.3 测试环境开发 为软件开发人员提供的开销 11.4 开发支持 数据库管理；开发环境；系统构造 11.5 项目管理 11.6 配置管理 评估；正在进行中的配置管理 11.7 文档记录 11.8 质量管理和质量计划 评审 用户（不同类型） 管理者 发行简介 技术手册，也就是描述软件如何工作的手册 帮助文本 为软件开发人员提供的开销