存在的问题有:1、投入大于产出;2、无法根据市场的变化动态地调整产品;3、质量反馈严重滞后;4、价值交付周期长。投入大于产出,花了很长时间但是最终交付的产品与客户的期望偏差很大。需求不是一次性或者一段时间内就可以完全定义清楚的。
1、投入大于产出
花了很长时间但是最终交付的产品与客户的期望偏差很大。需求不是一次性或者一段时间内就可以完全定义清楚的。需求定义是个不断发现的过程。需求必须在整个研发过程中与客户不断沟通,反复澄清,甚至需要结合业务流程图、产品原型等工具,才能明确客户想要的需求是什么。需求的本质特性决定了即使瀑布模型存在一个专门的需求分析阶段,然而在设计、开发甚至测试阶段中仍旧会出现新的需求。
需求本身具备不确定性,客户也经常不完全清楚自己想要的是什么,只有看到了产品原型或者使用了产品之后,才有可能厘清自己的需求。因此需要持续获得客户对产品的反馈,才能明确产品下一步该做什么需求、不该做什么需求。
因此,瀑布模型试图在名列前茅步就定义好完整的产品需求,这其实是在试图实现一个无法实现的梦想。
2、无法根据市场的变化动态地调整产品
市场不是静态的。尤其是互联网产品,市场的变化非常迅速。而瀑布模型在需求分析阶段结束后冻结需求,之后任何需求的变化都需要走严格的变更流程。因为怕影响交付时间,一般都会抑制需求的变化。但是市场已经有了变化,抑制需求的变化反而不能交付真正适配市场的产品,即便最终按时交付,但是交付的是几个月甚至几年前冻结的需求文档里定义的那个产品,而不是现在市场上真正需要的那一个,反而贻误了新的商业机会。
3、质量反馈严重滞后
瀑布模型里严格区分了需求分析→设计→开发→测试等阶段,每个阶段通常都会耗时几周甚至几个月的时间,导致质量问题的反馈周期过长。例如:在开发阶段发现需求存在问题的时候,通常需求分析阶段结束已经过了好几个月了,对需求问题的修正除了需要走严格的变更评审流程之外,还需要对需求分析和设计阶段的产出物进行相应的调整,最终才能体现在开发阶段的产出物上。更为糟糕的是,测试阶段发现的Bug,有的是开发阶段引入的,有的是设计阶段引入的,有的甚至是需求分析阶段就出现了纰漏和错误。因此,从一个Bug引入的时候到发现它,已经过了至少几个月的时间。通常情况下,采用瀑布模型的项目,在交付前都会有长达几个月的集中修改Bug的阶段。
4、价值交付周期长
在瀑布模式里,一个产品从立项到发布给客户一般需要经过几个月、一年甚至几年的时间。在研发的中间过程中,没有任何可以给客户使用的产品。虽然在客户的要求下,也许有一些文件和报告会提供给客户,但产品的实际进展对客户还是一个黑盒。
于是在这样的背景下,软件工程迎来了第二次浪潮:敏捷软件开发。XP(极限编程)、Scrum等各种敏捷方法出现,在2001年的时候诞生了敏捷宣言。2003年,精益软件大师Mary Poppendieck将精益思想融入到软件工程中,诞生了精益软件开发原则。
随着近几年移动互联网的快速发展,为了抓住市场上稍瞬即逝的商机,满足不断增长的业务需求和用户体验,促使服务提供商对软件产品有了更高的期望和要求:不仅仅是能够短周期内迭代交付,而是持续不断地按需部署到生产环境。由此,DevOps概念和技术在这个背景下诞生。
延伸阅读:
什么是瀑布模型
瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么较好 “返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
瀑布模型是较早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动。同时评审该项活动的实施,若确认,则继续下一项活动;否则返回前面,甚至更前面的活动。对于经常变化的项目而言,瀑布模型毫无价值。
文章标题:瀑布模型存在的问题是什么,发布者:小编,转载请注明出处:https://worktile.com/kb/p/33489