在理解敏捷项目管理之前，我们先看一下它与传统项目管理之间有什么联系和差异。
传统项目管理模式：一般指瀑布模式。它必须完成上一阶段工作并通过检验才能启动下一阶段工作，将整个项目过程划分为五大过程组。
要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。
敏捷项目管理模式，一般包含迭代和增量。它将整个项目过程拆分为若干个迭代，每个迭代完成一部分用户可感知的完整功能。一般情况下，每个迭代内的项目过程均遵循五大过程
敏捷项目管理到底是什么？
我从定义、本质、框架、常见实践4个方面总结。
一、敏捷项目管理定义
敏捷：是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
敏捷项目管理：指在项目活动中运用敏捷的理念，配合专门的知识、技能、工具和方法 ，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。
二、敏捷项目管理本质
通过敏捷项目管理定义，我想你已经猜到其本质是什么。是的，其本质是一种理念，并基于这种理念进行不断实践在不确定和混乱的环境种取得项目成功，同时将这些实践总结提炼为团队稳定的解决方案。
这种理念也被先驱者们总结为敏捷软件开发宣言和敏捷开发十二原则。
敏捷软件开发宣言：
我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷开发十二原则：
1.我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要度量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10.以简洁为本，它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12.团队定期地反思如何能提高成效，并依此调整自身的行为表现。
三、敏捷项目管理框架（方法）
虽然敏捷项目管理的本质是理念，看起来很玄乎。但是敏捷先驱们基于这种里面已经开发出了非常多的看得见摸得着的敏捷管理框架，日常项目管理工作中常见管理框架有以下几种：
SCRUM
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
Kanban（看板管理）
看板管理在工业企业的工序管理中，以卡片为凭证，定时定点交货的管理制度。
XP（极限编程）
极限编程注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
Lean Startup（精益创业）
精益创业的核心理念可以追溯到软件行业的敏捷开发管理。例如“最小可用品”与“原型建模”非常相似，都追求快速的版本迭代，以及时刻保持与客户的接触并获得反馈等等，精益创业可以理解为敏捷开发模式的一种延续。
Iterative Development（迭代式开发）
迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
FDD （Feature-Driven Development，特性驱动开发）
特性驱动开发是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
当然，也有很多不是很常见的敏捷框架，如Crystal Methods（水晶方法族）、ASD（Adaptive Software Development，自适应软件开发）、DSDM（动态系统开发方法）、轻量型RUP等，这里不展开描述。
四、敏捷项目管理常见实践
2020敏捷年度状态报告中统计，Scrum仍然是运用最广泛的敏捷方法（框架），Scrum和Scrum结合其它方法混合使用占比超过75%。所以当你不知如何选用敏捷项目管理框架时，可以考虑Scrum结合其他方法混合使用。毕竟有时候追随别人是最快的捷径。
既然Scrum这么受欢迎，在这里总结一下Scrum的要点（以下信息来自：Scrum中文网）：
1、SCRUM理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：
第一：透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
2、SCRUM框架
Scrum框架包括3个角色、3个工件、5个事件、5个价值：
3个角色
产品负责人（Product Owner）
敏捷教练（Scrum Master）
开发团队（the development team）
3个工件
产品Backlog（Product Backlog）
冲刺任务（Sprint Backlog）
产品增量（Increment）
什么是产品Backlog? 什么是Sprint Backlog?
产品Backlog 指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner 为Product Backlog 中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
产品Backlog 是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第1 个Sprint 有活可干。
随着Sprint 的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之深，他们可以据此建议更改或者添加产品Backlog 中的任务。在Sprint 计划会议上，产品负责人为产品Backlog 中的任务确定优先级，并向Scrum团队描述这些任务。Scrum 团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint 中要完成哪些功能，并把它们挪到Sprint Backlog 中去。
5个事件
Sprint（Sprint本身是一个事件，包括了如下4个事件）
Sprint计划会议（Sprint Planning Meeting）
每日站会（Daily Scrum Meeting）
Sprint评审会议（Sprint Review Meeting）
Sprint回顾会议（Sprint Retrospective Meeting）
5个价值
承诺 – 愿意对目标做出承诺
专注 – 把你的心思和能力都用到你承诺的工作上去
开放 – Scrum 把项目中的一切开放给每个人看
尊重 – 每个人都有他独特的背景和经验
勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重
