敏捷、瀑布開發模式
=================敏捷開發==============
幾位食客來餐館吃飯（來項目啦~）
不確定吃些什麽菜，找服務生要菜譜（客戶往往提不出具體需求）
服務生拿出菜譜，有圖有文，食客點了十盤菜（根據原型及文檔基本確定了需求）
廚子們開始準備（項目啟動）
小工切菜，廚子炒菜，先炒了兩盤，端出去先給食客品嘗（先拿實例給客戶用用）
食客說還不錯，廚子繼續炒，繼續端出去（開發期間不斷給客戶試用，敏捷講究這個，人們叫它叠代）
食客發現這次兩盤味道淡了，廚子給加了鹽（叠代的好處，需求變更後馬上改）
又上兩盤，不夠辣，廚子給加了辣椒（叠代的壞處，反復多了，增加工作量）
到最後兩盤時，應食客要求，給換了這兩盤菜，還好沒炒（叠代的好處，需求再變更，不怕）
食客吃完，很滿意（想怎麽挑怎麽挑，直到滿意）
================瀑布模型開發================
幾位食客來餐館吃飯（來項目啦~）
不確定吃些什麽菜，找服務生要菜譜（客戶往往提不出具體需求）
服務生拿出菜譜，有圖有文，食客點了十盤菜（根據原型及文檔基本確定了需求）
廚子們開始準備（項目啟動）
小工切菜，廚子炒菜（基本不怎麽去了解需求了）
N長時間後，食客餓急：你們先上一盤行不？（N長時間客戶什麽都看不到）
十盤菜炒好，端了出去（項目一次性完成）
食客說大部分還不錯，有兩盤味道淡了，有兩盤不夠辣，有兩盤想換掉（我是客戶，我要變更）
廚子：加鹽加辣可以，換菜不行，換了我那兩盤的成本咋辦（瀑布的壞處，需求變更後不好改）
最後廚子給加了鹽，加了辣，菜沒法換（盡量讓客戶滿意）
食客吃完，吃的不爽，下次不來了（客戶不滿意）
目前流行敏捷，總體上看確實比瀑布有優勢，並且還不僅僅體現在需求變更上，還有很多方面。但還是得根據具體情況來，瀑布也有它的好處，比如電話定餐。s
敏捷、瀑布開發模式