这里的聚会有点晚了，但这是我根据你写的内容的看法。
现在，Scrum 是一种项目管理方法，而不是一种开发方法。但在我看来，关键是要有适当的开发流程。没有一个，您将大部分时间花在反应而不是构建上。
我是一个测试优先的人。在我的开发过程中，我首先构建测试来执行需求和设计决策。你的团队是如何执行这些的？我在这里要说明的一点是，您根本不能“把东西扔到栅栏上”并期望除了失败之外的任何事情。这种失败要么是由测试团队（由于没有很好地测试，因此让问题溜走），要么是由开发人员（由于没有构建解决问题的产品）。我并不是说你必须先编写测试——我不是激进分子或测试优先的布道者——但我是说你必须有一个流程来生成高质量、经过测试、准备好生产的代码，当你达到迭代的结束。
在我称之为死亡螺旋方法的开发方法中，我一直是正确的。多年来，我以这种模式为政府（美国）开发了软件。它不能很好地工作，它要花很多钱，它会产生迟到的代码，糟糕的代码，并且对士气没有任何帮助。当您将所有时间都花在修复本来可以避免的错误上时，您将无法取得任何进展。我完全被这件事打败了。
您不希望 QA 发现您的问题。你真的想让他们失业。我的目标是让 QA 大吃一惊，因为一切正常。诚然，这是一个目标。在实践中，他们会找到东西。我不是超人。我犯错了。
回到调度...
在我目前的工作中，我们做 Scrum，我们只是不这么称呼它。我们在这里不喜欢标签，但我们喜欢按时生产高质量的代码。每个人都在船上。我们告诉 QA 我们将准备测试什么以及何时测试。如果他们提前两周来敲门，他们可以和手说话。每个人都知道时间表，每个人都知道发布中的内容，每个人都知道产品必须按照宣传的方式工作，然后才能进入 QA。那是什么意思？你告诉 QA “不要费心测试 XYZ - 它已经坏了，直到发布 C 版才会修复”，如果他们去测试，你把他们指向那个声明并告诉他们不要浪费你的时间。苛刻，也许，但有时是必要的。我不是要粗鲁，但每个人都需要知道“规则”
您的管理层必须参与其中。如果他们不是，你就会遇到麻烦。QA 无法运行该节目，开发组也无法完全运行它。所有的组（即使这些组每个组只有一个人或一个戴多个帽子的人）都需要在同一页面上：客户、测试团队、开发人员、管理层和其他任何人。通常，超过一半的战斗是沟通。
也许你在 sprint 中的努力超出了你所能完成的范围。情况可能就是这样。你为什么这样做？满足时间表？如果是这样，那就是管理层需要介入并解决问题的地方。如果您要提供 QA 错误代码，请期望他们将其扔回去。最好给他们 3 件有用的东西，而不是 8 件未完成的东西。目标是产生一些在每次迭代中完全实现的功能，而不是把一堆半途而废的东西放在一起。
我希望收到它的本意——作为鼓励而不是咆哮。就像我提到的那样，我一直在你所在的地方，这并不有趣。但有希望。你可以在一个 sprint 中扭转局面，也许两个。也许您不会在下一个 sprint 中添加任何新功能，而只是修复损坏的部分。你必须作为一个团队来决定。
编写测试代码的另一个小插件：自从采用了“先编写测试”的方法后，我发现自己对我的产品更加放松和自信了。当我所有的测试都通过时，我就有了一种没有它们就无法拥有的自信。
祝你好运！