瀑布开发和敏捷开发
一、瀑布开发
定义：瀑布开发模型以文档为驱动，它的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据。
开发流程：
需求分析：对于需求进行详细的分析和评估，形成需求分析文档；
设计：技术评估，规划时间节点，形成技术文档以及时间规划；
开发：按照时间规划，进行开发，每个阶段完成一定的内容；
测试：开发完成后，进行测试，有问题就修改，直到可以用为止。
特点：
最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
优点：
1、步骤清晰明确；
2、文档完整，开发过程中可以作为参考。
缺点：
1、瀑布开发是从工业发展过来的，不适合计算机软件的开发；
2、开发周期长，花大量时间去编写文档，耗费时间、人力；
3、客户只有在整个项目完成时才可以看到成果，会导致信任问题；
4、风险大，在开发过程中并不能明白最后的结果，同时不能适应变化；
故事场景：
1、客人到餐馆来点菜（新项目）；
2、不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）；
3、根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）；
4、后厨开始准备（项目启动）；
5、根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）；
6、半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）；
7、再过了二十分钟，十个菜都一起上来了（项目最终一次交付）；
8、客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）；
9、这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）；
10、于是，后厨只给客户加了盐，加了辣客人吃完，不是很满意，下次不来了（没有满足需求）。
二、敏捷开发
定义：敏捷开发模型只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
特点：
强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
工作方式：
作为一个整体工作；
按短迭代周期工作；
每次迭代交付一些成果；
关注业务优先级；
检查与调整；
优点：
1、迭代快，开发周期短；
2、不再耗费大量的时间来写文档，而是人与人面对面交流，只写一些必要的文档；
3、分工详细，每天都输出成果，客户能够看得到，会信任项目团队；
4、沟通多，容易发现问题，同时能够激起团队的协作、奋斗；
缺点：
1、人与人之间的信任是非常重要的环节，但是这个比较难完成，技术团队的成员可能技术能力差别大，同时也有互相竞争，又或者是项目团队的成员有所保留，不愿意这样的沟通；
2、团队在开发期间的任务多、压力大，需要时刻保持“兴奋”，一般很难做到。
故事场景：
1、客人到餐馆来点菜（新项目）；
2、不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）；
3、根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）；
4、后厨开始准备（项目启动）；
5、配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）；
6、客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）；
7、上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更） ；
8、又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）；
9、到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）；
10、客人吃完，很满意（基本满足了全部的要求）。
后话：每一个开发模式都有着重点，它的好与坏基本上都是见仁见智的（也不能一棒子打死，比如说：政府的外包项目，基本上都是按照传统的瀑布开发模型来开发，政府的人才懒得在中间不断的去提需求！而小企业的自营项目，基本上很多时候老板的需求就是需求，变更极其频繁，而且还乐意参与到项目中，所有敏捷开发就很适合这类型），只有适合企业的开发模式才是好模式！
