问瀑布模型的替代方案是什么

EN

瀑布的问题是它由单一的阶段组成，每个建筑都在前一阶段。因此，在整个系统设计完成后，代码是在一个块中开发的，这反过来发生在收集并签署所有需求之后。

这是一个问题，因为任何更改都必须通过一个复杂的程序来批准，并在所有阶段中产生涟漪。但历史的教训是:改变是会发生的。当我们开始编码时，需求总是不完整的，或者被错误地指定了，或者只是过时了。很多时候，设计和构建都是建立在假设的基础上，而当系统到达UAT时，这些假设就会失效。这会导致疯狂的返工和延误。

事实是，并不是许多客户擅长于设想一个工作的软件软件系统所需的那种抽象思维。而且太多的IT专业人员缺乏理解业务逻辑所需的经验。瀑布拒绝接受这些事实。

唯一诚实的需求规范是“当我看到它的时候我会知道它”。因此，尽快将可用的软件呈现在真正的用户面前是至关重要的。任何专注于在短迭代中增量地交付工作软件的方法都将“缓解瀑布模型的缺点”。

最初是RAD或DSDM。然后XP把横幅挂起来。现在有了Agile和相关的东西，比如Scrum和Kanban。

那么为什么人们坚持使用瀑布方法呢？

有一种普遍的看法认为，敏捷只是牛仔黑客的掩护，让他们抛弃所有无聊的过程，继续他们最喜欢的事情:编写代码。“极限编程”的品牌肯定鼓励了这种想法，老实说，这并不是一个毫无根据的指控。也就是说，一些程序员假装敏捷，作为不进行计划、设计或文档编制的借口。这并不反映敏捷的实际实践，它需要与任何其他方法一样的严格性。

此外，敏捷要求客户的员工投入更多的时间，这是许多组织不愿接受的。此外，为账单买单的人可能不愿授权他们的初级员工做出决定。客户和用户之间有一个重要的区别。

当涉及到外包时，瀑布模型提供了一个简单的框架，用于将可交付成果与阶段性支付相匹配。实际上，合同方面可能比这更强:在欧盟，瀑布被授权用于所有价值1亿欧元或更多的项目。

最后，还有一些瀑布效果很好的项目。这些项目具有稳定的知识域，客户和开发人员都能很好地理解这些知识域。

最后一个单词

尽管失败了，瀑布还是成功地交付了许多项目。这是因为努力工作、能力和正直比方法论更重要。

1970年，Winston Royce博士在一篇题为“管理大型软件系统的开发”的论文中记录了瀑布模型。基本上概述了他关于顺序开发的想法。他的想法是，软件可以以类似于汽车的方式生产，汽车是按顺序/线性阶段拼凑在一起的。

这种线性方法在一开始就不能真正考虑到软件的变化。与最终用户/客户没有紧密的关系，因此很难勾勒出可能的问题区域。

值得注意的是，瀑布模型的某些阶段允许“回溅”，从而在开发期间有足够的时间返回并进行小的更改。时间限制、涉及的工作量和预算实际上并不允许使用此模型进行太多更改。

瀑布模型是旧的，随着时间的推移，软件范例本身也会发生变化。面向对象编程很流行，那时候它还不是很活跃。通过使用瀑布模型，很明显，缺陷已经被发现，这导致了替代开发方法。

好了，现在让我们来看看替代方案。Alistair Cockburn(2008)将增量模型描述为一种分级和调度策略，在该策略中，各个部分以不同的时间或速率开发，并在完成特定部分后进行集成。

incremental基本上看起来很像这样：

Analysis->Design->Code->Test
  Analysis->Design->Code->Test
  Analysis->Design->Code->Test

许多好处包括生命周期是灵活的，并且允许从一开始就进行更改。工作的软件，或者更确切地说，部件是在早期快速生成的。由于进度的小迭代，生成的代码较早地进行测试和管理。并不是系统的所有需求都是预先收集的，只是一个提纲。这允许快速启动，但在某些系统中这可能是一个缺点，因为可能会错过像所支持的系统架构这样的东西。

另一方面，Iterative允许对系统的某些部分进行返工和修订，以改进系统。留出时间来考虑这一点。迭代并不是从完整的需求规范开始的。开发是通过指定和实现软件的一部分来完成的。对软件进行审查，以便进一步确定requirements.This更像是一种top down方法。这种方法的缺点是确保所有迭代都是兼容的。当每个新的迭代被批准时，开发人员可能会采用一种称为反向工程的技术，这是一个系统的审查和检查过程，以确保每个新的迭代与以前的迭代兼容。持续迭代的主要好处是客户被保持在循环中，最终产品应该满足需求。

Iterative approach diagram.

其他方法包括原型设计。进化的和一次性的。这些也被认为是一种更多的自上而下的方法。这两个过程都借鉴了engineering.In工程，构建待建对象的比例模型是很常见的。通过构建模型，工程师可以测试设计的某些方面。软件开发原型方法提供了相同的思想。原型设计并不是一种独立的、完整的开发方法，而是一种处理更大、更传统的开发方法中选定部分的方法。

抛出原型-抛出原型不保留已开发的原型。在一次性原型设计中，从来没有任何意图将原型转换为工作系统。相反，原型是快速开发的，以演示系统设计的一些不清楚的方面。还可以开发它来帮助用户或客户在不同的功能或界面特征之间做出决定。一旦解决了任何问题或不确定性，原型就可以被“扔掉”，学到的原则可以用于实际产品的设计和文档编制。

进化原型-在进化原型中，你首先对目标系统的部分进行建模，如果原型过程成功，你就可以从这些部分进化出系统的其余部分。这种方法的一个关键方面是原型成为实际的生产系统。这个过程允许在原型中成功地对系统的困难部分进行建模，并在项目的早期处理。

其他需要关注的领域包括敏捷-> SCRUM，极限编程，结对编程等。

试图保持简短，但人们写的书都是关于这类东西的，有太多要讨论的东西。

可能值得一看：Incremental and Iterative

瀑布方法的替代方法是“以正确的方式做它”。

如果您在工厂车间的装配线上，瀑布似乎是有意义的。但我从来没有见过它作为设计的一部分，process...and软件开发完全是一个设计过程。因此，瀑布方法从来没有真正起作用，因为它不能帮助创建高质量的产品，而是专注于过程。过程可以是伟大的，但如果它生产的产品是二流的，那又有什么意义呢？