停止对瀑布模型的污名化

[1000copy]

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

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

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

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

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

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

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

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

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

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

[chendy]

首先，不管啥模型，最后决定交付效率和质量的都是人
神仙团队别说瀑布模型，整个倒立拉屎模型都能提前交付质量还贼高

然后，瀑布模型的主要问题是太死板，想象一下你的上游系统，过去半年都没动静，某一天突然拉出来 100 个接口让你接，换谁都难受
相比之下敏捷主要是小步快跑，避免步子太大扯到蛋，也因为步子小，受变更的影响也没那么大，也一定程度增加了无意义的变更数量

[brom111]

现在公司都是赚钱第一位的。 真有公司认真的在想后续维护吗

[catamaran]

自己的产品随便敏捷，交付客户的产品，交付日期定的死死的，怎么敏捷？

[aheadlead]

http://worktile.com/blog/scrum-aglie/

[Hawthorne]

如果金字塔顶部强，就用瀑布模型；
如果金字塔底部强，就用敏捷模式。

[nctllnty]

说的好兄弟，没有银弹

[crysislinux]

现在基建太好了，瞎基吧乱写也能撑很久。。

[wdold]

我是感觉敏捷这一套就是资本家为了压榨打工人强推的一套概念罢了，什么拥抱变更，快速迭代，呵呵

[InkStone]

瀑布模型在现实中其实用得还不少

不过还有个影响体验的关键问题是……需求来源本身就不是单一的，产品的设计者往往对接多个产品，需求实现者也往往对接多个需求。

在单个需求上做到瀑布模型，很多时候并无助于整体研发体验的改善

[akiyamaakira]

@crysislinux 这就是根本原因，如果没有任何开源的东西可以用，每个公司都需要自己从头撸，那不可能以现在的节奏做产品。

[jack2020]

国内是田园敏捷；其实如果瀑布模型走歪了，也会搞成田园瀑布，正所谓“路线错了，工具/知识越多越 F D”

[aycclm]

所谓的"敏捷"=说改就改，没有产品规划
完全扭曲了 Scrum 的本质

[huzhizhao]

谁给钱，谁话事啊

[cybort]

关键是公司让你一个人做完所有事情，分工不存在的

[1000copy]

@cybort 你们公司没有测试和产品吗？

[sagaxu]

敏捷：“周五下班前提需求，周一上班前已经上线”

[levelworm]

@aycclm 对，这是所有 frustration 的来源。

[cowcomic]

其实楼主说的这个不是严格意义上的瀑布，可以叫螺旋模型或者迭代模型都可以，就是多个小瀑布连起来
严格的瀑布是没有迭代这一说的，一个瀑布结束，就彻底交付，维保期顶多改 BUG 。瀑布最大的问题就来源于这个一把梭哈上

[GeekGao]

引用 OP 原话： “瀑布模型的核心要点有两条：

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

----

敏捷开发也可以符合你说的这两点啊。 该不会认为敏捷开发过程 == 野猪围攻开发法吧。。。

[hcbb]

这是一个平衡