TFS工作项类型：任务与方案，还是同时使用两者？

Question

在默认的TFS设置中，有三种工作项类型：场景，任务和错误。最后一个是非常简单的，任务也是：这是团队成员完成的具体工作。但我认为情况有点模糊。

我通常会为更大和更一般的工作单元创建一个场景：例如“创建将员工行添加到雇主的功能”。然后，更小，更具体的工作项将成为任务，例如：“创建详细信息表单。”，“在服务器上创建保存方法”等等

当我签入更改时，我将变更集链接到方案和特定任务。这是一个好习惯吗？你如何处理任务和场景？最佳实践的任何资源？

我也听说场景实际上是针对用例的，是这样吗？

Answer 1

场景可以是任何用户故事。

您只需签入任务即可。 创建任务时，应先将它们链接到方案，然后再分配给开发人员。

这样，签到和场景之间的关联是自动的（并且可报告）。

无点双重处理

Answer 2

在MSF Agile模板中，Scenarios也可以被认为是“User Story” - 有点像一个轻量级的敏捷用例。

该方案详细介绍了希望实现的功能的广泛图景，记录了用户与系统的一部分进行交互的单一路径。例如，在Stack Overflow中，一些场景可能是“提出问题”或“回答问题”。场景和服务质量要求可以被视为MSF Agile中的顶级工作项（即定义系统的工作项），其中场景是功能要求，服务质量是非功能性要求。

我倾向于从每个场景创建多个任务，通常只记录我对任务的签到。在TFS 2010中，正确的分层工作项目即将到来，这将使这种工作方式更容易报告。目前工作项关联是双向的（即，您可以说任务与场景相关联，但您不能说它是它的子项）。

在任务和场景中标记您的签到没有任何问题，只是在签入时它会为您创建更多的工作。此外，许多开发人员可能会提供这样的场景 - 作为一项任务趋势在个人活动的粒度上下降。

如果您正在将一个工作项与场景进行大量关联，那么以下提示可能对您很方便（http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html）。它向您展示了如何修改标准MSF Agile流程模板以删除签入功能以解决方案，但只是将签入与该工作项相关联。解决像Scenario这样的长时间运行的工作项的签入几乎总是不是你想要发生的 - 但它是开箱即用的默认行为。

希望有所帮助。

Answer 3

如果通过“默认TFS设置”表示“MSF for Agile Software Development”项目模板，则场景定义如下：

  

场景是一种工作项，   记录用户的单一路径   通过系统进行交互。作为   角色试图达到一个目标，   场景记录了具体步骤   他们会考虑尝试   实现这一目标。有些情况会   记录成功的道路;其他人会   记录不成功的一个。什么时候   写作场景，具体为   有很多可能的途径。

要获得更多信息，请仔细查看团队资源管理器项目下的“文档/流程指南”文件夹 - 它可以很好地解释推荐的流程

Answer 4

您可以将场景视为代表用户视角，而任务则是开发人员的视角。根据{{​​3}}方案“代表通过您正在构建的系统进行用户交互的单一路径。”，并且任务“标识团队成员要执行的特定工作项。”

任务可以链接到方案。在作为开发人员签入时，您已经解决了任务而不是场景，因此您应该将变更集与此任务联系起来。