存在的问题有：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
微信扫一扫 
支付宝扫一扫 
