引导：协调跨部门需求

焦点小组：同职能、同部门

变更流程：记录、评估、提交（pm给ccb）、更新、通知

风险-识别到风险：更新风险登记册、定性、定量、规划、应对

风险发生：

已知风险——查阅风险登记册直接应对

未知风险——走变更，管理储备

问题：三动一分析

定义识别方案选择执行验证

个体的互动

可用的软件

客户合作

响应变化（拥抱变更）

价值驱动

拥抱变更

经常的及时反馈 较短周期

个体互动

信任（资源支持和协助） 服务型领导，仆人式领导

提倡面对面交谈 集中办公 够用效果好 效率高

可工作的软件（首要度量标准）完成的可用的 

可持续开发 步调稳定延续  速率（产能）稳定

自组织团队  自主 主动 完成  XY理论

自组织团队：自行决定计划及其组件的整合方式。

适应性环境下，对项目经理的期望保持不变，把对具体产品的规划和交付授权给团队来控制。

产品愿景——用户故事

电梯演讲

切蛋糕！ 完整得增量

相对估算

DOD

测试驱动开发TDD

行为驱动开发BDD

验收测试驱动开发ATDD

持续集成

sprint评审会

sprint回顾会议

三个工件：

１、产品代办事项列表（PB）

用户故事——可用于ｓｐｒｉｎｔ

１、一个排序的列表

２、列出了所有的特性

３、优先级由高到低排列一个顺序，排在顶部的产品待办事项列表条目需要立即进行开发。更清晰、更具体（符合就绪的定义）优先级低，细节信息越小。（KANO模型和MOSCOW法）

满意程度和具备程度

必备需求、期望型、魅力型、反向需求

４、

２、sprint backlog 冲刺（迭代）代办事项列表

考点： 团队成员主动领取任务（自组织、鼓励成员挑战、透明）交叉培训，

考点：开发团队专注于达成sprint的目标，当前sprint无变更

3、产品增量

（1）一个sprint完成的所有产品代办列表项的总和 

（2）新的增量必须是完成的，道道scrum团队完成的定义的DOD

（3）增量是sprint结束时可检视的和已完成的产品组成部分。

（4）增量时迈向愿景或目标的一步。无论产品负责人是否决定发布它，

技术负债：重构

核心——五个事件

1、sprint

是scrum的核心，持续时间为某个限时，以构建一个完成的，可用的，潜在可发布的产品增量

sprint长度通常保持一致（规定的时间盒）——短周期交付，及时反馈，步调稳定延续

spriｎｔ计划会议、每日ｓｃｒｕｍ站会、开发工作、ｓｐｒｉｎｔ评审会议和ｓｐｒｉｎｔ回顾会议构成　

ｓｐｒｉｎｔ期间不变更

所有未完成的产品代办事项都会被放回到产品代办事项列表中，并重新估算。花在他们身上的工作会很快贬值，所以必须经常重估

只有产品负责人才有取消ｓｐｒｉｎｔ的权力

（１）ｓｐｒｉｎｔ计划会议

考点：团队决定一个ｓｐｒｉｎｔ完成多少！！！！　

ｓｐｒｉｎｔ不变更，变更不应该纳入到sprint的变更事项中

故事点和团队速率

１、故事点和相对估算

斐波那契数列　１、２、３、４、８、１３

２、刺探、探测、探针（ｓｐｉｋｅ）

快速而简陋

３、速率：衡量团队在每个ｓｐｒｉｎｔ中可以解决的工作量的指标，也是ｓｃｒｕｍ的关键指标

由于每个团队选取的基准用户不同，不同的敏捷团队每个ｓｐｒｉｎｔ完成的故事点不具有可比性

故事点不是越多越好，而是越稳定越好，团队的速率需要经过多个ｓｐｒｉｎｔ才能稳定。一般不会随意的增加资源。

计划会议最终目的：sprint　backlog

（２）每日ｓｃｒｕｍ站会（考点！！！）

１５分钟

１、昨天做什么

２、今天做什么

３、是否有任何障碍

会议只记录问题，讨论问题

scrum master强制执行每日scrum站会规则——只有开发团队成员才能参加

增进交流沟通

考点！！！信息发射源

大白墙或白板

高可视化、图形化的方式展示

