我在敏捷环境中工作，事情已经发展到这样的状态:客户认为由于当前敏捷场景的失败(这就是他们的想法)，他们更喜欢瀑布。他们之所以有这样的想法，是因为在冲刺的最后阶段发生了大量的设计级别变更，而我们(开发人员)无法在他们指定的时间内完成。
像往常一样，我们都互相指责。从我们的角度来看，最后所说的更改太多，设计/代码更改也太多。而从客户的角度来看，他们提示我们(开发人员)没有完全理解需求，并且提出的解决方案“不是”他们在需求中的预期。 (就像他们要求我们画一只老虎，而我们画了一只猫)。
因此，客户(不是我们)认为敏捷流程不正确，他们希望切换到瀑布模式，恕我直言，这将是灾难性的。原因很简单，他们对敏捷模式本身的满意度还不够，那么在瀑布式开发的设计阶段花费了如此多的时间，他们如何能够容忍输出呢？
请提出您的建议。
最佳答案
首先 - 问问自己真的在进行敏捷吗？如果您是，那么您应该已经向客户交付了大部分可用功能，满足了他们在早期冲刺中的要求。理论上，“损害”应该仅限于您发现需要进行大量设计更改的最后冲刺。在这种情况下，您应该已经证明了自己的交付能力，现在需要与客户对话以计划现在所需的变更。
但是，根据您的描述，我怀疑您已经陷入了仅以两周为周期进行开发的陷阱，而没有每次实际交付到生产中，并且为第一个正确的发布制定了固定的结束日期。如果是这种情况，那么您实际上是在没有预先进行需求分析/设计的情况下进行迭代瀑布 - 通常是一个糟糕的地方。
完整的瀑布不一定是答案(有足够的证据表明它存在问题)，但在实践中，一定量的前期规划和设计通常比新兴架构的“纯粹”敏捷精神更可取。实际上适合精益方法)。如果大型项目只是开始修改代码并希望经过一定次数的冲刺后一切都会好起来，那么它们根本无法希望实现合理稳定的架构基础。
除了上述之外，“纯”敏捷的另一个常见问题是客户期望管理。敏捷被认为是一件美妙的事情，这意味着客户可以推迟决策、改变主意并添加他们认为合适的新要求。然而，这并不意味着结束日期/预算/所需的工作量保持不变，但人们似乎总是错过这一部分。
关于agile - 放弃敏捷，转向瀑布——这样对吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3226711/