作为致力于推广敏捷实践的个人和组织， 这也许是我和团队在面试的时候与候选人必然会提及的问题了。

“敏捷项目比传统项目快”是一个比较常见的回答，而且往往候选人的理解会跑偏，前文我们详细讨论了“敏捷项目管理是不是比传统项目管理快”，其实也是为今天的话题做个铺垫。

而其他的“加分”答案都围绕着迭代，对变化的响应，产品的价值交付等等......这些回答并没有太大的问题，我也完全认同，但个人总感觉有些浅尝辄止，意犹未尽。

一次非常偶然的机会，在自己团队内部，重新发起了对这个问题的讨论。有一些新的碰撞和理解，跟大家分享分享。

另，本文的初衷是为了通过一系列对比来更好的说明两种项目管理方式对于“如何做好项目管理”这个问题不同的思考路径。观点只是说明某个特点在这种模式下更加突出，并非在另一模式下完全无视或者缺失，请各位看官辩证的理解。^_^

是以为序。

我们先从从最容易感知的“外在不同”开始聊起。

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

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

如果我们用经典的“项目管理铁三角”的方式来描述，区别就更加的直观了。

传统项目管理

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

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

敏捷项目管理

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

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

基于上述可见的不同，第一个重要的区别就呼之欲出了：

区别一：预测型 Vs 经验型

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

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

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

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

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

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

注：大家表笑，这是笔者的亲身经历，当时第一感觉是：WoW~项目经理怎么做到的?

敏捷项目管理则认为，我们很难成功预测“较远的”未来。所以不去做过于时间跨度大和详细的规划，而把长期项目拆分成一个个短小迭代。相应的，增强的是在迭代衔接的过程中去根据实际情况做相应的调整的部分，根据团队实际的承载能力，永远做价值高的东西。

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

也不难理解。因为敏捷项目中团队和迭代周期是固定的，我们只要看看过往项目的结果、对比一下前序迭代的工作输出就能做出一个相对准确的估算：除非有工作方法的变革（工具或流程），团队的输出基本是稳定的。根据历史经验去排要做多少需求就可以了。

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

所以，笔者把敏捷项目管理称之为经验型的项目管理模式。

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

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

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

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

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

它的很多设计天生就是为了应对变更而生的：因为需求和外部因素天生具有较强的不确定性。你很容易发现很多机制是确保应对变化的：比如对需求做纵向的切分，细化需求粒度，项目团队更频繁的交流（坐在一起，站会），迭代中间优先级的调整，迭代及发布燃尽图及时更新等。

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

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

注：当然，敏捷项目管理也不是随时能变，做哪算哪，此处不做展开。

以上对比的结论恰巧也说明了，传统项目管理和敏捷项目管理适用的场景不同：

传统项目管理适用于需求比较明确且外部变化不大的项目；

敏捷项目管理则更多的应用于需求和外部因素都可能有随着项目实施有较大变化的项目。

区别二：短期目标 Vs 长期运营

在介绍项目定义临时性这个特点时候，传统项目管理特意提及了为了确保项目的成果，项目结束之后是需要运营的。

传统项目管理从设计上是把项目实施和运营的界限划的比较清楚的：在单一项目（Project）管理和项目集（Program）管理中都很少体现运营的部分，只是在项目组合(Portfolio)的层面有所体现。

所以，笔者认为，传统项目管理相对更加注重“短期目标“，即项目目标的达成。

敏捷项目管理则不同，为了快速获取反馈或者“试错”，它把项目实施和运营的大循环打散，把运营工作下沉，在项目以短小迭代为单位的实施过程中就融入了运营的属性。

敏捷项目其实是更早的以MVP的版本交付产品，尽早的获得项目成果的运营数据，再去决定下一步产品的发展/调整方向。我认为是比传统项目管理视界更加长远，为了“长期运营”服务。

最近10年，互联网公司壮大之后，产品经理这个新角色的声势日渐兴盛，甚至把项目经理PM的简称都抢过去了。我想其更具备“长期运营”的属性，而不同于项目经理只注重“项目交付”可能是重要的原因之一吧。

还有一个我们都经历过的例子可以说明这种“短期目标”和“长期运营”思维的不同导致行动的迥异。

我们应该都签过合同，无论是甲方还是乙方，如果对于合同条款双方都“寸土不争”，很难达成共识，背后的根本原因还是潜意识的认为这是一锤子的买卖的“短期行为”，怕对方占便宜，我方吃亏。如果是抱着“长期运营”的思考，觉得是可以长期跟对方合作的，那估计也不会那么那么在意此刻“锱铢必较”了，反正以后还有机会“要”回来。

所以，传统项目管理更注重“短期目标”，而敏捷项目管理更倾向于“长期运营”，这也是一个本质上的区别。

区别三：管人理事 Vs 借事修人

传统项目管理和敏捷项目管理都有一个关键词是管理。关于管理，有另外一个朴素的说法是：有“人”和“事”两个基本元素，管理无外乎是如何看待和“处理”这两个元素。

笔者认为，传统项目管理是“管人理事”。

如前文所述，项目经理的主要工作就是“达成项目目标”：工作的重心在于如何协调好项目成员以及与项目成员发生关联的资源，以最高效的方式交付项目。

所以，虽然项目经理在项目过程中会充分的了解项目成员，创造一个良好的团队氛围和有利的工作条件，最终落脚点还是在“事”上：通过“管人”达到“理事”的目的。

