Team Projects have turned out to a more confusing feature than was intended in Visual Studio Team System. We are in the process of building some guidance for when to create them, but in the meantime, I thought I would shed some light on how we use them internally at Microsoft.
Team Projects were intended to represent the largest unit of work possible in your organization. For us at Microsoft, that means a product or prodct line. ‘Visual Studio 2005’ for example, is a product line that we represent with a single Team Project.
Visual Studio 2005 is made up of a number of products, features and technologies. For example, ASP.NET, Team System and the Common Language Runtime are all part of the Visual Studio 2005 product line.
To keep things organized, we use ‘Areas’ extensively in our single Team Project. Permissions can be set on areas to restrict access to various parts of a given Team Project; I’ll do a video on this shortly.
Here is how are ‘Areas’ are laid out:
‘Areas’ are used all the way down to the feature level; for example, the Team Foundation Server Version Control team uses an Area to define each SCM command:
‘Areas’ are something we’ll be talking a lot more about in upcoming presentations and documentation. They are a really useful way of categorizing within a Team Project. Hopefully showing you how we categorize things within our teams helps a bit. More detailed guidance is on its way.