（软件/it）项目管理课程笔记（新手入门，未完待续……）

流程
1. 甲方招标书定义
  1. 邀请人
  2. 合同细节
  3. 需求
  4. 标书模板
2. 乙方项目分析
  1. 流程（如何实施，如何满足甲方要求）
3. 招标与竞标
4. 合同签署
招标方式
1. 公开招标：对于所有
2. 有限招标：对于一定范围内
3. 多方洽谈：甲方找几个人谈
4. 直接谈判：直接找人
案例

2.3_项目章程

project charter：确认项目存在的文件，包括对项目的确认，对项目经理的授权和项目目标的概述等
敏捷项目章程
1. 项目目标
2. 发布标准
3. 预期的工作流
项目经理的职责
1. 开发计划-->组织实施-->项目控制
2. 敏捷强调：仆人式领导方式
项目经理的能力
1. 技术项目管理
2. 领导力
3. 战略和商务管理

3_生存期模型

3.1生存期模型选择

四种项目模型：

3.2预测型：

从头到尾按顺序来
瀑布模型：需求明确，方案明确，适合短期项目

V模型：需求明确，方案明确，对系统的性能、安全性要求高

3.3迭代型/原型模型：

对原型不断的构造、评估、修改，一直迭代

需求不明确。复杂性高，需求变更频繁

3.4增量型：

每个增量都是一个可交付的成果（最终结果）
每个增量都包括设计、开发、测试、集成

优点：
1. 阶段式提交一个可交付的产品
2. 关键的功能更早出现
3. 早期预警问题避免缺陷蔓延
4. 阶段性完成可以降低估计失误

3.5敏捷型：

与传统模型的区别
1. 敏捷：自适应的过程（不断调整）
2. 传统：预测性的过程（按照计划走，达到预期目标）
敏捷方法

3.5.1 scrum

1. 客户、市场、高层：提出需求
创意、缺陷、功能：形成产品发布图等

产品负责人：产品经理，最了解市场，最明确要开发出什么产品的人

产品Backing：按照优先级排序出最想优先实现的需求

冲刺（大的绿圈）：Scrum中的一个迭代

Team：人数一般为7+-2，全覆盖所有的技能，也不需要太多的沟通成本

每日立会：主要为项目成员，更新看板和燃尽图

Scrum master：不解决任何技术问题，只是负责流程的维护、工作分派

冲刺评审会：搞出一个demo邀请所有相关方来验收
项目需求来自待开发的功能离别
初始需求，要有优先级，
每个迭代按照优先级进行，1-4week，提交可交付的成果
成果进行评审、反馈，进行下一个迭代

两层的项目规划

远期：产品订单product backlog

近期：冲刺订单sprint backlog

迭代开发过程

四个会议进行管理

3.5.2 XP（extreme programming）极限编程

最佳实践

entire team practices

whole team 团队意识：客户、程序员、分析员、经理。。。是平等的

planning game 两个计划：发布计划、迭代计划

small release 小版本：如果有可能每天都要发布小版本

customer test 每个需求都有验收测试

development team practices

collective ownership 每个人都能读所有代码

coding standard 编程标准

sustaninable pace每周保证40h工作时间，统一效率

metaphor 以讲故事的角度形象的描述需求

continuous integration 频繁整合系统以发布一个新的可用系统

developmentor practices

simple design用最简单的办法实现小需求，后续不断地重整优化

pair programming 结对编程，两个程序员在同一台机器上编写

test-driven development 测试驱动开发，每次代码都应该运行一遍所有测试

refactoring 重构，不断改进

3.5.3 lean精益

不断改进（删除），减少流程浪费

3.5.4 持续交付（CI/CD）

持续集成

将个人代码持续向集体部分交付

持续部署

集成的代码持续向可运行的环境交付，测试

持续交付

尽早向客户交付，以便发现生产环境中的问题

3.5.5 DevOps：

