我已经阅读了很多关于敏捷和瀑布的信息，但我想不出今天有人应该做瀑布的任何理由。我特别关心测试过程。我是否错过了什么，是否有一些我忽略的明显优势？
问问题
1863 次
4 回答
6
仍然存在适合使用瀑布的情况。典型示例包括军事、太空、医疗和安全关键系统，例如飞行控制软件，在这些系统中，您绝对需要首先详细确定规格，开发它，然后彻底测试完整的产品。
敏捷适用于大多数业务和产品软件（即大多数构建的软件），因为它允许用户从一个粗略的想法开始，并在他们进行时对其进行改进。如果他们的网站或内部业务线应用程序在几次迭代中并不完全正确（或存在错误），那么它通常被从有效的位中快速交付的业务价值所抵消。您不会想从一个核电站控制器系统的粗略构想开始，然后在进行过程中对其进行改进。
使用纯瀑布的权衡是在这些场景中开发软件的成本要高出几个数量级。然而，成本效益仍然是有利的，因为您无法承受（例如）您的航天器在进入轨道的中途遇到空指针异常。
两者之间当然有灰色阴影。可以在瀑布框架中使用敏捷技术（参见 RUP），并且可以在纯瀑布和纯敏捷之间扩大和缩小平衡。
于 2012-06-26T07:48:08.460 回答
2
瀑布式开发模型的主要优点之一是它已经被使用了多年。有用。尽管有很大的转变和对敏捷的关注，但瀑布是一个非常清晰的过程，每个开发部分都有起点和终点。
随着敏捷编程的引入，很容易看到瀑布的下降以及它如何不适应当今的编程需求。
只要您谨慎并提前计划并进行充分测试，我会说敏捷测试可以与瀑布式测试一样有效甚至更有效 - 当测试引发一些可能导致设计改变方式的错误时，使用敏捷当然更容易.
要考虑的另一件事是使用测试驱动开发进行开发。 http://en.wikipedia.org/wiki/Test-driven_development
于 2012-06-26T07:38:41.763 回答
0
外包
我见过许多公司坚持使用瀑布进行外包项目。大多数供应商在报价方面都会非常具体。瀑布非常适合这个模型 - 你交出你想要的东西，他们会生产它。我不是这个的粉丝，但我可以理解执行这种方式的原因。我认为大多数外包公司最终会找到一种变得更加敏捷的方法，因为它越来越成为行业标准。
于 2012-06-28T02:51:12.633 回答
0
问题的答案取决于您为项目使用的开发方法。它是敏捷的/是瀑布式的/等等。在过去的三到四年里，我参与了仅涉及敏捷或仅涉及瀑布式的项目，因此将它们用作我的参考点。如果项目的需求不断变化，我们永远不应该进行瀑布设计，因为瀑布方法假设设计/分析/等已经完成，而如果我们采用敏捷，它是基于增量方法，我们将项目划分为随着我们进行增量故事和构建/测试，因此如果需求发生变化，它不会涉及开发人员和测试人员的大量返工。例如，假设我们必须创建四个新网页作为我们项目的一部分，然后瀑布假设他们的设计等已经完成，一旦所有四个页面都开发完毕，测试将开始，而在敏捷的情况下，我们首先开发一个页面并将其交给 QA 进行测试 [手动/自动化]，等等。因此，我们可以看到敏捷除了在开发时发现功能缺陷/错误之外，还通过使其不易于受到需求更改的影响为我们的项目增加了价值。
于 2014-01-25T05:30:16.787 回答