08.09 星期三
有新干系人加入时，先分析，再做其他操作
敏捷项目有新需求，先列入到待办项列表，再分析影响，不需要分类
风险管理计划是项目经理自己用的，不是用于上报的
要削减预算，必须缩小范围
质量审计和合规有对应关系
整合工作不能委托/授权给其他人
风险问题要“疑似从有”
技术意见不一致，鼓励其讨论沟通
敏捷项目不需要遵循变更流程
需求问题不能闭门造车，需要和相关方讨论
08.10 星期四
讨论的目的是为了有解决方案，看到讨论会议选择“解决方案”选项
有“替代方案”的选项可以考虑优先选择，因为体现了主动性
DoR包括了DoD，DoD包括了验收标准，验收标准包括了测试案例
工作包是最小单位，由WBS分解的
效益管理计划包括：目标收益，战略一致性，实现收益的时限
和项目收益有关的：效益管理计划和商业论证
08.12 星期六
模拟六：
MoSCow是排序工具
团队章程不是项目章程，不包含项目目标，搞清楚项目章程和团队章程的区别
审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。
自组织团队由团队决定应该接受哪些培训
自下而上估算，需要掌握详细信息
PMO提供了新项目应遵循的详细模板，项目经理应遵守模板要求。除非出现特殊情况，如公司模板不适合项目的具体情况，可以提出变更
质量缺陷必须修复，但如果不影响正常上线，完全可以在上线后进行修复
范围管理计划是程序型计划，不需要渐进明细地制定
模拟七：
项目经理应密切关注影响项目的内外部事业环境因素的变化
项目评估多在项目开始前或项目完成后进行
工作流可理解为系列工作，由一个小团队负责的。有问题，要面对；负责工作流的团队有可能肩负多个项目以及运营工作，即兼职团队，因此与团队主管及其职能经理一起会面解决更好
内部变更问题，但目前只是一面之词，应先确认一下再做决策
如何区分工作项的优先级？敏捷项目的工作优先级按商业价值进行排序
质量管理计划中不包含验收标准
供应商出问题，对项目经理而言，一般当成风险识别，记录在风险登记册、分析影响并制定应对计划
规划风险应对的工具：备选方案分析、成本效益分析
要在多个方案中挑选最合适的，应先量化，再决策，净现值（NPV）更全面
KANO是为待办项排优先级的技术
质量问题一般不当成风险
项目风险管理的责任人是项目经理。无论谁识别的风险，无论已经汇报给谁了，只要项目经理发现，就应该对风险进行管理
章程中包括成功标准和退出标准，而退出标准更强调在项目中止时使用
项目目标评审会议是针对整个项目的，而不是当前迭代
矩阵型组织下，团队成员身不由己，其工作安排都由其职能经理决定
管理无定式，应具体情况具体分析。PMO要求的策略是为项目服务的，如果与具体的项目特定不一致，对项目的开展造成了阻碍，是可以和PMO协商调整、修改策略的
08.13 星期天
模拟八：
“之前的事件反馈”，属于下列哪一项的内容？属于经验教训，敏捷方法的经验教训在回顾会议总结，属于回顾会议的结果
已知-未知风险发生后，应该做什么？首先应该记录在风险登记册
每次冲刺结束都要让干系人验收
规划质量管理包括定义质量标准、指标和规划质量管理的路径
新法规影响项目，应记录——分析影响——上报发起人——采取措施
新老团队成员之间不能相互协作，属于了解、信任问题，应使用团队建设活动来增加了解、信任
立即发挥作用（增量交付），随时添加功能（迭代开发），都是敏捷方法的特点
里程碑信息最早出现在项目章程中
机会一旦上报，就不再由项目团队做进一步监督
在项目结束前，指导团队实施效益管理计划并跟踪成果
模拟九：
与战略相关的工作优先级变更，发起人的意见更重要，临时组织“特别指导委员会”，缺少合理性
审计：用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程
项目目标应包含一系列的成功标准，如时间、成本、范围、质量等，“主要干系人和项目经理应就这些问题达成共识并予以记录”。这些成功标准必须获得干系人的同意
风险发生变成问题，可以先记录在问题日志中，再进行解决
“避免将来发生这类情况？”此类问题的正确答案基本上就是两个：一、记录经验教训；二、使用问题日志。
根据验收结果更新需求跟踪矩阵
敏捷项目的范围、需求变更问题。敏捷的范围变更，直接增删待办项列表即可，且应由产品负责人拍板
敏捷项目，开发团队应根据待办项列表的优先级来安排冲刺工作。如果PO增加或减少了功能，也应该设置优先级，让团队都了解哪些工作更重要、优先开发
敏捷项目的自组织团队，技术方面的决策，由团队当家做主。
进度审查会议哪一项议程最重要？进度审查会议属于监控过程，更新解决方案和行动安排比较重要
项目团队发现一个设计问题，需要变更。即使设计工作也是项目团队所为，此时也应先告知客户，客户同意后才能通过变更控制过程变更设计；如果设计工作是客户或第三方所为，则变更请求应由客户提出
PMO总监发现的是一个项目管理流程漏洞，应该进行改进。各部门一起参与制定政策，修补流程的漏洞
团队就方法、技术意见不一致，属于积极的冲突，项目经理应鼓励团队自行探讨解决。