这些都是阶段性的，放宽心。认真做好自己，别人甩锅过来，接就好了，解决掉能力范围内的问题，尝试解决能力范围外的问题，解决不了，及时抛给领导，领导不接再抛回去。正所谓，不在其位，不谋其政。心累还是考虑了不是自己范畴的事，再说目前的境况又不是你造成的，我们说应该怎么或怎么怎么，喊你去改规则也不合适，都比不上你的自我调节。调节好了，就不心累了。。

我公司现在碰到的情况和你类似。
如果业务不独立有耦合的话，这么搞问题很多，但是上头领导发话了，也只能尽力去协调配合。最终的结果就是突出一个心累、效果差。
主要问题就是出现在跨小组配合下。随便举几个例子：开发被其他小组借用，因为之前是他负责的这块，导致定好的内容延期；测试内容跨小组时，对测试的压力非常大，经常有漏测的情况出现；基础服务、刷数等内容，经常某个小组处理了，另一个小组没处理导致 BUG 甚至阻塞测试进度。
还有很多吧，就不一一细数了。
我非常不推荐在业务不独立的情况下搞敏捷小组，效率没有提升，反倒将信息封闭成了一个个孤岛。

都一样，但是我们测试的 leader 还不放权，各种插手各个敏捷小组的测试，相当于测试不仅要做敏捷小组的工作，还要做这个测试 leader 安排的工作，导致大家怨声载道，像敏捷教练投诉吧，敏捷教练也没有办法，因为测试 leader 是老板心腹

噢 最近我们也在转型 你说的各自玩各自的解决 我这边是统一出一个基层的敏捷流程规范 然后各条业务线遵循这个最小化规范去执行 可以在一定的范围内定制 同时测试还是属于一个大的团队 划分业务线去进行支援协调

业务没划分好吧。。。正常来说独立的业务相互甩锅可能性不大

之前我们老大说，每个测试人员应该有自己主要负责的项目或者自己主要负责的测试类型（比如专项测试、性能测试、接口测试等），这样工作干起来才有意思。后面我才 get 到这实际是在培养测试人员的 owner 意识。但是这并不代表其它的项目或者其它的模块或者其它的测试类型你就不需要关注了。其它项目或者其它模块可以通过交叉测试或者团队 bug 大扫除的形式去保障测试工作的完整性。这样测试很好，那样测试也不差，我觉得可以集百家之长，把项目干好，而不是相互扯皮推诿。