APC*_*APC 16
瀑布的问题在于它由整体阶段组成,每个阶段都在前一阶段.因此,代码是在整个系统设计完成后的一个块中开发的,而这又是在收集并签署所有需求之后发生的.
这是一个问题,因为任何变化都必须通过复杂的程序来批准,并在所有阶段中起到作用.但历史的教训是:改变发生了.在我们编码时,要求总是不完整,或错误指定或仅仅是过时的.通常基于在系统到达UAT时无效的假设来设计和构建.这导致疯狂的重新工作和滑点.
事实并非许多客户擅长设想一个有效的软件系统所需的抽象思维.太多的IT专业人员缺乏理解业务逻辑所需的经验.瀑布拒绝接受这些真相.
唯一诚实的要求规范是"当我看到它时我会知道它".因此,尽快在真实用户面前获得工作软件至关重要.任何专注于在短迭代中递增递送工作软件的方法都将"减轻瀑布模型的缺点".
最初是 RAD或DSDM.然后XP拿起横幅.现在有敏捷和相关的东西,如Scrum和看板.
那么为什么人们坚持使用瀑布方法呢？
人们普遍认为,敏捷只是掩盖了牛仔黑客抛弃所有无聊过程的东西并继续他们最喜欢的东西:编写代码."极限编程"的品牌肯定会鼓励这种想法,而且说实话,这不是一个毫无根据的指控.也就是说,一些程序员假装敏捷是不计划,设计或记录的借口.这并不反映敏捷的实际做法,它需要与任何其他方法一样严格.
敏捷也需要客户的工作人员更多的时间,许多组织都不愿意接受.支持该法案的人也可能不愿意让初级员工做出决策.客户和用户之间存在重要区别.
在外包方面,瀑布模型提供了一个简单的框架,用于将可交付成果与分阶段付款相匹配.事实上,合同方面可能比那更强:在欧盟瀑布的所有项目都要求价值1亿欧元或更多.
最后,还有瀑布运作良好的项目.这些项目拥有稳定且知识领域的知识域,客户和开发人员都能很好地理解这些知识域.
遗言
尽管失败,瀑布已经成功地完成了许多项目.这是因为努力工作,才能和诚信比方法更重要.