5

在默认的 TFS 设置中，存在三种工作项类型：方案、任务和错误。最后一个非常简单，而且任务也很简单：这是团队成员要完成的特定工作。但我认为场景有点模糊。

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

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

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

4

4 回答 4

11

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

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

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

无意义双重处理

于 2009-02-03T10:07:47.233 回答
3

在 MSF 敏捷模板中，场景也可以被认为是“用户故事”——有点像轻量级敏捷用例。

场景详细描述了想要实现的功能的大致情况，记录了用户与系统部分交互的单一路径。例如，在 Stack Overflow 中，有几个场景可能是“提出问题”或“回答问题”。场景和服务质量需求可以被认为是 MSF Agile 中的顶级工作项（即定义系统的工作项），其中场景是功能性需求，而服务质量是非功能性需求。

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

根据任务和场景标记您的签入并没有错，只是它在签入时为您创建了更多工作。此外，该场景可能由许多开发人员交付 - 因为任务往往会失败在个人活动的粒度上。

如果您正在将工作项与场景关联很多，那么以下提示可能对您很方便 ( http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html )。它向您展示了如何修改标准 MSF Agile 过程模板，以消除签入解决方案的能力，而只是将签入与该工作项相关联。为像场景这样的长期运行的工作项解决签入问题几乎总是不是您想要发生的——而是开箱即用的默认行为。

希望有帮助。

于 2009-02-03T10:08:53.160 回答
2

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

场景是一种工作项，记录用户通过系统交互的单一路径。当角色试图达到一个目标时，场景会记录他们在尝试达到那个目标时将采取的具体步骤。有些场景会记录成功的路径；其他人将记录一个不成功的。编写场景时，请具体说明，因为有许多可能的路径。

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

于 2009-02-03T10:05:06.567 回答
2

您可以将场景视为代表用户的视角，而任务则是开发人员的视角。根据MSF Agile 文档，场景“表示通过您正在构建的系统进行的用户交互的单一路径。”，任务“识别团队成员要执行的特定工作项”。

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

于 2009-02-03T10:08:03.050 回答