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