燃尽图、燃气图、积累流量图、停车场图额，信号灯图

意义：沟通——高效、透明

减少很多不必要的会议

（3）sprint评审会议

快结束是，两周的sprint 一般2个小时

开发团队演示完成的工作，解答关于所有交付增量的问题，演示增量的目的是为了获得反馈并促进合作

结果是一份修订后的产品代办列表

（4）sprint回顾会

总结 经验教训，明确接下来的sprint中需要实施的改进

PDCA

其他敏捷实践

看板，可视化管控，消除瓶颈

WIP  

极限编程

3.1.1预测型的特点和问题

3.1.2MVP（minimum viable product）最小可行产品

快速验证团队的目标，快速试错

1、时间、资金不足无法做大而全，推向市场

2、不知道市场反响快速试错

3、竞品 

3.1.3stacy矩阵

需求的不确定性

选择预测、敏捷、混合

混合型生命周期

敏捷

个体互动胜过流程和工具

可用的软件胜过详尽的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

敏捷的十二原则

1、及早，持续不断的交付有价值的软件（价值驱动）

2、欣然面对需求变化（拥抱变更）

3、经常，较短周期，交付可工作的软件，及时获得反馈

4、业务人员和开发人员必须相互合作（个体互动）

5、提供所需的环境和支援，辅以信任 （服务型领导风格）

6、面对面交谈（提倡集中办公）

鱼缸窗口、远程结对

7、可工作的软件（成果可工作）

8、可持续，步调稳定延续。（团队速率稳定）

11、自由组织团队（敏捷的输出，而非输入）

12、定期反思提高，PDCA

敏捷实践——srcum3-3-5-5

3个角色：

(1)产品负责人（PO），业务专家，负责需求

(2)管理专家

(3)开发团队

产品负责人——产品代办事项列表的唯一责任人

最终的责任人你，决定接受或者拒绝每次Sprint完成的产品增量

敏捷教练（scrum master）确保scrum 团队遵守scrum的理论、实践和规则

scrum master服务于PO，服务于开发团队

开发团队：负责在每个ｓｐｒｉｎｔ的结尾交付潜在可发布的完成产品增量。

自组织，跨职能（所有技能）、不认可开发团队成员的头衔（都是开发者）、可以有特长和专注领域（团队成员是T型人才）一专多能、

风险管理：先识别，关注优先级，应对风险的计划，实施应对计划，监督、监控

敞口：概率（高中低）*影响 （大中小）最好用数字

规划风险管理：

风险偏好，风险承受力，风险临界值 

项目韧性：只有在发生后才能被发现的突发性风险

整合式风险管理：

较高层面识别出的风险，授权给项目团队去管理。

在较低层面识别出的某些风险，给较高层面去管理

风险管理计划：

识别，评估，应对，实施

风险分解结构（RBS）

干系人风险偏好

风险概率和影响定义：

概率和影响矩阵

识别风险：

所有项目干系人识别

识别风险是一个迭代的过程

数据收集：头脑风暴、访谈、核对单（checklist）

数据分析：

根本原因分析（RCA）、假设条件和制约因素分析、文件分析、 SWOT分析

输出：风险登记册（已识别风险清单，潜在风险责任人，潜在风险应对措施）

输出：风险报告

实施定性风险分析：

数据分析：风险数据质量评估

风险概率和影响评估：对每个风险都要进行概率和影响的评估

低概率和影响的风险将被列入风险登记册钟的观察清单，以供未来监控。

风险分类：RBS，WBS

数据表现：概率和影响矩阵

规划资源管理：

马斯洛的需求层次理论

赫兹伯格的双因素理论：

保健因素——导致不满足感的因素，做的好提高激励，做的不好损害激励

比如：工作环境或条件、工资、同事或上下级之间的关系、个人生活、安全、地位、职务

激励因素——成就感、责任感

边际福利、额外待遇、光环效应

规划资源管理：how

1、工作分解结构WBS

2、组织分解结构OBS

3、资源分解结构RBS

责任分配矩阵：

如果团队是由 内部或者外部人员组成 ，RACI矩阵对明确划分角色和职责特别有用。

资源管理计划：如何分类、分配、管理和释放项目资源的指南

资源管理计划的内容：

项目团队资源管理

