开发人员成为多个scrums的一部分有什么问题？

Question

我作为开发人员在2个scrums工作，很难做任何事情 - 我想问其他人是否有同样的问题以及他们做了什么来管理他们的工作？

它似乎不是一种敏捷的工作方式。

Answer 1

问题是承诺之一。作为一个团队，您在sprint计划会议上与同行一起承诺，每天每次scrum都将共同完成。如果你有另一个团队，那自然会破坏这一承诺，它也会使你的WIP膨胀并导致任务切换以及两个团队的仪式的额外开销。

为什么你们两队都参加？通常的答案是：领域知识，技能组合，因为我们只有一个QA（在那里插入任何学科），资金/分配等。

我从根本上相信，在你以一种可以为你的队友服务的方式组建你的团队之前，你的团队将不会拥有一支可靠的，可预测的团队。

Answer 2

将您的情况作为impediment报告给scrum主人，并且只承诺您认为可以实现的工作，直到这个障碍得到解决（由scrum master（s））。对于谁承诺完成大部分工作而不是实现它，并不是一场竞赛。

Answer 3

我认为这是一个纪律问题。如果你关注你需要有scrum纪律。当您是共享资源时，会出现转换成本和生产力损失。如果您仍想遵循此规则，则需要采取措施降低转换成本并提高生产率。

您可以定义的日期是您要去工作的日期。例如：前三天您在一个项目中，接下来两天您在其他项目中。如果您这样定义，那么您可以计划工作以提高生产率并降低转换成本。

另一件事是减少站立和冲刺计划的参与时间。确保优先考虑您的区域并进行讨论，然后离开这些仪式而不是参加整个会议。这是scrum master计划的责任。

Answer 4

可以在多个团队中工作，但每个团队都需要体谅并接受他们只能获得50％（或者不到）的时间。

在计划时，不要过度提交，看一下你可以在sprint中大致达到的故事点数，并且只承担每个团队总数的50％。

尝试将时间分配到早上的A队工作和下午的B队。然后，每个团队都会知道您何时可以使用，并且应该尝试（除非紧急）在您不工作时不要打扰您。

有专门的计划，站立时间，并试图让团队坚持这些，这样你就不会被双重预订。

每个团队的scrum master（或任何当选人）也可以考虑让他们聚在一起scrum scrum，并以与普通scrum相同的方式快速讨论事情的进展情况，以便他们了解你的压力是什么下。

但是你管理这个问题，由于诸如规划，站立，敏捷引入的回顾之类的承诺，你将比在一个团队中完成更少的实际工作。