development和operations组合，开发和运维紧密合作

4_软件需求管理

4.1需求管理过程（5个过程）

需求确认：需求获取->需求分析->需求规格编写->需求验证

需求获取：问卷、讨论会、展示，最有效的是面对面的沟通）

需求分析：

需求规格编写：需求规格说明书

需求验证：是否正确/一致/完全/可行/可检验/可跟踪....最后的签字

需求变更

核心是制定一个需求变更控制系统

需求变更控制流程

4.2传统需求管理过程

原型方法

通过不断的评价原型，完成需求的建模

工具：axture

基于数据流方法-结构化建模

数据流图DFD

数据字典DD

系统流程图

基于UML方法-面向对象建模

4.3敏捷需求管理过程

需求来源：

product backlog 产品代办事项列表

sprint backlog 待办事项列表的细化

需求分析user story(对应UML的用例图)，use story cards and story wall

MoSCoW

优先级排序

Must have

should have

could have

want have

5_软件项目的任务分解/范围界定

5.1任务分解的基本概念

任务分解是项目管理的基础

工作分解结构（WBS: work break down structure）

是对项目由粗到细的分解过程

面向交付成果

组织并定义了整个项目的范围

工作包（work packages）

WBS的最低层次的可交付成果

工作包应当由唯一的主体负责

WBS字典：对工作包进行详细的解释

5.2任务分解方法

类比

模板

自上而下(最常规，由一般到特殊)

自下而上

WBS分解建议

最底层是可控和可管理的，但是不能过细

每个工作包必须有一个提交物

定义任务完成的标准

有利于责任分配

分解到40h以内，敏捷项目分解到小时

5.3敏捷任务分解

epic：比较大、模糊的需求

epic可以分解

acceptance criteria：epic分解完之后应该给出用户接受标准

例子

6_软件项目成本计划

6.1传统估算方法

成本相关概念

软件项目规模：工作量（例如：软件规划、项目管理、需求分析、系统设计、编码、测试、维护……）

规模单位：LOC（loc of code）、FP (Function Point)、人月/人天/人年……

软件项目成本

完成软件规模相应付出的代价

待开发项目所需资金

人的劳动的消耗所需要的代价是软件产品的主要成本

货币单位

成本估算的结果

直接成本：与具体项目相关的成本（例如参与项目的人员成本）

间接成本：可分摊到各个具体项目中的成本（培训、房租水电、市场费用……）

6.1.1 代码行估算法

特点

与具体的编程语言有关

分解足够详细

有一定的经验数据

6.1.2 功能点估算方法

1、特点

2、 albrecht

（1）简介

（2）公式

（3）UFC未调整功能点计数

外部输入EI(external input)：例如输入的账号密码，也可以是表单、对话框等多种形式

外部输出EO(external output)：例如教务系统显示的成绩

外部查询EQ(external inquiiry)：就是查询啊，与EO相比多了个逻辑处理

外部接口文件EIF'S(external interface files)：例如成绩导出

内部逻辑文件ILF'S（internal logical files)：用户可以识别的一组逻辑相关的数据，完全保存在应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目，例如关系数据库中的一个表，系统文件等……例如评教结果？

计数规则（文件、类型、类型个数）

事务组件进行定级（界定规则如下，可以略）

因此在计算的时候可以直接套用这个

例如：

（课程里没讲，我也不太清楚我分的对不对……）

外部输入(3)：录入订单、修改订单、删除订单

外部输出(1)：统计订单

外部查询(1)：查询订单

外部接口(1)：从外贸订单系统到汇率系统

内部逻辑文件(2)：客户资料、汇率查询转换

（4）TCF 技术复杂度因子

每个因子的取值范围0-5

3、其他方法

4、功能点和代码行的转换

6.1.3 用例点估算法

用例点的确定：通过用例图确定角色、用例、相应的复杂度

