当客户的需求完全不变时，使用敏捷是错误的吗？

我最近看到很多帖子说，使用敏捷的主要原因之一是因为客户经常更改需求。

但是，假设客户不会经常更改需求。实际上，客户的要求虽然严格，但可能有些含糊（但没有任何不合理的含糊），但无论如何，我还是使用敏捷。

我之所以选择敏捷，是因为该软件足够复杂，以至于存在一些细节和问题，直到我真正面对这些问题时我才意识到。我可以像瀑布一样进行全面的繁重计划，但是要花上几个月才能完成所有高级设计和低级代码签名。但是，系统有一个非常具体的固定体系结构设计。

我的问题是：这会被认为是不好的，牛仔编码，反模式等吗？在需求稳定时开始编码之前，我们是否必须采用瀑布式计划并尽可能详细地计划，而不是敏捷中的这种“让我们去做”的心态？

编辑：这里的主要观点是：我们不能责怪客户改变需求。假设客户向我们指出了一个非常具体的问题，给我们一个非常合理的细节的愿望清单，然后让我们独自一人（即客户有自己的生产性工作要做，别再烦他们了。只向他们演示当您有最低限度的工作原型时结束）。在这种情况下使用敏捷会错吗？

将其视为不良的牛仔编码反模式吗？

简短的回答：不。正确地进行“敏捷”并不意味着“没有计划”，而是意味着不会过度分析事物。

使用敏捷的主要原因之一是因为客户经常更改需求。

这是一个过于简化的陈述。“更改需求”还涉及团队对需求的理解如何变化。这是关于当客户实际看到该软件的一些版本时，客户对需求的优先级如何变化。

实际上，“敏捷”最适合您所描述的情况的 IMHO- 客户对他的总体需求有很好的了解，您可以从中编写一个总体计划，在待办事项中填充很多“用户案例”，并且已经足够的信息来选择正确的系统架构。然后，敏捷开发策略的短暂迭代将有助于使“含糊的要求”更加精确，如果您仍然朝着正确的方向前进，则会获得大量反馈。它还将为您提供有关实际工作量和成本的早期反馈（即使您详细了解每一点要求，在瀑布式方法中仍然会失败）。

在这种情况下使用敏捷仍然是一个很好的主意。敏捷有很多好处，其中只有一项就是来自客户的定期反馈，以及您所提到的响应不断变化的需求的能力。

瀑布项目因失败而臭名昭著的主要原因之一是“几乎完成”的问题-最后测试产生的大量bug，留下无法发布的产品，也不知道是否需要再花两天或两年的时间来修复突出的bug。敏捷完全消除了这种风险。如果敏捷项目正在运行，您仍然可以提供一个工作版本，该版本：

A）通过演示向客户证明您实际上就在那儿（“所有这些故事都已完成，如果您愿意，我们可以做最后几个”），再花一些时间就能得到他们想要的东西。

B）潜在地足以使他们无论如何开心和释放。

对我而言，消除这种完全失败的风险仅仅是一个足以使企业转向敏捷开发流程的理由，构建比最初计划的更好的软件的能力正在锦上添花。正如其他答案中提到的那样，那些“具体”的要求通常仍然令人惊讶。

如果您需要与客户之间频繁的反馈循环，那么敏捷是理想的选择。这可能是因为需求经常更改，但是也可能是由于其他原因。

另一方面，如果需求是完全稳定的，并且客户只希望一次大爆炸交付，那么敏捷可以同样很好地工作，但是您可能需要针对客户在此期间期望的参与量进行一些调整。项目。这意味着必须在您自己的组织中担任产品负责人角色，并且该人员必须从客户那里获得足够的授权才能做出决定。

您始终可以将较大的发行版划分为较小的发行版（冲刺），并要求您的客户提供反馈。这样，您可以确定自己做的正确，客户可以跟踪您的进度。

如果出了点问题，您可以为您的客户提供一个尽快纠正您的机会，这非常好。最好尽快纠正您的错误，而不是在结尾时给他废话，然后甚至在您不知道从哪里开始时尝试解决该问题。