敏捷開發(fā)

客人到餐館來點(diǎn)菜（新項目）

不確定客戶想吃什么的時候，通常選好餐廳后會先看看餐廳的菜單（客戶往往提不出具體的需求）

根據(jù)圖文菜單，客人點(diǎn)了是個菜（根據(jù)原型和設(shè)計稿，基本確定了需求）

后廚開始準(zhǔn)備（項目啟動）

配菜、炒菜，先上了兩盤，讓客人嘗了嘗味道（先提供可用實(shí)例給客戶用）

客人說還不錯，后廚繼續(xù)準(zhǔn)備后面的菜，陸續(xù)上菜（不斷迭代，不斷測試）

上菜過程中，客人突然發(fā)現(xiàn)有個菜的味道太淡了，讓后廚加了點(diǎn)鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）

又上了兩盤，不夠辣，又拿到后廚加了辣（敏捷的壞處，需求沒有提前明確，反復(fù)迭代，增加了工作量）

到最后兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）

客人吃完，很滿意（基本滿足了全部的要求）

瀑布模型開發(fā)

客人到餐館來點(diǎn)菜（新項目）

不確定客戶想吃什么的時候，通常選好餐廳后會先看看餐廳的菜單（客戶往往提不出具體的需求）

根據(jù)圖文菜單，客人點(diǎn)了十個菜（根據(jù)原型和設(shè)計稿，基本確定了需求）

后廚開始準(zhǔn)備（項目啟動）

根據(jù)客人的下單配菜，炒菜（基本上不會主動去了解完整需求）

半個小時了，菜還沒上桌，客人餓極了（項目啟動后很長一段時間客戶什么都看不到）

再過了二十分鐘，十個菜都一起上來了（項目最終一次交付）

客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重復(fù)了想換掉（我是買單的，我要變需求）

這時候大堂經(jīng)理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經(jīng)炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）

于是，后廚只給客戶加了鹽，加了辣

客人吃完，不是很滿意，下次不來了（沒有滿足需求）

7、總結(jié)

但總的來說，在現(xiàn)在管理項目過程中，并沒有嚴(yán)格的按照完全的敏捷或者完全的瀑布模式，都是各自摻雜了其他的方式。在實(shí)際項目過程中，過于強(qiáng)調(diào)模式并沒有意義，重要的是能不能預(yù)防問題的發(fā)生，在問題發(fā)生之后能不能用最小的成本解決，模式更多起一個參考作用