如果一个故事正在进行中，然后泳道已经准备好进行代码审查和 QA，那么故事的分配应该如何工作？故事是否应该继续分配给开发人员？代码审查和 QA 任务是否应该被创建为其中的子任务？或者当故事被开发人员转移到代码审查时，它应该被重新分配，当代码审查完成时，它被审查员转移到 QA 通道，并由审查员重新分配给 QA。将正在进行的票证重新分配给未来的状态似乎是反模式。在进入 sprint 之前重新分配票证看起来可以，但之后不行。
【问题讨论】：
标签： scrum user-stories
Scrum 对工作的完成方式和董事会的管理方式没有任何意见。然而，许多团队通过看板的“拉动”方法来回答这个问题。在这种情况下，工作永远不会被分配或给予，它只是被要求/承担。因此，当审阅者开始工作时，工作将被移至“代码审查”。同样，测试人员在开始时会将工作转移到 QA。 “就绪”列有点用词不当，因为它们不是状态。相反，它们是先前状态的状态。如果您的订单是 Code Review - QA Ready - QA，那么事实上，QA ready 是 Code Review 工作的一个可能名称。这似乎微不足道，但防止在没有所有者的情况下工作停滞的过程中发生堆积是非常重要的。
【讨论】：
没有单一的答案，但一种方法是将用户故事视为任务的容器，其中每个任务都是任何类型的小型技术交付物。有了这种心态，您就可以有效地停止思考受让人是谁，因为每个开发人员都会对目标做出自己的小贡献。
任务重新分配的一个问题是，在某一时刻，您可能会失去对每个开发人员所做的工作和工作效率的跟踪。因此，从这个意义上说，让每个团队成员完成自己的任务并完成用户故事可以解决这个问题。
然后，您可以将用户故事分配给产品所有者，或者您可以将其分配给拥有交付所有权的开发人员，以测试测试人员何时接管。但是，当分配给开发人员时，用户故事并不意味着他拥有用户故事，这只是意味着他有责任确保移交测试不多不少。
当测试人员遇到错误时，您会创建一个附加到用户故事的错误。
【讨论】：
不推荐。这是可行的。你必须评估你目前的工作情况。如果用户故事可以产生完全不同的影响，那么最好停止冲刺，重新评估您的情况并进行必要的更改 - 然后继续。无论哪种方式，当您在待办事项中添加新的用户故事时，都很难满足最后期限。
【讨论】：
我们使用了一些不同的方法。就像我们在 Jira Board 上有以下专栏一样。
开发人员从待办事项中选择一项任务并将其分配给他自己并使其保持在进行中。完成后，他将其移至 Ready for Review 并保持未分配。有人会挑选它并将其分配给自己并进行审查。在审查之后，该人会将案例转移到为 QA 做好准备，而无需将其分配给任何人。任何有空或愿意处理案例的人都会将该案例分配给他自己，当他开始处理该案例时，他会将其移至测试中。作为测试的结果，案例可以进入返工/拒绝或完成。如果它移至返工/拒绝，他会将其分配给最初从事此工作的原始人。而那个人在对其进行返工时，会将案件再次转移到进行中。
【讨论】：