瞎想的
瀑布模型其优点比如:
1)为项目提供了按阶段划分的检
查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
4)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
很好地解释了为什么瀑布模型还能在如今使用,但是我想说的不是这个。我们再看看其缺点:
1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4)瀑布模型的突出缺点是不适应用户需求的变化。
我想说的是从第三点联想到了“人性本恶”。
假定有一位从不索求无度的客户,非常乐意出钱。他聘请了一个视客户为上帝的团队帮他开发项目,团队之间不存在任何矛盾,且能对客户的需求完美满足,并且能在预算和时间范围内按最高性价比制作其产品。
然而上述条件不可能同时成立,因为人性本恶。客户与开发团队之间无法完全信任彼此,且因为人性本恶,我们也无法保证沟通交流、资金给付完全到位。
正是因为人性本恶,所以只能选择把需求落在书面上。我们需要合同的约束力迫使沟通交流尽量表意清晰、资金尽快到位,需要合同的约束力迫使项目的各个阶段能在期限内完成。
此外合同里的事项在稍晚的时间多半会有变,在和同事先让一步,等有需求变化的时候在抬价之类的,同时也印证了人性本恶。
没了。