Creating a New Project versus Reusing an Existing Project

Not every new project you undertake will require creating a new Team Project in Visual Studio Team System, and you will need to consider many issues when deciding whether you should. Obviously, if you have a new Visual Studio Team System infrastructure, this decision will likely be much simpler because you may not have an existing project to work with. If you do have existing projects, there are a number of important points you will need to consider when deciding. You might need to make this decision, for example, if you are managing a new version of an existing software product or if you are managing a multi-phase project over a long period of time. If your new project has absolutely nothing to do with any existing Team Project, you should almost certainly create a new Team Project.

Let’s assume that you have an option to continue with an existing Team Project. Let’s further assume that you would like to have modified work item types for your new project but do not want to affect the information or the display settings of any existing work items in the existing Team Project. Unfortunately, work item types are defined at the Team Project level. If you want to use an updated work item definition, for example, a complex bug work item type definition that captures more information and has a modified workflow, all existing work items of that type in the project will reflect this change. Therefore, if you require conflicting work item type definitions in the same project, your only option is to create a new Team Project and use the updated work item type definitions in the new project, which forces your team to refer to the previous project for work items that were created using the conflicting work item definition.

Somewhat related to work item type definitions is how work item fields specified in the work item types within your project map to fields in Office Project. This mapping, which is specified in the process template used to create a project, is responsible for telling Visual Studio Team System how to map work item information into preset columns within Visual Studio Team System and is essential for any form of synchronization between Office Project and work items within Team Foundation Server. For example, the MSF process template maps the Assigned To work item field to the Resources field in Office Project and the State field to Office Project’s Text13 field. This mapping applies to all integrations between Office Project and work items in a particular project. If you need to make modifications to these field mappings, you will need to create a new Team Project.

The permissions that you can assign to your team members are also done at a project level. Let’s assume that you wanted to extend an existing Team Project because it naturally represented the next phase of a much larger project, and that Brian, one of your developers, also happened to be on that project. Brian, however, is a junior developer with limited rights to access certain aspects of the code and is restricted from performing certain tasks such as editing project-level information. If you wanted to give Brian greater permissions on your new project without affecting the permissions set for the existing Team Project, your only choices would be to create a new Team Project or to completely change permissions for the existing Team Project. There is no way to have conflicting sets of permissions for your team within the same Team Project. Similar to Team Project permissions, a Team Project can have only one set of source control policies, which include checkin notes and checkin policies. If your new project will have a completely new set of checkin notes or checkin policies, yet you do not want to affect checkin policies of the existing code base of the project, you must create a new Team Project for your team and apply the new source control settings to the new project.

As mentioned earlier, every time you create a new Team Project, Visual Studio Team System creates a new project portal for your team. There can be only one project portal per Team Project. You may want to have a fresh project portal for a new project; you might not want to reuse an existing project portal site because existing content is not relevant to your new project. In this case, you can either clean up the content of the existing project portal or create a new Team Project and a resulting new project portal for your project.

Of course, one of the most obvious reasons for creating a new team project is if you want to use a completely different process template based on different process guidance. For example, the original Team Project could have been created from the MSF for Agile Software Development process template, but you have decided to base your new project on the Agile Software Development with Scrum process template. There is no way to switch a Team Project from one methodology to another, thus you will need to create a new Team Project for your new project. Of course, when you create a new project, you will see the updated process guidance as part of the project portal created for your team.

Generally speaking, for most corporate environments, it makes sense to create a new Team Project for every new project you undertake, which is slightly different than a company that sells software, which tend to have a more evolutionary process of software development. In fact, deciding to create a new Team Project within a product company could be quite difficult. Do you create a new Team Project for every major release? What if your product has many different subproducts such as with Microsoft Office-would you create a Team Project for each of the subproducts or even components? Do you maintain different delivery schedules for different products? Do you have different teams working on different products? Do you use different technology and methodologies for different products in your product line? The answer to these questions along with some of the technical constraints listed previously will help determine whether you should create new Team Projects. Generally speaking, when creating an entirely new version of a product, you should lean toward the creation of a new Team Project versus creating a “point” release (such as Version 1.1, 1.2, 1.3, et cetera). If your company sells a suite of products that are built by different teams on different schedules, you should also consider using a dedicated Team Project for each of the products in the product suite.

If you do decide to reuse existing Team Projects, there are certain things you should consider to make life a bit easier for you and your team. One of the great benefits of using one Team Project to house many software construction projects is the ability to perform cross-project reporting, because the reports that ship with Microsoft Visual Studio Team System can report only on the project from which they reside. If you decide to use a single Team Project, you must be extra diligent in how you structure your area and iteration because they must be appropriately specified and partitioned to allow both projects to work fairly autonomously if required. For example, a normal project may have a simple area tree and iteration sequence that you can use to categorize your work items, as depicted in Figure 3-9. When you will be managing several projects under the same Visual Studio Team System umbrella, you will likely have area and iteration hierarchies that look more like Figure 3-10, which take into consideration the differing feature areas and release schedules for the different projects. You should also be aware that even though you will have the ability to report on multiple projects at the same time, you will likely be required to set appropriate filter criteria if you wanted to see the progress of any single project within your Team Project.

Figure 3-9: A typical area breakdown for a Team Project

Figure 3-10: Area breakdown when managing two products under one Team Project