估算流程：通过用例视图确定角色、用例、相应的复杂级别，然后确定用例权值和角色权值，相加后得到未调整的用例点再计算技术复杂因子。。。

步骤：

UAW

6.1.4类比/自上而下估算法

介绍：根据以往完成类似项目所消耗的总成本/工作量，来推算要开发的软件的总成本/工作量

使用情况

相似项目

先要计算相似度

而实际中常常是主观判断

6.1.5自下而上估算法

定义

评价

相对比较准确，他的准确度来源于每个任务的估算情况

花费时间

6.1.6 三点估算法

三种估算值

两种计算方法

6.1.7参数估算法

1、定义：参考的模型不定

2、walston-felix模型

原理

3、COCOMO (constructive cost model) 【待续……】

介绍

原理

COCOMO 81

4、参数模型估算【待续……】

6.1.8 专家估算法

6.2敏捷估算方法

思路：story point估算方法

过程：

6.3成本预算

分配项目成本预算包括三种情况：
1. 给任务分配资源成本：与资源的费率有关，例如加班费率、标准费率……
2. 给任务分配固定资源成本：一个项目的资源需要固定数目的资金，例如兼职人员成本
3. 给任务分配固定成本：不管工期多长/不用什么资源，某项任务的成本不变，例如外包任务、培训任务
成本基线示例：

7_软件项目进度计划

任务定义

任务关系

历时估算

项目进度编排

项目进度确定

7.1 进度基本知识

1、任务：确定为完成项目的各个交付成果所必须进行的逐项具体活动

对于该WBS而言，工作包’设计‘可以分出两个任务，而且这两个任务之间有逻辑关系（写说明书之后才能将进行设计评审）

2、任务关系：

根据关联关系安排顺序；

四种常见关系

任务之间关联关系的依据

强制性依赖关系：任务之间固有的关系，不以人的意志为转移，例如必须要先写设计说明说再进行设计评审
软逻辑关系：不是固有的关系，人主观安排
外部依赖关系：依赖项目之外因素，例如用户环境测试要根据用户的环境准备好
内部依赖关系：内部的强制性依赖关系

任务关系矩阵D（01矩阵）：其中Dij，任务i是任务j的前置

3、常见图

（1）网络图

PDM（precedence diagramming method）优先图法，节点法（单代号）网络图

节点表示任务，线表示逻辑关系

ADM（arror diagramming method）箭线法（双代号）网络图

双代号：两个号唯一确定一个任务
虚线：虚活动，只是为了表示逻辑关系不需要消耗资源

（2）甘特图：任务的基本信息，方便查看工期、时间、资源等

（3）里程碑图：项目中重大工作的完成情况，标示时间的标记

（4）资源图：项目进展中资源的分配情况

（5）敏捷项目管理中：

燃尽图：还有多少任务没有完成

燃起图：已经完成了多少任务

7.2 历时估算

估计任务、路径、项目的持续时间

7.2.1 传统历时估算

经验导出模型

CPM（关键路径法估计）

PERT（工程评估评审技术）

预留分析

其他

7.2.2 敏捷历时估算

7.3 进程编制方法

超前和滞后

关键路径法

时间压缩法

资源优化

7.4 项目进度确定

敏捷计划

8 软件项目质量计划

8.1 基本概念

1、软件质量是软件满足明确说明或者隐含的需求的程度

人们通常把影响软件质量的特性用软件质量模型来描述

2、ISO/IEC9126模型

通过采取质量特征值可以计算量化的质量值

3、质量的形成：质量形成于产品或者服务的开发过程中，而不是事后的检查（测试）把关等。

4、质量成本

预防成本：前期质量成本

缺陷成本：后期质量成本（修复的成本很大）

8.2 软件项目质量活动

1、软件质量管理活动：软件质量保证、软件质量控制

2、质量管理的对象：过程质量、产品质量

质量控制（QC）前期质量活动

质量保证（QA）后期质量活动

