停止对瀑布模型的污名化

提起瀑布模型，人们往往有这样的印象：它是刻板、僵化的“老古董”。但真的是这样吗？

这种刻板印象可能来源于教科书。然而，编写教科书的人未必真正了解瀑布模型。

作为最早成型的软件开发生命周期模型之一，瀑布模型的主要特点是通过时间维度来降低软件开发的复杂性。它将软件开发过程划分为需求分析、产品设计、编码实现、上线和维护等阶段，并要求每个阶段都产出成果供下一阶段使用。

当然，根据实际情况，这些阶段可以适当精简，但至少应包含两个阶段：分析和编码。

简而言之，不同类型的工作由不同的团队在不同的时间完成，从而减轻个人的心智负担。

瀑布模型的核心要点有两条：

1. 不要在一个步骤完成之前进入下一个步骤，否则会导致在不同类型工作间反复切换，增加心智负担，失去分工的价值。
2. 如果在下一步发现上一步的问题，应该遵循变更流程，而不是轻易打断已经进行的步骤。例如，如果开发阶段发现需求问题，应尽可能将其推迟到下一个迭代周期。原因同上。

许多团队对变更请求来者不拒，不懂谈判，不敢拒绝，结果导致交付延期和问题堆积。这样的团队甚至没有正确执行瀑布模型。

软件开发周期模型后来出现的迭代开发、增量开发和敏捷开发，都是以瀑布模型为基础的。每一个迭代或增量都是一个小瀑布，都需要完成需求分析、产品设计、编码、测试和发布流程，至少包含分析和开发两个步骤的小瀑布。新的生命周期模型并没有否定瀑布模型，而是在其基础上进行了发展。

既然新的模型没有否定瀑布模型，你为什么否定它？