问迭代开发方法对web应用程序来说是好是坏

EN

迭代是反对瀑布开发的。如您所知，您应该经历几个不同的阶段来交付软件产品。

• 需求工程/许可
• 分析与设计
• 实现
• 测试与验证
• 部署和维护

在每个阶段结束时，您将得到一些工件或可交付的结果。在瀑布策略中，一旦你完成了一个阶段，一切都完成了，你就不会再回到那个阶段了。

在迭代方法中，您将反复经历这些阶段。在每个周期中，您重复所有或部分这些阶段，在每个周期结束时，您将交付一个工作产品。

迭代方法允许您逐步开发您的软件，您将能够逐步建立并进一步扩展您的产品。您可以在第一个周期结束时只提供web应用程序的框架，然后在每个周期之后，您将重新检查您的需求、设计、实现和测试计划。你会发现错误并修复它们。同时，您将收到来自您的最终客户的反馈，并相应地更改您的产品。

像scrum这样的敏捷方法主要是关于如何消除不必要的广泛过程，如繁重的文档、正式会议等等。因此，您可以转而专注于您的产品和代码，并以更快的速度迭代周期。敏捷既不执行瀑布，也不执行迭代方法，但事实是瀑布现在已经过时，不再在工业中使用。

迭代开发已经有很长一段时间了。它当然早于敏捷，尽管您可以说它是敏捷开发方法的祖先。

有一些非敏捷开发方法包括迭代，比如RUP，所以它不仅仅是一个敏捷实践。

还有很多方法可以使用迭代方法。例如，您可以预先收集需求和设计，然后只在开发阶段使用迭代。

像XP和Scrum这样的敏捷框架将迭代进行得更远一些，并且在每次迭代结束时看起来都有一个“可发布的”产品。

敏捷迭代方法的好处：

• 该产品可在开发的早期阶段发布。
• 进度通常更容易衡量(发布的代码是对进度的很大度量)
• 迭代方法允许团队更容易地响应更改。

敏捷迭代方法的局限性：

• 要将像UAT和法规遵从性这样的东西安装到迭代中，这可能是一个挑战。
• 可能存在与频繁发布和频繁重新规划相关的开销。

您可以认为在每次迭代结束时都有一个可发布的产品作为一种纯形式的迭代开发。并不是每个团队都采用这种方法。例如，有些人可能会将用户测试保留到几次迭代之后。这样做的缺点是，你永远无法确定工作是否“完成”，因为潜在的用户反馈可能会改变事情。