确定项目结果与质量标准是否相符,同时,确定不符的原因和消除方法 
控制产品的质量，及时纠正缺陷 
例如：代码评审、单元测试 
Is it right done? 
这个任务本身提高产品的质量 
一般由开发人员实施

通过评价项目整体绩效,建立对质量要求的信任 
提供项目和产品可视化的管理报告 
例如：《软件设计说明书》质量审计
Is it done right? 
这个任务本身并不能提高产品的质量（因为已经完成啦）
一般由质量保证部门人员实施

质量控制活动

技术评审 
代码走查 
测试（主要） 
数据分析

质量博征活动--审计(Audit)：

是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较
软件项目中常用的质量保证活动：项目执行过程审计、项目产品审计

8.3 敏捷项目质量活动

1、敏捷项目的质量规划特征 

全程质量审查 
早发现问题 , 多版本提交 
不断进行质量方法评估和改进（通过每次迭代）

2、敏捷项目的质量活动 

结对编程(Pair Programming) 
测试驱动开发TDD(Test Driven Development) ：先写测试用例，再写代码来满足用例
持续集成与测试：频繁讲工作集成到整体系统中，然后再进行重新测试，以确定整个产品仍然按照预期工作。
不同层面测试：单元测试  集成测试  系统级测试  冒烟测试  回归测试
验收测试驱动开发（ATDD) ：与客户一起讨论验收标准，创建测试用例，据此驱动代码编写，进行自动化测试，满足验收标准。
重构Refactor：简单设计之后编写可以运行的代码  版本运行之后逐步完善代码和设计

迭代评审：迭代完成后，向项目相关人员展示迭代版本运行情况，得到用户反馈
迭代回顾会议：评审该迭代过程，看是否需要改进

8.4 软件项目质量计划

软件质量计划：

确定项目应达到的质量标准(目标) 
决定如何满足质量标准的计划安排和方法

质量计划方法

试验设计：通过分析大量数据获取结论，从而得到方法 
基准对照：参考最佳项目实践来搞
质量成本分析：分析项目活动与质量成本的关系，从而确定合适的
数据图形分析: 流程图方法  因果分析图,  思维导图……

输出形式没有统一标准，主要是为了方面对照

9 软件配置管理计划

9.1基本概念

1、配置管理：（项目需求、代码都有很多对应的版本，配置管理可以明确其对应关系）

记录软件产品的演化过程 
得到精确的产品配置。 
最终保证软件产品的完整性、一致性、追朔性、可控性

主要功能：版本管理、变更管理、其它

2、软件配置项 SCI:software configration item 

受控于软件配置管理的款项，是配置管理的最小单位，即管理的最小文件
需求规格可能是一个文件也可能是多个文件，因此需求规格可以是一个配置项也可能是多个配置项
每个配置项也需要定义一个标识符，即文件名
例子

3、基线

基线提供了软件生存期中各个开发阶段的一个特定点, 标志开发过程一个阶段的结束,或者里程碑 
一个(些)配置项形成并通过审核，即形成基线 
基线修改需要按照正式的程序执行
例子

4、软件配置控制委员会(SCCB)(Software Configuration Control Board)

评估变更 
批准变更申请 
在生存期内规范变更申请流程 
对变更进行反馈 
与项目管理层沟通

9.2软件项目配置管理过程

1、配置项标识、跟踪：

将软件项目中需要进行控制的部分拆分成SCI，例如将需求分析拆分成许多配置项
配置项被唯一的标识
配置项的命名规则：

配置项的跟踪
- 建立配置项的对应关系，以便于进行跟踪和版本控制.
- 实现数字化管理

2、配置管理环境建立：

软件配置管理库是用来存储所有基线配置项及相关文件的等内容的系统，是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。
出现变更需要经过变更控制流程、将新版本评审/验证。。。
需要安装相关的程序来实现，例如rational，VSS, SVN, GIT

3、基线变更管理过程

