1.敏捷开发
客人到餐馆来点菜（新项目）
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）
后厨开始准备（项目启动）
配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）
客人吃完，很满意（基本满足了全部的要求）
(在举个例子)
打个比方，客户说他想要造一座金字塔，你作为“咨询师”，认为这座金字塔要造10年，肯定不能指望一次设计好就一口气做完，于是问客户这个金字塔是要干什么？客户说要当坟墓，于是，你提出先做一个小坟墓的功能，能装木乃伊那种。客户同意了，你哐哧哐哧做了一个月，制造了一个小型地下墓室，演示给客户看，客户看了，一拍大腿，说看到这个墓室才想明白，其实他要的不是金字塔，要的是一个有排场的墓地，这样简陋埋在地下的墓室不够牛逼，于是你和客户达成第二阶段设计，做一个带兵马俑方阵来让这个墓地显得有排场，客户同意了，于是你又哐哧哐哧做了一个月，做了一个小型兵马俑方阵。客户看了兵马俑方阵，又一拍大腿，说这个方阵还真牛逼，但是能不能增加一些现代元素，把古代兵马俑换成现代装甲兵团，你于是又……（如此，周而复始，每个阶段只完成客户一个需要，当然，我上面只是一个荒诞的例子，但是你应该能够get到敏捷的含义。）
2.瀑布模型开发
客人到餐馆来点菜（新项目）
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
后厨开始准备（项目启动）
根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我- 要变需求）
这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
于是，后厨只给客户加了盐，加了辣
客人吃完，不是很满意，下次不来了（没有满足需求）
3、总结
但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用
最后借用民国时候的一句话：少研究一些主义，多关注一些实际问题（net）
