We have just started playing around with TS, and I have some questions around best practices for Bug and requirement tracking in our environment.
We add functionality to our product on a project by project basis, but there may be defects or requirement requests that do not get completed in a praticular project. What is the best way to track these. Can I move them from project to project May be an example will make it easier to understand.
Our product is named widget. We will have a project to add features, and basically create widget 2.0. After the Widget 2.0 project I will have a widget 3.0 project. We will generate bugs and requirements while doing the 2.0 project. Once the project is complete, we will get filed bugs and issues on 2.0 as well. We will start 3.0 with outstanding bugs and feature requests from 2.0. To make it somewhat even more complicated, we will have a widget 2.0 for customer a, and a widget 2.0 for customer b. The core product will be widget 2.0, but there will be customer specific features for company a, and for company b. There will be a widget 2.0, comapny a project, and a widget 2.0 company b project. Later there will be a widget 3.0 company a project, and a widget 3.0 company b project.
What I am trying to figure out is the best way to set these up in team system. If I set up a new project for each instance, how do I persist the bugs and requirements not addressed Would it make more sense to set up a widget core project, and a company a, company b project, and then have the later versions as new areas
Anyone have any thoughts on this
Thanks!
Paul
Defect Tracking across projects
daniel kurtz
What I would suggest is to have only one team project.
I think that you should only create a project per product. Because you want to track the whole lifecycle of the product and not only one version.
Working with different versions should then be solved by picking the right branching and merging strategy. I would use the areas and iterations to define the different features and the different iterations you are going to implement them.
I would use the branch by purpose model and create a branch after you shiped to a specific customer. The you can keep that brach to maintain that specific version an even use merge between the different brances to reverse or forward integrate additional fixes or features to other branches.
You can then move the workitems to a later iteration (or release if you want) and work with the same items.
If you do want a project per version, the only way to keep the item is to copy it from one project to the other and reschedule it there.
You only should start a new project if you need to manage it as a different project. If not keep the same project and make sure to implement a correct configuration management plan within TFS version control.
Hope this helps,
Marcel