基线修改应受到控制，这种变化要经SCCB授权，按程序进行控制并记录基线修改的过程。
基线变更系统（最重要的部分）

变更请求

4、配置管理审：配置管理过程审计  基线审计

5、配置状态统计例如：  被批准的配置项  变更请求的数量  配置项的所有请求的变化状态  配置项所有被批准的变更实现状态  配置管理系统以及SCCB在运作中发生异常的次数等等

6、配置管理计划大纲—举例  人员职责（确定SCCB等）  配置项定义  基线定义  版本控制（说明配置管理工具）  定义变更控制系统

9.3敏捷配置管理计划

1、敏捷配置管理  敏捷的一个重要特征是持续交付，因此，配置管理是重要的要素  敏捷需要全面配置管理

2、全面配置管理的基本要求 

代码和编译构建产物的配置管理（最主要）
- 制定有效的分支管理策略 
  - 基于分支的开发 
    - 开发都在分支上提交，并且可能有多个并行分支，直到快要上线时甚至上线后才合并到主干
  - 基于主干的开发
    - 所有提交到主干上，提交后自动触发持续集成进行验证和快速反馈。 
    - 持续交付更倾向使用基于主干的开发模式
- 配置管理工具
  - GIT 分支管理：Master  Develop  Release  Hotfix  feature
应用的配置管理 
环境的配置管理（硬件、网络、web系统等）

10 软件项目团队计划

10.1团队计划

1、组织结构的主要类型 :

职能型（多级领导、经理）

项目型（项目经理可以全权负责该项目的情况，项目结束就可以解散了；缺点是资源难以共享）

矩阵型（前两者的混合；易引起职能经理和项目经理之间的冲突）

2、选择合适的项目角色例如: 1) 项目经理 2) 系统分析员 3) 系统设计员 4) 数据库管理员 5) 支持工程师 6) 程序员 7) 质量保证人员 8) 配置管理人员 9) 业务专家（用户） 10) 测试人员

人员职责计划

责任分配矩阵(RAM) 
组织分解结构 (OBS) 
- OBS & RAM
其它,例如文本型

干系人管理计划

干系人（stakeholder）是能影响项目决策、活动或者结果的个人、群体或者组织，以及会受到或者自认为会受到项目决策、活动或者结果影响的个人、群体或者组织。

沟通计划

沟通方式：1.书面沟通和口头沟通 2. 语言沟通和非语言沟通 3. 正式沟通和非正式沟通 4. 单向沟通和双向沟通 5. 网络沟通才
项目沟通活动的分类  内部与外部  正式和非正式  渠道（上级沟通,下级沟通,横向沟通）  书面与口头
沟通渠道（人员越多，沟通的渠道就会相对越多，因此需要用一定的方式来减少不必要的和确保有效的沟通渠道）
- 项目组织图：项目组织图以图形方式展示项目团队成员及其报告关系

沟通计划是确定谁需要信息，需要什么信息，何时需要信息，以及如何将信息分发给他们。

10.2敏捷团队计划

人员的角色：

敏捷的角色

Scrum 角色

产品负责人(Product owner ) 

团队促进者(Team facilitator ) 

跨职能团队成员(Crossfunctional team member )

——编码测试等啥都干的程序员

Product Owner（产品负责人） 

Scrum Master （ Scrum主管） 

开发团队

敏捷团队 
- 最有效的敏捷团队往往由三到九个成员组成。(黄金人数5-9人) 
- 理想情况下，敏捷团队应该集中在一个工作场所工作。 
- 团队成员100%为专职成员, 协同工作， 
- 敏捷鼓励自我管理团队。
仆人式领导 
- 仆人式领导是通过对团队服务来领导团队的 
- 注重理解和关注团队成员的需要和发展 
- 仆人式领导为团队赋权 
- 旨在使团队尽可能达到最高绩效。
敏捷方法提倡高度透明 
- 邀请所有相关方参与项目会议和审查
- 将项目信息发布到公共空间（看板等）

