TFS 工作项类型：任务与场景，还是两者同时使用？
在默认的 TFS 设置中，存在三种工作项类型：场景、任务和错误。 最后一个非常简单，也是任务：这是团队成员需要完成的一项特定工作。 但我认为场景有点模糊。
我通常为更大、更通用的工作单元创建一个场景：例如“创建向雇主添加员工行的功能”。 更小、更具体的工作项目将是任务，例如：“创建详细表单”、“在服务器上创建保存方法”等。
当我签入更改时，我将更改集链接到场景和特定任务。 这是一个好习惯吗？ 您如何处理任务和场景？ 有最佳实践资源吗？
我还听说场景实际上是针对用例的，是这样吗？
In the default TFS setup there are three work item types: scenario, task and bug. That last one is quite straightforward, and task also: it's a specific job for a team member to complete. But I think scenario is a bit vague.
I usually create a scenario for larger and more general units of work: for example "Create functionality to add employee lines to an employer." Smaller, more specific work items would then be tasks, for example: "Create detail form.", "Create save method on server.", etc
When I check in changes I link the changeset to the scenario AND to the specific task. Is this a good habit? How do you deal with tasks and scenarios? Any resources to best practices?
I've also heard scenarios are actually meant for use cases, is this so?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
场景可以是任何用户故事。
您只需签入任务即可。
创建任务时，应首先将它们链接到场景，然后再分配给开发人员。
这样，签到和场景之间的关联是自动的（并且可报告）。
没有意义双重处理
Scenarios can be any user story.
You only need to check in to the task.
When tasks are created, they should be linked to a Scenario first, before assigned to developers.
That way the association between checkins and scenario is automatic (and reportable).
No point double handling
在 MSF Agile 模板中，场景也可以被认为是“用户故事" - 有点像轻量级敏捷用例。
该场景详细描述了想要实现的功能的总体情况，记录了用户与系统一部分交互的单一路径。 例如，在 Stack Overflow 中，几个场景可能是“提出问题”或“回答问题”。 场景和服务质量要求可以被视为 MSF Agile 中的顶级工作项（即定义系统的工作项），其中场景是功能性需求，服务质量是非功能性需求。
我倾向于从每个场景创建多个任务，并且通常只记录我对任务的签到。 在 TFS 2010 中，将出现适当分层的工作项目，这将使这种工作方式更容易报告。 当前工作项关联是双向的（即，您可以说任务与场景关联，但不能说它是场景的子级）。
根据任务和场景标记签入并没有什么问题，只是它在签入时为您创建了更多工作。此外，场景可能会由许多开发人员交付 - 因为任务往往会失败在个人活动的粒度上。
如果您需要将工作项与场景进行大量关联，那么以下提示可能对您有用 (http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html）。 它向您展示了如何修改标准 MSF Agile 流程模板，以删除签入解决方案的功能，而仅将签入与该工作项相关联。 解决像场景这样的长时间运行的工作项的签入几乎总是不是您想要发生的事情 - 但这是开箱即用的默认行为。
希望有帮助。
In the MSF Agile template, Scenarios can also be thought of as "User Story" - kinda like a lightweight agile use case.
The Scenario details the broad picture of the functionality that is wanted to be implemented, recording a single path of a users interaction with a part of the system. For example, in Stack Overflow a couple of Scenarios might be "Ask a Question" or "Answer a Question". Scenarios and Quality of Service Requirements can be thought of as top level work items in MSF Agile (i.e. the work items that define the system) with Scenarios being functional requirements and Quality of Service being non-functional requirements.
I tend to create multiple tasks from each scenario and typically only record my check-ins against the task. In TFS 2010 properly hierarchical work items are coming which will make this way of working easier to report on. Currently work item associations are bi-directional (i.e. you can say that a task is associated with a scenario but you cannot say that it is a child of it).
There is nothing wrong with marking your check-in against the task and scenario, just that it creates more work for you when checking in. Also, the scenario might be getting delivered by a number of developers were-as a task tends to be down at the granularity of individual person activities.
If you are doing a lot of associating of a work item to a scenario, then the following tip might be handy for you (http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html). It shows you how to modify the standard MSF Agile process template to remove the ability for check-in's to resolve the Scenario but just associate the check-in with that work item. Resolving on check-in for a long running work item like a Scenario is nearly always not what you want to happen - but is the default behavior out of the box.
Hope that helps.
如果“默认 TFS 设置”指的是“MSF for Agile Software Development”项目模板，则场景定义如下：
要获得更多信息，请仔细查看团队资源管理器中项目下的“Documents/Process Guidance”文件夹 - 它很好地解释了推荐的流程
If by "default TFS setup" you mean the "MSF for Agile Software Development" project template, then a scenario is defined as follows:
To get a bit more info on this, have a good look at the "Documents/Process Guidance" folder under the project in team explorer - it explains the recommended process fairly well
您可以将场景视为代表用户的视角，而任务则代表开发人员的视角。 根据 MSF Agile 文档，场景“代表了用户通过您正在构建的系统进行交互。”，并且任务“确定团队成员要执行的特定工作项目。”
任务可以链接到场景。 当您作为开发人员签入时，您已经解决了一项任务，而不是场景，因此您应该将变更集与该任务相关联。
You can think of scenarios as representing the users perspective, whereas tasks are the developers perspective. According to the MSF Agile documentation a scenario "represents a single path of user interaction through the system you are building.", and a task "identifies a specific item of work for a team member to perform."
Tasks can be linked to scenarios. When checking in you, as a developer, have solved a task, not the scenario, so you should relate the changeset to this task.