这是一个创建于 171 天前的主题，其中的信息可能已经有所发展或是发生改变。
提起瀑布模型，人们往往有这样的印象：它是刻板、僵化的“老古董”。但真的是这样吗？
这种刻板印象可能来源于教科书。然而，编写教科书的人未必真正了解瀑布模型。
作为最早成型的软件开发生命周期模型之一，瀑布模型的主要特点是通过时间维度来降低软件开发的复杂性。它将软件开发过程划分为需求分析、产品设计、编码实现、上线和维护等阶段，并要求每个阶段都产出成果供下一阶段使用。
当然，根据实际情况，这些阶段可以适当精简，但至少应包含两个阶段：分析和编码。
简而言之，不同类型的工作由不同的团队在不同的时间完成，从而减轻个人的心智负担。
瀑布模型的核心要点有两条：
- 不要在一个步骤完成之前进入下一个步骤，否则会导致在不同类型工作间反复切换，增加心智负担，失去分工的价值。
- 如果在下一步发现上一步的问题，应该遵循变更流程，而不是轻易打断已经进行的步骤。例如，如果开发阶段发现需求问题，应尽可能将其推迟到下一个迭代周期。原因同上。
许多团队对变更请求来者不拒，不懂谈判，不敢拒绝，结果导致交付延期和问题堆积。这样的团队甚至没有正确执行瀑布模型。
软件开发周期模型后来出现的迭代开发、增量开发和敏捷开发，都是以瀑布模型为基础的。每一个迭代或增量都是一个小瀑布，都需要完成需求分析、产品设计、编码、测试和发布流程，至少包含分析和开发两个步骤的小瀑布。新的生命周期模型并没有否定瀑布模型，而是在其基础上进行了发展。
既然新的模型没有否定瀑布模型，你为什么否定它？
42 条回复 • 2024-07-11 05:51:00 +08:00
 |
1
onikage 171 天前 via iPhone
严重同意，现在很多敏捷不过是在向金主无底线妥协
|
 |
2
RightHand 170 天前 via Android  7
敏捷开发是向上管理，老板每天、每时都能看到进度。瀑布是向下放权，老板只能到某个节点知道一个进度，开发甚至能决定哪部分要优先开发。个人暴论：敏捷就是以放弃质量（能跑就行）来提升所谓的快跑、快速迭代，一大堆技术债。
|
 |
4
C0dEr 170 天前
敏捷的基础是有清晰的功能发展路线
|
 |
5
xiaokaiyyy 170 天前
@RightHand 不能同意更多！
|
 |
6
crocoBaby 170 天前 2
敏捷开发都是高手玩的,菜鸟玩会变屎山
|
 |
7
levelworm 170 天前 via Android
没办法，需求一直变，很难完全固定住。好的团队能够把大纲固定好，这就很不错了。
|
 |
8
snxq1995 170 天前
在不同的团队面前谈开发模型，是不可能达成一致的。
瀑布模型之所以被流行趋势不认可，主要是由于： 1. 集成太晚，提高交付难度。 2. 阶段切换之间，浪费太多生产力。 导致很直接的原因就是很难做到**按时交付**，而这个结果是致命的。 |
 |
9
SoviaPhilo 170 天前 1
所有人都知道这个东西不靠谱， 但是老板就是相信这个
顺便一提， 我现在所在的团队推敏捷， 实际落地的时候一个项目组同时负责两个 sprint 的开发。 再加上潜在的线上问题运维支持的时间，以及随时都会有的 BI 协助要求 就这敏捷总监还说大家估时要准确，不要注水。 不注水就死定了 |
|
10
snxq1995 170 天前
现在流行趋势是集成左移，测试左移，用基础设施来自动化重复的工作。所以对于小团队来说，没有基础设施，没有那么大的交付压力，瀑布模型还是很适合的。
|
 |
12
cstj0505 170 天前
敏捷模型也不是不行,不过要求技术 leader 有很强的掌控能力,如果被产品或者功能交付牵着鼻子走,哪只能是越来越烂
|
 |
13
xuanbg 170 天前
有瀑布很容易改成敏捷，但没瀑布的要玩敏捷大多都变成了糊弄事。
|
 |
14
TUNGH 170 天前
我太同意了,尤其是这句话
1.不要在一个步骤完成之前进入下一个步骤，否则会导致在不同类型工作间反复切换，增加心智负担，失去分工的价值。 我发现很多 bug 都是来回切换分支修改紧急需求导致的. |
 |
16
tinycold 170 天前 4
不得不承认一个事实是，搞不好敏捷的团队，要搞好瀑布估计也悬。
就国内（绝大部分）的开发团队而言，光是能顺畅协作已是大幸。土法炼钢一直是国内（超大部分）的主流，更何况工作久了就会发现很多时候软件开发过程中还受公司政治倾向影响。 |
 |