11 软件项目风险计划

11.1 风险管理过程

风险类型
- 预测角度
  - 已知风险－Known known （bug） 
  - 可预测风险-Known unknown （人员离职）
  - 不可预测风险-unknown unknown
- 范围角度：商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险、产品规模风险等。
项目风险的三要素（从以下三个方面进行分析的过程）
- 风险事件
- 事件概率
- 事件影响
风险管理的四个过程
- 风险识别：识别风险事件, 系统化地确定对项目计划的威胁，识别已知和可预测的风险。
- 风险评估：对风险事件发生概率的评估，对项目风险影响的评估，给出项目风险排序
- 风险规划：针对风险分析的结果，制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响
- 风险控制：风险控制是在项目执行过程中实施和监控风险计划，同时，不断进行风险识别、风险分析、风险规划的过程

11.2 风险管理过程

风险识别
- 方法
  - 德尔菲方法  （找几个专家，匿名收集其对风险的识别结论，再反馈给他们，迭代3-5次，使其趋于一致）
  - 头脑风暴法  （专家会议）
  - 情景分析法  （编剧本的方法，推断事件发展）
  - 利用风险条目检查表（对于相关问题进行问答：是否又足够的人员可用？是否与客户合作过？）
- 结果
风险评估
- 流程
  - 分析：风险发生的概率（P） 风险对项目的影响（I） 风险值，R=F(P,I)
  - 确定优先次序： 按风险值排序 确定最需要关注的TOP 风险
- 方法
  - 定性风险评估：定性评估风险概率及后果
    - 风险概率度量：高、中、低  极高、高、中、低、极低  不可能，不一定，可能和极可能  等等
    - 风险影响度量：高、中、低  极高、高、中、低、极低  灾难，严重，轻微，可忽略  等等
    - 风险概率及后果估计-矩阵图
  - 定量风险评估：
    - 1. 盈亏平衡分析（成本和收益相等时，确定盈亏平衡点）
    - 2. 敏感性分析（与软件项目的有关的一个或多个因素发生变化时，看影响）
    - 3. 模拟
    - 4. 决策树分析（最常用）
      - 决策树分析是一种图表分析方法 
      - 提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率 
      - 提供选择一个最佳的方案的依据
      - 决策树分析与EMV ( Expected Monetary Value)
        EMV (损益期望值)是决策树的一种计算值  根据预期结果、发生的概率计算出一种期望的损益
        例如：某行动方案成功的概率是50%，收益是10 EMV=10*50%=5
风险规划的主要策略：
- 1. 回避风险：
  - 回避风险是对可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案，
  - 例放弃采用新技术（但是由于回避这个风险，可能会造成开发技术落后的新风险）
- 2. 转移风险：
  - 转移风险是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法，
  - 例如  分包  开脱责任合同  保险
- 3. 损失控制
  - 损失预防例如：项目技术培训，预防技术失败
  - 损失抑制例如：项目人员储备，抑制人员流失的损失
- 4. 自留风险：由项目组织自己承担风险事故所致损失的措施

11.3 敏捷项目风险计划

敏捷项目风险应对方法：损失预防与损失抑制策略 
- 跨职能项目团队(识别风险) 
- 选择迭代内容 (选择风险小的) 
- 频繁评审增量产品 
- 持续测试可以及早发现问题 
- 客户参与可以减少需求变更的风险
敏捷项目存在风险 
- 没有长期计划,识别一些风险比较困难. 
- 没有长期规划，存在变更

12 软件项目合同计划

13 项目集成计划执行控制