培训

团队建设

资源控制

认可计划

输出：团队章程（基本规则）

团队制定 或参与制定的团队章程可发挥最佳效果，并需要定期审查和更新

规划沟通管理：

沟通的核心概念——信息交换

梅拉宾法则（7%-38%-55%）

沟通的划分维度

项目沟通管理的核心概念

项目管理风格的变化：

将干系人纳入项目评审范围

让干系人参加项目会议

社交工具的使用日益增多

多面性沟通方法

规划沟通管理——基于每个干系人或者干系人群体的信息需求

沟通需求分析

沟通渠道：  N(N-1)/2

沟通模型： 

沟通方法：推式沟通、互动沟通（最有效）、拉式沟通（信息量很大或者受众很多）

沟通风格评估：常用于不支持项目的干系人。

项目沟通管理计划：

规划干系人参与——搞人的策略 

数据收集、

输出：干系人参与计划

项目经理应该意识到干系人参与计划的敏感性，并采取恰当的预防措施

范 进 成

规划成本管理——估算、预算、管理、监督和控制项目成本的过程。

一、估算成本：近似估算

单位：某种货币单位——通常使用

其他计量单位（人天）——为了消除通货膨胀的影响

估算随着项目进展逐步提高

准确性：

粗略量级估算（ROM）——（-25%到+75%）

确定性估算——（-5%到+10%）

输入文件：项目进度计划

活动持续 时间估算就会对

和进度的相似估算方式：类比、参数、三点、自下而上估算

风险:

应急储备包含在基准中，PM有权使用

管理储备不包含在基准中，PM提出变更请求

输出文件：成本估算、估算依据

二、制定预算

汇总所有估算

1、成本汇总：成本估算——工作包——控制账户——整个项目

2、数据分析：管理储备针对”未知-未知”风险，提出变更

3、历史信息审核——有助于参数或类比

4、资金限制平衡 ——可能会导致进度计划的改变，可以通过在项目进度计划

输出：成本基准

项目资金需求=管理储备+成本基准

工作包得活动印记储备

规划质量管理：

质量管理大师：

戴明PDCA环

朱兰

克鲁斯比，零缺陷，强调一次把事情做对，代价是最小的

石川，鱼骨图

田口玄一

项目质量管理要兼顾项目管理和项目可交付成果两个方面（过程+结果）

1、质量和等级的区别（酒店的例子）

质量——内在特性满足要求的程度

等级——设计意图，对用途相同但技术特性不同的级别分类

2、一些术语的区别

预防——防止问题

检查——发现问题

预防胜于检查

属性抽样——二元结果（合格/不合格）

变量抽样——数值（合格的程度）

3、有效性递增的五种质量管理水平

4、质量管理的趋势和新兴实践

客户满意、持续改进。。。

5、规划质量管理（定标准）

输入：组织过程资产

质量政策，

工具与技术：标杆对照、头脑风暴、访谈、成本效益分析（比较其可能成本和预期效益，决定值得不值得）、质量成本（一致性成本、非一致性成本）、流程图（所需要的步骤顺序）

输出：质量管理计划、质量测量指标（核实结果是否合格）

CPM 关键路径法

最长的路径，是关键路径

关键路径 越多，风险越大

次关键路径与关键路径越接近，风险越大

总浮动时间（TF）

开始——结束额

第2天开始，做5天，第6天做完

总浮动时间为0的，是关键路径TF

总浮动时间，体现灵活性

自由浮动，不影响任何紧后活动FF

总浮动时间为负，项目延期

关键路径排出来的进度计划未必可行，需要资源配合

资源平衡技术

资源平衡，

资源平滑，不会改变关键路径得长度，无法实现所有资源得优化

减少负荷得变化

进度压缩：不缩减项目为前提，缩短或加快进度工期

1、赶工：以最小得成本增加来压缩进度工期（加班、加人、加急）本质，花钱买时间。

2、快速跟进： 顺序进行得活动改为并行开展。可能造成返工和风险得增加。

进度基准：干系人批准得进度模型， 

项目进度计划：里程碑进度计划、概括性进度计划、详细进度计划、项目日历。

制定项目章程——识别干系人——收集需求——定义范围——创建WBS（工作包）——定义活动——排列活动顺序——估算活动持续时间——制定进度计划

