Team Project granularity

I'm just 1 day into my road trip, and already I've had some enlightening moments.  For example, make darn sure you get a luggage claim ticket when you check in.  :)

In our meetings with customer A today, we learned they had started down the path of creating a Team Project for each developer on their team.  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.

First off, Team Projects are team oriented, not individual oriented.  Think of them as a container for resources for all the roles within a project (developer, tester, project manager, builder, change management, etc.).  This includes development methodology, process guidance, a team sharepoint portal, a source control repository, a workitem repository, checkin policies, and reports.  So if you find yourself wishing you could create a Team Project without all the extra "goo" (e.g. sharepoint portal, reports, etc.) that goes along with them, you might not be thinking about them in quite the right way...

Another point is that a Team Project is not the same entity as a solution or a source code project (e.g. a C# console application).  A Team Project can contain multiple solutions and source code projects as well as much more (work items, reports, builds, etc.).

If your organization has only 1 application under development, the answer is easy; create a Team Project for your app and stick with it until you decide to follow a new development methodology.  As you issue new releases, use iterations to track your milestones.

If your organization has multiple applications in development, it might be suitable to create 1 or many Team Projects depending on several factors.  For example, do the products ship on the same schedule?  Does each project follow the same development methodology?  Can all the projects use the same work item types, check-in policies, or check-in notes?  Are the applications logically related?  How many source control versions and work items do you estimate the projects to contain?  All of these are relevant points to consider.

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.

Comments

• Anonymous
  August 21, 2006
  Jason Barile is out visiting customers this week. In his first post from the road, he blogs about...
• Anonymous
  August 22, 2006
  Rob Caron just pointed on a post by Jason Barile about Team Project Granularity. This subject is a common...
• Anonymous
  September 02, 2006
  Buenas, desde hace unos días estamos manteniendo una conversación interesante dentro de los foros de
• Anonymous
  September 30, 2006
  Buenas, desde hace unos días estamos manteniendo una conversación interesante dentro de