在 TFS 中处理未结束 sprint 的任务和用户故事的最佳方法是什么?
我的做法:
- 使用正确的原因子状态将每个任务设置为“已关闭”。我将此任务 + 原始估计 + 剩余时间复制到记事本。
- 从用户故事中删除迭代(以便它再次出现在产品待办列表中)
对于下一个冲刺:
- 将记事本中的任务作为新任务添加到 TFS,将其分配给正确的用户故事并将用户故事设置为当前 sprint。
这只是一种方法。你有更好的想法或建议吗?
如果你真的在做 Scrum,你会看到对任何团队来说唯一重要的指标就是“剩余工作量”。问题是,许多人痴迷于度量、统计、数据和对 Scrum 本质的松散跟踪。
所以保持简单。在 sprint review 中,只需与 PO 就何时完成工作达成一致,然后将未完成的任务分配给约定的 sprint。
如果您想提高一点生产力;然后创建一个未完成任务的查询,只需将迭代列值替换为下一个 sprint 并发布回 TFS。
有两种思想流派:
每个团队的任务都不同。如果您在接下来的 sprint 中再次选择故事,请更新任务迭代路径并完成。如果您不选择备份,我将删除这些任务,以便您讨论如何在您选择备份时存在的软件上下文中满足需求。将任务留在故事中超过 sprint 会给我们一种错误的安全感,即这些仍然是所有必要的事情。我宁愿重新评估我们将如何实现它。
我们做与您完全相同的事情,但不使用记事本,我们只需将任务复制到一个新任务中,然后将其分配到新的迭代中。默认情况下,复制任务链接到原始任务的所有工作项,以及原始任务本身。
旧任务保留在旧迭代中并被标记为“已关闭”。
也许我没有正确解决您的问题,但这是我的观点:撤消任务的主要思想是未完成待办事项/用户故事。因此,在冲刺之后,所有完成的 backlogitems/userstories -> 新增量。如果一个 backlogitem 没有完全准备好,那么整个 backlogitem 就不会被交付,即使它只剩下几个任务。只需将所有内容回滚(保留代码:))并完成冲刺。backlogitem/userstory 进入下一个 sprint。
在我看来,没有必要将它们标记为关闭。只需保留剩余的任务,将它们标记/标记为未完成,开始一个新的 sprint,并将具有该特定标记的所有任务应用为新的/即将到来的 sprint(如有必要,重新评估它们的时间和困难)。
这是一个非常常见的场景,我们在积压工作中有一些东西可以为此创建一个适合目的的解决方案,但我们还没有将它优先于其他工作。
如果您认为这很重要,请随时在user voice处添加建议。我们在优先级中使用该网站:这是您影响我们的机会
Ewald Hofman(TFS 产品组)