1.冲刺评审会是需要相关的干系人参加的，在冲刺评审会上干系人可以审查并澄清角色、责任和管理模式
2.采购中的争议，往往找合同和SOW，SOW是对需要采购的详细范围的描述，与供应商在可交付成果方面有争议时，可以查看SOW
3.状态报告（工作绩效报告）是 PM 负责的
4.冲刺本身就是一次共同作战，冲刺规划了本次冲刺的工作和承诺信息
5.项目既可以采用预测，又可以采用敏捷，说明可以进行优化成为混合型，即确定的部分采用预测，不确定的部分采用敏捷
6.项目结束时由相关部门进行各种审计，将为项目交付物带来更多价值
7.迭代里迭代待办事项列表不会再进行变更
8.有抱怨，说质量保证可能有问题，应该进行分析和解决。质量审计是质量保证过程主要的工具之一；
先进行质量审计，如果确定有问题，再使用因果分析
9.敏捷转型首先强调组织、文化、高层的因素
10.RACI 责任分配矩阵是属于资源管理的一部分
11.敏捷团队的任务重新分配需要民主进行开会来进行，而非PM直接执行
12.需求不明确可能是敏捷项目， 几个月 按时迭代太长，达数月，应该采用段迭代/小增量
13.收集需求时，当需求不明确，需要使用原型法从模型创建、用户体验、反馈收集、原型修改的反复循环过程。例如先设计故事板及用户界面框图，从客户方获得反馈和更明确的需求
14.风险已经消失，项目即将完成，应该关闭风险，即风险审查/风险再评估
15.敏捷不提倡详细的工作报告，一是这回总文档沟通效率很低，而是这样节省下写文档的经历就可以花在更重要的开发工作上
尽量不做详细的工作绩效报告，而是面对面沟通
16.质量问题是在控制质量过程，质量问题往往过程没有做好，需要审计质量过程
17.敏捷项目经历及SM不解决具体的技术问题，提供培训来扫除障碍
20.项目结束后，PM和成员依然被要求进行支持，说明未成功转移，项目结束时要执行项目移交，移交后的支持工作是由运营团队来承担的。
21.团队章程包括：团队价值观，沟通指南，决策标准和过程，冲突处理过程，会议指南，团队共识等；
22.出现越界的情况，属于确定的问题，应该找原因来解决问题，当题干显示出现问题时，选项里的因果图往往是正确选项
23.快速部署 属于 敏捷领域；；详细的计划将需要很长时间进行规划和讨论，不能满足快速部署
24.一般赶工会增加成本，快速跟进会增加返工风险
25.采购中出现不一致的情况，首先检查采购合同和采购计划
16.冲刺迭代中不增加用户故事
27.商业价值降低应该与项目发起人讨论并建议重新评估项目的商业价值
28.PO需要监督外部环境变化，以获得新需求
29.敏捷采用增量交付，每次迭代遵守时间盒。当要完成的待办事项已经占满本次迭代的能力时，其他待办事项留给后续的迭代里去规划和执行
30.先分析风险，然后才是规划风险应对，然后可能根据应对措施提出变更请求
1.对使用敏捷工具存在分歧，往往是不能正确使用，也说明要进行培训
2.基本规则是团队成员制定的可期望行为
3.问题解决不能等，晚解决的代价非常高
4.纠正措施需要被批准才能执行；；；项目团队负责解决项目执行中的问题
5.多项目或项目集时，开发团队可以制定一名成员对其依赖性进行管理，并参加各敏捷团队的SOS协调会
6.立项时不可能获得所有干系人的批准
7.RACI标明每个人的角色与职责，有效防止职责不清和冲突
8.合作来解决冲突，分析情况并产生解决方案
9.之前迭代的平均速度可以影响下一次迭代可承受的工作量，只有高优先级任务而不是所有任务作为下一个迭代的候选工作
10.敏捷团队给特定的人员提供培训，这违背了技能在团队中共享的原则
11.题目特别提出新产品，首先应该查看产品远景，了解产品启动的原因和关键功能
12.共享工作区是一种实体环境或者虚拟环境，比如实体形式上团队公用一块办公区域，使用大型白班，虚拟形式的信息共享网站，在线协作工具等，其主要母的就是帮助
团队成员快速的分享信息，彼此协作
13.新版本特性开发与支持旧版本不能横向比较哪一项工作更重要。不过在估算新特性开发速度时必须要考虑对过去版本的维护成本。
14.要让技术债务可见，并按照正确的优先顺序进行处理。将技术债务插入到待办列表来解决问题
15.团队收集并提供个人估算，说明估算是自下而上，由团队工作做出的，这符合宽带德尔菲方式，在团队每个人估算的基础上达成一致同意
16.结对变成在预估时时长翻倍，为开发人员和审查人员分配相同的时间完成工作
17.规划会议内容为 估算故事大小，确定故事优先级
18.将故事进行拆分，使用的是解聚的方法，解聚与分解的区别在于解聚的结果仍然是完整的故事，而分解时把故事拆分成了任务，每个任务不在能够独立实现某一个特性
19.敏捷倡导适应型规划，随着团队对于工作的深入认识，计划可以进行调整。应该通过沟通，合理引导干系人的期望
20.累计流量图可以看出当前缺陷的数来那个，目前处于哪个解决状态以及循环时间和前置时间等多个指标
21.变更管理计划定义了变更控制过程，并记录变更控制委员会的角色和职责
22.敏捷方法里往往不使用问题日志。问题日志的目的是确保问题被跟踪和解决，敏捷里是待办实现列表
23.干系人意见需要去解决，可能记录在问题日志，而非干系人参与计划（计划性文件，确定了如何使干系人达到期望的参与程度）
24.PM与团队编制项目管理计划后，需要与干系人进行交流与更新，并获得主要干系人（例如指导委员会）的批准
25.敏捷倡导将风险记录在信息发射源中，将风险透明化
26.缺乏干系人支持是监督干系人参与有问题，需要检查干系人参与计划并执行好管理干系人参与
遵守变更流程10步：预防--1变更请求--2分析影响--3备选方案--4CCB批准--5更新项目管理计划--6沟通干系人--7执行--8检查--总结；；
问题解决流程7步：定义问题----分析原因---产生多种解决方案（备选方案）--- 选择最佳方案----执行方案----检查结果---总结教训
风险流程：识别风险---更新风险登记册---定性分析---定量分析---规划风险应对---指定风险负责人---实施风险应对---监控风险
范围蔓延是未受变更控制的非法变更； 当发生冲突时，需要冲突管理和谈判来解决
资源具有专业性，需要相近熟练程度的替代资源，而非仅仅通过培训资源就实现替代
质量控制测量结果是对项目实施中可交付物的质量控制结果的记录，遇到未达到质量标准的情况，先检查QC记录。质量管理计划里不反映项目实施中的可交付物的质量结果
16.制定供方选择标准，包括筛选系统（必须满足某些评估因素的最低门槛），和加权系统（对不同的评估因素设置权重，并求得加权总分），以此获得符合要求的最好的供应商。
20.谈判是项目经理获得期望资源的必要方法。通常为获得最佳资源，需要与职能经理进行谈判；为获得稀缺资源，需要与其他项目经理及管理团队进行谈判（稀缺资源默认已经被其他项目占用）
23.迭代（冲刺计划）中不增加用户故事，且用户故事是面向产品的
30.PO的角色是必须有的，否则无法规划项目
31.敏捷领导应该关注团队的动态，了解辅导是在个人和整个团队层面进行的
34.识别风险后，先进行风险定性分析，并设置风险责任人，再规划相应的风险应对
36.沟通管理计划可以获得计划的沟通人员、沟通渠道等；干系人等级册不包含沟通规划的内容
38.干系人的不满意：
先理解干系人的沟通需求，再更新计划及提供信息
干系人参与计划之目的是让干系人达到“满意”，不满意的话首先检查哪些措施没有执行好或者制定好
干系人对可交付成果不批准/不满意，检查需求如需求跟踪矩阵
干系人对信息担心/不满意，检查沟通管理计划
干系人对某个问题不满意，检查干系人参与计划
39.项目经理对项目负责，有始有终，完成项目收尾的工作，确保所有相关项目文件均已存档
51.敏捷三角形：限制的时间，限制的成本/资源，可变的范围。。。最小可行产品是高优先级，PO对backlog及其事项的优先级排序最终负责
54.预算不够，则按优先级来交付，抓大放小
58.冲刺里是由缓冲事件，以应对不确定因素，但并非为了吸收延迟
59.采购中出现需要不一致的情况，首先检查采购合同和采购计划
61.出现重大问题，不代表需要终止项目
进度压缩会增加成本或风险，一般赶工会增加成本，快速跟进会增加风险
敏捷倡导尽早交付部分功能；团队很有经验，符合敏捷“个体与互动（宣言价值观）”；干系人支持与客户配合，可以获得很快的增量评审； 详细的计划将需要很长时间进行讨论和规划，不能实现快速部署
2.凸显模型可用于确定已识别相关方的相对重要性。适用于复杂的相关方大型社区，或在相关方社区内部存在复杂的关系网络（简单理解是因为凸显模型将干系人分为8类，而权力利益方格只分为四类）
凸显模型。通过评估相关方的权力(职权级别或对项目成果的影响能力)、紧迫性(因时间约束或相关方对项目成果有重大利益诉求而导致需立即加以关注)和合法性(参与的适当性), 对相关方进行分类。在凸显模型中,也可以用邻近性取代合法性,以便考察相关方参与项目工作的程度。这种凸显模型适用于复杂的相关方大型社区,或在相关方社区内部存在复杂的关系网络。凸显模型可用于确定已识别相关方的相对重要性。
3.发起人一般批准项目章程，关键干系人/主要干系人们批准项目管理计划
PM与团队编制项目管理计划后，需要与干系人进行交流与更新，并获得主要干系人们（例如指导委员会）的批准
4.敏捷强调团队， 故事并不包括技术愿景与远景
10.通过会议如 引导式研讨会等，帮助干系人实现讨论协商，最终获得共识
12.虽然是敏捷，但与供应商的合作需要更多的规范化，对所有的潜在供应商一视同仁，进行协商及招投标，而非简单确定之前的或某人推荐的供应商
15.项目初始阶段（启动阶段），规划阶段之前，高层级风险时包含在项目章程里的。
16.问题解决流程7步：定义问题----分析原因---产生多种解决方案（备选方案）--- 选择最佳方案----执行方案----检查结果---总结教训
17.商业论证记录了项目对组织的价值，此时需要审查商业论证。
干系人一键需要解决，可能记录在问题日志，而非 干系人参与计划（计划性文件，确定了如何使干系人达到期望的参与程度）
18.敏捷里的工件主要为团队所使用的，一般不需要给干系人共享。甚至工件不一定特别规范，因为团队往往在一起办公，面对面而不是非常依赖文档；
敏捷项目里干系人主要是通过评审会了解项目进展，如果有的干系人需要了解更及时的进展信息，可以邀请他来参加每日站会（但不要干扰开发团队）
20.敏捷三角形（固定时间，固定的成本/资源，可变的范围），敏捷团队一般不增加新人员。增加人员会使敏捷团队回到形成期及震荡期，团队绩效下降，且随着人数的增多，团队在沟通和协调上的代价增大，人均绩效下降
21.一般问题不要升级给发起人，PM是项目层级内问题的解决这
23.进行敏捷实践时，需要分析、选择并裁剪适合于组织自己的具体敏捷方法；敏捷肯定可以带来收益，不需要过渡论证是否可以应用
30.资金的事情需要找发起人，但应该先做好分析准备，再去找发起人
31.转型敏捷，先进行敏捷培训。对使用敏捷工具存在分歧，往往是不能正常使用，也说明要进行培训。使用敏捷工具的分歧，不是干系人之间的利益分歧，让他们首先正确理解敏捷工具
33.敏捷主张学习别人的优良做法，它山之石可以攻玉
项目刚启动，PM 不可为团队进行赋能和帮助
39.产品 backlog 是 Scrum 的核心，也是一切的起源。从根本上说，它 就是一个需求、或故事、或特性等组成的列表，按照重要性的级别 进行了排序。它里面包含的是客户想要的东西，并用客户的术语加 以描述。
41.缺乏干系人支持的问题，需要通过干系人管理来解决。执行干系人分析，规划干系人参与计划，举行开工会议以获得干系人承诺，这些将保证干系人更好的支持
43.开工会议期间，团队收到干系人对计划的支持，和对项目的承诺，说明在规划和沟通方面做的都很有效
50.缺乏干系人支持，是监督干系人参与有问题，需要检查干系人参与计划并执行好管理干系人参与-----------------计划好、执行过程好、name结果就会好；；干系人支持不够往往是干系人期望未满足
51.敏捷提倡不同敏捷团队之间的知识共享和交流
61.敏捷包含迭代和增量；增量交付可用尽早地、持续不断地交付有价值的产品增量让客户满意，每次迭代都可以适应竞争市场带来的变化；；；；迭代交付的往往是原型或半成品样机，可用性不够
63.敏捷里团队是自组织自管理，项目领导通过服务型支持团队来自己解决问题，需要指导和支持团队，只授权是不够的
70.风险时将来可能的问题/机会。他涉及到时间、概率和影响
73.障碍（例如缺陷/技术债）是backlog里的一类事项，需要进行优先级排序，放在相应的位置
81.敏捷三角形（固定的时间，固定的成本/资源，可变的范围），钱不够时，减少范围。敏捷三角形不增加预算。。。不能做完所有工作时，那就只能做重要的那部分，使用优先级排序来选择重要的
84.干系人建议项目经理不要结束该项目，项目经理应该审查范围管理计划，来看是否应该提出范围变更请求
85.出现不一致，就先沟通。沟通尤其是会议，是实现从不一致到一致的良好实践
86.产品设计不合规格，说明产品设计前的需求收集没做好，应该捕获客户的需求以满足客户的标准
87.控制图里出现越界（上下线控制线以外），则说明过程失控。过程失控，意味着大量的结果不符合指标
88.担忧，是因为沟通不足，加强沟通。针对特殊话题需要互动式沟通，面对面开会沟通是效率最高的方式
89.启动大会具有重要意义，尽量获得所有干系人的参加和承诺，分片开启动会，可以实现所有人都参与并获得承诺
100.项目团队负责解决项目执行中的问题，一般问题不要升级给发起人，PM是项目层级内问题的解决者
110.PO对产品需求负责，且po需要参加演示会/评审会
111.多项目时项目直接的依赖关系是要管理的。敏捷项目经理通过服务型/仆人式来支持自组织团队，所以这里的理解是由团队管理这种依赖性。开发团队可以指定一名成员对其进行管理，并参加各种敏捷团队的SOS协调会
116.需求频繁变化，不可能在签合同的时候就明确规定范围和功能
119.项目立项时，不可能获得 所有干系人 的批准
121.立项的召开启动会议的时机，是在项目管理计划得以批准后召开，也即它是规划阶段的最后一件事，所以会议结束意味着规划阶段就结束了
129.RACI图（执行、负责、咨询和知情图）标明每个人的角色和职责，有效防止职责不清和冲突；RACI是一种更详细的RAM（责任分配矩阵），简单的RAM还不能有效区分角色与职责
130.可行性研究的不确定程度很高，首选工料合同
131.敏捷项目以团队为核心，团队是自组织自管理，要鼓励并相信团队工作，敏捷需要适应变化，不可能一开始就识别出并规划几乎所有风险
133.项目开始前，先制定项目的产品路线图和发布计划，以便干系人理解方向与远景
135.敏捷项目往往没有沟通管理计划这样的文档
144.需要减少哪些需求，使用成本收益分析来减少那些相对而言成本高收益低的需求;
规划时的变化，不是项目变更，直接讨论分析并修改计划；不是项目变更，所以不用进行发起变更请求
169.冲刺计划会使团队内部定义本次冲刺的工作会议，客户不需要参加。并且，客户更多是提出检查结果，不关心中间的实现过程
171.清晰的愿景/远景是北极星，明确方向和目标
173.所有干系人都要重视，甚至反对性的干系人需求往往更重要
177.导师是指导和支持，不是代替。教练不能冲上去打球，老师不能替学生考试
179.干系人优先级排序不是根据需求的优先级进行排序的
180.风险发生时，更新风险登记册，并非风险管理计划
4.敏捷项目 通过信息发射源 进行项目进展情况展示
6.弥补缺陷可以走变更流程；缺陷补救属于变更请求
12.敏捷很少有规划，推荐及时调整
13.交流及沟通不畅属于沟通管理，定位沟通管理领域
31.定位预防的干系人抱怨，是干系人管理，定义一个用户焦点小组，是指定一个群体，找出会抱怨的重要客户群体
35.交付时缺少某些重要的流程文件和批准，属于过程审计；应该进行过程质量审查；过程审计检查过程中的差距
37.
43.快速响应能力 属于 敏捷特性
59.塔克曼团队五阶段：形成阶段--〉震荡阶段--〉规范阶段 --〉成熟阶段 --〉解散阶段
68.启动阶段，规划还么有开始，没有制定范围，也还没有变更流程，新的法律法规和项目都必须遵守
66.项目迭代过程中的变更，可走变更流程，迭代结束的变更，可以进行迭代审查，以应对变化
80.识别风险---更新风险登记册---评估风险影响
82.经验教训登记册可以避免未来在发生
83.问题的最佳解决流程进行会议沟通
85.要确保就必须有具体的行动才行；遵循合规一般指的是PMO
91.敏捷的原则：敏捷倡导可持续开发，主张发起人，开发人员和用户能够长期维持稳定的开发步伐。敏捷不主张加班
93.先判断是否为问题，如果是问题再解决问题
94.敏捷环境的解决冲突，自组织自解决，达成共识是解决冲突的最好方法
108.项目经理无权更新项目的商业论证，只有向发起人提出建议更新商业论证的途径
110.
112.程序正义
113.来自职能领域的一位团队成员对可交付成果进行频繁变更，妨碍了项目的整体绩效，若要预防这个问题，项目经历应该做什么？应该确保应用整体变更控制过程
118.发起人担心，所以是干系人管理，项目经历可运用软技能说服项目发切人批准新的预算估算，软技能包括：沟通，引导，说服等等；
120.资源冲突的解决方案：请求与项目经理召开调解会议
124.供应商与项目经历之间沟通失误，项目经理应该执行应对计划，与供应商共同应对问题，而不是单方面去处理问题
126.程序正义：先审查程序/计划，再按照程序正义或计划中的方法执行
137.创建工作分解结构是在 定义范围基准之后才进行的活动；在此之前可进行的活动为 采用干系人的意见制定范围说明书
139.团队管理，定位资源管理
141.干系人参与共同讨论，用排除法
147.焦点小组一般用于收集信息，不出结论
149.组织过程资产：经验教训知识库可以避免之前的问题再次发生
155.干系人管理，让关键干系人参与决策过程，可避免在功能验收时，功能被关键干系人拒绝
156.敏捷中的待办事项估算是有开发团队自己估算的
157.额外的范围属于范围蔓延，范围蔓延是违法的
158.可能排除，也有可能没有排除
162.有信息（状态报告）定位沟通领域
167.产品愿景：在项目初始阶段由关键干系人（客户/发起人/产品负责人）提供，属于项目的高级目标，产品能为客户带来价值的描述；；且敏捷推荐 讨论沟通等方式解决问题
169.考察问题流程：：** **
3.敏捷没有 关键路径一说
7.已识别的风险才能走风险应对流程；题意没有说明是已识别的风险，且已发生，那就走问题流程；问题发生，进行解决问题
12.敏捷价值导向，有价值可以拥抱变更；选项的成效性不同，选择成效比较好的选项。。。敏捷没有变更流程
16.纠正问题，走问题流程，其余的选项非 问题解决相关领域
17.干系人向团队成员请求获取项目的整体状态，属于干系人对沟通信息不满意，应该检查或更新沟通管理计划
19.更新干系人参与计划可以提高干系人对项目的了解和支持
22.团队建设，认可和奖励都是建设团队的方法
27.团队有震荡阶段进入规范阶段，项目经理可以计划社交活动，以帮助建立更牢固的人际关系，并确立共同的目标
29.共同承诺比共同制定要优
31.项目经理协助团队消除障碍；
风险的应对措施可以是待办事项列表的一部分，但是是PO的事情不是团队的事情
48.敏捷主要用来消除不确定性；不能解决团队内部的矛盾和冲突
49.正在制定进度计划，合理分配资源
50.没有文化中立的团队一说
51.精益生产 主要用来消除浪费
63.控制账户，挣值等属于项目管理领域，非敏捷领域；；敏捷通过估计用户故事点数来预测产品的预算
65.速度，迭代中实际完成功能的故事点之和，让团队得以观察历史表现，来更准确的规划后续迭代工作；可能需要4-8次迭代才能达到稳定的速度；
68.干系人管理 更新干系人参与计划
69.收尾过程理论上验收已通过，但是这里就是没有验收通过，因此可以理解为想要收尾了，检查是否符合收尾条件进行分析并回应干系人
75.冲刺活动不能轻易停止进行
77.SOS多个敏捷团队协作和同步集成的方法
79.已经发生的属于问题流程，
81.敏捷的风险管理：通过持续的反馈和验收，降低风险
84.产品特征有不同想法，属于冲突；可以一起决定最终的想法
85.使用者主动获取信息属于拉式沟通；被动获取属于推式沟通
91.愿景和目标是期望的体现；目标清晰才能作对
98.情商是管理自己和识别他人情绪的能力，不能解决问题；无法验收，问题无法解决，问题上报流程
101.PO的职责：规划愿景和路线图
106.要开的会议必须开，沟通对项目非常重要
108.已发生的属于问题，走问题流程而不是风险流程
114.敏捷模式适应实时的变化
117.只可能是整体影响分析不到位
118.多项目资源协调，分析不同项目，已确定对共同资源的最有效利用
121.回顾可以解决和改善项目过程当中遇到的问题
126.非客户提出的变更，尽可能不要变更
128.项目团队成员对做出贡献比较困难，属于问题，项目经历应该接近团队成员，已确定任何问题，然后计划相应的解决方案；
131.风险探针：基于风险的策略，通过向技术复杂度最低的国家发布产品，最大限度的提高产品的感知价值
134.敏捷最重要的是尽早和不断的给客户提供价值；在一个迭代中期，一个团队成员提出了一个新的做事方法，这个方法对最终客户没有提供任何价值，但是他可以帮助团队更有效的工作，项目经理应该不考虑这个变化，因为他最终没有给客户带来价值
141.敏捷团队的速度是固定的，敏捷的价值：通过尽早和持续不断的向客户交付有价值的软件使客户满意
142.产品负责人的职责：确定待办事项列表的优先级；；团队不能确定待办事项列表的优先级；团队可以和产品一起商定DOD
143.敏捷项目经理应该如何管理和控制新项目的范围：花很短的时间来定义范围，并建立原型来完善需求；；敏捷项目没有范围基线
145.参加规划会和评审会。定义验收标准和及时给出反馈
150.关键问题需要走问题流程，而不是风险流程
152.敏捷项目功能是否被包含，是由产品负责人决定的，而不是团队决定的，需求功能等澄清需要找产品负责人；；干系人有误解可以进行解释和澄清
154.产品负责人的职责：确定待办事项列表的优先级；；团队不能确定待办事项列表的优先级；团队可以和产品一起商定DOD
160.障碍项目经理应该消除障碍，通过与关键干系人沟通，获得承诺
162.回顾会议的作用：总结经验教训，针对下次迭代必须改善的特定工作
174.变更会增加成本，启动新项目也会增加成本
9.商业论证是在项目启动阶段的文件输出；风险管理计划不包含已知的风险；已知的风险在风险登记册
11.项目文件应该保存在项目管理信息系统中，并与适当的干系人共享；PMIS中包含配置管理
12.需求追踪矩阵可以跟踪需求是否完成；；干系人担心，要和干系人一起澄清检查
13.提升团队士气，首先要了解团队成员的期望
25.渐进明细，可参考历史数据来指导工作
31.资源发生变化，首先更新资源相关的文件
32.风险被管理的信息没有传递给首席执行官，属于沟通管理
41.风险储备分析包含管理储备与应急储备；识别风险之后，应首先进行定性分析，再进行定量分析，然后制定风险应对措施等，风险储备分析是在成本估算的时候需要进行分析的
48.问题管理流程，首先审查设计缺陷是否真的会影响质量，确定是否是问题
57.敏捷中没有快速跟踪相关的操作，且敏捷不支持加班；
61.问题管理流程，收集信息分析问题寻找根本原因
62.敏捷的转型是循序渐进的，先分析敏捷成熟度，再决定是否要辅导团队成员敏捷等技能
64.敏捷的开发团队需要通才或者T型人才
93.有错误属于问题，解决问题分析根本原因。通过回顾会议分析问题提出解决方案
101.采购问题，需要走问题流程，提出解决方案
121.团队管理，团队成员参与决策有助于改善缺乏方向，有自主权有助于提升热情
128.当问题无法解决时，走风险管理流程
153.干系人意见不一致，通过项目目标确保一致
157.项目正在启动，发现问题和发起人汇报
162.项目经理的职责：包括指导、辅导、教练等职责，并帮助团队消除障碍；；每日站会不讨论如何解决详细问题
165.敏捷开发团队是自组织自管理、彼此信赖、高度协作、知识分享的，致力于打造通性人才
168.项目经理的授权是在项目章程当中
173.错误发票是质量问题，因此更新问题日志，问题如果不处理可能会影响更大的风险。。。