https://blog.csdn.net/xudahai513/article/details/125216704
https://img-blog.csdnimg.cn/13587251eff440a880cb1d12d8576b29.png
Scrum Master是团队的导师和组织者，与Product Owner紧密合作，及时为团队成员提供帮助。促使team按照
Scrum Master并非团队的领导（因为团队是
确保
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（
Scrum Master在团队中的作用
在junior团队中：主导和控制
在intermediate团队中：引导和教导
在Senior团队中：辅导和协助
一句话总结SM这个角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。
第一象限：严防死守（重点管理）
第二象限：投其所好（令其满意）
第三象限：保存关注（定期监督）
第四象限：确保知会（及时告知）
凸显模型：就是综合分析相关方权力、紧迫性和合法性，确定相关方需要被关注的优先级，和管理相关方参与的策略。//适用于复杂的相关方大型社区
遵守变更流程10步：预防--1变更请求--2分析影响--3备选方案--4CCB批准--5更新项目管理计划--6沟通干系人--7执行--8检查--总结；；
1、组织过程资产是具体的（如流程与程序、模板、档案、经验教训、知识库等） 2、事业环境因素是宏观的（如外部的法律、法规、国家政策与市场环境；内部的企业管理制度，文化等） 3、组织过程资产可以在项目过程中被直接使用、更新或修改，而事业环境因素不能被剪裁和直接使用，但会受到它的影响。 4、组织过程资产和事业环境因素经常一起作为输入，但事业环境因素是不会成为输出，而组织过程资产会被不断的作为输出被更新 5、组织过程资产和事业环境因素是两个相对的概念
随着组织中的scrum团队增加，特别是在多个scrum团队比较紧密地工作在一个产品上的时候（对大型的公司这个非常正常），我们就不得不面对不同团队之间的协同的挑战，所以寻找和探索大规模敏捷的解决方案就变得很自然。行业里目前有一些大规模敏捷的解决方案，最基础的就是Scrum of Scrums（SoS）
的做法就是每个scrum团队选出1-2个代表，团队的代表聚在一起分享进度和协同解决依赖。如果组织很大，scrum团队太多，也会出现先按部门的划分在不同的部门里做SoS，然后不同部门的代表再聚在一起做“Scrum of Scrum of Scrums”。也就是分层次的SoS。
链接：https://www.jianshu.com/p/c66b8dcccd2a
链接：http://www.pmquanzi.com/articlDetails/1293.html
开工会议：它的英文是Kick-off meeting。有时候中文翻译为开踢大会，开球大会，启动大会。就好比足球比赛开场之前，每位教练都会在更衣室对他的足球队员进行一个战略战术的宣贯。虽然它也翻译为启动大会，但是这个会议并不是在启动过程组召开的，它属于规划过程组。它是项目管理计划制定完，执行之前召开的。召开完启动大会之后，那么项目就顺利的进入了执行过程组。
启动大会有哪些干系人参与呢？比方说项目的发起人、项目经理、项目团队、客户、高级管理层等等，都会邀请来参加本次的启动大会，邀请众多的关键干系人来参加本次的启动大会。在启动大会上面，获得团队对本次项目的承诺，以及要告知每位干系人他们的角色和职责。它也是一个宏观的、务虚的会议。什么叫宏观务虚呢？不干实事，不做太过细节的事情。实际上，这个启动大会就是让大家互相见个面，熟悉一下对方，让每个人都知道自己在项目当中该干什么？然后互相沟通一下，鼓舞士气，并且在项目启动大会上面，项目经理会向项目团队展示项目管理计划，获得关键干系人对项目管理计划的正式认可。
召开时间：是启动阶段结束时召开的会议。
主要任务：发布项目章程，并任命项目经理，赋予项目经理动用组织资源的权力。
注意事项：
（1）召开会议前已经对相关方进行了识别，有了相关方登记册和相关方管理策略。这时，应该让各相关方认识和会面，同时让客户方领导向项目经理和项目小组成员进行授权，调动员工的积极性，让客户方从上到下形成共识，为团队日后开展相关工作扫除障碍。
（2）召开启动会时，已经对风险进行了初步规划与识别。
（3）项目经理要向相关方汇报项目计划，不过这时的计划是非常粗略的，不能用于指导项目实施。
用来指导项目实施的项目管理计划需要滚动式规划渐进明细，通过制定项目管理计划过程组，才能得到真正的项目管理计划。
召开时间：规划阶段结束
会议目的：
（1）正式批准综合性项目计划，并在相关方之间达成共识。
（2）落实具体项目工作，为进入项目执行阶段做准备。
\3. 已做事项：开踢会议召开前，通常已经确定了项目的组织结构，并且定义了团队成员的角色与职责。
\4. 已有文件：这时用于指导项目的项目管理计划已经制定出来，有了项目范围说明书、范围基准、各分项管理计划、进度计划、采购计划、风险登记册等文件。所以，在开踢会议中，通常需要对项目的范围、进度、成本、风险应对等事项进行确认，并在相关方之间达成共识。
把预先选定的相关方和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。焦点小组会议往往比“一对一”的访谈更热烈，由一位受过训练的主持人引导大家进行互动式讨论。
研讨会是快速定义跨职能需求和协调相关方差异的重要技术，通过邀请主要的跨职能相关方一起参加会议，对产品需求进行集中讨论与定义。
由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参会者达成一致意见。这项技术的另一个好处是，能够比单项会议更快地发现和解决问题。
引导式研讨会有两种方式 ：在软件行业用“联合应用开发”，注重把用户和开发团队集中在一起，来共同改进软件开发过程；在制造行业 ，则使用“质量功能展开”来帮助确定新产品的关键特征，最终得到功能排序。
会议确定实施风险管理活动的总体计划，确定用于风险管理的成本种类和进度活动，并将其分别纳入项目的预算和进度计划中；建立或评审风险应急储备的使用方法；分配风险管理职责；并根据具体项目的需要来“裁剪”组织中有关风险类别和术语定义等的通用模板，如风险等级、不同风险的概率、对不同目标的影响，以及概率影响矩阵。
如果组织中缺乏可供风险管理其他步骤使用的模板，会议也可能要制定这些模板，这些活动的输出将汇总在风险管理计划中。
状态审查会是监控项目风险的最后一个工具与技术 ，但项目风险管理应该是定期状态审查会中的一个议程，其所占用的会议时间长短取决于已识别的风险及其优先级和应对难度。
从本质上看，这是一个全面评估的大会，它的具体内容包括：
项目的详细计划； 项目的绩效的控制程序和方法； 项目进行过程中，面临的风险和不确定性判断和控制； 项目小组的人员安排； 项目小组内部交流和沟通界面的形成； 项目进行过程中，报告制度的安排； 客户关系； 分包和承包者关系； 与其他机构的关系； 会计与核算的方式、内容和结果； 项目进行过程中，其他没有言明但重要的事项。
投标人会议是在投标书或建议书提交之前，在买方和所有潜在卖方之间召开的会议。
目的
保证所有潜在卖方对本项采购（包括技术要求和合同要求）都有清楚且一致的理解，保证没有任何投标人会得到特别优待。
\2. 注意事项
（1）要把对问题的回答，以修正案的形式纳入采购文件。
（2）买方必须尽力确保每个潜在卖方都能听到任何其他卖方所提出的问题，以及买方所作出的每一个回答。
（3）时刻关注这个问题：让所有的潜在卖方得到的信息都是一样的，使他们都处于同一起跑线上，真正发挥招投标的作用。
任何项目收尾，都要总结经验教训，更新知识库，这些知识将成为组织过程资产，供以后的项目参考。在总结经验教训时应当注意区分几项重要工作的分配：
经验教训总结：人人需要参加。
参与：项目相关方。
编写：项目团队（包括项目经理）。
负责：项目经理。
归档：PMO。
质量保证指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。质量保证应贯穿于项目的始终。
质量保证往往由质量保证部或组织中与此名称相似的单位提供，但并非必须由此类单位提供。考|试/大质量保证的物件可以是项目团队以及实施组织的管理层（内部质量保证，或者是客户和其他未实际参与项目工作的人们（外部质量保证）
8.2.1 质量保证的投入
\1. 质量管制计划（Quality management plan）
质量控制量度的结果（Results of quality control measurements），质量控制量度指以便于比较分析的格式表示的质量控制测试和量度的记录。
\3. 工作定义（Operation definitions）
8.2.2 质量保证的工具与技术
\1. 质量规划的工具与技术，质量规划的工具与技术也适用于质量保证。
\2. 质量审计（Quality audits）
质量审计指对其它质量管制活动进行有组织的审查。质量审计的目的是发现所汲取的有助于改进本项目或实施组织内其他项目绩效的教训。
质量审计可以事先安排，也可以随机进行；
8.2.3 质量保证的产出
\1. 质量改进（Quality improvement），质量改进指采取行动提高本项目的成效与效率，为项目干系人提供额外效益。
多数情况下，实施质量改进时应按综合变更控制的程序准备变更申请，或者采取纠正措施。
原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改过程，应用系统 “最初版本”就逐步演变为系统 “最终版本”。
原型法就是不断地运行系统“原型”来进行启发、揭示、判断、修改和完善的系统开发方法。
工作分解结构：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细的定义。
WBS总是处于计划过程的中心，也是制定进度计划，资源需求，成本预算，风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS 定义的。
工作分解结构（简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。即：项目→任务→工作→日常活动。
工作分解结构以
工作包(work package)是WBS的最底层元素，一般的工作包是最小的"可交付成果"，这些可交付成果很容易识别出完成它的活动、成本和组织以及
WBS是一个描述思路的规划和设计工具。它帮助
\1. WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
2 .WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
3 .WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
WBS防止遗漏项目的可交付成果。
WBS帮助项目经理关注项目目标和澄清职责。
WBS建立可视化的项目可交付成果，以便估算工作量和分配工作。
7 .WBS帮助改进时间、成本和资源估计的准确度。
WBS帮助项目团队的建立和获得项目人员的承诺。
9 .WBS为绩效测量和
10 .WBS辅助沟通清晰的工作责任。
WBS为其他项目计划的制定建立框架。
WBS帮助分析项目的最初风险。
(https://upimg.baike.so.com/doc/10040871-10521086.html#)
组织分解结构：按照组织现有的部门、单元和团队排列，并在每个部门下列出项目活动或工作包，运营部门只需要找到其所在OBS的位置，就能看到自己的全部职责。
工作分解结构：5.4 为成本管理计划提供了框架，以便据此规范地开展成本估算、预算和控制。
资源分解结构：9.2.3.3 资源分解结构按照资源类别和资源类型提供以识别资源的层级结构。用于规划，管理和控制项目工作，每向下一层都代表对资源的更详细描述，直到信息细到可以与工作分解结构相结合来规划和监控项目工作。
资源类别包括人力，财力，设备和用品。资源类型包括技能水平，要求证书、等级水平和适用于项目的其他类型。在规划，资源管理过程中资源分解结构用于指导项目的分类活动。在这过程中，资源分解结构是一份完整的文件，用于获取和监督资源。
风险分解结构：风险分解结构有助于项目团队考虑单个风险的全部可能来源，对识别风险或归类已识别风险，特别有用。
一、形成阶段
众所周知，团队刚形成时，领导者在如何处理任务和组织人员方面犹豫不决。团队成员会寻找明确的方向，并且可能会急于考虑任务而不考虑团队建设，即思考如何一起工作。在这个阶段，角色和责任尚不明确，领导者的任务是消除团队成员的疑虑，了解成员的动机和偏好，并帮助他们相互了解。通过对话来发现团队的共同目标也十分重要。在对话中需要询问：要实现的目标是什么？团队存在的意义是什么？我们要倾听什么？
二、冲突阶段
该阶段往往伴随着冲突和职位争夺。谁拥有权力，谁没有权力？这是一个重大问题。派系也会随之产生，致使一些人感受到归属感，而其他人则没有。成员情绪可能会十分激动。团队领导者必须正确处理成员间的冲突，帮助他们理解意图、角色、责任和目标。这意味着团队领导者必须以建设性的方式引导冲突。该阶段有两个重大危险：
首先是成员间尽力避免冲突，从而消除了意见分歧，阻碍了新观念产生，这对团队的创造力是一个灾难。
其次是冲突加剧，演化为私人冲突并导致失控。
无论出现上述哪种情况，你的团队都无法建立起相互尊重或信任，成员间无法互相倾听或交流，因此不能有效地共同工作。团队领导者需要确保意见分歧是非私人的，同时鼓励不同意见，这样才能产生积极效果。
度过冲突阶段的重要建议是，提醒团队成员，他们拥有共同目标以及其他的共同之处。在任何一个发展阶段中，如果团队缺乏目标都会举步维艰。
三、规范阶段
接下来将介绍一个更有凝聚力的集体的形成过程。具体情况如下：
• 进行角色分工与责任分配。
• 明晰目标。
• 保持团队和谐十分重要。
• 淡化冲突和分歧。
• 开展团队进度讨论。
• 成员们一起工作，共同完成任务。
• 进行组内任命。
在这一阶段，团队领导者的任务之一是创建分组，推行有效的工作方法，根据团队成员的偏好和技能分配任务。团队领导者也应该允许不同的声音，避免团队陷入趋同思维的陷阱。如果人们不敢提出反对意见，那么潜在的有价值建议就会被埋没。
四、运行阶段
在这一阶段，团队合作默契，领导者已经形成了自己的领导方式，具有战略意识并形成共同愿景，同时允许团队多样性存在。成员有更多的灵活性和自主权，能够积极地相互帮助和扶持。除非团队成员更新，否则最终团队表现会下降，但领导者还是希望尽可能延长这一阶段。成员的成就应该得到认可和祝贺。新成员加入后需要很好地融入团队。领导者需要努力促进和鼓励多样性，并时刻顾全大局，不断提醒团队成员不忘初心。
五、解散阶段
团队解散是任何团队生命周期的自然组成部分。它既可能是整个团队的结束，也可能是一些成员离开团队。在这一阶段，领导者需要关注两件事——学习和欣赏。对于那些离开团队的人，我们应该给予感谢和认可，这一点非常重要，往往很容易被忽视。了解团队对组织的贡献，团队成员学到了什么，以及如何将这些学习反馈给组织，都是非常有用的。这意味着未来的团队成员可以从中受益，从而少走弯路。最后，团队应该一起庆祝，这将激发他们继续前进，因为团队解散时，成员们都会感觉若有所失，但这也意味着团队成员将进入具有正能量和成就感的新团队。
这个模型很有意义，它使人们意识到，所有团队都必然要经历这些发展阶段。这意味着团队领导者可以关注团队的发展阶段，并尝试通过干预来推动团队发展。认识到团队需要经历形成、冲突、制订规则和行为规范化等阶段，才能最终取得成果，这些阶段是正常的也是有益的。如果你认为这只是一个简单的线性过程，将是很危险的。作为一名团队领导者或团队成员，你曾经一帆风顺地度过这些发展阶段吗？当然不是！事实上，那时可能更加混乱。因此，我们认为将该模型视为一个动态过程会更加有益，即将团队的形成、冲突、规范、运行和解散作为一个循环的持续过程。
进度压缩定义：
进度压缩技术是指在不缩减项目范围的前提下，缩短或加快进度工期，以满足进度制约因素、强制日期或其他进度目标。负值浮动时间分析是一种有用的技术。
快速跟进：
英文名：Fast tracking。将原来顺序进行的计划活动并行执行，快速跟进增加了返工风险，通常会导致风险增加。
赶工：
英文名：Crashing。通过增加资源，以最小的成本代价来压缩进度工期的种技术。考虑加班等，对费用和进度进行权衡，确定尽量少增加费用的前提下最大限度地缩短项目持续时间。赶工导致成本增加，且并非总是切实可行的。 
“实施整体变更控制”也是项目整合管理 监控过程组中的一个过程。
首先来看一下PMBOK中对实施整体变更控制过程的相关定义。
实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。**本过程需要在整个项目期间开展。实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。**
主要流向：1、指导与管理项目工作；2、控制质量；3、控制采购。
有几个关键点：
1、变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。
2、在整个项目生命周期的任何时间，参与项目的任何相关方都可以提出变更请求。
3、变更请求可以书面和口头方式提出，但是所有的变更请求都必须以书面形式记录（口头提出后需补书面记录），并纳入变更管理和（或）配置管理系统中。
4、在基准确定之前，变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准，就必须通过变更控制程序来处理变更请求。
5、在批准变更之前，可能需要了解变更对进度的影响和对成本的影响。
6、如果提出的变更请求不影响项目基准，那么项目经理可以直接对变更请求进行批准、推迟或否决。
7、如果提出的变更请求影响项目基准，那么项目经理需要进一步将此变更请求提交至CCB进行批准、推迟或否决。
注：CCB（Configuration Control Board，变更控制委员会）是一个正式组成的团队，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。
不是所有变更都需要经过CCB，只有涉及基准变更的才会交付CCB审核处理，一般的变更PM即可处理，特殊、紧急的涉及基准的可不通过CCB由PM紧急处理。
8、变更请求得到批准后，可能需要新编（或修订）成本估算、活动排序、进度日期、资源需求和（或）风险应对方案分析，这些变更可能要求调整项目管理计划和其他项目文件。某些特定的变更请求，在CCB批准之后，可能还需要得到客户或发起人的批准，除非他们本身就是CCB的成员。
一、变更请求批准前
1、影响变更
最好的变更就是没有变更，此时项目经理应该通过初步分析，口头影响提交变更请求的人，这通常是对重要相关方提出变更请求时采取的策略，例如建议重新开始一个项目，而不是变更当前的项目。注意这种变更往往影响重大，或者影响较广，变更得不偿失。
2、提交变更
提交变更请求包含的内容比较多，狭义的理解是提交变更请求单，相当于书面记录变更。广义的理解可以认为包括提交请求单、分析影响、CCB 批准等后续步骤。
3、分析变更的影响
对正式提交的变更请求进行影响分析，以便确定后续采取什么样的应对方案。如果提交变更和分析影响同时出现，选择“提交变更请求”。
4、制定解决方案
5、提交 CCB 批准
其中前三条考的比较多。
二、变更请求批准之后
变更批准后要做的几件事：
1、 更新变更日志；
2、 更新项目管理计划；
3、 通知有关的相关方；
4、 实施批准过的变更；
5、 确认或验证已批准变更的实施情况。
其中前三条考的比较多，注意这几条的顺序。
三、变更类题目永远不选的选项
对于变更类题目，常见的不能选的选项包括：
1、 拒绝变更，一般是给个看似合理的理由然后说不能变更
2、 忽略变更，就是继续执行当前的计划，对变更漠视不理
3、 拖延变更，强调下次开会时再讨论，或者说下一阶段再处理等等。
4、 直接变更，不做分析和判断直接实施变更，除非按照整体变更流程已经到了这一步，否则一般不是正确选项，但这种概率很低。
5、 直接更新计划，按变更请求直接修改计划，除非按照整体变更流程已经到了这一步，否则一般不是正确选项。
项目经理在变更中的作用
项目经理在变更中的作用，是响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转换为资源需求，供授权人决策；并根据评审结果实施即调整基准。确保项目基准反应项目实施情况。
管理干系人的定义：
在整个项目生命周期中，与干系人进行沟通和写作，以满足其需要与期望，解决实际出现的问题，并促进干系人合理参与项目活动的过程。
主要作用：
帮助项目经理提升来自干系人的支持，并把干系人的抵制降到最低，从而显著提高项目成功的机会。
管理干系人参与包括下面的活动：
1.调动干系人适时参与项目，以获取或确认他们对项目成功的持续承诺；
2.通过协商和沟通，管理干系人的期望，确保实现项目目标；
3.处理尚未成为问题的干系人关注点，预测干系人在未来可能提出的问题。需要尽早识别和讨论这些关注点，以便评估相关的项目风险；
4.澄清和解决已识别出的问题；
需要注意的关注点：
1.确保干系人清晰的理解项目目的、目标、收益和风险，可以提高项目成功的概率；
2.通过管理干系人参与，不仅能使干系人成为项目的积极支持者，而且还能使干系人协助指导项目活动和项目决策；
3.主动管理干系人参与可以降低项目不能实现其目的和目标的风险。通过预计人们对项目的反映，可以事先采取行动来赢得支持或降低负面影响。
4.干系人对项目的影响能力通常在项目启动阶段最大，而后随着项目的进展逐渐降低；
5.项目经理负责调动各干系人参与项目，并对他们进行管理，必要时可以寻求项目发起人的帮助。
核心内容：
输入：
干系人管理计划——13.2规划干系人管理
沟通管理计划——10.1规划沟通管理
变更日志——4.5实施整体变更控制
组织过程资产——
工具与技术：
沟通方法
人际管理技能
管理技能
输出：
问题日志
变更请求
项目管理计划更新
项目文件更新
组织过程资产更新
关于输入
1.干系人管理计划：描述了用于干系人沟通的方法和技术，为调动干系人最有效的参与项目提供指导；用于确定各干系人之间的互动程度；与其他文件一起，该计划有助于制定在整个项目生命周期中识别和管理干系人的策略。
2.沟通管理计划：为管理干系人期望提供指导和信息。用到的信息包括：干系人的沟通需求；需要沟通的信息，包括语言、格式、内容和详细程度；发布信息的原因；将要接收信息的个人或群体；升级流程。
3.变更日志：用于记录项目期间发生的变更。应该与适当的干系人就这些变更及其对项目时间】成本和风险等的影响进行沟通；
4.组织过程资产：组织对沟通的要求；问题管理程序；变更控制程序；以往项目的历史信息；
关于工具与技术
1.人际关系技能：项目经理应用人际关系技能来管理干系人的期望，如：
建立信任；
解决冲突；
积极倾听；
客服变更阻力；
2.管理技能：项目经理应用管理技能来协调各方以实现项目目标，如：
引导人们对项目目标达成共识；
对人们施加影响，使他们支持项目；
通过谈判达成共识，以满足项目要求；
调整组织行为，以接受项目成果。
关于输出
1.问题日志： 2.变更请求——在管理干系人参与过程中，可能对产品或项目提出变更请求。变更请求包括2个部分：针对项目本身的纠正或预防措施；针对相关干系人的互动的纠正或预防措施
3.项目管理计划更新：可能需要更新的管理计划有：干系人管理计划。
4.项目文件更新：可能需要更新的项目文件包括：干系人登记册。
5.组织过程资产更新：可能需要更新的组织过程资产包括：
给干系人的通知——
项目报告——采用正式或非正式的项目报告来描述项目状态。报告包括：经验教训总结、问题日志、项目收尾报告和出自其他知识领域的相关报告。
项目演示资料——项目团队正式或非正式向任一或全部干系人提供的信息
项目记录——包括函件、备忘录、会议纪要及描述项目情况的其他文件
干系人的反馈意见——
经验教训文档——
原文链接：https://blog.csdn.net/zzc125/article/details/53312169
✈预测型生命周期（瀑布型生命周期）——在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。
✈迭代型生命周期——项目范围通常于项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一系列重复的循环活动来开发产品，而增量方法是渐进地增加产品的功能。
从粗略到精细，从模糊到清晰
✈增量型生命周期——是通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
每次只交付一部分，像搭积木一样
✈适应型生命周期——属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。
Scrum 开发模式
✈混合型生命周期——是预测型生命周期和适应型生命周期的组合。充分了解或有确定需求的项目要素遵循预测型开发生命周期，而仍在发展中的要素遵循适应型开发生命周期。
https://www.cnblogs.com/OliverQin/p/10608512.html
预测型（集中交付）、（分批交付）迭代型（重复）、（分批交付）增量型（增加）、敏捷型（快速价值交付+文化理念转变）
重点是敏捷宣言和原则
看板（信息发射源）和燃尽图
仆人式管理者的角色定位
首先沟通（扫清障碍）记录到待办项
项目的质量问题（针对定义类型 DOD、AC、DOR）
稳定和灵活的一种平衡
渐进过渡（迭代、增量）
风险不大、具有中低程度不确定性的项目尝试这些新技术（先提供价值）
成功后在尝试复杂的敏捷项目
敏捷项目 一步一步来
https://zhuanlan.zhihu.com/p/564949163
资源平衡/平滑/赶工
资源平衡 *为了在资源需求与资源供给之间取得平衡，根据资源制约对开始日期和结束日期进行调整的一种技术 *克服特定时间内资源数量有限或过度分配 *资源平衡往往导致关键路径改变，通常是延长
资源平滑（resource smoothing） *对活动自身进行调整，从而使项目资源需求不超过预定的资源限制的一种技术 *相对于资源平衡，资源平滑不会改变项目关键路径，完工日期不会延迟 *活动只在其自由和总浮动时间内延迟（只调整非关键路径上的活动） *资源平滑无法实现所有资源的优化
资源平衡会让某个资源工作时候更轻松一点，但会使工作延迟；；资源平滑不会使工作延期，因为调整的是非关键路径上的活动。
赶工和快速跟进都是进度压缩技术 进度压缩是在不缩减项目范围的前提下，缩短工期以满足项目进度要求
赶工（crashing） *通过增加资源，以最小的成本增加来压缩进度工期的一种技术 *赶工适用增加资源就能缩短持续时间，且位于关键路径上的活动 *赶工可能导致风险和/或成本增加
快速跟进（fast tracking） *将正常情况下顺序进行的的活动或阶段改为至少是部分并行开展 *只适用于能够通过并行活动来缩短项目工期的情况 *快速更近可能造成质量风险，也有可能增加项目成本
记忆方法：赶工和快速跟进都能缩短工期； 赶工是加钱加人加资源，例如加班、加几个人、加设备等。用成本可以使工作快速做完。 快速跟进是用风险换时间，可能一毛钱不花也可能事后要返工、质量不合格或者可能要花更多的钱。
13.识别风险，并解决风险的流程：识别到风险，下面是风险分析（定性定量分析），然后才是规划风险应对（指定风险负责人），然后可能根据应对措施提出变更请求
风险登记册：包含 识别的风险
德尔菲技术避免 “圣人”光环效应和“凡人”从众心理的影响，给出更客观的分析和决策结果。（关键词：广受尊敬的人物）
范围蔓延是未受变更控制的非法变更； 当发生冲突时，需要冲突管理和谈判来解决
资源具有专业性，需要相近熟练程度的替代资源，而非仅仅通过培训资源就实现替代
质量控制测量结果是对项目实施中可交付物的质量控制结果的记录，遇到未达到质量标准的情况，先检查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 是
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.风险发生时，更新风险登记册，并非风险管理计划