当客户的需求根本不改变时，使用敏捷是错误的吗？

Question

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

但是，假设客户端不经常更改需求。事实上，客户有明确的需求--虽然可能有点模糊(但没有什么不合理的模糊)，但我还是使用了敏捷。

我之所以使用敏捷，是因为软件非常复杂，在我真正面对这些细节和问题之前，我不会意识到这些细节和问题。我可以做一个全面的大规模规划方法，如瀑布，但它将需要几个月的时间来完成所有的高层次设计和低级别编码签名。有一个非常具体的，固定的体系结构设计，尽管。

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

编辑:这里的要点是:我们不能责怪客户更改需求。假设客户给我们指明了一个非常具体的问题，给我们一份非常合理的详细愿望清单，让我们自己去做(即客户有自己的有价值的事情要做，不要再烦他们了)。只有演示接近尾声时，你有一个最低的工作原型)。在这种情况下使用敏捷是错误的吗？

Answer 1

如果这被认为是坏的，牛仔编码，反模式。

简短回答:不。正确地做“敏捷”并不意味着“没有计划”，而是意味着不要过分地分析事情。

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

这句话太简单化了。“变更需求”也是关于团队对需求的理解是如何变化的。它是关于当客户看到软件的几个版本时，关于需求的优先级是如何变化的。

事实上，“敏捷”最适合你描述的情况--客户对他的总体需求有很好的了解，你可以用它写一个总体计划，用大量的“用户故事”填充你的积压，并且已经有足够的信息来选择正确的系统架构。然后，敏捷开发策略的简短迭代将有助于使“模糊需求”更加精确，如果您仍在朝着正确的方向前进，将提供大量反馈。它还会给你关于真正的努力和成本的早期反馈(即使你知道每一个细节的需求，在瀑布方法中，这仍然是你可能失败的事情)。

Answer 2

在这种情况下使用敏捷仍然是一个非常好的主意。敏捷有许多好处，其中之一就是客户的定期反馈和您提到的应对不断变化的需求的能力。

瀑布项目因失败而声名狼藉的主要原因之一是“几乎完成”的问题--测试最终产生了一大堆错误，留下了无法发布的产品，也不知道是否还需要两天或两年时间才能修复这些突出的缺陷。敏捷完全消除了这种风险。如果一个敏捷项目运行过度，您仍然可以提供一个工作版本，其中：

( A)通过演示(“所有这些故事都完成了，如果你想的话，我们可以做最后几个故事”)来向客户证明你实际上就在那里(如果你想要的话，我们可以做最后几个故事)，再多一点时间就能得到他们想要的东西。

( B)对他们来说可能是足够好的，他们无论如何都会感到高兴和释放。

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

Answer 3

如果您需要与客户端进行频繁的反馈，那么敏捷是非常理想的。这可能是因为需求经常更改，但也可能是出于其他原因。

另一方面，如果需求是完全稳定的，而且客户只期望一个大爆炸的交付，那么敏捷可以同样良好地工作，但是您可能需要调整一些东西，以适应客户希望在项目期间参与的程度。这意味着产品负责人角色必须从您自己的组织中填补，并且该人员必须得到客户足够的授权才能做出决策。