敏捷、瀑布开发模式

=================敏捷开发==============

几位食客来餐馆吃饭(来项目啦~)

不确定吃些什么菜,找服务生要菜谱(客户往往提不出具体需求)

服务生拿出菜谱,有图有文,食客点了十盘菜(根据原型及文档基本确定了需求)

厨子们开始准备(项目启动)

小工切菜,厨子炒菜,先炒了两盘,端出去先给食客品尝(先拿实例给客户用用)

食客说还不错,厨子继续炒,继续端出去(开发期间不断给客户试用,敏捷讲究这个,人们叫它迭代)

食客发现这次两盘味道淡了,厨子给加了盐(迭代的好处,需求变更后马上改)

又上两盘,不够辣,厨子给加了辣椒(迭代的坏处,反复多了,增加工作量)

到最后两盘时,应食客要求,给换了这两盘菜,还好没炒(迭代的好处,需求再变更,不怕)

食客吃完,很满意(想怎么挑怎么挑,直到满意)

================瀑布模型开发================

几位食客来餐馆吃饭(来项目啦~)

不确定吃些什么菜,找服务生要菜谱(客户往往提不出具体需求)

服务生拿出菜谱,有图有文,食客点了十盘菜(根据原型及文档基本确定了需求)

厨子们开始准备(项目启动)

小工切菜,厨子炒菜(基本不怎么去了解需求了)

N长时间后,食客饿急:你们先上一盘行不?(N长时间客户什么都看不到)

十盘菜炒好,端了出去(项目一次性完成)

食客说大部分还不错,有两盘味道淡了,有两盘不够辣,有两盘想换掉(我是客户,我要变更)

厨子:加盐加辣可以,换菜不行,换了我那两盘的成本咋办(瀑布的坏处,需求变更后不好改)

最后厨子给加了盐,加了辣,菜没法换(尽量让客户满意)

食客吃完,吃的不爽,下次不来了(客户不满意)

目前流行敏捷,总体上看确实比瀑布有优势,并且还不仅仅体现在需求变更上,还有很多方面。但还是得根据具体情况来,瀑布也有它的好处,比如电话定餐。s

原文地址:https://www.cnblogs.com/RogerLu/p/9689444.html

时间: 2024-07-31 03:37:26

敏捷、瀑布开发模式的相关文章

敏捷开发是一个什么样的开发模式

在信息技术高速发展的今天,有很多的开发任何要求开发人员增量交付,迭代式开发,能够持续集成.很显然传统的瀑布开发模式已经不能满足需要了,于是,敏捷开发这种模式就出现了. 接触过敏捷开发的朋友可能会知道,敏捷开发有如下的价值观: 个体与互动 胜于 过程与工具,可工作软件 胜于 复杂文档 用户协作 胜于 合同谈判,响应变化 胜于 遵循计划 下面新霸哥将会用一个真实的案例的给大家讲讲敏捷开发. 每天早晨上班前一项重要的任务那就是晨会(由于时间很短,所以大家都是站立开会的),主要就是回报一下昨天自己的工作

敏捷开发模式下的测试工作

在华为业务线上有近40天的时间了,参与了两个版本,华为的项目大多数走的都是敏捷迭代开发模式了,至于什么是敏捷,网上有很多的解释与资料,这里就不阐述了,就说说这期间华为的一个敏捷模式. 敏捷开发的最大特点是:积极响应用户的需求,快速高质量的交付软件.所以很多需求会按照用户需求程度以及模块之间的关联程度划分为多个迭代,这里的迭代你可以看做是一个小的完整的版本周期,每个迭代包含多个story,一个story相当于一个功能点,一个小的需求,而一个大的完整的发布版本一般由几个迭代版本组成.敏捷开发的周期一

管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革

管理从砖瓦进化为人 --浅谈传统软件工程到敏捷软件开发之变革 前言 如果把软件开发过程比作修筑一座建筑的话,传统的软件工程方法对人的管理就像是把人化作一砖一瓦,秩序地堆砌,一层一层构建起摩天大厦. 显然地,人是不同于砖瓦那样的死物的.人作为一种复杂的动物,软件开发者会有喜怒哀乐,枯燥重复的工作内容会使他们提不起兴趣而缺乏激情:客户想法会随变动的现实而一天天有所转变,软件需求很难保持一成不变:开发者与测试者对于项目的认识会存在差异,而差异将导致效率的降低--因而传统的有些"反人类天性"的

软件开发模式:瀑布与敏捷

瀑布和敏捷不是什么新概念,这里只是个人在团队合作中不得不去思考而做的归纳和总结,同时记录自己曾经踩过的坑,新瓶装旧酒,希望对你有所启发. 瀑布模式 瀑布模型是比较传统一种开发模式,特别是在2B的传统企业,包括ERP,MES,WMS,CRM,OA,IBMS等系统当中可以经常见到他们的影子.现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中. 如上图所示,瀑布模型优缺点都很突出. 优点明显: 阶段清晰.从计划到开发最后到上线运行,三个阶段非常清晰. 时间顺序.每个阶段顺序必须是从上到下,严格

敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

第11章 DIP:依赖倒置原则 DIP:依赖倒置原则: a.高层模块不应该依赖于低层模块.二者都应该依赖于抽象. b.抽象不应该依赖于细节.细节应该依赖于抽象. 11.1 层次化 下图展示了一个简单的层次化方案: 高层的Policy层使用了低层的Mechanism层,而Mechanism层又使用了更细节的Utility层.它存在一个隐伏的错误特征,那就是:Policy层对于其下一直到Utility层的改动都是敏感的.依赖关系是传递的. 下图展示了一个更为合适的模型: 每个较高层次都为它所需要的服

敏捷开发模式

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力.它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用. 在敏捷方法其独特之处以外,他和其他的方法也有很多共同之处,比如迭代开发,关注互动沟通,减少中介过程

敏捷软件开发:原则、模式与实践——第5章 重构

第5章 重构 在Martin Fowler的名著<重构>一书中,他把重构定义为:“在不改变代码外在行为的前提下对对代码做出修改,以改进代码内部结构的过程.”可是我们为什么要改进已经能够工作的代码结构呢?我们不是都知道“如果它没有坏,就不要去修理它!”吗? 每一个软件模块都有3项职责.第一个职责是它运行起来所完成的功能.这也是该模块得以存在的原因.第二个职责是它要应对的变化.几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种变化应尽可能地简单.一个难以改变的模块是有问题的,即使能够工

敏捷开发模式下的测试

敏捷开发 敏捷开发倡导的就是迭代式和增量式的开发模式,并且强调测试在开发过程中的重要性 .主要是围绕以用户为中心,以客户需求为导向的开发过程,这个过程有一个特点就是"随时有变化".虽然敏捷开发引入了灵活性,但其中的重点还是在于客户满意度.客户是敏捷过程的关键环节.如果,客户能够有所参与,并且客户了解到开发对于他们参与的欢迎,那么有助于增加客户对最终产品和开发team的信心和满意度.如果客户由于其他原因不愿意参与进来,那么选择传统的开发流程更好.敏捷开发有三个比较明显的特征:依赖客户完成