1，站会上只说明各自工作内容和障碍，不评论其他内容，也不会褒奖或者批评别人，所以要强调站会基本规则，然后关注障碍和给予帮助。站会上遇到的问题，会后解决，而不是冲刺回顾中解决。
2，基本套路之一：采购中遇到任何问题和争议，首先查看合同&协议。
3，前说：该框架没有定义好哪些工作时可以测量的，那么就先定义到底哪些可以测量
4，计划扑克：多轮估算，计划驱动，用于估算故事的大小。是基于德尔菲估算技能、是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。
5，不同时区导致的工作停顿，是时差导致的问题，所以项目经理应该制定客服时差的挑战，安排好工作任务和时间。
6，敏捷应该如何评估和管理风险？在每个sprint中通过每日站会、迭代会和回顾会中形成反馈。
7，沟通需求：沟通的方式、所需信息的内容、格式、详细程度等。
沟通被理解并要求反馈，这是沟通的模型。沟通方法：推式、拉式、交互式。
8，确保团队作为一个有组织的单位来运转：1，定规矩，团队章程和团队行为。
9，动用管理储配要走变更，变更批准后要纳入到成本基准里。项目预算=成本基准+管理储备。应急储备已经包含在成本基准里。
10，团队缺少主题专家SME，未来也需要这种专业知识，所以意思是，我们需要培训一名成员成为SME。有选项里“下一次”的意思是要等待，一般来说很少选择。
11，客户没有敏捷经验，我们要服务于客户及干系人，给别人推荐计划或者文档这种方法是让别人自己去学，不符合仆人式服务的原则。
12，有人离开，先查原因，再查影响。
13，询问最小可行产品MVP成本，说明项目还没开始，也就没有EV、CPI和BAC等。敏捷没有控制账户（在WBS讲过），并且自上而下估算不够细致。
14，团队成员有成功之处，最好的办法是开项目组会议，并记录该成员的贡献。项目管理计划是个指南，不做记录成员信息。责任分配矩阵记录团队角色和职责，不记录成员贡献。
15，组建虚拟团队，招募资源和沟通，确定活动需要的类型和数量这属于估算活动和资源，输出rbs（资源分解结构），跟组建团队没关系。要考虑成员的档期和时间，类似与资源日历。
16，干系人问题，管理干系人参与（早识别早分析早参与），获得干系人支持。跟风险没关系。
17，敏捷什么情况下产生影响？在考虑变更还是不变更的时候考虑，敏捷让PO处理优先级，而不是团队成员评估影响。
迭代评审会除了演示交付成果外，还更新待办列表（PB）。
18，敏捷五个事件：sprint，sprint规划会议、站会、评审会、回顾会。五大事件。
19，推进里程碑：进度压缩。
20，哪些文件能确保项目成功？组织过程资产、历史经验教训和问题日志。项目还没开始做，项目范围说明和管理计划只能说明项目要做什么，不能确保项目成果。
21，敏捷方法要什么因素才能交付产品？产品待办列表、产品愿景、产品路线图。项目刚开始，还没开始计算绩效指标，所以不涉及进度绩效等绩效指标。
22，为了确保快速交付，关于进度分析，预测型则关注进度压缩，敏捷型关注MVP、优先级等。主要关注两点：找到关键路径，对关键路径进行压缩。满足里程碑只能是按计划进行，而不是快速交付。

