从2021年9月开始，PMP®考试的考纲和题型将发生变化，敏捷内容将增加，那么敏捷和瀑布管理有什么区别呢？下面就给大家列一下敏捷的思想和原则：
一、如何判断这是敏捷？
看关键词汇，比如：快速变化、迭代、冲刺sprint、用户故事、用户画像、史诗、最小化可行产品MVP、燃尽图、燃起图、看板、增量交付、持续发布、迭代规划会、每日站会、迭代评审会、回顾会、lDoD（Defineof Done）等。
二、如何区分对待敏捷和预测？
预测是大规划、大执行、大交付；
敏捷是小步快跑-迭代+增量，不断交付l预测是严格控制变更；
敏捷是拥抱变化
注意：敏捷不是随便乱改，也必须要经过评估，只是团队+客户，讨论达成共识，就改了。没有冗长的流程和审批过程，以及各类繁复的文件。
三、敏捷宣言
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
四、敏捷框架Scrum作为敏捷的经典框架之一，比较典型。遵循PDCA原则，由3355构成，3种角色、3种工件、5种会议、5种价值观。
1. 三种角色
· ProductOwner：作为客户代表，定义所有产品功能，决定产品发布的内容及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理的调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
· ScrumMaster：起到教练的职责，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队的胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
· Dev Team：经典团队拥有5-9人，团队成员都是多面手（程序员，测试员，用户经验设计，等等），团队成员都全职工作（特殊职能可以例外（数据库管理员）），团队自我组织和管理，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整。
2. 三种工件(Artifaccts)：
· ProductBacklog：产品需求的列表，包含业务需求、技术需求、NFR等，理想情况下，每一个待完成的工作都将对客户产生价值，PO对该列表进行优先级排序，每个迭代开始前，优先级排序还需再度修正，待办事项列表中的条目以用户故事的形式呈现，ProductBacklog遵循DEEP模型（Detailed适当的详细程度、Estimated被估算的、Emergent涌现的、Prioritized排了优先级的）
· SprintBacklog：ProductBacklog 的子集，只记录当前迭代的工作，将用户故事拆分成任务，团队成员主动领取任务，团队成员有共同的迭代目标，为交付可工作的成果而努力，团队成员可以添加、删除或者更改迭代中的任务，迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新。
· Product Increment：团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付（发布和交付解耦），每次交付的用户故事必须符合验收条件，每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事。
3. 5种会议
· 产品梳理会P.B Refinement：拆分Epic\Feature、分析Userstory、重新估计并重排优先级。
· P 迭代计划会Sprint Planning Meeting：第一阶段：选取用户故事，确定迭代目标（PO与团队一起从P.B中选择待完成的用户故事）；第二阶段：拆分任务，创建S.B（团队拆分和确认任务给出工作量估算）S.B是团队协作的结果 不是只有SM和PO来决定的。
· D 每日站会Daily Scrum：属性：每天都开，15分钟结束，站着开会；所有相关的人被邀请，只有Scrum Master、Product Owner、Dev Team能够在会上发言，避免无关的讨论。
· C 迭代评审会Review：团队需要演示所完成的迭代工作，典型的做法是使用演示形式展示新功能或者底层架构的实现，非正式的，2小时的提前准备，不需要正式演示文，整个团队都需要参加，邀请所有关注产品的人参加。
· A 迭代回顾会Retrospective：周期性的回顾，总结工作中的经验和教训，15-30分钟，在每个迭代结束时进行，整个团队都需要参加，可能还包括客户，迭代回顾内容：哪些工作良好（应该继续保持）？哪些做的不好（应该停止）？哪些可以改进（就被按优先排序的改进的行动达成共识？）。
4、 5种价值观：
勇气Courage，开放Open，专注Focus，承诺Commitment，尊重 Respect。