Organizing Projects into Products or Customers or Releases?
Hi!
We're trying to figure out how to best organize our VSTS projects.
We have 5 different product all sharing the same core. We have core releases every 3 month, and a product release about every 6 month.The core is developed together with the product, so before the start of a new core release, the "core" functionality from all released product are merged into the Core. In addition a product are usually sold together with some customitation. This is done through developing some "add-on" modules to the product.
So these are the different approches we are thinking of:
- One project per product. One project for the Core. One project for each add-on module
- One project per customer
- Only one project for the entire company.
- One projects per release
Each approche has some advantages we would like to have:
- Approch 1
- Advantages: We would like the common entrypoint for each product. The "Product portal" is important.
- Disadvbantages: How to share information between the core and each application? Bugs reported in a product may be valid for all product using the core. Many small projects for some of the simpler add-ons
- Approch 2
- Advantages: Easy entrypoint for each customer.
- Disadvantages: The product is present in many projects.
- Approach 3
- Advantages: Simple entrypoint to info
- Disadvantages: Huge set of info - how to seperate everything
- Approach 4
- Advantages: Easy entrypoint for a developer -
- Disadvantages: Many projects - how to handle info across projects
The list of advantages/disadvantages could obviously be much longer, but this is what we've figured out so far. We would really appreciate any help or advaise on this.
(Maybe we're over-estimating the value of getting this right, but please let us know.)
Regards
Lars Erik
[2054 byte] By [
Larsi] at [2007-12-20]
I always recommend keeping things in one team project unless you have a specific reason why that won't work. Separating work items with Areas & Iterations, source control with branches, documents with Sharepoint sub-sites, etc. is usually no problem.
A great question! Based on what you’ve described, my recommendation would
be:
- One project for each release (core and product)
- One project for each customization
My reasons for this recommendation is that a project, is by definition, temporary. It has a beginning and an end and once the goals of the project have been completed, then the project should be closed down.
With each new project, you can decide to change work item type definitions, reports, queries, process guidance … all based on what you learned from past projects.
Creating a VSTS project for each real project, also allows teams to try out new ideas for a thatproject, without affecting reporting on past projects or other concurrent projects. Then you can compare how projects went and make incremental improvements over time.
I like the reasoning behind this. However, how do you handle the enhancement requests and tasks that may have been put off until a future version? Do you recreate them all from the previous project? Is there a way to migrate the work items from one project to the other? Our current product, currently on version 8, has over 200 enhancement requests that are all valid it's just a matter of cost justification and timing. I can't imagine having to migrate those from one project to another. Would you keep those in another app like ClearQuest instead of TFS?
Another great question. Unfortunately, in the V1 product, there is no built-in way to migrate a bunch of items from one project to another. If you want to do this, you have the following options:
1) Import the items from the old project into an Excel spreadsheet. Open another Excel spreadsheet which a list attached to the new project. Paste the items from "old" Excel spreadsheet to the "new" Excel spreadsheet. Publish the items to the new project. This however, does not copy any of the history or links/attachments.
2) You can copy them one work item at a time, using "Copy Work Item..."
3) YOu can use the object model to do it. See this forum post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=286833&SiteID=1
We are looking to add this functionality in the next release.
Another option is to just store all your enhancements in a separate project, then allocate them to specific releases by either copying only the ones allocated for a release(project), or using something like "Area Path"
Hope this helps.
