项目管理之敏捷与瀑布 
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://gzycm520.blog.51cto.com/175220/71074 |
敏捷开发
几位食客来餐馆吃饭（来项目啦~） 不确定吃些什么菜，找服务生要菜谱（客户往往提不出具体需求） 服务生拿出菜谱，有图有文，食客点了十盘菜（根据原型及文档基本确定了需求） 厨子们开始准备（项目启动） 小工切菜，厨子炒菜，先炒了两盘，端出去先给食客品尝（先拿实例给客户用用） 食客说还不错，厨子继续炒，继续端出去（开发期间不断给客户试用，敏捷讲究这个，人们叫它迭代） 食客发现这次两盘味道淡了，厨子给加了盐（迭代的好处，需求变更后马上改） 又上两盘，不够辣，厨子给加了辣椒（迭代的坏处，反复多了，增加工作量） 到最后两盘时，应食客要求，给换了这两盘菜，还好没炒（迭代的好处，需求再变更，不怕） 食客吃完，很满意（想怎么挑怎么挑，直到满意） 瀑布模型开发
几位食客来餐馆吃饭（来项目啦~） 不确定吃些什么菜，找服务生要菜谱（客户往往提不出具体需求） 服务生拿出菜谱，有图有文，食客点了十盘菜（根据原型及文档基本确定了需求） 厨子们开始准备（项目启动） 小工切菜，厨子炒菜（基本不怎么去了解需求了） N长时间后，食客饿急：你们先上一盘行不？（N长时间客户什么都看不到） 十盘菜炒好，端了出去（项目一次性完成） 食客说大部分还不错，有两盘味道淡了，有两盘不够辣，有两盘想换掉（我是客户，我要变更） 厨子：加盐加辣可以，换菜不行，换了我那两盘的成本咋办（瀑布的坏处，需求变更后不好改） 最后厨子给加了盐，加了辣，菜没法换（尽量让客户满意） 食客吃完，吃的不爽，下次不来了（客户不满意） 目前流行敏捷，总体上看确实比瀑布有优势，并且还不仅仅体现在需求变更上，还有很多方面。但还是得根据具体情况来，瀑布也有它的好处，比如电话定餐。 本文出自 “知识改变命运” 博客，请务必保留此出处http://gzycm520.blog.51cto.com/175220/71074 本文出自 51CTO.COM技术博客 |
gzycm520
博客统计信息
热门文章
最新评论
友情链接
