V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
1000copy
V2EX  ›  程序员

停止对瀑布模型的污名化

  •  5
     
  •   1000copy · 13 天前 · 4434 次点击

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

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

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

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

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

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

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

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

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

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

    42 条回复    2024-07-11 05:51:00 +08:00
    onikage
        1
    onikage  
       13 天前 via iPhone
    严重同意,现在很多敏捷不过是在向金主无底线妥协
    RightHand
        2
    RightHand  
       13 天前 via Android   ❤️ 7
    敏捷开发是向上管理,老板每天、每时都能看到进度。瀑布是向下放权,老板只能到某个节点知道一个进度,开发甚至能决定哪部分要优先开发。个人暴论:敏捷就是以放弃质量(能跑就行)来提升所谓的快跑、快速迭代,一大堆技术债。
    Rehtt
        3
    Rehtt  
       13 天前 via Android   ❤️ 4
    @RightHand 非常同意,敏捷+人员流动=大量屎山
    C0dEr
        4
    C0dEr  
       13 天前
    敏捷的基础是有清晰的功能发展路线
    xiaokaiyyy
        5
    xiaokaiyyy  
       13 天前
    @RightHand 不能同意更多!
    crocoBaby
        6
    crocoBaby  
       13 天前   ❤️ 2
    敏捷开发都是高手玩的,菜鸟玩会变屎山
    levelworm
        7
    levelworm  
       13 天前 via Android
    没办法,需求一直变,很难完全固定住。好的团队能够把大纲固定好,这就很不错了。
    snxq1995
        8
    snxq1995  
       13 天前
    在不同的团队面前谈开发模型,是不可能达成一致的。

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

    导致很直接的原因就是很难做到**按时交付**,而这个结果是致命的。
    SoviaPhilo
        9
    SoviaPhilo  
       13 天前   ❤️ 1
    所有人都知道这个东西不靠谱, 但是老板就是相信这个


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


    不注水就死定了
    snxq1995
        10
    snxq1995  
       13 天前
    现在流行趋势是集成左移,测试左移,用基础设施来自动化重复的工作。所以对于小团队来说,没有基础设施,没有那么大的交付压力,瀑布模型还是很适合的。
    cstj0505
        11
    cstj0505  
       13 天前
    @crocoBaby 没时间,高手也只会写石山
    cstj0505
        12
    cstj0505  
       13 天前
    敏捷模型也不是不行,不过要求技术 leader 有很强的掌控能力,如果被产品或者功能交付牵着鼻子走,哪只能是越来越烂
    xuanbg
        13
    xuanbg  
       13 天前
    有瀑布很容易改成敏捷,但没瀑布的要玩敏捷大多都变成了糊弄事。
    TUNGH
        14
    TUNGH  
       13 天前
    我太同意了,尤其是这句话
    1.不要在一个步骤完成之前进入下一个步骤,否则会导致在不同类型工作间反复切换,增加心智负担,失去分工的价值。
    我发现很多 bug 都是来回切换分支修改紧急需求导致的.
    vueli
        15
    vueli  
       13 天前
    @Rehtt #3 完全正确,完全正确,完全正确!!!我就在改屎山
    tinycold
        16
    tinycold  
       13 天前   ❤️ 4
    不得不承认一个事实是,搞不好敏捷的团队,要搞好瀑布估计也悬。

    就国内(绝大部分)的开发团队而言,光是能顺畅协作已是大幸。土法炼钢一直是国内(超大部分)的主流,更何况工作久了就会发现很多时候软件开发过程中还受公司政治倾向影响。
    clifftts
        17
    clifftts  
       13 天前
    严重同意,但是本质上两种开发模式都是对需求把控的问题,瀑布相对还把控一下,敏捷就完全是粗放,但是我说的敏捷是指国内所谓落地的敏捷。很多国外的好想法好管理落地到国内基本就走形变样,完全是保留名字的挂羊头卖狗肉
    metalvest
        18
    metalvest  
       13 天前 via Android
    敏捷这套东西其实是当年一堆所谓的意见领袖和社区布道者推起来的,现在一般叫做卖课的
    root71370
        19
    root71370  
       13 天前
    @tinycold "受公司政治倾向影响" 这个太对了
    ZZ74
        20
    ZZ74  
       13 天前
    敏捷的一大卖点是快速响应需求变化,能够及早发现开发的东西和实际需求的偏离。
    实际情况是绝大多数业务几乎不会变化,银行,信贷,保险,生产制造,仓储等等主业务几乎不会变化
    如果使用瀑布,一开始做好需求和概要设计,有变化就修改,其实十分清晰,内耗更少。
    chendy
        21
    chendy  
       13 天前   ❤️ 1
    首先,不管啥模型,最后决定交付效率和质量的都是人
    神仙团队别说瀑布模型,整个倒立拉屎模型都能提前交付质量还贼高

    然后,瀑布模型的主要问题是太死板,想象一下你的上游系统,过去半年都没动静,某一天突然拉出来 100 个接口让你接,换谁都难受
    相比之下敏捷主要是小步快跑,避免步子太大扯到蛋,也因为步子小,受变更的影响也没那么大,也一定程度增加了无意义的变更数量
    brom111
        22
    brom111  
       13 天前
    现在公司都是赚钱第一位的。 真有公司认真的在想后续维护吗
    catamaran
        23
    catamaran  
       13 天前
    自己的产品随便敏捷,交付客户的产品,交付日期定的死死的,怎么敏捷?
    Hawthorne
        25
    Hawthorne  
       13 天前   ❤️ 3
    如果金字塔顶部强,就用瀑布模型;
    如果金字塔底部强,就用敏捷模式。
    nctllnty
        26
    nctllnty  
       13 天前
    说的好兄弟,没有银弹
    crysislinux
        27
    crysislinux  
       13 天前 via Android
    现在基建太好了,瞎基吧乱写也能撑很久。。
    wdold
        28
    wdold  
       13 天前
    我是感觉敏捷这一套就是资本家为了压榨打工人强推的一套概念罢了,什么拥抱变更,快速迭代,呵呵
    InkStone
        29
    InkStone  
       13 天前
    瀑布模型在现实中其实用得还不少

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

    在单个需求上做到瀑布模型,很多时候并无助于整体研发体验的改善
    akiyamaakira
        30
    akiyamaakira  
       13 天前
    @crysislinux 这就是根本原因,如果没有任何开源的东西可以用,每个公司都需要自己从头撸,那不可能以现在的节奏做产品。
    jack2020
        31
    jack2020  
       13 天前
    国内是田园敏捷;其实如果瀑布模型走歪了,也会搞成田园瀑布,正所谓“路线错了,工具/知识越多越 F D”
    aycclm
        32
    aycclm  
       13 天前   ❤️ 1
    所谓的"敏捷"=说改就改,没有产品规划
    完全扭曲了 Scrum 的本质
    huzhizhao
        33
    huzhizhao  
       12 天前
    谁给钱,谁话事啊
    cybort
        34
    cybort  
       12 天前 via Android
    关键是公司让你一个人做完所有事情,分工不存在的
    1000copy
        35
    1000copy  
    OP
       12 天前 via iPhone
    @cybort 你们公司没有测试和产品吗?
    sagaxu
        36
    sagaxu  
       12 天前
    敏捷:“周五下班前提需求,周一上班前已经上线”
    levelworm
        37
    levelworm  
       12 天前 via Android
    @aycclm 对,这是所有 frustration 的来源。
    cowcomic
        38
    cowcomic  
       12 天前   ❤️ 1
    其实楼主说的这个不是严格意义上的瀑布,可以叫螺旋模型或者迭代模型都可以,就是多个小瀑布连起来
    严格的瀑布是没有迭代这一说的,一个瀑布结束,就彻底交付,维保期顶多改 BUG 。瀑布最大的问题就来源于这个一把梭哈上
    GeekGao
        39
    GeekGao  
       12 天前
    引用 OP 原话: “瀑布模型的核心要点有两条:

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

    ----

    敏捷开发也可以符合你说的这两点啊。 该不会认为敏捷开发过程 == 野猪围攻开发法吧。。。
    hcbb
        40
    hcbb  
       12 天前
    这是一个平衡
    zhangk23
        41
    zhangk23  
       12 天前
    瀑布模型本就是早年间老美用来骗经费的法子罢了
    msg7086
        42
    msg7086  
       12 天前
    否定瀑布模型否定的是冗长的周期。一个瀑布就要花上几个月甚至数年时间了。Windows 8 到 8.1 ,8.1 到 10 ,都相当于是一个一个瀑布。比如我们要做 Windows 8.1 了,先花 3 个月时间提出所有的需求,然后花 1 年时间编码,再花 6 个月时间测试和修补,然后直接把 8.1 发出来。
    后来搞成半年更新一个版本,其实已经是半个敏捷了,不能完全算是瀑布了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5370 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 57ms · UTC 06:08 · PVG 14:08 · LAX 23:08 · JFK 02:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.