敏捷、瀑布开发模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

猜你喜欢

转载自www.cnblogs.com/RogerLu/p/9689444.html