1，改善干系人关系，两个答案都正确的话，考虑完整性和优先操作。干系人参与计划是搞人策略，要更新的是干系人登记册。
2，混合方法对组织来说是新的，那么混合方法不一定能制定详细的进度计划，且同步干系人的不仅仅是计划。
3，敏捷项目拥抱变更，无需提交变更流程，变更要放到待办列表里下个sprint评估。
4，干系人存在分歧，要找PO负责沟通澄清。帕累托是查询问题的主要原因，28定律。
5，发现类似项目，优先考虑：组织过程资产（之前的经验教训）、类比估算。
6，仪表盘是工作绩效报告的一种形式，沟通将使用这种形式，属于沟通管理计划有关。
7，敏捷，细化用户故事是PO产品负责人的事，不是敏捷教练的事情。
8，干系人没有时间，本质上是干系人参与度不够，所以要加强干系人参与，要求他来开会等。
9，团队的角色和职责，记录在资源管理计划里，而不是RACI矩阵里。
10，需求不清楚应该先澄清需求，明确需求后再创建原型。
11，文件的版本不对，消息的迟发、缓发等，算沟通问题，查阅沟通管理计划。
12，项目经理上报：明确说 项目经理无能为力，现在要做的事情超出项目经理的权限。
PM难以获得干系人的验收，已经无能为力，只能上报领导/发起人。
13，确认到期是项目延期，还是资源日历冲突，但根源是资源日历冲突的问题，所以本质上要考虑资源管理计划里的冲突管理。
14，之前的经验教训——组织过程资产，在开工会议的作用是，传达项目目标，阐明干系人角色和职责，获得干系人对项目支持的承诺。在这个会议上，要让客户在这方面的职责。
15，莫斯科评估和卡伦模型是用来排优先级，成本效益分析是评估值不值得，投资回报比是财务指标，商业论述里的；挣值分析是说明绩效。
16，spi 1.8，cpi 0.1，进度快了一倍，成本超支10倍，说明资源投入不合理，资源过度使用导致成本超支，俗称盲目赶工，所以要修订资源管理计划。
17，团队建设：促进团队协同工作；减轻压力加强合作对应的工具是情商。
18，干系人变更，首先更新干系人登记册，沟通是更新沟通管理计划，但是项目团队更新什么文件来保持适当沟通？注意，团队不能直接更改计划，需要走变更流程。团队能直接修改项目文件。所以，项目经理让团队更新 <干系人登记册>，来进行适当的沟通。

1，有成员离开：分析原因、评估影响
2，识别风险工具：优势、劣势、机会和威胁（swot）分析
3，敏捷里，任务不是分配的，是成员主动领取。
4，原因是新技术导致执行速度下降，要了解新技术的影响，相应的调整，其中培训也是调整团队的方法，跟MVP没关系。
5，团队分散无法合并，就是虚拟团队，要解决沟通、协作。
6，执行质量下降，要确认已完成定义DOD，测试的工作无法单独添加到待办事项PB里，所以无法单独添加测试工作。
7，转型的项目，预测转敏捷，考的是转敏捷的顺序，首先是 商业论证、项目章程等立项相关。创建待办列表是稍后的事。
8，敏捷的要求包括：自组织，团队要求跨职能，具备所有完成项目的技能。
9，发起人对项目需求不满意，干系人的问题，要符合发起人的期望，就要先了解发起人的期望，需要分析他的需求是什么，干系人分析。
10，敏捷一般不太召开特别会议，属于计划外会议。回顾会议上是总结经验教训，不是指导。仆人式领导应该给予指导和帮助。
11，团队基本规则是由团队制定，团队参与制定，并不断的更新，可以减少误解提升生产力。
12，变更请求的结果要及时记录变更日志并通知传达。
13，问题解决流程：识别问题、收集信息、分析问题、制定方案、实施方案、评估改进方案。有问题要查原因。
有问题先更新问题日志。识别风险先更新风险登记册。识别新干系人先更新干系人登记册。
14，敏捷的特点：对价值的驱动，是基于价值衡量的方法。
15，每个冲刺sprint下午开两个会，一个评审，一个回顾。
16，干系人对目标存在分歧，就要引导和达成共识。
17，有两个计划一般不给干系人分享，沟通管理计划、干系人参与计划。计划是希望人遵守，但沟通是量身定制，需要根据干系人的需求更新计划。干系人参与计划是搞人的策略，比较敏感不适合给干系人看。
18，团队不负责给干系人服务，应该专注于sprint目标。给干系人服务式项目经理的工作，仆人式领导。
19，外部供应商的问题，属于外部干扰，应该由项目经理解决障碍。
20，范围缺失，范围要变更，走变更流程。属于已发生的问题，不属于风险管理计划的内容。
21，绕过PM直接跟团队沟通，属于沟通问题，优先考虑沟通管理计划相关。
22，RCA（根本原因分析）作用：寻找问题的原因，杜绝问题的再次发生。

启动（2）
制定项目章程、识别干系人

规划（24）制定项目管理计划
规划范围管理：收集需求——定义范围——创建WBS
规划进度管理：定义活动——排列顺序——估算资源
规划成本管理：估算持续时间——制定进度计划——估算成本——制定预算
规划质量管理、规划资源管理、规划沟通管理
规划风险管理——识别风险——实施定性风险分析——实施定量风险分析——规划风险应对
规划采购管理、规划干系人参与

执行（10）
获取资源、建设团队、管理团队、实施采购
指导与管理项目工作、管理质量、管理沟通、管理干系人参与、实施风险应对、管理项目知识

监控（12）
控制范围、控制进度、控制成本、控制资源、监督风险、控制采购、监督干系人、监督沟通
控制质量、确认范围、监控项目工作、实施整体变更控制

