Head First PMP – 5 – 范围管理(Scope Management)

原创 2015年11月17日 16:26:02

首先我们区分一下产品范围(Product Scope)、项目范围(Project Scope)的概念

  • 产品范围表示你和你的团队正在构建的产品或服务的特性和功能。
  • 项目范围是建立产品所需完成的全部工作。
  • 本章所描述的范围管理是针对项目范围,而不是产品范围。
  • 范围蔓延(Scope Creep)是指导致团队做额外工作的失控变更(Uncontrolled Change)

范围管理(Scope Management)就是要做正确的事,在建立产品之前你必须知道要建立什么。这意味着明确哪些超出范围,而不是哪些是属于范围的一部分。范围管理知识领域包括以下6个过程

  • 计划范围管理(Plan Scope Management)
  • 收集需求(Collect Requirements)
  • 定义范围(Define Scope)
  • 创建工作分解结构(Create Work Breakdown Structure)
  • 控制范围(Control Scope)
  • 核实范围(Validate Scope)

1. 计划范围管理(Plan Scope Management)

输入(Inputs)
企业环境要素(Enterprise Environmental Factors)
组织过程资产(Organizational Process Assets)
项目管理计划(Project Management Plan)
项目章程(Project Charter)
工具或技术(Tools and Techniques)
专家判断(Expert Judgment)
会议(Meetings)
输出(Outputs)
需求管理计划(Requirements Management Plan)
范围管理计划(Scope Management Plan)
  • 计划范围管理过程需要计划出一些方法和途径,用于找出你要做什么以及什么超出了范围,也就是明确指出如何执行范围管理知识领域其他的过程。

2. 收集需求(Collect Requirements)

输入(Inputs)
干系人管理计划(Stakeholder Management Plan)
需求管理计划(Requirements Management Plan)
干系人登记表(Stakeholder Register)
范围管理计划(Scope Management Plan)
项目章程(Project Charter)
工具或技术(Tools and Techniques)
与干系人讨论的工具和技术:
访谈(Interview)
辅助工作室(Facilitated Workshops)
专题小组讨论会(Focus Groups)
群体决策技术(Group Decision-Making Techniques):
一致同意(Unanimity)
多数同意(Majority)——一件事情多数人同意则通过
少数服从多数(Plurality)——从多件事中挑选多数人认同的事情通过
总裁制(Dictatorship)
群体创新技术(Group Creativity Techniques):
思维导图(Idea/Mind Maps)
德尔菲法(The Delphi Technique)——群体匿名投票, 适合估算工作量和时间
亲和图(Affinity Diagrams)——需求分组
头脑风暴(Brainstorming)
名义群体法(The Nominal Group Technique)——头脑风暴的一种形式,对头脑风暴的结果进行投票,排序组织
对比分析(Benchmarking)
文档分析(Document Analysis)
上下文图(Context Diagrams)——展示产品范围内的过程和特性之间的关系,以及用户如何与之交互
问卷调查(Questionnaire)
观察(Observation)
原型(Prototype)
输出(Outputs)
需求文档(Requirements Document)
需求追溯矩阵(Requirements Traceability Matrix)
  • 需求文档要列出所有的功能性需求非功能性需求
  • 功能性需求(Functional Requirements)一般是指新特性(New Features)、Bug修复(Bug Fixes)、新行为或不同的行为(New or Different Behavior)。
  • 非功能性需求(Nonfunctional Requirements)主要是指产品质量属性,包括性能(Performance)、可靠性(Reliability)、错误处理(Error Handling)和易用性(Ease of Use)。

3. 定义范围(Define Scope)

输入(Inputs)
需求文档(Requirements Document)
组织过程资产(Organizational Process Assets)
范围管理计划(Scope Management Plan)
项目章程(Project Charter)
工具或技术(Tools and Techniques)
辅助工作室(Facilitated Workshops)
产品分析(Product Analysis)
替代方案识别(Alternatives Generation)
专家判断(Expert Judgment)
输出(Outputs)
项目范围说明书(Project Scope Statement)
项目文档更新(Project Document Updates )
  • 项目范围说明书指出你在项目中将要做以及不应做的工作。

4. 创建工作分解结构(Create Work Breakdown Structure)

输入(Inputs)
企业环境要素(Enterprise Environmental Factors)
组织过程资产(Organizational Process Assets)
范围管理计划(Scope Management Plan)
项目范围说明书(Project Scope Statement)
需求文档(Requirements Document)
工具或技术(Tools and Techniques)
 
