瞎想的

　　瀑布模型其优点比如：

1）为项目提供了按阶段划分的检

 

查点。

2）当前一阶段完成后，您只需要去关注后续阶段。

3）可在迭代模型中应用瀑布模型。 增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

　　很好地解释了为什么瀑布模型还能在如今使用，但是我想说的不是这个。我们再看看其缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4）瀑布模型的突出缺点是不适应用户需求的变化。

　　我想说的是从第三点联想到了“人性本恶”。

　　假定有一位从不索求无度的客户，非常乐意出钱。他聘请了一个视客户为上帝的团队帮他开发项目，团队之间不存在任何矛盾，且能对客户的需求完美满足，并且能在预算和时间范围内按最高性价比制作其产品。

　　然而上述条件不可能同时成立，因为人性本恶。客户与开发团队之间无法完全信任彼此，且因为人性本恶，我们也无法保证沟通交流、资金给付完全到位。

　　正是因为人性本恶，所以只能选择把需求落在书面上。我们需要合同的约束力迫使沟通交流尽量表意清晰、资金尽快到位，需要合同的约束力迫使项目的各个阶段能在期限内完成。

　　此外合同里的事项在稍晚的时间多半会有变，在和同事先让一步，等有需求变化的时候在抬价之类的，同时也印证了人性本恶。

　　没了。

转载于:https://www.cnblogs.com/TaketoriHishou/p/5385668.html