我目前是敏捷项目的产品经理，我们有4个开发团队，每个团队都有一名PM。由于PM之间的整合中重复出错（一个故事影响另一个故事，双方都没有实现它直到交付时间）。 我想知道一个像故事一样的机制＆＃34;拉请求＆＃34;在你的公司？如果是这样，那么阶段是什么？谁参与了？如果没有，你建议如何避免这些错误？
答案 0 :(得分：2)
解决此问题的一个好方法是争取independent用户故事。在多团队环境中，独立故事更容易处理。
同样值得确保每个产品只有一个积压。即使您有多个团队正在使用该产品，也可以这样做。只需一个待办事项就可以更容易地识别和标记任何依赖关系。
答案 1 :(得分：-1)
我非常同意Barnaby Golden的两点。
此外，尝试不要陷入陷阱，即假设业务需求的基础技术方面仅影响单个团队或单个技术领域。你不知道。通常，技术专家本人一眼不知道，所以您怎么能？
在我目前的任务中，邀请我们参加改进会议（必须与IT提出并讨论新需求和业务用户案例），必须将 发送给所有团队。
通常，每个团队中至少有一位专家会在会议之前阅读用户故事，并与他们的同事讨论是否需要参加优化会议，或者该故事真的对他们没有影响。
如果在会议期间很明显将有一个不存在的团队受到影响，则鼓励尝试自发地将该团队的一名成员加入会议。
这样，专家（即团队）将决定哪些团队受需求影响。
正如Barnaby Golden所说，我们还使用Scrum of Scrum捕获团队之间任何不可预见的依赖关系。
也许可以看看Nexus，SaFE或更少的Scrum扩展原理，以获取有关如何应对多团队开发挑战的更多信息。