输出(Outputs)
工作分解结构(Work Breakdown Structure)
WBS字典(WBS Dictionary)
范围基线(Scope Baseline)
项目文档更新(Project Document Updates )
  • 一般有两种分解工作的方式,基于项目或阶段(Project or Phase)基于可交付成果(Deliverables)
  • 分解出来的最小单位称为工作包(Work Package),工作包必须是可计量的(Measurable)
  • 项目范围说明书、工作分解结构和WBS字典统称范围基线(Scope Baseline)。
  • 为何范围会变化:
    • 好的变化(Good Change)——不需要更多的时间和成本,且对项目质量没有影响
    • 坏的变化(Bad Change)——好注意但是有影响
      • 范围蔓延——一个变更引起另一个变更,另一个变更又引起新的变更
      • 镀金——多此一举,画蛇添足

5. 控制范围(Control Scope)

输入(Inputs)
组织过程资产(Organizational Process Assets)
工作绩效数据(Work Performance Data)
需求文档(Requirements Document)
需求追溯矩阵(Requirements Traceability Matrix)
项目管理计划(Project Management Plan)
批准的变更请求(Approved Change Requests)
工具或技术(Tools and Techniques)
差异分析(Variance Analysis)
输出(Outputs)
工作绩效信息(Work Performance Information)
变更请求(Change Requests)
组织过程资产更新(Updates to Organizational Process Assets)
项目管理计划更新(Updates to Project Management Plan)
项目文档更新(Project Document Updates )
  • 控制范围的目标就是更新范围、计划、基线和WBS信息。
  • 变更的流程:
    • 1) 确实需要一个变更
    • 2) 创建一个变更请求
    • 3) 让变更得到批准——整合变更控制
    • 4) 完成差异分析
    • 5) 重新计划工作
    • 6) 创建一个新的基线

6. 核实范围(Validate Scope)

输入(Inputs)
可交付成果(Deliverables)
工作绩效数据(Work Performance Data)
需求文档(Requirements Document)
需求追溯矩阵(Requirements Traceability Matrix)
项目管理计划(Project Management Plan)
工具或技术(Tools and Techniques)
群体决策技术(Group Decision-Making Techniques)
检查(Inspection)
输出(Outputs)
接受的可交付成果(Verified Deliverables)
工作绩效信息(Work Performance Information)
变更请求(Change Requests)
项目文档更新(Project Document Updates )
  • 正式验收(Formal Acceptance)意味着你已经得到所有干系人的书面确认(Written Confirmation),证实你的可交付成功满足需求和项目管理计划。
  • 核实范围控制范围的顺序不确定,因为检查未通过时,要再走控制范围的流程,发起变更请求。
 
本章完!

http://www.alanzeng.cn/2015/11/head-first-pmp-5-scope-management/
版权声明:本文为博主原创文章,转载请注明出处。

相关文章推荐

Head First PMP – 2 – 组织(Organization)、约束(Constraint)和项目(Project)

一不小心,阅读计划就被打断了几天,今天开始又重新拾起来。下面是第二章的要点整理。 1. 组织类型(Types of Organizations) 名称 职能型 (Functional...

项目范围管理 Project Scope Management

项目范围管理 Project Scope Management 搜集需求 Collect Requirements  Inputs Tools and Techn...

《 Head first设计模式 》学习笔记 – 模板方法模式

模板方法模式在一个方法中定义了一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。 有些人没有咖啡就活不下去;有些人则离...

《Head first设计模式》学习笔记 – 迭代器模式

迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露其内部的表示。 爆炸性新闻:对象村餐厅和对象村煎饼屋合并了! 真是个好消息!现在我们可以在同一个地...

《Head first设计模式》学习笔记 – 命令模式

一个家电公司想邀请你设计一个家电自动化遥控器的API。这个遥控器有7个可编程的插槽,每个都可以指定到一个不同的家电装置。每个插槽都有对应的“打开”和“关闭”按钮。这个遥控器还具备一个整体的撤销按钮。 ...

《Head first设计模式》学习笔记 – 抽象工厂模式

抽象工厂模式提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体类。 确保原料的一致 披萨店成功的关键在于新鲜、高质量的原料。要如何确保每家加盟店使用高...

《Head first设计模式》学习笔记 – 观察者模式

观察者模式定义了对象之间的一对多依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。 客户有一个WeatherData对象,负责追踪温度、湿度和气压等数据。现在客户给我们...

《Head first设计模式》学习笔记 – 外观模式

我们已经知道适配器模式是如何将一个类的接口转换成另一个符合客户期望的接口的。现在我们要看一个改变接口的新模式,但是它改变接口的原因是为了简化接口。这个模式被巧妙地命名为外观模式,之所以这么称呼,是因为...

《Head first设计模式》学习笔记 – 单件模式

单件模式确保一个类只有一个实例,并提供一个全局访问点。 有一些对象我们只需要一个,比方说:线程池、缓存、对话框、处理器偏好设置和注册表的对象等等。事实上,这类对象只能有一个实例,如果...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)