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

无论您是Scrum Master，项目经理，产品负责人还是团队成员，还是只想回答“如何在现实世界中运行敏捷 Scrum项目”这一问题的人，本文绝对可以为您提供答案。

传统项目管理

传统的项目管理（瀑布）方法是线性的，其中过程的所有阶段都按顺序发生。该方法取决于可预测的工具和可预测的经验。每个项目都遵循相同的生命周期，包括可行性，计划，设计，构建，测试，生产，支持等阶段，如下图所示。

瀑布与敏捷软件开发

整个项目是预先计划的，没有任何改变要求的范围，例如瀑布，PMI的PMBOK和PRINCE2都是刚性和高度控制的。他们概述了从开始到结束的项目规划的不同阶段，并假设您具有您需要的所有要求和信息。

这种方法假设时间和成本是变量和要求是固定的。这就是传统项目管理面临预算和时间表问题的原因。

敏捷项目管理

当传统系统侧重于前期规划时，成本，范围和时间等因素都很重要，敏捷管理突出了团队合作，客户协作和灵活性。

敏捷拒绝将这些传统的项目管理方法视为繁琐，限制性的，并且不适合新的速度时代。敏捷项目管理是迭代的，旨在不断地将用户反馈和持续发布与软件开发项目的每次迭代相结合，如上图所示。每个任务输出都是您向利益相关者销售的产品。团队和工作结构是围绕创建对客户或客户直接有用的东西而设计的。

传统还是敏捷 – 如何选择？

根据Standish Group的2011年CHAOS宣言，敏捷项目比瀑布项目成功三倍。下图显示了根据2002年至2012年执行的项目进行的研究报告的具体结果：

瀑布vs敏捷项目的成功率

传统与敏捷之间的差异

下表总结了Scrum与传统项目管理模型之间的许多差异。

项目变更的成本

传统上应避免对软件项目进行更改，因为游戏后期的成本较高，而敏捷软件开发了解变更是不可避免的，投资详细计划并不实际。这在敏捷宣言的四个值之一中清楚地表达出来：

“ 响应遵循计划的变化 ”

敏捷对这一概念提出了挑战，并认为变更成本可能相对平稳，如下图所示：

传统与敏捷的变革成本

项目管理中的敏捷与传统铁三角

项目管理的成功传统上与项目的约束参数在范围，时间，成本和质量方面的能力相关联，如下图所示。这是一个流行的比喻，指出项目经理被要求在这些限制之间达成合理的权衡。

敏捷与项目管理中的传统铁三角

传统铁三角的问题是什么？

例如，通过增加预算或缩小范围可以更快地完成项目。同样，增加范围可能需要预算和时间表的相应增加。在不调整时间表或范围的情况下削减预算将导致质量下降。然而，在实践中，约束之间的交易并不总是可行的。例如，在一个人员充足的项目上投入资金（和人员）会减慢速度。此外，在运行不良的项目中，通常不可能在不对质量产生负面影响的情况下改进预算，进度或范围。

在传统意义上，项目管理中的铁三角明显不足以作为项目成功的典范，因为它忽略了成功的关键维度，包括对利益相关者的影响，学习和用户满意度。

敏捷意识中的铁三角 – 一种范式转换

在传统方法中，三角形通常看起来像左边的那个，如下图所示。如您所见，产品要求有固定的范围。因此，为了确保产品能够完成我们所需的所有功能，我们需要对我们的资源（和预算）和计划（截止日期）有一点灵活性。如果我们绝对需要该产品具有前期需求规范中描述的功能列表，那么我们可能需要将发布日期延迟几个月或更长时间。

在敏捷意义上，有一个固定的时间表（在Scrum中我们通过时间限制的 Sprint和固定资源来实现这一点。因此，当事情根据计划不起作用时，需要减少范围。在敏捷中但是，我们确保即使我们必须在范围上妥协，我们仍然会在产品积压中提供最高优先级的项目，以最大化项目产生的价值。

敏捷意义上的铁三角