我在敏捷环境中工作，并且由于当前敏捷场景的失败（他们认为），事情已经发展到客户认为他们更喜欢瀑布的状态。让他们这样想的原因是在冲刺的最后阶段发生的大量设计级别更改，我们（开发人员）无法在他们指定的时间内完成。
像往常一样，我们都互相指责。从我们的角度来看，最后所说的更改太多，设计/代码更改太多。而从客户的角度来看，他们抱怨我们（开发人员）没有完全理解需求，并提出了“不是”他们在需求中想要的解决方案。（就像他们让我们画一只老虎，我们画了一只猫）。
所以，客户（不是我们）觉得敏捷过程是不正确的，他们想切换到瀑布模式，恕我直言，这将是灾难性的。简单的原因是他们在敏捷模式中的满意度本身还不够，那么在瀑布开发的设计阶段花费了这么多时间之后，他们将如何容忍输出呢？
请提出您的建议。
首先——问问自己你真的在做敏捷吗？如果您是，那么您应该已经向客户交付了大部分可用功能，以满足他们在早期 sprint 中的要求。从理论上讲，“损害”应该仅限于您发现需要进行较大设计更改的最后冲刺。在这种情况下，您应该已经证明了自己的交付能力，现在需要与客户进行对话以计划现在需要的更改。
但是，鉴于您的描述，我怀疑您陷入了仅以两周为周期进行开发的陷阱，而没有每次都实际投入生产，并且为第一次适当的发布考虑了固定的结束日期。如果是这种情况，那么您实际上是在没有预先进行需求分析/设计的情况下进行迭代瀑布 - 通常情况下是一个糟糕的地方。
完整的瀑布不一定是答案（有足够的证据表明它存在什么问题），但在实践中，一些前期规划和设计通常比新兴架构的“纯”敏捷精神（符合实际上是精益方法）。如果大型项目只是开始编写代码并希望在一些冲刺之后一切顺利，那么他们根本无法希望获得一个合理稳定的架构基础。
除了上述之外，“纯”敏捷的另一个常见问题是客户期望管理。敏捷是作为这种奇妙的东西出售的，这意味着客户可以推迟决策、改变主意并在他们认为合适的时候添加新的需求。然而，这并不意味着结束日期/预算/所需的努力保持不变，但人们似乎总是错过那部分。
当您有不明确的需求并且您可能需要在项目的后期阶段进行设计更改时，敏捷开发方法特别适用。在这种情况下，瀑布是不太合适的方法。瀑布方法适用于易于理解的项目，以及在项目生命周期内需求不太可能发生变化的项目。这听起来不像这里的情况。
你的冲刺有多长？另一种方法可能是减少冲刺长度 - 至少在项目开始时。更频繁地向客户交付新版本并与客户讨论更改。如果您没有按照他们的意愿行事，这将更快地显现出来，因此在实施不符合客户要求的解决方案上浪费的时间就会更少。
我不知道你经营什么样的商店，所以我很难提出好的建议。不过，我可以提供两个指导原则：
听起来您有严重的项目管理和架构/设计问题，而且您的沟通也出现了问题。从根本上说，我认为改变你的开发方法不会解决任何问题，因此是错误的做法（尽管它可能会恢复一些客户的信心）。
我会特别担心转向瀑布，因为您现在选择基本上只捕获一次需求（我们知道您有问题）而没有输入能力。这种刚性对于不灵活的交付目标是有好处的，但是在你一直在变化的地方完全不合适——这就是敏捷！
短期内我会退后一步，在这个阶段与他们仔细检查您的要求。重新协商并确认与这些相关的当前状态。
中期来看，我会与客户展开更多的沟通——试着让他们参与一段时间的每日例会（直到你恢复信心，然后你才能更灵活）。
从长远来看，你必须担心你的 PM 和高级开发人员是如何设法让你进入这个职位的。如果客户不合理，那是一回事（但仍然由 PM 来管理，所以你没有被赦免）。抱怨有太多变化是不合理的，这只是意味着您在确定需求时搞砸了（这是对话，而不是独白），或者您必须进行更多但可能更短的冲刺。
最重要的是，我看不出向瀑布移动可能是正确的。它不能直接解决任何问题，我只能看到它加剧了您已经强调的问题。
警告：我真的不能平衡地看待瀑布，因为我从未见过它有效地工作，而且恕我直言，它对于企业项目来说已经完全过时了。
敏捷开发并不能使您免于实际提出您和客户都理解的设计的负担。敏捷只是使得以较小的增量而不是一次完成设计成为可能。而且，对于难缠的客户，提出合适的设计需要时间。
所以，我会花更多的精力与客户坐下来，用白板讨论他们真正想要的是什么。在这种情况下，我认为开发过程是敏捷的还是瀑布式的并不重要。
敏捷或瀑布只是文字。只有有用的东西，也有没用的东西。对许多人来说，软件开发似乎是虚拟的，他们不明白为什么要改变他们要求的一件小事就很困难。
您的客户应该明白，构建软件就像建造房屋一样：当您建造了所有地基和墙壁时，很难更改所有房屋的最终计划和房间设计。
一些实践有助于避免此类问题：数据建模、数据字典、数据流图……目标是详细了解每个需求。将产品切割成许多独立的块有助于开始编码，同时继续设计或指定最终产品的其他部分。
有关所有有效的实践，请参阅 Steve McConnell 的书：“快速软件开发：驯服狂野的软件计划”。
让他们这样想的原因是在冲刺的最后阶段发生的大量设计级别更改，我们（开发人员）无法在他们指定的时间内完成。
Scrum 在某种程度上是一个“短瀑布”，您应该远离对 sprint 持续时间不断变化的需求。似乎这并没有发生！因此，不要看到切换到传统瀑布式会获得任何收益，但您应该坚持在 sprint 持续时间内冻结要求。也许你的迭代太长了？（我假设您遵循 Scrum，因为您提到了 sprint）。
与您的客户交谈并同意以下内容：
- Shorter iterations, up to 3 weeks max.
- No changes in requirements during the iteration.
- Features are planned at the beginning of the iteration
- Every iteration ends with deliverable: fully functional software with all features that are fully operational
- Iteration length does not change. Unfinished features are left for the next iteration (or maybe discarded if client changes his mind).
- Number of "feature points" you can deliver in a single iteration should be based on the team metric, not client insistence. This is your "capacity".
- Client decides what features (but not how many of them) are planned for the iteration
您应该问自己的另一件事是，为什么您的应用程序中有如此多的“设计级别更改”。到现在为止，您应该已经有了基本的架构和设计。也许你应该回顾一下实际的设计并尝试强加一些设计指南并实现一些模式。例如，在典型的企业 Web 应用程序中，您可能最终会使用 DAO 之类的东西。当您添加新功能时，您会创建新的 DAO，但基本架构和设计不会改变。
然而，您似乎没有提供客户想要的东西。在这种情况下，将工作产品交付给客户是最重要的，因此他可以为下一次迭代提供合理的反馈。
关于
“我们（开发人员）无法在他们指定的时间内完成。”
客户不应该是指定迭代时间范围的人。迭代长度应始终相同。进入迭代的需求应该作为客户优先级的结果而获得，但是为迭代计划的需求数量应该基于团队执行的估计以及您在迭代期间能够交付的“点”数量.
目前尚不清楚您的意思是哪种设计更改。图形设计？用户体验设计？代码设计？
无论如何，最好的解决方案是与客户进行更多、更早的讨论。共同开发满足客户要求的明确、具体的示例。您可以将这些示例转换为回归测试，以确保您继续满足它们。
此外，随着您的进展继续讨论。显示可用的输出——不要等到 sprint 接近尾声。并首先处理最有可能产生问题的部分。还要寻找更容易改变你发现经常改变的东西的方法。
关键是让客户更多地参与，甚至是设计的迭代。也许您会希望进行一些仅针对设计的讨论。
对我来说，这听起来好像敏捷项目中没有“大计划[TM]”。使用敏捷流程并不意味着没有长期计划，它更多的是要应对更远的未来越来越多的不确定性。例如，应该有一个发布计划，其中包含未来 2 个月内所有发布的计划功能（以及之后发布的功能的不太详细的计划），因此客户可以清楚地知道何时期望某个功能，何时有可能改变要求。
同样在我看来，这个过程似乎没有（足够的）客户参与。我知道这是一个非常有问题的点，但是如果可以在每次迭代结束时与客户讨论当前的进展情况，这会很有帮助。正如@Mark Byers 已经写的那样，您从客户那里获得的反馈越多，您就越好。
也尽量不要指责，因为这会让人们阻止。尝试使用检查并采用方法来获得更好的流程。
您的客户不知道如何开发软件，或如何管理软件开发过程。不要期望客户就这些问题提供有意义的指导。作为一种特殊情况，客户并不真正知道“瀑布”和“敏捷”等术语的含义；不要期望他们为您的开发方法提供有意义的输入。此外，只要在商定的预算和时间范围内满足要求，客户就不会真正关心这些细节。不要指望他们关心，也不要将他们与许多不充分的构建和与您的内部流程无关的信息混淆。
以下是客户真正关心并试图与您讨论的内容（部分使用您自己的技术术语）：他们的要求、他们失望的期望以及您与他们沟通的方式。在这些问题上，客户是绝对的权威。将他们所说的解释为关于您的关系和产品，而不是对内部流程的有用评论。不要用你的内部截止日期和流程来混淆水，讨论进展和期望以及关系。（如果他们坚持谈论内部，您可以重新映射术语：例如，他们理解为“下一个版本”的内容可能在内部被称为“下一个主要版本”，或其他）。
在我看来，客户在被要求提供反馈或使用糟糕的构建之前可能想要更高的阈值。值得验证这是否属实。如果是这样，你应该尊重这一点——如果你的团队认为这是最好的，那么仍然在内部使用敏捷方法。如果他们说“瀑布”，您可能会在内部将其解释为“我们为需求设定了最后期限，然后暂时不允许添加更多功能”。与客户讨论在要求截止日期之后进行这种冻结是否适合他们。
你团队中的某个人需要成为客户的拥护者，站在客户的问题之上并为他们而战。这个倡导者不能被边缘化，也不能站在团队一边反对客户；他们应该是代理老板。然后，您可以将内部流程沟通（团队到倡导者）与外部沟通（倡导者到客户）分开。倡导者可以在某种程度上使客户免受喋喋不休和他们不喜欢的构建的影响，而无需人为地对您的内部流程进行某种管理或调度。
澄清一下，我根本不认为您应该与客户保持秘密或疏远，但您应该（A）倾听客户对这种关系的看法以及您的沟通方式并尊重这一点，（B）保持这一点与内部开发过程分开，应该以最终满足客户期望的任何方式进行管理。
解雇客户。即使你不理解他们的意思是你的错，瀑布也会给他们 1 次机会给你反馈，而不是在每个 sprint 结束时有机会。有些人/客户真的很愚蠢，以至于不值得为他们工作。解雇他们，或者告诉他们你正在使用 Waterfall 而没有实际切换。
这里明显的问题是与客户的沟通。如果你真的想做敏捷，你必须与客户就日常基础进行沟通。只有客户才能做出决定。如果您仅在春季中期和 sprint 结束时与客户沟通，那么稍后您自然会在应用程序中发现问题。冲刺中实现的功能也必须被客户接受和测试。直到那些功能没有完成。
我写这篇文章是因为我目前的项目有类似的问题，但我知道我们失败的地方。
开发过程的远程调试非常困难，以至于我不愿就您应该做什么提出任何意见。在我看来，您团队之外的任何人似乎都无法获得足够的信息来对此做出非常有用的判断。
一个较小的结论是猜测出了什么问题。根据您的描述，您认为早期的可交付成果听起来像是银行的进步，但最终却被重做。
造成这种情况的一个常见原因是“所有”需求的发现/创建较晚，这些需求对项目范围内的所有事物都应该是真实的。如果认真对待，这些可能是非常致命的：例如，像“所有对话框都必须可调整大小”这样简单的事情显然超出了微软对 Windows 进行改造的能力。
“一旦他们看到我们编写的代码的结果，他们就会说，'哦，我们必须改变它。这不是我的意思，'”上汽的雷诺兹说。“那是我们开始在一个又一个更改请求之后记录更改请求的时候。”
例如，根据 SAIC 工程师的说法，在 8 个团队完成了大约 25% 的 VCF 之后，FBI 希望在所有屏幕上添加“page crumb”功能。这种导航设备也被称为“面包屑”，这个名称的灵感来自于 Hansel 和 Gretel 的童话故事，它为用户提供了一个 URL 列表，用于标识通过 VCF 到达当前屏幕所采用的路径。SAIC 工程师表示，这种新功能不仅增加了复杂性，而且延迟了开发，因为必须使用新功能对已完成的线程进行改造。
那里的关键词是“所有屏幕”。面对这种性质的变化，除非您有一些预先存在的工具支持，否则您可以直接打开（更改所有背景颜色真的应该是微不足道的），您就有麻烦了。你认为你已经取得的进展将追溯证明是虚幻的。
解决此类问题的唯一已知方法是在第一时间解决它们。如果那失败了，那就忍受他们错了。
如果团队和客户之间的沟通问题没有解决，如果客户只在产品完成后才看到产品（隧道效应），瀑布的情况可能会更糟。
您评论了 sprint 6-7 的更改开始导致对早期 sprint 中完成的任务进行返工。这些更改应该在 Sprint Review 期间更早地检测到。
如果功能描述中存在误解，并且团队没有实现客户的期望，则应在不迟于实现该功能的 Sprint 之前检测到这一点，并且最好在当前 Sprint 中修复。
如果客户改变主意，新的想法应该被添加到产品待办列表中，优先考虑并为 Sprint 选择，就像任何其他待办事项一样。这不应被视为返工。
您是在每个 sprint 之后将软件交付给客户，还是只是进行演示？
沟通不畅的根源可能在于 Sprint 计划：团队应该只提交明确定义的待办事项。项目的定义应包括验收标准。客户是产品负责人，还是产品负责人？
许多商店添加了敏捷装饰，以使自己对期望它的客户“看起来很敏捷”。也许您只需要添加一些瀑布装饰，然后每 2 个 sprint 向他们展示一次产品。