为什么选择 Scrum：定义过程与经验过程

有些项目相当直接且相对可预测，可以应用合理的规划和决策工具。其他更复杂或不可预测的项目需要更多依赖自组织和创新的不同方法。

由于三个因素的融合：人员、需求和技术，大多数软件开发项目在本质上被认为是复杂且不可预测的。在过程控制模型和项目复杂性的背景下，可以更容易地理解用于交付和管理项目的各种方法。

定义的过程——传统的计划驱动方法

传统上，一旦项目开始，就会创建一个需求包，然后“签字”。项目经理假定此签核会产生一组固定的需求，并且现在可以开始计划。项目经理估计完成需求所需的时间并制定项目计划。该计划预测项目将在某个日期之前完成，并将该日期传达给客户。

这种方法的根本缺陷在于，驱动一切的计划是基于这样一种假设，即需求是固定的并且不会改变。经验告诉我们，从来都不是这样。需求永远不会固定——它们总是在变化。当需求发生变化时，计划受到影响；因此，完成日期也需要更改。不幸的是，在许多情况下，这是不可能的，团队必须在他们承诺的日期之前交付。这是发生重大危机并且项目开始失控的时候。

经验过程——敏捷价值驱动方法

价值驱动的敏捷方法基于 改变整个思维方式的经验主义 。它从一开始就假设任何预先存在的需求都不是固定的，它们会改变。

敏捷思维还假设您必须在某个日期之前交付。这种方法固定了时间和资源，并使需求未确定。对我们来说，这种方法更接近于创建软件的现实。现在，价值驱动的整个概念非常有意义。当您有固定的时间不确定是否可以交付所有需求时（因为它们会改变，因此完成它们所需的时间也会改变），自然的反应是优先考虑需求并首先完成那些为客户增加最大价值的人。

您可能会想，“那些在交货日期之前没有完成的需求呢？” 这就是您使用价值驱动方法的原因。您承认并非所有要求都将在交货日期之前完成。要问的重要问题是您是否已交付足够的功能来支持为客户提供价值的系统。

软件项目的失败率

Standish Group 最近发布了 2015  CHAOS 报告。CHAOS 报告自 1994 年以来每年都发布，是软件开发行业状况的快照。今年，该报告研究了全球 50,000 个项目，从微小的改进到大规模的系统重新设计实施。今年的报告包括对成功的增强定义，着眼于以前调查中涵盖的一些其他因素。

结果表明，要从软件开发项目中取得成功，仍有许多工作要做。该表总结了过去五年使用成功因素的新定义（按时、按预算并取得令人满意的结果）的项目成果。

随着近年来敏捷开发方法的采用，可以比较敏捷和传统瀑布项目之间的项目成果。如下表所示，在所有项目规模中，敏捷方法都能带来更多成功的项目和更少的彻底失败

传统方法的问题是什么？

传统的基于计划的方法本身并没有缺陷。它只是不适合当今的软件行业。基于计划的方法最初是基于传统的项目管理概念，起源于建筑行业。在建筑行业，基于计划的方法是合适的：作为要求的蓝图是固定的，并且在建造建筑物时可能不会改变。您可以估计建造钢柱、浇筑混凝土等需要多长时间。

传统的基于计划的方法适用于建筑行业但不适用于软件行业的原因在于我们控制经验系统（如软件开发）和控制定义系统（如建筑或制造）的方式不同）。下表显示了定义过程的特征与经验过程的特征之间的差异。

看完表格不难看出，软件开发绝对是一个经验过程，而不是一个定义的过程。问题是多年来我们一直将软件开发视为一个已定义的过程——而这种方法行不通。

参考

1. Standish Group 2015 年混乱报告
2. 用一个不完美的词变得敏捷 — Greg Smith 和 Ahmed Sidky

其他 Scrum 读物

• 3 分钟 Scrum
• Scrum 的 5 个价值观是什么？
• Scrum 的演变是什么？
• 经典项目管理与敏捷项目管理
• 为什么 Scrum 难以掌握？
• Scrum 中的速度是什么？
• 什么是敏捷？什么是 Scrum？