PMP考试启用新考纲后，加入了一半敏捷及混合型题目，敏捷项目管理内容成为PMP考生必须备考的内容之一，慧翔天地为您分享PMP考试敏捷项目管理重点知识点。
敏捷宣言
我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始更重视：
【个体和交互】胜于【流程和工具】
【工作的软件】胜于【详尽的文档】
【客户合作】胜于【合同谈判】
【响应变化】胜于【遵循计划】
也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。
敏捷十二原则
准则1：我们的较高目标是，通过尽早和持续地交付有价值的软件来满足客户。
准则2：欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
准则3：要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
准则4：项目实施过程中，业务人员与开发人员必须始终通力合作。
准则5：要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
准则6：无论是对开发团队还是团队内部，信息传达最有效的沟通方法是面对面的交谈。
准则7：可用的软件是衡量进度的首要衡量指标。
准则8：敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该保持步调。
准则9：对技术的精益求精以及对设计的不断完善将提高敏捷性。
准则10：简洁，即尽最大可能减少不必要的工作。这是一门艺术。
准则11：最佳的架构、需求和设计出自于自组织团队。
准则12：团队要定期反省怎么做才能更有效，并相应地调整团队的行为。
敏捷阶段框架
相较于结构化项目管理的启动、规划、执行、监控、收尾五大过程组，部分流派将敏捷也做了一个五阶段框架：构想、推演、探索、适应、结束。他们不能直接跟结构化项目管理中五大过程组完全匹配对应，但是可以粗略这样对应。
四种生命周期及对比
预测型生命周期：一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。也称为瀑布式。
迭代型生命周期：这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。
增量型生命周期：这种方法向客户提供各个已完成的，可能立即使用的可交付成果。
敏捷生命周期：这种方法既有迭代，也有增量，便于完善工作，频繁交付。
计划始终贯穿其中，每种生命周期都有计划要素，不同之处在于完成多少计划以及何时完成
仆人式领导
特征：建立社区、倾听、同理心、成长承诺、治愈能力、管理能力、意识、洞察力、说服力、化繁为简能力。
1、帮助、促进团队发展。
2、为团队消除障碍。
3、为他人贡献铺路。
4、教育相关方，使其了解为什么要敏捷以及如何敏捷。
5、通过指导、鼓励和帮助为团队提供支持。
6、通过技术项目管理活动，如量化风险分析来帮助团队。
7、庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。
敏捷团队特征
1、团队规模：3-9名。
2、理想情况下，集中办公。
3、100%专职成员、跨职能团队、通才型希赛网、自我激励自律的成员。
4、鼓励自我管理团队，由团队成员决定谁执行下一阶段工作。
5、敏捷团队与仆人式领导一起茁壮成长，领导支持团队的工作方法。
6、团队频繁创造产品增量，团队集体对工作负责并共同拥有完成工作所需的所有必要技能。
7、限制在制品(WIP)、彼此依赖实现交付。
8、以各种方式开展合作(结对、群集、群体开发)。
敏捷团队的角色
1、跨职能团队成员：拥有各种必要技能;以常规节奏交付潜在可发布产品;核心职责是在短时间内交付任务。
2、产品负责人：指导产品的开发方向;创建、维护产品待办事项;根据商业价值排序任务;提供反馈。
3、团队促进者：确保遵循敏捷流程;引导、指导、消除障碍。
项目经理作为仆人式领导的职责
1、帮助、促进团队发展。
2、为团队消除障碍。
3、为他人贡献铺路。
4、教育相关方，使其了解为什么要敏捷以及如何敏捷。
5、通过指导、鼓励和帮助为团队提供支持。
6、通过技术项目管理活动，如量化风险分析来帮助团队。
7、庆祝团队成功，为团队与外部团队合作提供支持，并起到桥梁作用。
卡诺分析与MoSCoW
卡诺分析
Kano用于给需求进行优先级排序，它将需求分为以下四种类型：
作为阀值的功能：必须的功能。是产品要成功就必须具备的那些功能。改善增加阀值功能数量到一定程度，对客户满意度提升就没有多少影响了。
线性功能：“越多越好”的功能。它的改善与数量增加能直接提升用户满意度，它的降低和数量减少也直接降低用户满意度。
兴奋点和惊喜点：指提供了很高满意度，并常常为产品增加额外价格的那些功能。但是缺少它不会让客户满意度降到中性以下。
无关紧要属性：这些特性无论从哪方面来说对客户都没有影响。因为客户对其根本就不关心，我们应该努力消除、最小化或者延迟交付这些特性。
MoSCoW
莫斯科法则，就是must or should，could or would not，用于给需求进行优先级排序。
按照“Must：必须做的；Shoud：应该做的；Could：可以做的；Would not：不要做的”来做，保证PO所需要的Must、Should完成，并力争Could能完成；在响应变更时，优先考虑牺牲Could乃至Should需求特性。