17
clifftts 170 天前
严重同意，但是本质上两种开发模式都是对需求把控的问题，瀑布相对还把控一下，敏捷就完全是粗放，但是我说的敏捷是指国内所谓落地的敏捷。很多国外的好想法好管理落地到国内基本就走形变样，完全是保留名字的挂羊头卖狗肉
|
 |
18
metalvest 170 天前 via Android
敏捷这套东西其实是当年一堆所谓的意见领袖和社区布道者推起来的，现在一般叫做卖课的
|
 |
20
ZZ74 170 天前
敏捷的一大卖点是快速响应需求变化，能够及早发现开发的东西和实际需求的偏离。
实际情况是绝大多数业务几乎不会变化，银行，信贷，保险，生产制造，仓储等等主业务几乎不会变化 如果使用瀑布，一开始做好需求和概要设计，有变化就修改，其实十分清晰，内耗更少。 |
 |
21
chendy 170 天前 1
首先，不管啥模型，最后决定交付效率和质量的都是人
神仙团队别说瀑布模型，整个倒立拉屎模型都能提前交付质量还贼高 然后，瀑布模型的主要问题是太死板，想象一下你的上游系统，过去半年都没动静，某一天突然拉出来 100 个接口让你接，换谁都难受 相比之下敏捷主要是小步快跑，避免步子太大扯到蛋，也因为步子小，受变更的影响也没那么大，也一定程度增加了无意义的变更数量 |
 |
22
brom111 170 天前
现在公司都是赚钱第一位的。
 真有公司认真的在想后续维护吗 |
 |
23
catamaran 170 天前
自己的产品随便敏捷，交付客户的产品，交付日期定的死死的，怎么敏捷？
|
 |
25
Hawthorne 170 天前 3
如果金字塔顶部强，就用瀑布模型；
如果金字塔底部强，就用敏捷模式。 |
 |
26
nctllnty 170 天前
说的好兄弟，没有银弹
|
 |
27
crysislinux 170 天前 via Android
现在基建太好了，瞎基吧乱写也能撑很久。。
|
 |
28
wdold 170 天前
我是感觉敏捷这一套就是资本家为了压榨打工人强推的一套概念罢了，什么拥抱变更，快速迭代，呵呵
|
 |
29
InkStone 170 天前
瀑布模型在现实中其实用得还不少
不过还有个影响体验的关键问题是……需求来源本身就不是单一的，产品的设计者往往对接多个产品，需求实现者也往往对接多个需求。 在单个需求上做到瀑布模型，很多时候并无助于整体研发体验的改善 |
 |
30
akiyamaakira 170 天前
@crysislinux 这就是根本原因，如果没有任何开源的东西可以用，每个公司都需要自己从头撸，那不可能以现在的节奏做产品。
|
 |
31
jack2020 170 天前
国内是田园敏捷；其实如果瀑布模型走歪了，也会搞成田园瀑布，正所谓“路线错了，工具/知识越多越 F D”
|
 |
32
aycclm 170 天前 1
所谓的"敏捷"=说改就改，没有产品规划
完全扭曲了 Scrum 的本质 |
 |
33
huzhizhao 170 天前
谁给钱，谁话事啊
|
 |
34
cybort 170 天前 via Android
关键是公司让你一个人做完所有事情，分工不存在的
|
 |
36
sagaxu 170 天前
敏捷：“周五下班前提需求，周一上班前已经上线”
|
 |
38
cowcomic 170 天前 1
其实楼主说的这个不是严格意义上的瀑布，可以叫螺旋模型或者迭代模型都可以，就是多个小瀑布连起来
严格的瀑布是没有迭代这一说的，一个瀑布结束，就彻底交付，维保期顶多改 BUG 。瀑布最大的问题就来源于这个一把梭哈上 |
 |
39
GeekGao 170 天前
引用 OP 原话： “瀑布模型的核心要点有两条：
不要在一个步骤完成之前进入下一个步骤，否则会导致在不同类型工作间反复切换，增加心智负担，失去分工的价值。 如果在下一步发现上一步的问题，应该遵循变更流程，而不是轻易打断已经进行的步骤。例如，如果开发阶段发现需求问题，应尽可能将其推迟到下一个迭代周期。原因同上。 ” ---- 敏捷开发也可以符合你说的这两点啊。 该不会认为敏捷开发过程 == 野猪围攻开发法吧。。。 |
 |
40
hcbb 170 天前
这是一个平衡
|
 |
41
zhangk23 170 天前
瀑布模型本就是早年间老美用来骗经费的法子罢了
|
 |
42
msg7086 170 天前
否定瀑布模型否定的是冗长的周期。一个瀑布就要花上几个月甚至数年时间了。Windows 8 到 8.1 ，8.1 到 10 ，都相当于是一个一个瀑布。比如我们要做 Windows 8.1 了，先花 3 个月时间提出所有的需求，然后花 1 年时间编码，再花 6 个月时间测试和修补，然后直接把 8.1 发出来。
后来搞成半年更新一个版本，其实已经是半个敏捷了，不能完全算是瀑布了。 |
Select Language