是否应该将待办事项分配给scrum主？

Question

我正在和工作中的人辩论，认为我知道答案，但我想听听别人怎么想。如果有的话，这将证实我是对的，或者给我一个更好的方法来接近我正在做的事情。

在这种情况下，我扮演Scrum作为项目业务分析师的角色。我认为，积压中的项目不应分配给特定用户。我也认为，当我整理或审核时，不应分配给我的物品，包括确定要求或验收标准。

我试图避免不断地处理大量不可操作的项目列表，这就是在将待办事项分配给我时所发生的情况。我应该能够专注于积压的项目，我正在整理或审查。此外，我也是一名开发人员，所以如果我能够看到我正在管理的项目的清晰列表，而不是将不包括在当前sprint中的项分配给我，这会有所帮助。

你认为如何？

谢谢!

Answer 1

在敏捷开发中，做任何有用的事情。找出障碍并消除它们--如果分配的项目妨碍了你的工作效率，那么就找出一些解决办法。

如果您正在尝试实现Scrum过程，那么Scrum得到项目分配听起来更奇怪：

• Scrum只是一个注意Scrum过程被遵循的角色。这个角色甚至可以通过团队成员进行轮换。角色只关心你如何做事，而不关心你做什么。
• 物品没有分配。产品负责人优先考虑，团队交付。Scrum并不直接参与积压整理或任务分配，他们只是协助PO和团队最有效地完成他们的职责。
• 然而，Scrum关注的是为待办事项管理找到合适的技术。
• 理想情况下，团队如何管理任务是一个内部问题。在实践中，任务分配给个人是不可避免的，但我认为这是非常不敏捷的。

听起来，Scrum过程并不是真正的问题，不管您是否试图遵循它。这听起来更像是在使用某种问题管理系统，这种系统阻碍了您的工作，并且正在强制执行奇怪的流程，或者是以与团队试图使用的流程相反的方式使用的。

• 该系统和使用该系统的人员是否可以改变，使问题可以不被分配？
• 如果没有，是否可以为Scrum角色建立一个单独的帐户？
• 或者系统可以提供标签或队列来区分待办事项和开发任务？
• 您的系统是否适合跟踪未定义的待办事项？物理表示法，如手写卡片，可以非常好地工作。

Answer 2

确定工作流修复的问题。如果你的问题是你的团队有囤积者，他们不相信别人会拿出他们最喜欢的票，并做好适当的工作，那么你的方法可能是一个很好的选择。

另一方面，如果开发人员不知道从待办事项中提取什么，或者很难让他们为整理工作添加技术细节，那么在他们投入到冲刺工作之前负责门票可能会更好。

如果这是一种修复您自己的工作流的方法，那么您是否可以使用更好的筛选器或工具？