我应该何时在TFS 2010中为任务分配迭代

Question

我正在开发一个在TFS 2010中使用Agile模板的项目，我正在尝试决定何时应该为任务分配迭代。目前我有一堆用户故事，这些用户故事已经分配了一个迭代。然后，我为每个用户故事创建了任务并将它们链接起来。

所以，我的问题是，即使已经为用户故事分配了迭代，我是否应该为任务分配迭代？我应该怎么做与用户故事没有真正关联的“一般”任务？例如，我可以创建一个涉及更新控件引用或执行代码审查的任务。是否应该为它们分配迭代，是否值得管理两种类型的任务，即分配给用户故事的那些任务和那些不分配的任务？

Answer 1

当您的团队致力于完成这些任务时，将设置迭代。如果在审核了您决定推迟某些任务的任务后，请将迭代设置为稍后的sprint。

来自MSDN上excerpt的MSF for Agile Software Development v5.0：

  

您可以将区域和迭代字段分配给大多数工作项   在Microsoft Solutions Framework（MSF）的流程模板上。您   在创建时指定区域和迭代字段的值   工作项目或在审查产品或迭代积压期间。如果   您将工作项推迟到以后的时间，您应该更改其迭代   相应

从工作项定义guide：

  

在“区域和迭代”列表中，单击相应的区域和   迭代，或将这些字段留空以便在以后分配   计划会议。

关于一般任务，有一些特殊的工作项，例如Issue (Agile)和Impendiment (Scrum)。

Answer 2

你绝对应该查看this资源，它是A.Bjork的一个演示文稿，介绍了一种处理你所追求的内容的方法。

我们倾向于将UserStories分配给未来的迭代，在迭代开始之前，在“计划扑克”发生的时候 - 我们生成＆amp;将任务分配给团队。
这样做至关重要，因为TFS要正确跟踪您的工作：插入“小时”的唯一工作项是“任务”类型 - 所以这就是Burndown图表显示您的工作效率。

如果你在冲刺期间向团队成员添加另一个任务，那将被TFS视为“计划外工作”（模拟中断！）并且会破坏团队速度的计算。

尝试将长期运行的任务分解为较小的任务，这些任务应适合每个冲刺。在最坏的情况下，例如，如果您有一个巨大的重构任务，您可以为每个sprint分配几个子任务，然后将伞 - 任务分配给最后一次迭代 - 您的重构完成。

除了时间跟踪（完全基于任务），您还需要在迭代中添加所有其他对sprint重要的工作项，这样您将来可以跟踪每个问题，用户故事等被考虑。