敏捷开发

客人到餐馆来点菜(新项目)
不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
根据图文菜单,客人点了是个菜(根据原型和设计稿,基本确定了需求)
后厨开始准备(项目启动)
配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)
客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)
上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)
又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)
到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)
客人吃完,很满意(基本满足了全部的要求)

瀑布模型开发

客人到餐馆来点菜(新项目)
不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)
后厨开始准备(项目启动)
根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)
半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)
再过了二十分钟,十个菜都一起上来了(项目最终一次交付)
客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我要变需求)
这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)
于是,后厨只给客户加了盐,加了辣
客人吃完,不是很满意,下次不来了(没有满足需求)