软件项目管理的重要四个要素：范围(Scope)  质量(Quality)  进度(Time)  成本(Cost)
- 其中成本是核心
- C=F(S,Q,T) C 与 S成一定正比关系 C 与 Q成一定的正比关系 C 与T成一定的反比关系
项目执行控制过程
项目执行控制的步骤：建立标准，采集项目实际数据，实际结果与计划比较，决定是否修正计划
- 项目数据是项目执行控制的依据
- 计划修改的原因:  计划的不合理  客观原因导致
敏捷项目的集成管理 
- 敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。 
- 项目经理的关注点在于营造一个合作型的决策氛围 
- 对具体产品的规划和交付授权给团队来控制。 
- 确保团队有能力应对变更 
- 变更过程可视为一个敏捷项目
（敏捷）变更初始待办事项列表排序以及管理跟踪变更过程

14 项目核心计划执行控制▲

传统

敏捷

范围

分析技术：
- 偏差分析：将范围基准于实际的结果比较，看误差是否在临界区间内，是否需要变更
- 趋势分析：审核范围偏差随事件变化的情况，看范围管理整改改善/恶化
防止不合理的范围扩张
- 蔓延(Scope Creeping)是没有经过项目范围控制程序而出现的项目范围的扩大
- 镀金(Gold-plating) 镀金是在工作范围之外,项目团队额外增加了工作量

需求不断被定义

把需求列入未完项 
不断构建和评审原形系统 
通过发布多个版本来明确需求

成本进度管理

图解控制法 (偏差分析)

相关图：
- 甘特图：计划时间/开始时间/实际时间等
- 延迟图？？？：对没有按照进度计划进行的活动提供了更加醒目的展示
- 时间线？？？：记录了计划和显示了项目执行期间目标变更的方法（斜着的延长线）
- 费用曲线图：
- 资源图偏差：
偏差分析与控制
- 精确记录任务消耗的实际时间 
- 量化任务的计划偏差 
  - 持续时间偏差 (%) =(( 实际持续时间 - 计划持续时间 )/ 计划持续时间 )*100 
  - 进度偏差 (%)=(( 实际结束时间 - 计划结束时间 )/ 计划持续时间 )*100 
- 对计划偏差进行根因分析

如图所示
- 任务时间：实际>计划
- 费用：实际<计划
- 人员：实际<计划
故进度推迟的原因可能是缺乏足够的资源

挣值分析法 

基础概念：
- ① BAC(Budget At Completion)  预算总值（估算结果）
- ② TAC(Time At Completion)  预计完成时间
- ③ BCWS(Budgeted cost of work scheduled)  计划工作成本
- ④ ACWP(Actual cost of work performed)  实际工作成本
- ⑤ BCWP(Budgeted cost of work performed)  已获值/(Earned Value)目前项目的价值
例题解释：（挣值分析输出）
- 进度差异:SV（Schedule Variance）=BCWP-BCWS =0：按照计划进度进行  <0：落后于进度
  - SV= 1：目前完成11万的规模，而计划为10万的规模，进度差异为1万的规模
- 成本差异:CV（Cost Variance )=BCWP-ACWP  =0：按照计划预算进行  >0：低于预算
  - CV=-1：目前投入12万，产出的价值是11万，成本差异为-1万
- 进度效能指标 SPI（Schedule Performance Index)= BCWP/BCWS =1：按照计划进度进行 >1：超前于进度 <1：落后于进度
- 成本效能指标：CPI(Cost Performance Index)= BCWP/ACWP  =1：按照计划预算进行  >1：低于预算  <1：超出预算
  - 研究表明：进度进展到20%左右的时候，CPI趋于稳定
- EAC (Estimate At Completion)=BAC/CPI 预测项目完成成本
- SAC(Schedule At Completion )=TAC/SPI 预测项目完成时间
- 成本偏差:VAC=BAC-EAC 
- 时间偏差:VAT=SAC-TAC
- 未完工指数 TCPI=剩余工作/剩余成本 =(BAC-BCWP)/(Goal-ACWP)
BCWP计算
- 50/50规则（常用）当一项任务开始、没有结束前，获得一半的价值。
- 0/100规则当一项任务没完成前，没有价值。
- 经验加权按照经验百分比计算价值。

