传统项目管理 VS 敏捷项目管理

项目管理广泛应用于软件开发行业
，完整的项目管理包含五个部分，分别是
：项目启动、项目规划
、项目执行、项目监控、项目收尾
。

随着软件行业的发展，传统的敏捷项目管理模式，已经不适应于当前互联网行业快速迭代快速开发的需求，从而衍生出了 “敏捷项目管理”
。

传统项目管理和敏捷项目管理有什么不同呢
？

传统项目管理是计划驱动
，而敏捷项目管理是价值驱动

从项目管理的三要素
：时间、范围
、成本来看

传统的项目管理是先确定产品的需求

，在根据项目需求规划和评估所需要的人天
、开发排期等
。此种模式下，只有需求是确定的，而所需要到人力分配、开发时间排期等是根据需求来制定的，所以，需求的制定需要非常的详细
，导致的结果就是前期需求会耗费大量的时间和精力
。这样的好处是：根据制定好的项目需求、人力分配和开发排期可以估算成本，总览项目的全貌，查看进度，有效规避或者减少项目开发风险
。 缺点是：一旦需求变动，会导致项目管理整体流程出现问题，对于需求的变动非常敏感
，不适合当前的互联网行业。此种管理模式

，也非常的耗时，效率较低下
。

敏捷项目管理和传统项目管理的三要素正好相反，敏捷项目管理中
，只有成本（人力）和实践是固定的，而需求是不固定的，或者说，需求是变化的
，有权重区别
。在这种情况下
，项目组优先开发有价值的、需求紧迫的功能特性
，这样，项目开发中
，就可以把最重要
、最紧迫的需求和功能特性完成
，其他不重要
、待定的需求和功能，就先往后排期
，这样遇到需求变更后
，也可以轻松应对。此种管理模式


，由于在需求阶段节省了大量的时间和人力，效率较高，耗时也较短
。所以，敏捷项目管理和敏捷开发一样，受到互联网行业的喜爱和追捧。

如果从项目流程来看

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

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

敏捷项目管理则较简化，主张团队内部的面对面沟通和交流。以 Scrum 为代表
，简单

、持续集成、不断交付

、价值优先、拥抱变化的原则
。在面对市场、需求时刻变化与不断发展的技术时变得十分友好。

从项目风险来看

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

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

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

敏捷项目管理不同于传统项目管理，一方面开发评估是以工作量为导向而非时间导向
，为风险留足了应对空间

，且每个sprint冲刺周期较短，即使出现部分风险
，相对来说对于已交付成果来说，变更相对较少
；另一方面，敏捷项目管理在项目没有正式结束前，交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复。

从企业项目管理来看

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

但是，作为行业客户
，在大部分的商务场景下客户都会希望通过固定成本合同来实现自己的利益最大化，问题是现在合同双方都很难在项目开始时明确约定需求和最终实现方式
。所以
，在客户不能接受 Scrum 时

，通常会选择外瀑布内敏捷的项目管理模式（有人称为“信封法”），满足双方的利益。

敏捷项目管理只是一个灵活的实践框架
，提供的是一套清晰的游戏规则，根据不同的环境可以提供一系列不同的途径


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

无所谓哪个是更优势的管理方法
，只能看哪个是更适合的管理方法
！

关注公众号:PMP 项目管理之家、才聚项目管理PMP暨NPDP考试中心