Welcome to Manicprogrammer Sign in | Join | Help

Jason Barile on Team Project Granularity

Rob Caron just pointed on a post by Jason Barile about Team Project Granularity. This subject is a common issue and one that we had here in the company I work for.

Should we use Team Projects by Customer? Or by Product? Or by Product Family? We ended with the customer solution, since we almost always end up with 1 product by customer (save one exception).

Jason Barile is out visiting customers this week. In his first post from the road, he blogs about team project granularity, which is a frequent topic of discussion on blogs, in the forums, at conferences, and elsewhere. 

Confusion around the proper granularity of Team Projects is not uncommon, especially given the re-use of the word "project" in the name.  So here is some quick guidance and a link to more information that might help you think through your Team Project layout.

From: Team Project granularity

Working on the team that provides documentation and other content for Team System, it was nice to see that Jason also linked to the guidance we provided on the subject:

Check out the MSDN guide, Planning a Team Project for more assistance in making decisions around Team Project usage.  When you've finished that, read through the guides on configuring and customizing Team Projects to further meet your needs.

From: Team Project granularity

Technorati Tags: - - - - - - - -

Published Tuesday, August 22, 2006 4:00 PM by heynemann

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Jason Barile on Team Project Granularity

Tuesday, August 22, 2006 6:32 PM by Jason Barile
Without knowing any more about your applications, this sounds like a very reasonable approach.  If your applications are partitioned by customer, then one Team Project per customer probably works fine.  If you have LOTS of different customers (e.g. over 200) though, you might consider an app-centric organization instead.  I'm assuming your applications probably share some common code as well, so you might want 1 TP for all the shared code and then another one per customer for the non-shared pieces.

Enter the text you see in the image:

Leave a Comment

(required) 
required 
(required)