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

有人能给我解释一下迭代开发方法以及在开发web应用程序时使用它的好处/局限性吗

另外，我一直在研究它，但我很困惑，它是否是敏捷的一部分？有消息说是的，有消息说不是

---

谢谢大家

迭代与瀑布式开发相反。正如您所知，交付软件产品应该经历两个不同的阶段

• 需求工程/启发
• 分析与设计
• 实施
• 测试与验证
• 部署和维护

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

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

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

---

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

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

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

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

像XP和Scrum这样的敏捷框架将迭代进行得更进一步，并希望在每次迭代结束时都有一个“可发布”的产品

敏捷迭代方法的好处：

• 该产品可在开发的早期阶段发布
• 进度通常更容易衡量（发布的代码是衡量进度的重要指标）
• 迭代方法允许团队更容易地响应变化

敏捷迭代方法的局限性：

• 将UAT和法规遵从性等内容融入迭代可能是一个挑战
• 频繁发布和频繁重新规划可能会带来开销

---

您可以将在每次迭代结束时拥有一个可发布的产品看作是迭代开发的一种纯粹形式。并非每个团队都使用这种方法。例如，有些人可能会在多次迭代之后才进行用户测试。这样做的缺点是，您永远无法真正确定工作是否“完成”，因为用户反馈可能会改变情况。

这不是真正的编程问题。查阅敏捷宣言并从它开始。“迭代”不是敏捷的唯一部分，所以迭代并不一定等同于敏捷。嘿，谢谢，你知道在每个阶段结束时。您是否需要用户来测试可交付成果？测试是一个完全不同的故事，应该由不同的堆栈持有者（开发人员、测试人员、用户等）在不同的层次（分析、设计、实现等）进行