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

项目管理广泛应用于软件开发行业。完整的项目管理包括五个部分，即：项目启动、项目计划、项目执行、项目监控和项目结束。

随着软件行业的发展，传统的敏捷项目管理模式已经不能满足当前互联网行业快速迭代、快速发展的需求，产生了“敏捷项目管理”。

传统项目管理和敏捷项目管理有什么区别？

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

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

传统的项目管理是先确定产品需求，然后根据项目需求规划和评估所需的人工日和开发进度。在这种模式下，只确定需求，根据需求制定人力配置和开发时间调度。因此，需求的制定需要非常详细，导致前期需求消耗大量的时间和精力。这样做的好处是可以估算成本，可以查看项目的全貌，可以检查进度，可以有效避免或降低项目开发的风险。缺点：一旦需求发生变化，就会导致项目管理的整体过程出现问题，对需求的变化非常敏感，不适合当前的互联网行业。这种管理模式也非常费时低效。

敏捷项目管理的三个要素和传统项目管理正好相反。在敏捷项目管理中，只有成本(人力)和实践是固定的，而需求不是固定的，或者说需求是变化的，有权重差异。在这种情况下，项目团队优先开发有价值、有迫切需求的功能特性，这样在项目开发中最重要、最迫切的需求和功能特性就可以完成，其他不重要、悬而未决的需求和功能可以先延期，这样在需求变更后就可以轻松处理。这种管理模式在需求阶段节省了大量的时间和人力，效率更高，耗时更短。因此，与敏捷开发一样，敏捷项目管理受到互联网行业的喜爱和追捧。

如果从项目流程来看

项目管理过程可以概括为五个过程组：启动、计划、执行、监控和结束。敏捷项目管理的框架是：构思、推测、探索、适应和终止。

传统的项目管理要对项目所有过程的风险进行管理和控制，要求不同环节的文件输入和输出，以及每个环节的启动、计划、执行、监控和收尾。如果采用传统的项目管理模式，一旦有超出规划的变更，需要经过批准后才能实施变更。

敏捷项目管理更简单，提倡团队内部的面对面交流。以Scrum为代表，简单、持续集成、持续交付、价值至上、拥抱变化的原则。面对市场、不断变化的需求和不断发展的技术，变得非常友好。

从项目风险来看

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

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

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

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

从企业项目管理来看

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

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

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