“敏捷项目比传统项目快”是一个比较常见的回答，我们先从最容易感知的“外在不同”开始聊起。

传统项目管理：以瀑布模型为基础，明确每一个阶段的工作及完成标识，达成阶段目标后流转到下一个阶段，如瀑布流水一般完成整个项目交付。

敏捷项目管理：则是将项目分成一个个固定周期的短小迭代，以增量的方式分批次交付项目。

•传统项目管理

不变：往往先明确范围，再根据范围明确成本，时间等计划，再根据计划的实际执行情况相应的调整资源投入或者时间计划，但基本范围是不会有大的调整的。

可变：其项目团队（简单的理解，软件项目投入的资源主要是团队的人力和设备）是随着项目进行可变的，项目结束，项目团队解散。新的项目启动，再重新组建项目团队。

•敏捷项目管理

不变：敏捷项目中，团队是相对固定和长期存在的，不会随着项目的完结而解散，所以成本是固定的（同上）；同样，迭代遵循时间盒的原则，到时间就结束，所以周期也是固定的（一般2~4周，团队达成共识即可），一个迭代完成之后一定会有增量产品交付使用。

可变：可以调整的是每个迭代交付的需求/特性，可以根据外部情况的变化在迭代之间调整需求/特性的优先级，甚至放弃某些需求/特性。

区别一：预测型 Vs 经验型

因为项目是独特的，都有一定的不确定性。所谓项目管理铁三角的逻辑，是用确定性来应对不确定性：即不可能三个角都是可变的，总要固定至少一个要素。（如上图）

传统项目管理固定的是范围，认为交付物是确定的，用调整资源投入和时间进度这两个因素来应对项目执行过程中的不确定性。

敏捷项目管理给出的答案则是固定资源和时间进度这两个因素，可变的是调整交付范围。

传统项目管理是基于预测型的项目管理模式，是以计划驱动的；敏捷项目管理是基于经验型的项目管理模式，以价值驱动。

这是两种完全不同的设计逻辑：

传统项目管理认为在项目初期必需弄清足够多的细节，并基于此给出可行的详细计划，其实是一种预测未来的行为。所以，传统项目管理是一种预测型的项目管理方式。

往往越复杂的项目需要项目经理给出的计划越详尽：比如说在半年后某一个上午，某个项目成员在做一项具体的任务会出现在项目计划的甘特图中 。

敏捷项目管理则认为，我们很难成功预测“较远的”未来。所以不去做过于时间跨度大和详细的规划，而把长期项目拆分成一个个短小迭代。

相应的，增强的是在迭代衔接的过程中去根据实际情况做相应的调整的部分，根据团队实际的承载能力，永远做价值高的东西。

那为什么说敏捷项目管理是经验型的项目管理呢？

也不难理解。因为敏捷项目中团队和迭代周期是固定的，我们只要看看过往项目的结果、对比一下前序迭代的工作输出就能做出一个相对准确的估算。

除非有工作方法的变革（工具/流程），团队的输出基本是稳定的。根据历史经验去排要做多少需求就可以了。

而对于需求优先级的调整也是根据增量产品的输出获取一定反馈再做出的，对于价值判断我们每一个迭代都会重新评估，也是有一定积累的参考经验的。同时，因为迭代周期相对较短，对于短时间的未来我们的预测会准得多。

敏捷项目管理可以称之为经验型的项目管理模式。

弄清了这两种项目的底层设计逻辑，对于两种项目管理模式对于变化/变更所体现的不同态度就不难理解了。

传统项目也不是说不允许变更，但从PMI标准变更管理流程上就能感受到，设置了相当多的确认/审核环节（没记错的话，拢共分8步），相当重。

我把传统项目管理对于变更管理的方式称之为为“控变”。从根儿上来说，传统项目管理是拒绝变更的：因为绝大多数情况我们都已经预测到了，所以最好没有变化，一切按照计划来。

一旦出现与项目开始时的预测与计划偏差较大的时候，传统项目管理的实际处理就会显得非常拧巴：要么严格遵守变更流程，项目效率降低；要么变更流程流于形式，形同虚设。

而敏捷项目管理恰恰相反，认为变更一定会发生。

它的很多设计天生就是为了应对变更而生的：因为需求和外部因素天生具有较强的不确定性。

你很容易发现很多机制是确保应对变化的：比如对需求做纵向的切分，细化需求粒度，项目团队更频繁的交流（坐在一起，站会），迭代中间优先级的调整，迭代及发布燃尽图及时更新等。

相应的，敏捷项目管理对于变更管理的方式称之为“应变”。

所以，你不可能让传统项目管理做到真正的“拥抱变化”，因为基因是完全不同的。

以上对比的结论恰巧也说明了，传统项目管理和敏捷项目管理适用的场景不同：传统项目管理适用于需求比较明确且外部变化不大的项目；敏捷项目管理则更多的应用于需求和外部因素都可能有随着项目实施有较大变化的项目。