我什么时候应该为 TFS 2010 中的任务分配迭代
我正在开发一个使用 TFS 2010 的敏捷模板的项目，并且我正在尝试决定何时应该为任务分配迭代。目前我有一堆用户故事，这些用户故事已被分配了一个迭代。然后，我为每个用户故事创建了任务并将它们链接起来。
所以，我的问题是，即使用户故事已经分配了迭代，我是否应该为任务分配迭代？对于与用户故事没有真正关联的“一般”任务，我应该怎么做？例如，我可以创建一个涉及更新控件引用或执行代码审查的任务。是否应该为这些分配迭代？是否值得管理两种类型的任务，即分配给用户故事的任务和未分配给用户故事的任务？
I am working on a project that is using the Agile template with TFS 2010 and I'm trying to decide when I should assign an Iteration to a task. At the moment I have a bunch of User Stories and these User Stories have been assigned an Iteration. I've then created Tasks for each User Story and linked them.
So, my question is should I assign an Iteration to the tasks even through the User Stories have already been assigned an Iteration? And what should I do about "general" tasks that are not really associated with a User Story? For example, I could create a task that involves updating references for controls or performing a code review. Should these be assigned an Iteration and is it worthwhile managing two types of tasks, i.e. those assigned to User Stories and those that aren't?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您的团队致力于完成这些任务时，就要设置迭代。如果在审查任务后您决定推迟一些任务，则将迭代设置为稍后的冲刺。
摘录来自 MSF for Agile Software Development v5.0：
从工作项定义指南：
关于一般任务，有专门的工作项目，例如 问题（敏捷）< /a> 和 障碍（Scrum）。
Iteration is to be set when your team is committed to work on these tasks. If after reviewing the tasks you decide to defer some, then set the iteration to a later sprint.
An excerpt from MSF for Agile Software Development v5.0 on MSDN:
And from the work item definition guide:
Regarding the general tasks, there are special work item for this such as Issue (Agile) and Impendiment (Scrum).
您绝对应该查看此资源，这是 A.Bjork 的演示它提供了一种处理您所追求的事情的方法。
我们倾向于将 UserStories 分配给未来的迭代，并且在迭代开始之前，在“计划扑克”发生时- 我们生成&将任务分配给团队。
这样做至关重要，因为 TFS 可以正确跟踪您的工作：插入“小时”的唯一工作项目是“任务”类型 - 所以这就是燃尽图的内容显示您工作效率的图表。
如果您在冲刺期间向团队成员添加另一个任务，TFS 会将其视为“计划外工作”（模拟中断！），并且会扰乱团队速度的计算。
尝试将长时间运行的任务分解为较小的任务，以适应每个冲刺。在最坏的情况下，例如，如果您有一个巨大的重构任务，您可以将多个子任务分配给每个冲刺，然后将伞任务分配给最后一次迭代 - 重构完成时。
除了从时间跟踪（仅基于任务）中，您还需要将对于冲刺很重要的所有其他工作项添加到迭代待办事项中，以便您将来能够跟踪每个问题、用户故事等的时间曾是 经过考虑的。
You should definitely check out this resource, it's a presentation by A.Bjork that presents with a way to deal with what you 're after.
We tend to assign UserStories to future Iterations, and before an iteration starts, at the time 'planning poker' takes place - we generate & assign the Tasks to the team.
Doing so is vital, for TFS to keep a proper tracking of your efforts: the only Work Item where 'hours' are inserted is the type 'Task' - so this is what feeds the Burndown charts that show how effective you work.
If you add another Task to a team-member during the sprint, that would be perceived as 'unplanned work' by TFS (simulating an interruption!) and will mess up the calculations for your Team's velocity.
Try breaking your long-running Tasks into smaller ones, that shall fit into each sprint. At worst, for example if you have a huge refactoring Task, you can make several child-Tasks assigned to each sprint and then have the umbrella-Task assigned to the last iteration - where your refactoring is completed.
Apart from time-tracking (which is solely based on Tasks) you need to also add into your iteration backlog all other work items that are important for the sprint, so you 'll be able to track in the future when each Issue, User Story etc was considered.