TFS work item types: tasks vs. scenarios, or use b

问题:

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?

回答1:

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

回答2:

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.

回答3:

If by "default TFS setup" you mean the "MSF for Agile Software Development" project template, then a scenario is defined as follows:

A scenario is a type of work item, recording a single path of user interaction through the system. As the persona attempts to reach a goal, the scenario records the specific steps that they will take in attempting to reach that goal. Some scenarios will record a successful path; others will record an unsuccessful one. When writing scenarios, be specific as there are many possible paths.

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

回答4:

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.