识别风险，有根本原因分析

风险里面有上报

干系人参与度评估矩阵

获取资源也涉及多标准决策分析

谈判

塔克曼模型

马斯洛需求层次

赫兹伯格双因素

自行解决-私下协作-正式

撤退回避-强迫-合作-缓和包容-妥协调解

1定义2识别3方案4选择5执行6验证

管理沟通：汇报

引导参与获得支持

谈判沟通管理期望

识别与干系人有关的问题和风险

及时的澄清和解决问题

显性知识和隐形知识

核实的可交付成果：控制图，7点

获得验收、移交、总结经验教训、更新组织过程资产、归档、释放资源

挣值管理

采购绩效审查：合同谈判、ADR、起诉

监控项目工作：工作绩效信息整合为报告

关键路径+资源优化

范围明确:总价

有范围但有重大变更：成本补偿

没有范围：工料

敏捷：价值驱动、拥抱变更、及时反馈、个体互动

面对面交谈：1.鱼缸窗口 2.远程结对

Scrum Master

BAC总值

PV截止当天计划已完成进度

EV截止当天实际已完成进度

AC实际成本

SV=EV-PV进度偏差

CV=EC-AC成本偏差

SPI=EV/PV

CPI=EV/AC绩效 

EAC=AC+（BAC-EV）/CPI

剩余绩效TCPI=（BAC-EV）/（BAC-AC）

现值PV=投资终值FV/（1+折现率）^n年数

2.1.1制定项目章程

正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。 

注意点：（宏观）

1、在项目执行组织与需求组织之间建立起的伙伴关系。

2、由项目以外的实体来启动，如 发起人、项目集或项目管理办公室等。

3、尽早确认并任命项目经理（要求接入启动和结束，例如开展商业论证和效益管理）拟任命

4、项目经理应该参与项目章程的制定，以便对项目需求有基本的了解。

5、最好在制定项目章程时就任命，最晚在规划开始之前。

项目章程的批准：

发起人负责——批

PM可以制定相关章程。——做

项目立项书

制定项目章程——输入：

1、商业文件

（1）商业论证（商业需求分析、成本效益分析）（文档化的经济可行性研究报告）

（2）效益管理计划

考点：

（1）商业文件在项目之前制定，需要定期审核。（2）商业 文件不是项目文件，项目经理不可以对他们进行更新或者修改，只可以提出相关建议。

2、协议——定义启动项目的初衷

协议形式：合同、谅解备忘录、服务品质协议、意向书等

有的先行实施，注意风险管理

3、工具与技术：专家判断

基于某应用领域、知识领域、学科 和行业等的专业知识而做出的合理判断。（来自具有专业学历、知识、技能、经验或者培训经历的任何小组和个人）

4、工具与技术：数据收集

头脑风暴：畅所欲言（追求数量、要求质量）

焦点小组：召集同领域（职能）的干系人和主题 专家讨论相关议题。SME

访谈：通过与干系人直接交谈来了解相关信息。

5、工具与技术：人际关系与团队技能

引导：达成共识

会议管理：面对面会议效果最好，有时也需要举行虚拟会议。

输出：

1、项目章程

项目的目的 ，目标，项目的成功标准、退出标准

高层级的需求，主要可交付成果，高层级的项目描述、高层级的战略和运营假设条件和 制约因素

2、假设日志：用于记录整个项目生命周期中的所有假设条件和制约因素。

假设条件（前提条件）

制约因素（对项目或过程的执行有影响的限制因素）

限制性因素——与风险管理有关系（威胁/机会）

2.1.2识别干系人（相关方）

干系人：能影响项目或者受项目影响的个人或组织

定期、尽早识别项目干系人

识别干系人：工具与 技术

1、数据收集

头脑风暴、头脑写作

识别身份信息（基本信息）

2、数据分析

干系人分析：

3、数据表现

干系人映射分析/表现

权力/利益方格：使用于 小型项目、干系人与项目的关系很简单

重点管理（利益高，权力高）：分管领导

令其满意（利益低，权力高）：其他非分管领导

随时告知（利益高，权力低）： 甲方项目经理

监督（利益低，权力低）：

权力/影响方格

凡是计划中没有的（计划外的） 都需要走变更