很多人都知道，项目管理领域有两种管理方式：传统项目管理和敏捷项目管理。很多人在团队引入敏捷的时候，会有一个疑惑，传统瀑布式项目管理和敏捷项目管理的区别是什么？

传统VS敏捷

传统项目管理通常采用的是瀑布式、部分迭代开发模式，瀑布式开发，是指将项目划分为N个阶段，每个阶段的工作都建立在前一阶段的基础上，从项目计划上看，就像是逐级向下的瀑布，由此得名。轮船、汽车制造业，建筑行业一般沿用此法。要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大、成本越高，影响到项目的交付质量。

敏捷项目管理强调商业价值的尽早交付，项目团队的自组织，不断响应客户动态的需求变化，持续的优化项目产品和交付流程。它作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。

两者之间的联系

敏捷项目管理声称要摆脱繁冗的流程制度文档，但是对于关键的项目文档，比如需求规格说明书等等，是要求必须具备的。所以，敏捷项目管理的项目流程制度管理可以看作是对一套完善的项目管理流程制度的裁剪，只是裁剪的好坏在于敏捷项目团队成员的适应性与自主性。

具体的敏捷方法在每个迭代周期中都存在立会制度，燃尽图、看板监控、计划发布等，这些和PMBOK中对项目生命周期的五个过程组启动、规划、执行、监控和收尾的定义没有冲突矛盾。实际上敏捷项目管理的这些措施可以看作是PMBOK项目生命期五个过程组执行的微缩版，区别在于敏捷项目管理的迭代周期，时间很短，在去执行过程中裁剪了很多规范正式的项目管理流程制度。

两者之间的区别

项目管理流程可以总结分为五个过程组：启动、规划、执行、监控、收尾。敏捷项目管理框架是：构想、推测、探索、适应、结束。

传统项目管理要对项目的所有过程进行管理和风险把控，并要求在不同环节的有文档输入和输出，每个环节都存在启动、规划、执行、监控和收尾。如果采用传统的项目管理模式，一旦出现规划以外的变更，都需要经过批准后才能执行改变。

敏捷项目管理则较简化，主张团队内部的面对面沟通和交流。以 Scrum 为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则。在面对市场、需求时刻变化与不断发展的技术时变得十分友好。

任何项目中的项目风险都存在不确定性，一旦发生，会对项目造成积极或消极的影响，如影响范围、进度、成本和质量。

传统项目管理要求在规划过程中规划风险管理、识别风险，对风险进行定性/定量分析，给出风险应对方案。因为风险的不确定性，要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。

传统项目管理要求持续跟踪风险登记表，并且记录风险应对措施在处理已识别风险及其根源方面的有效性，完成风险再评估和风险审计，直到风险被降到最低。

敏捷项目管理不同于传统项目管理，一方面开发评估是以工作量为导向而非时间导向，为风险留足了应对空间，且每个sprint冲刺周期较短，即使出现部分风险，相对来说对于已交付成果来说，变更相对较少；另一方面，敏捷项目管理在项目没有正式结束前，交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复。

某些行业目前还没有发展出固定的行业标杆，大家都在竞争中追求最大范围的满足行业需求。在这样的背景前提下，大部分项目都没有明确和长久稳定的需求，Scrum 管理模式很好的满足了这个行业的项目管理现状。

但是，作为行业客户，在大部分的商务场景下客户都会希望通过固定成本合同来实现自己的利益最大化，问题是现在合同双方都很难在项目开始时明确约定需求和最终实现方式。所以，在客户不能接受 Scrum 时，通常会选择外瀑布内敏捷的项目管理模式（有人称为“信封法”），满足双方的利益。

敏捷项目管理只是一个灵活的实践框架，提供的是一套清晰的游戏规则，根据不同的环境可以提供一系列不同的途径。传统项目管理却是一套中央集权制管理法，要求按计划行事，任何环节发生变更都必须获准后才能进行改变。不管是传统的瀑布式开发管理还是敏捷迭代式管理，没有哪个好与不好，只有在不同的项目环境中哪个更适合，需要量体裁衣。例如建筑行业适合传统的瀑布式管理方式，而互联网软件开发需在传统的管理方式中结合敏捷方法。所以，最终的趋势是互相兼容，优势互补。

查看更多项目管理知识，请点击访问项目知识库