我目前是敏捷项目的产品经理，我们有 4 个开发团队，每个团队都有一名产品经理。由于 PM 之间的整合重复错误（一个故事影响另一个故事，双方直到交付时间才意识到这一点）。 我想知道贵公司的故事“拉取请求”之类的机制吗？如果有，有哪些阶段？谁参与？如果不是，您建议如何避免这些错误？
【问题讨论】：
标签： user-stories agile-processes
解决这个问题的一个好方法是争取independent 用户故事。在多团队环境中处理独立故事要简单得多。
确保每个产品只有一个待办事项也是值得的。即使您有多个团队在开发该产品，也可以这样做。只需一份待办事项，就可以更轻松地识别和标记任何依赖项。
【讨论】：
我非常同意 Barnaby Golden 的两点。
除此之外，尽量不要陷入假设业务需求的基础技术方面只影响单个团队或单个技术领域的陷阱。你不知道。很多时候技术专家自己乍一看都不知道，你怎么知道？
在我当前的任务中，邀请参加我们的改进会议（新的需求和业务用户故事被提出并与 IT 讨论）必须发送给所有团队。
通常每个团队中至少有一名专家在会议之前阅读用户故事，并与他的同事讨论他们是否需要加入优化会议或者故事是否真的不会影响他们。
如果在会议期间很明显，一个不在场的团队会受到影响，我们鼓励尝试将该团队的一名成员自发加入会议。
这样，哪些团队受需求影响的决定是由专家团队做出的。
我们还使用 Scrum of Scrum 来捕捉团队之间任何不可预见的依赖关系，正如 Barnaby Golden 所提到的。
也许可以看看 Nexus、SaFE 或更少的规模化 Scrum 原则，以获取有关如何处理多团队开发挑战的更多信息。
【讨论】：