网络图分析

分析网络图中某任务的进度成本情况  可以采用贝叶斯网络解决项目中的不确定性问题
贝叶斯公式：
- 在B下A发生的概率=在A下B发生的概率 * A发生的概率 / B发生的概率
贝叶斯网络(Bayesian network)
- 是一种概率图模型，它是一种模拟人类推理过程中因果关系的不确定性处理模型，其网络拓朴结构是一个有向无环图(DAG)。贝叶斯网络的有向无环图中的节点表示随机变量
- 若两个节点间以一个单箭头连接在一起，表示其中一个节点是“因(parents)”，另一个是“果(children)”，两节点就会产生一个条件概率值。 
- 对于任意的随机变量，其联合概率可由各自的局部条件概率分布相乘而得出
- 例子：
贝叶斯网络分析软件进展
- 采用贝叶斯网络来解决软件规模进度的预测与控制问题。确定项目进度图示，选择影响软件规模进度的因素并且确定因素间因果关系，构建贝叶斯网络结构，根据项目数据，估计和预测实际偏差
- 步骤-1.构建项目网络图：
- 步骤- 2.构建活动的贝叶斯网络
  - 每个活动都要构建
  - 分析每个活动的影响因素（包括人力物力等）
  - 必须确定每个节点的各种状态，明确定义属性值，确定条件概率
  - 例子：
    - 如图所示与编码有直接联系的影响因素有5个，分别是估测准确性、人员变动率、代码进度质量、代码复杂性、需求变更
- 步骤- 3.数据处理
  - 将节点进行离散化和归一化，如下所示化为高中低三个级别
- 步骤- 4:贝叶斯模型学习
- 各节点变量的先验概率  确定条件概率分布表
步骤- 5.贝叶斯网络更新
步骤- 6.分析原因
敏感性分析：如下所示，最能影响的是编码质量，因此可以通过控制它来控制进度

敏捷方法

交付价值替代预测型衡量指标
基于迭代的项目: 燃尽图、燃起图
基于流程的衡量指标
- 交付周期  交付一个工作项目花费的总时间，从项目添加到看板直至项目完成 
- 周期时间  处理一个工作项目所需的时间 
- 响应时间  一个工作项目等待工作开始的时间
功能燃起图/燃尽图
完成指标管理 
- 迭代速率: 反映了一个团队在一个迭代周期内所能交付的 Story 个数。
  - 例如: 迭代速率=50个Story points/迭代 项目有500 Story points  则，项目大约还需要 10个迭代。
- 期望值管理: 团队的管理者要适当控制他们的期望值的提升，因为团队的生产能力应该有它的上限
进度变更  通过项目进度分析, 确定必要的变更  必要时,执行集成变更流程

15 项目辅助计划执行控制

传统

团队人员：对于不同类型的人采用不同的激励方式
干系人：
沟通
风险
合同

敏捷

团队（组织、责任、干系人、沟通）
风险（基于测试的开发、结对编程、多版本提交……）
客户

16 项目结束过程

项目验收合同终止项目最后评审项目总结报告

叮咚！你的小可爱已上线

关注

0
点赞
踩
15

收藏

觉得还不错? 一键收藏
2
评论
（软件/it）项目管理课程笔记（新手入门，未完待续……）

课程来源：中国大学mooc_软件项目管理_北邮中国大学mooc_IT项目管理_厦大1_基础和概述1.1_项目与软件项目项目project：唯一、临时性目标明确项目活动间有相关性周期有限定独特性成本约束不确定项目集programs 软件项目项目管理与软件项目管理项目管理：理解软件管理项目的核心约束：确保项目满足范围、进度、成本等约束，提高质量老师说：不同于其他传统行业的项目管理，没有软件项目经历的人是很难干.
复制链接

扫一扫

专栏目录