收尾（1）
结束项目或阶段

Scrum核心 3-3-5-5
3：三个角色：PO、Scrum master、开发团队
3：三个工件：产品代办列表PB、冲刺待办列表、产品增量
5：五个事件：Sprint、计划会议、Scrum站会、评审会、回顾会。
5：五个价值：承诺、专注、开放、尊重、勇气。

三个工件：
产品待办列表PB
用户故事：描述用户需求，我，想要，目的价值
（1）PO负责PB内容和优先级
（2）列出了需求特性、功能、内容、改进方法、缺陷修复等。
（3）优先级排序，优先级高的描述更清晰更具体，给出明确定义（DOR）
方法：KANO和Moscow，必备需求、具备需求、期望需求、魅力需求、反向需求。
（4）通过产品backlog梳理增加细节、估算和排序，是个持续不断地过程。PO和开发一起讨论。
（5）条目的评审和修改由PO和开发之间展开。
（6）估算是由开发完成的。
另外，DOR和DOD是在一开始的时候开发和PO公共决策，并且整个过程是不断修正的。

冲刺待办列表 SprintBacklog
（1）是一组当前sprint选出来的产品待办列表条目，外加产品增量和实现目标的计划。
（2）用户故事拆分成任务，团队主动领取，非分配。（原因：十二原则之，团队拥有完成项目的全部能力，并且每个人是积极向上，不会出现完不成或者不愿意领取的任务）。
（3）工作目标清晰可见。
（4）内容足够具体清晰，进度上能在站会中得到理解。
（5）开发团队的任务就是完成sprint的目标。

产品增量Product Increment
（1）是一个sprint完成所有待办列表内容额总和，以及之前所产生的增量的价值总和。
（2）新的增量是必须完成的，必须达到“完成”的定义（DOD）。
（3）增量是在Sprint结束的时候可检视和已完成的产品组成部分。
（4）PO决定是否发布，但增量必须可用。

技术负债：
开发人员为了加速开发，在采用最佳方案时妥协采用加速开发进度的方案，从而带来的额外负担，比如后期必须重构或者其他副作用。

五个事件：
Sprint（计划会议、每日站会、开发工作、评审会议和回顾会议）
解释为 冲刺/迭代。持续时间短，一般是2周等。这个时间一般不变，原因：十二原则之步调稳定且延续、及时获取干系人反馈。结束时所有未完成的事项回到产品待办列表PB里，重新估算优先级等。

Sprint计划会议
（1）两周的sprint 最多4小时上限。Po介绍优先级高的功能，开发团队提出问题，能够完成的话就把这个任务从Procudtbacklog 移动到 Sprintbacklog里。开发评估如果超了，建议PO停止。开发团队决定一个sprint完成多少任务。最后开发和PO共同评审。
（2）计划会议内容一般不变更，变更内容不会纳入该待办列表里，而是加到后续产品待办列表PB里，后续评估。

故事点：一个度量单位，用于表示完成一个待办事项或者任务的所有工作量的估算结果。一般选择一个最简单的用户故事为基准，衡量其他的用户故事的工作量。
刺探/探针：作为试验品 快速简陋的实现，验证技术是否可行。
速率：衡量团队在单个sprint可以解决的工作量的指标，是scrum的关键指标。

注：
每个团队选的基准用户故事不同，不同的团队完成的故事点不具备可比性，并不是完成的越多越好，而是越稳定越好。团队速率一般是经过多个sprint磨合后才能稳定。

scrum站会
一般15分钟，开发团队自己召开。
昨天做了什么、今天准备做什么、遇到什么问题/障碍。
会上只记录，不讨论。
原则上只有开发团队参加。

信息发射源/信息扩散器：
可视化展现项目状态和信息，促进信息流通，倡导干系人观看，从而无需单独发送报告。燃尽图、累积流量图等。

评审会议
Sprint快结束时举行，一般2小时，用于内部检视产品增量并调整待办事项列表PB。
（1）讨论并演示已完成的工作，获取反馈促进合作。
（2）讨论下一步工作内容，最终修订产品待办列表PB，阐明下一个sprint的产品待办事项。

回顾会议
评审会议之后，下一个sprint会议之前，一般不超过2小时。明确在接下来的sprint需要实施的改进。

五大价值观：
承诺：愿意对目标做出承诺。
专注：能力全部用于承诺的工作中。
开放：scrum把项目的一切开放给每个人。
尊重：每个人都有独特的背景和经验。
勇气：做出承诺、履行承诺，接受尊重。