在默认的 TFS 设置中，存在三种工作项类型：场景、任务和错误。最后一项非常简单，而且任务也很简单：这是团队成员要完成的特定工作。但是我觉得场景有点模糊。
我通常为更大和更一般的工作单元创建一个场景：例如“创建功能以将员工行添加到雇主”。更小、更具体的工作项将是任务，例如：“创建详细表单。”、“在服务器上创建保存方法。”等
当我签入更改时，我会将更改集链接到场景和特定任务。这是一个好习惯吗？你如何处理任务和场景？任何有关最佳做法的资源？
我还听说场景实际上是针对用例的，是这样吗？
【问题讨论】：
标签： tfs task-tracking
场景可以是任何用户故事。
您只需要签到任务。 创建任务时，应先将它们链接到场景，然后再分配给开发人员。
这样，签入和场景之间的关联是自动的（并且可报告）。
没有意义的双重处理
【讨论】：
在 MSF 敏捷模板中，场景也可以被认为是“User Story”——有点像轻量级敏捷用例。
场景详细描述了想要实现的功能，记录了用户与系统一部分交互的单一路径。例如，在 Stack Overflow 中，有几个场景可能是“提出问题”或“回答问题”。场景和服务质量要求可以被认为是 MSF Agile 中的顶级工作项（即定义系统的工作项），其中场景是功能性需求，而服务质量是非功能性需求。
我倾向于从每个场景创建多个任务，并且通常只记录我对任务的签到。在 TFS 2010 中，将出现适当分层的工作项，这将使这种工作方式更容易报告。当前工作项关联是双向的（即，您可以说任务与场景相关联，但不能说它是场景的子项）。
根据任务和场景标记您的签到并没有错，只是它在签到时为您创造了更多的工作。此外，该场景可能由许多开发人员交付 - 因为任务往往细化个人活动。
如果您将工作项与场景关联很多，那么以下提示可能对您很方便 (http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html)。它向您展示了如何修改标准的 MSF Agile 过程模板，以消除签入解决方案的能力，而只是将签入与该工作项相关联。为像场景这样的长期运行的工作项解决签入问题几乎总是不是您想要发生的事情，而是开箱即用的默认行为。
希望对您有所帮助。
【讨论】：
如果“默认 TFS 设置”是指“MSF for Agile Software Development”项目模板，那么场景定义如下：
场景是一种工作项， 记录用户的单个路径 通过系统交互。作为 角色试图达到一个目标， 场景记录具体步骤 他们将尝试 达到那个目标。有些场景会 记录成功路径；其他人会 记录一个不成功的。什么时候 写作场景，具体为 有很多可能的路径。
要获得更多信息，请仔细查看团队资源管理器中项目下的“文档/流程指南”文件夹 - 它很好地解释了推荐的流程
【讨论】：
您可以将场景视为代表用户的视角，而任务则是代表开发人员的视角。根据MSF Agile documentation，场景“表示通过您正在构建的系统进行用户交互的单一路径。”，任务“确定团队成员要执行的特定工作项。”
任务可以链接到场景。在签入时，作为开发人员，您已经解决了一项任务，而不是场景，因此您应该将变更集与此任务相关联。
【讨论】：