传统项目管理与敏捷项目管理：主要差异及铁三角解析

传统项目管理

传统的项目管理（瀑布模型）方法是线性的，所有流程阶段按顺序依次进行。这种方法依赖于可预测的工具和可预测的经验。每个项目都遵循相同的生命周期，包括可行性分析、规划、设计、构建、测试、生产和支持阶段，如下图所示。

瀑布模型与敏捷软件开发

整个项目都是预先规划好的，不允许对需求进行任何更改——就像瀑布模型、PMI的PMBOK以及PRINCE2一样，它们僵化且高度受控。它们从头到尾划分出明确的阶段，并假设你已经拥有所有所需的需求和信息。

这种方法假设时间和成本是可变因素，而需求是固定的——这也是为什么传统项目管理常常在预算和进度方面遇到困难的原因。

敏捷项目管理

虽然传统系统高度重视前期规划，但成本、范围和时间等因素至关重要。而敏捷则强调团队合作、客户协作和灵活性。

敏捷否定了传统项目管理，认为其枯燥、限制性强，不适合快节奏的现代世界。敏捷项目管理是迭代式的，旨在每次开发迭代中持续整合用户反馈并持续发布。每个任务的产出都是你向利益相关者销售的产品。团队和工作流程都围绕着为客户创造直接有用的东西而构建。

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

根据Standish集团2011年的CHAOS报告，敏捷项目的成功率是瀑布模型项目的三倍。下图展示了2002年至2012年间研究得出的具体结果：

瀑布模型项目与敏捷项目成功率对比

传统与敏捷之间的差异

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

变更成本

传统上，软件项目中的变更会被避免，因为项目后期变更成本会显著增加。敏捷软件开发认识到变更不可避免，且过度投入前期规划是不切实际的。这一点在敏捷宣言的四个价值观之一中得到了明确表达：

“响应变化的需求，而非遵循固定的计划。”

敏捷对此观点提出挑战，并认为变更成本可能相对平稳，如下图所示：

传统与敏捷中的变更成本

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

传统上，项目管理的成功与在范围、时间、成本和质量方面的约束管理能力相关，如下图所示。这是一个流行的隐喻，表明项目经理需要合理平衡这些约束。

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

传统铁三角的问题在哪里？

例如，通过增加预算或减少范围，项目可以更快完成。同样，扩大范围通常需要相应增加预算和时间。如果不调整时间表或范围而削减预算，会导致质量下降。然而，在实践中，约束条件之间的权衡并不总是可行的。例如，在资源充足的项目中投入更多资金（和人力）实际上可能会减慢进度。此外，在表现不佳的项目中，如果不影响质量而改善预算、进度或范围，往往是不可能的。

因此，传统铁三角显然不足以作为项目成功的模型，因为它忽略了成功的关键维度，包括利益相关者的影响、学习成果以及用户满意度。

敏捷铁三角——范式转变

在传统方法中，三角形通常如下面左侧所示。如你所见，产品需求具有固定的范围。因此，为了确保产品交付所有所需功能，我们需要在资源（和预算）以及时间表（截止日期）上保持灵活性。如果我们必须确保产品包含初始需求规格中描述的所有功能，可能需要将发布日期推迟数月甚至更久。

在敏捷理念中，时间表是固定的（在Scrum中，这是通过时间盒 冲刺以及固定资源来实现）。因此，当事情不如预期时，必须缩减范围。但在敏捷方法中，我们确保即使必须在范围上妥协，仍然能够从产品待办事项列表中交付最高优先级的项目，以最大化项目产生的价值。

敏捷环境下的铁三角