目前PMP九月份考试使用的是第六版的教材，但是考纲却更新到了第七版，而第七版与第六版最大的区别就是它的敏捷项目管理部分从5%增加到了50%，可见敏捷管理的重要性。那么敏捷管理到底是什么呢？下面中创PMP之家来为大家详细介绍一下~
敏捷项目管理有别于传统的基于PMBOK或PRINCE2的项目管理模式，敏捷项目强调商业价值(Value)的尽早交付(短迭代)，项目团队(Team)的自组织(Self Organization)，不断适应(Adaptive)客户动态的需求变化(拥抱变化)，持续的优化项目产品和交付流程。所以敏捷强调价值(Value)、团队(Team)和适应性(Adaption)
在最新改版的第七版PMBOK教材中，就会新增大量的敏捷项目管理的内容，所以这也是第七版考试的重要内容。
敏捷的思想来自上个世纪30年代著名管理学大师休哈特的计划-执行-学习-行动(PDSA)的质量管理方针，此方针为我们耳熟能详的戴明环(PDCA，P-计划、D-做、C-检查、A-行动)由来的依据，可见敏捷是一种非常典型的质量管理思想，它和PMP有着同宗同种的来源，因为PMP的基本思想也是凡事先计划再做再检查和修正，不断PDCA的过程，也是戴明环的落地实践。推动敏捷思想落地的组织是在2001年成立的敏捷联盟，它构建了敏捷宣言和敏捷原则等理论体系，敏捷宣言和敏捷原则共同打造了敏捷文化。
推动敏捷思想落地的组织是在2001年成立的敏捷联盟，它构建了敏捷宣言和敏捷原则等理论体系，敏捷宣言和敏捷原则共同打造了敏捷文化。我们比较熟知是敏捷宣言，一共四条，敏捷宣言的解读如下：
敏捷宣言第一条：
个体和互动高于流程和工具(面对面的沟通、协作(Collaboration))
无论是什么类型的项目都是通过人来完成的。流程和工具可以帮助人，但绝不能自行替代人去完成项目工作。这条价值观包含的信息其实很多也很复杂。曾经供职于大型成熟组织的人可能都有这样的体会，他们知道在做什么，但却不知道为什么要这么做在于兆鹏先生的书里甚至写过一个案例，某公司曾经在项目上要求员工去整理一堆项目相关的技术文档，而这些文档都是马上即将被销毁的，要求整理的原因仅仅是因为公司流程要求这么做。这些都充分体现敏捷强调沟通协作等特点。
敏捷宣言第二条：
可工作软件高于详尽的文档(价值的体验、提倡最小可交付价值的产品(MVP))
敏捷强调持续交付和尽早的用户体验，文档够用就好。所谓够用就好就是如果有没有文档，所交付的产品质量都一样，那就不需要撰写那份文档。杜绝瀑布式开发周期过长和拖到项目收尾阶段再交付产品所带来的不必要的风险。敏捷希望最好的需求、架构和设计应出自团队与客户的不断互动。团队成员应该是跨职能的，即每个人可以兼具需求分析、架构设计、开发和测试等能力。这样在文档不尽详细的情况下，可以通过自我的不断学习和技能突破来交付可工作的软件。
敏捷宣言第三条：
客户合作高于合同谈判(不是对立的，而是共赢。相关方参与，在一起，共创价值)
敏捷让你和你的客户站在桌子的同一侧，当然这并不意味着不会有合同，不需要合同。这更多意味着，敏捷团队更愿意和客户在同一方向一起使劲，而不是把力气花在背离客户的方向。这一点和传统项目管理中，变更必须有严格的流程控制的思路是不一致的。但是在PMP的考试中，关于变更的问题，同学们还是应该按着传统瀑布式的思路来回答更好。
敏捷宣言第四条：
响应变化高于遵循计划(价值、迭代、探针、冲刺和反馈，适应性计划)
敏捷原则承认利用变更可以为客户创造更多的竞争优势，即尽早实现客户的市场或商业价值。敏捷强调动态适应业务战略或市场需求的变化，允许在合理的成本控制下的项目或阶段中后期的变更。针对这一条来讲，敏捷比PMP或PRINCE2更加大胆，因为未来市场上的商业需求更加多变和更加强调每个用户个体需求的多样性，比如C2F(客户的个性化需求直接和工厂的制造对接)的模式将更加普遍。
敏捷需要有计划，但是不完全拘泥于计划，这一点是值得其他理论体系学习的。另外，我们还要强调一点，在迭代开发过程中如果想临时添加额外待开发的用户故事，一般选择把优先级比较低的等量用户故事从本次迭代中移除，做到工作量的同等置换。因为团队在某次迭代的速率是一定的，速率就是团队整体的开发效率，每次迭代能够开发多少工作量是由团队自主决定的，这也体现了自组织团队的特点。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。