Are we using TFS 2010 incorrectly? [closed]

Answer 1

First off, welcome to the world of TFS. :)

There is nothing wrong with how you wish to work. The hierarchy you outlined is fine, and TFS will support any set of Work Item Types (WITs) and relationships (links) you require them to have. The Implementation tab, and all other tabs that show relationships with other WITs are merely filters to the entire list of WITs your type is related to (i.e. the Requirement's Implementation tab shows all work items that are of type Requirement or Task, and have a parent/child relationship).

What follows, is that you should think what artifacts (WITs) your process requires, and how they should work together, and customize your process template to work as you want it to.

This is relatively simple to do, especially when you use the process editor that is part of the Team Foundation Power Tools. If you want to modify the link pages, it is all done in the layout part of the work item type.

Regarding the question of the relationship between requirements and tasks: I always view requirements as the definition of what the user / customer needs. The requirement should be more outward facing, describing the need, the goal and the desired effects (and side effects). The tasks are more inward facing, and should tell the developer how he (or she) should go about achieving the above goals.

With that in mind, I always prefer to have a developer work only on tasks. Moreover tasks should always derive from a requirement (or a bug, or a change request, and so on). A task that doesn't come up as the result of a requirement might indicate that the work is either unnecessary or poorly planned.

Hope this helps, Assaf.

Answer 2

It sounds like you need to customize the out of the box process template that comes with TFS.

To be honest I think everyone should customize the templates to make sure they get the tools to fit their process, not change their process to fit the tools.

I'm not sure if you're aware of some of the customization options that are available so I'll just mention some of the ones I've used when customizing TFS for my company.

You can edit any work item type that comes out of the box in the process template. There are lots of customizations you can perform, for example, in my company we only wanted people in the test group to be able to close bugs, so we put that constraint on all transitions to the closed state.

You can add transitions, states, fields, tabs etc. as required.

If you want a new work item you can create a new one from blank or base one on an existing work item type, to create a new one from an existing type, export the work item type, edit the xml to change the name to your new type and then import it.

The concerns you have about relationship between the different work item types should be addressed by creating custom link types and then including them in your new template.

It seems like you have a good sense of the process you want to follow, I think you need to customize TFS to match that process.

The one drawback about performing this much customization is that the standard reports won't provide you with much useful info. This will require your team to write some new reports. You can also do some nice reporting in excel if that would meet your needs.

HTH

Answer 3

I think you going to have to go with a customized approach here. Pick the reports and metrics that are important to you as your requirements for TFS. From there, design the linkage between work items in a way that gets you your reports and metrics. Also, you probably already know this, but the Task WI does have a discipline field that allows it to be used for more than just development. Good luck!