停止对瀑布模型的污名化

[1000copy]

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

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

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

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

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

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

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

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

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

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

[onikage]

严重同意，现在很多敏捷不过是在向金主无底线妥协

[RightHand]

敏捷开发是向上管理，老板每天、每时都能看到进度。瀑布是向下放权，老板只能到某个节点知道一个进度，开发甚至能决定哪部分要优先开发。个人暴论：敏捷就是以放弃质量（能跑就行）来提升所谓的快跑、快速迭代，一大堆技术债。

[Rehtt]

@RightHand 非常同意，敏捷+人员流动=大量屎山

[C0dEr]

敏捷的基础是有清晰的功能发展路线

[xiaokaiyyy]

@RightHand 不能同意更多！

[crocoBaby]

敏捷开发都是高手玩的,菜鸟玩会变屎山

[levelworm]

没办法，需求一直变，很难完全固定住。好的团队能够把大纲固定好，这就很不错了。

[snxq1995]

在不同的团队面前谈开发模型，是不可能达成一致的。

瀑布模型之所以被流行趋势不认可，主要是由于：
1. 集成太晚，提高交付难度。
2. 阶段切换之间，浪费太多生产力。

导致很直接的原因就是很难做到**按时交付**，而这个结果是致命的。

[SoviaPhilo]

所有人都知道这个东西不靠谱， 但是老板就是相信这个


顺便一提， 我现在所在的团队推敏捷， 实际落地的时候一个项目组同时负责两个 sprint 的开发。
再加上潜在的线上问题运维支持的时间，以及随时都会有的 BI 协助要求
就这敏捷总监还说大家估时要准确，不要注水。


不注水就死定了

[snxq1995]

现在流行趋势是集成左移，测试左移，用基础设施来自动化重复的工作。所以对于小团队来说，没有基础设施，没有那么大的交付压力，瀑布模型还是很适合的。

[cstj0505]

@crocoBaby 没时间,高手也只会写石山

[cstj0505]

敏捷模型也不是不行,不过要求技术 leader 有很强的掌控能力,如果被产品或者功能交付牵着鼻子走,哪只能是越来越烂

[xuanbg]

有瀑布很容易改成敏捷，但没瀑布的要玩敏捷大多都变成了糊弄事。

[TUNGH]

我太同意了,尤其是这句话
1.不要在一个步骤完成之前进入下一个步骤，否则会导致在不同类型工作间反复切换，增加心智负担，失去分工的价值。
我发现很多 bug 都是来回切换分支修改紧急需求导致的.

[vueli]

@Rehtt #3 完全正确，完全正确，完全正确！！！我就在改屎山

[tinycold]

不得不承认一个事实是，搞不好敏捷的团队，要搞好瀑布估计也悬。

就国内（绝大部分）的开发团队而言，光是能顺畅协作已是大幸。土法炼钢一直是国内（超大部分）的主流，更何况工作久了就会发现很多时候软件开发过程中还受公司政治倾向影响。

[clifftts]

严重同意，但是本质上两种开发模式都是对需求把控的问题，瀑布相对还把控一下，敏捷就完全是粗放，但是我说的敏捷是指国内所谓落地的敏捷。很多国外的好想法好管理落地到国内基本就走形变样，完全是保留名字的挂羊头卖狗肉

[metalvest]

敏捷这套东西其实是当年一堆所谓的意见领袖和社区布道者推起来的，现在一般叫做卖课的

[root71370]

@tinycold "受公司政治倾向影响" 这个太对了

[ZZ74]

敏捷的一大卖点是快速响应需求变化，能够及早发现开发的东西和实际需求的偏离。
实际情况是绝大多数业务几乎不会变化，银行，信贷，保险，生产制造，仓储等等主业务几乎不会变化
如果使用瀑布，一开始做好需求和概要设计，有变化就修改，其实十分清晰，内耗更少。