我们的团队处于一个令人烦恼的境地：我们的公司正处于转型期，在两家理念截然不同的公司合并后，该转型期可能还要持续 3 到 6 个月。转型正朝着正确的方向前进（被收购的公司被收购是因为他们有能力很好地管理事物的技术方面），但进展缓慢且崎岖不平。

由于政治、重组和混乱，我们的 PM 在我们开始开发迭代之前无法为我们获得好的规格，但我们不能停下来。开发人员能够做到，但如果没有清楚地了解要使用的产品，我就无法共同开发自动化测试。现在基本的东西，比如测试和业务所有者之间的频繁通信不存在，并且在编码完成之前设计是不固定的。作为测试人员，我一直在争先恐后地收集需求 - 通常来自开发人员 - 并更改和重新更改我的固定装置 - 但它只是不起作用。由于我忙于响应基本的设计变更，我没有时间获得太多的测试覆盖率，也无法完成我的测试计划。

我们正在考虑在接下来的 3 到 4 个月内启动一个两次迭代的 scrum-fall 模型，其中测试/调试工作落后于设计和开发工作一次迭代。开发人员将设计和开发当前的工作迭代，而我为最后一次迭代编写夹具，然后我将测试他们的最后一次迭代，他们将修复这些错误。这个想法是这将持续几个月，然后我们应该有好的设计文档可用。

我已经考虑过的事情：“追赶”迭代，我正在测试上一次迭代和当前一次以转移到正确的 Scrum，不会成为问题；我将停止迭代测试工具的开发，因为这通常需要我大约 50% 的时间。我们没有最后期限的压力；这是一个大型、耗时的项目，我们可能还需要 5 个月的时间才能投入生产（尽管移动截止日期/资源承诺是目前混乱的一部分）。我相信我的 PM 会努力让我们回到正常冲刺的地步；我不认为由于懒惰而暂时转向 scrum-fall 最终会成为永久性的。

TL;DR：由于无法在 sprint 早期获得良好的规范和业务需求，我们将尝试让测试落后于开发一个 sprint。

问题：有人去过那里，做过吗？我应该注意哪些陷阱，我可以做些什么来帮助这个“scrum-fall”系统更顺畅地工作？我可以做些什么来帮助更快地恢复正常的 Scrum（为更好的文档和沟通铺平道路）？