而敏捷项目管理，笔者认为是“借事修人”：交付固然重要，但更重要的是“借项目交付”打造一支高效的团队/组织。

何以见得？我们看设计：

团队固定

对于传统项目管理来说，也有项目收尾的总结，但就笔者的经验来看，类似的总结可能大都落不到实处。团队不固定可能是主要原因，因为下个项目，可能团队成员就不一样了。

也正是这个原因，项目经理不可能花太多精力放在“团队打造上”，因为这个团队是“临时的”，项目经理所做的人的工作，都是服务于“事”--项目目标的。

敏捷要求团队成员基本固定，这样我们总结出来在之前踩过的“坑”，就可以完全避免再“踩”一遍。另一方面，在做总结或者Retrospective的时候，也不需要面面俱到。因为团队还在，我们挑紧迫的改善点，逐一落实，迭代进行。

团队固定，从一个侧面也体现了敏捷项目管理注重“长期运营”的特点：大家都知道，敏捷模式是提倡轻文档的，如果有些共识团队可以口头达成，是不一一定要全都落到纸面的。但如果某些产品经理“出尔反尓，翻脸不认”恐怕也是不work的。因为这次虽然研发配合你调整，下次恐怕就要求你完全把需求的每一个字都写的清清楚楚了，从长远看，还是不划算的。

可见敏捷项目管理的设计处处体现出“敏捷思维”：在“长期运营”产品的同时，更是在“长期运营”团队。

全情投入，跨职能团队（Cross Fuction）

敏捷项目管理不仅强调团队固定，更是要求组成具备不同能力的跨职能团队，从项目的一开始就全情投入而不是跨项目。

并且，在项目进行过程中，鼓励、甚至要求不同角色的同学尝试去承担其他角色的任务。笔者亲历的一个敏捷团队，某几个迭代中Team禁止最熟悉某个功能领域的同学去领取相应的任务，目的是提升团队其他成员对于这个重要功能领域的熟悉程度。

从项目一开始就所有人全情投入，让不熟悉的同学去做任务，这些现象在传统项目管理里面基本不会出现（尤其是后者）：很简单，因为从“事”完成的角度，这不是最“高效”的方式。

但敏捷项目为什么这么干？因为它的落脚点是“人”，是要打造一支效率更高，更能灵活应变的团队。让不熟悉的成员去从事相关任务，就单个迭代来说，效率是降低的；但从长期看，团队效率是提升的，因为有更多的人对这个领域有所了解，不至于形成‘“点单”，可以应对未来更复杂的项目执行。

从两种项目绩效描述的方式上，也能发现两种项目模式对于“事”和“人”看法的不同的端倪：

传统项目管理衡量的是项目成熟度，往往更关注“如期交付”，按时交付率、资源使用率等就成了常见词汇；

敏捷项目管理衡量的是团队成熟度，则更侧重于“团队打造”，团队交付速率，协同情况等描述大概率出现.....

再重申一次，不是说敏捷项目管理不关注交付，只是更关注于团队。而且这两个因素本质上并不矛盾：一支每个迭代都“跳票”的团队肯定也不是一支优秀的团队。

所以我说敏捷项目管理是“借事修人”，事（交付）固然重要，但落脚点在人，终极目的在于打造高效能的团队/组织。

注：在敏捷项目管理中，我们从来不追求一个敏捷团队的按时交付率是100%。相反，如果一个团队的交付率长时间都是100%，我们反倒会去考虑是不是团队成员过于追求安全，估算的太保守了......那团队成员为什么会这么保守呢？.......嗯，仍是团队或组织协作的问题。

做个总结，从传统项目管理和敏捷项目管理不同的设计思路出发，我们可以看到二者的主要区别：

预测型 Vs 经验型；

短期目标 Vs 长期运营；

管人理事 Vs 借事修人

以上就是我认为“敏捷项目管理和传统项目管理的更深层次的区别”，希望带给大家一些不一样的思考。

也非常欢迎大家积极留言，发表自己的观点，我们可以进一步深入交流。

写在最后

最近几十年的技术变化，催生出一个更加互相依赖，速度也更快的世界。这产生了一种错综复杂的状态，虽然我们监测和衡量的手段更加丰富，但当今世界在许多方面却变得更加不可预测。

如文中分析，传统的项目管理的基础在与规划和可预测性，而这个根基的动摇，是传统项目管理需要面临的巨大挑战。

在新的环境中则需要新的方法，我想这也是敏捷方法越来越被人关注的根本原因吧。

文章最后，留个彩蛋。我们来科普下“瀑布模型”的来历。^_^

Winston Royce博士在其1970年的文章《Managing the Development of Large Software Systems》中第一次阐述了“瀑布”（waterfall）方法的概念，并讨论了迭代式软件开发所具有的价值。

实际上，Royce也承认瀑布模型“是危险的并可能导致失败”，因为它将测试放在开发周期的最后，而主要的设计缺陷可能需要事后进行大量的返工。

他的文章一共9页，其中7页是用来描述如何改进基本的瀑布模型，包括采用迭代式开发方法以及在开发过程中让用户充分参与等。在阅读他的文章时，不禁想知道我们为什么忽略了他最后的注解，而只实现了前面介绍的基本模型。

带有讽刺意义的是，正是因为工业界只是有限的采纳了Royce的思想，才形成了后来软件开发的瀑布方法，而这种方法并不是Royce本人的最初观点。