Summary

Process templates define key aspects of a team project that affect how a team works. By customizing a process template, you can define security for team project control, what templates are available on the project portal, source code control check in notes, new work item types and queries, reports for monitoring and status, and which iterations and organization units are used. Process templates define the initial process settings for team project. Most process settings can be customized after a team project is created.

Overview of Process in Team Foundation

Software process is a significant part of Team Foundation functionality. A software process guides how a software product is built from beginning to end. In general a software process defines key activities to perform, identifies work products that are created, and describes roles that one or more people assume on the software project.

Visual Studio Team Foundation is designed to enact a process. This means that if a process defines a vision statement, which is a work product, you will see that vision statement document in Visual Studio Team Foundation. If a process defines a velocity report, you will see that velocity report in Visual Studio Team Foundation.

Process Templates

The process template is what defines a specific process in Team Foundation. The process template defines the tangible parts of the process such as work item types, reports, and default security settings. These tangible parts are what are enacted in Visual Studio Team Foundation. The parts of a process template are described in more detail below.

Security Groups and Permissions

The most important consideration before setting up a Team Foundation Server, or team project, is security. The process template defines a set of default security groups and permissions for a new team project. The process template also defines roles that team members assume while working on the team project. The roles do not have associated security groups or permissions, so you must decide how to configure security for the roles after the team project is created. Administrative considerations for roles and security is described later in this document.

Source Control Settings and Permissions

The process template also defines which check-in notes are used for a new team project, and if the new team project uses exclusive check-out. Also, the process template defines default permissions for source control. Administrative considerations for source control are described in more detail later in this document.

Work Item Types

A work item type is a database record which Visual Studio Team Foundation uses to track the assignment and state of work. For example, MSF for Agile Software Development has bug, task, risk, quality of service requirement, and scenario work item types. Administrative considerations for work item types are described in more detail later in this document.

Work Items

A process template can create default work items when a new team project is created. For example, a process template can create a default set of task work items that must be completed by team members to begin the team project. In general, there are no administrative considerations for default work items.

Work Item Queries

A process template defines the default set of public work item queries for a team project. In general there are no administrative considerations for work item queries.

Reports

A process template defines the default set of reports to be used by team members on the new team project. Administrative considerations for reports are described in more detail later in this document.

Work products and document templates

Work products and document templates are documents such as Microsoft Word files, and Microsoft Excel files that are copied to the project portal when the new team project is created. For example, MSF for Agile Software Development uploads a vision.doc file to the project portal that is the vision statement work product. Administrative considerations for work products are described in more detail later in this document.

Project areas and iterations

Project areas represent key groups or functional areas on the team project. For example, a team project may group team members into a client team, server team, and extensibility team. Iterations determine how many times the team will repeat a particular set of major activities (such as plan, develop, test).

Project areas and iterations are used to facilitate work item queries and reports for grouping. They allow the team to query for work items that just affect a particular area of the project, or a particular iteration. Administrative considerations for project areas and iterations are described in more detail later in this document.

Process guidance

Process guidance is HTML content that describes the activities, roles, work items, and other parts of the process for the team. In general there are no administrative considerations for process guidance content.

Other Settings

If you are using a 3^rd party process template plug-in, there may be additional security configurations or settings to consider. For more information, you will need to consult the documentation for the 3^rd party plug-in.

Process Template Providers

There are several sources of process templates. Visual Studio Team Foundation provides two process templates that you can install when setting up a Team Foundation Server. They are MSF for Agile Software Development, and MSF for CMMI Process Improvement.

Microsoft partners and 3^rd party vendors will also provide process templates. For more information on 3^rd party process templates, see the Visual Studio Team System Web site.

The final source of process templates is from within your own organization. Some organizations have a Project Management Office (PMO) that defines process to be followed by software teams. Also, some organizations have one or a few individuals who specialize in defining process for others. These are potential sources for additional process templates that may need to be installed on a Team Foundation Server.

Process Customization

There are two key scenarios for customizing a process in Team Foundation: the process template scenario and the team project scenario.

Customizing a Process Template

Consider an example of the first scenario where a process template is customized. Process template A is exported from a Team Foundation Server. The task work item type is removed from the process template, and it is imported back to the Team Foundation Server.

The customized process template does not affect any existing team projects. If a team project already exists that was created from process template A, the team project will still have the task work item type, even though the customized version of process template A no longer has the task work item type.

The customized process template affects all future team projects. If a new team project is created from the customized process template A, it will not have the task work item type.

Customizing a Team Project

In the second scenario, a team project is modified to have an additional work item type named story. Modifying a team project has no effect on any other team projects. So in this scenario, only the team project has the new story work item type.

Therefore, when making customization decisions, you must decide if you want the customization to affect all future team projects, or an existing team project. If you want to affect all future team projects, customize the process template. If you want to affect an existing team project, customize the team project.

Process Considerations before setting up a Team Foundation Server

Each Team Foundation Server represents a collection of team projects. How many Team Foundation Servers are required, and what they represent is a determination made by each organization. For example, you could decide that each Team Foundation Server stores all team projects for specific departments, and therefore the accounting applications department would have one Team Foundation Server for all their team projects. Or you could decide that each Team Foundation Server represents a product line.

Regardless of your strategy for assigning team projects to Team Foundation Servers, they will each need one or more process templates. When a team project is created on a Team Foundation Server, you must choose which process template to create the team project from. Therefore you must decide which process templates to make available on each Team Foundation Server.

Typically, which process templates are available on a Team Foundation Server will be determined by the types of team projects created on that Team Foundation Server. If most of the projects tend to be agile in nature, a Team Foundation Server may have only the MSF for Agile Software Development process template. However, if teams tend to customize process templates frequently, you could have as many process templates as there are team projects.

Because you can import a process template at any time to a Team Foundation Server, there is no concern about which process templates to use when you first set up a Team Foundation Server. In general, a good approach is to import the process templates that are typically required in your organization when you set up a Team Foundation Server. Then import additional process templates over time as they are needed.

Process Considerations before Creating a Team Project

Planning the Team Project

A team project will be created as the result of a request, typically from a product owner, or project manager. The new team project may represent a new software product to be created, or the next version of an existing product. Planning should take place before the team project is created to ensure the correct process template is used, and all security considerations are met. In general, take the following steps when planning a new team project.

Meet with Key Stakeholders

Meet with the key stakeholders in the team project such as the product owner, project manager, leads, and other administrators who may be needed to help create the new team project.

Determine the Process Template

The stakeholders for the new team project should evaluate available process templates and decide which one they will use for the team project. They should also decide if the process template must be customized. If so, the process template must be customized and imported to the Team Foundation Server before the new team project can be created.

Review Considerations

You should review with the stakeholders key considerations outlined in below in this document. Answer questions such as these: Which security groups need to be created? Who will have permission to create new reports? Are additional fields needed in any work item types after the team project is created?

Create the New Team Project

Once a plan is agreed upon and documented, create the new team project. Then follow the plan to configure additional security settings and anything specific outlined in the plan.

Roles

A role is a function filled by one or more people on the team. Process guidance defines roles appropriate for the type of process. For example, MSF for Agile Software Development defines the project manager, architect, developer, tester, business analyst, and release manager roles. MSF for CMMI Process Improvement adds additional roles such as test manager and auditor.

Roles and Security

Roles defined in a process template should not be confused with actual job titles or security groups. For example, a role may be named tester, but on a team project, many individuals with different job titles may assume that role, such as Web tester, security tester, or software test engineer.

The roles defined in a process template do not require or create security groups or assign specific users any permissions. Therefore, before you create a new team project, you should plan which security groups, users, and permissions are necessary. Consider which roles individuals will assume, because this will guide which permissions they will have. For example, the release manager role in MSF for Agile Software Development generally has more permissions in source control than developers because release managers must manage and build the released product.

A good approach to planning security for roles is to map each process role to appropriate Team Foundation roles such as Team Project Lead, and Team Project Contributor. Then decide which team members fulfill the process roles, and map them to the Team Foundation roles as well. After the team project is created, you will need to configure security settings for each team member as defined in the plan.

Reports

A report is a specific set of metrics describing conditions or events on one or more team projects. Before you create a team project, discuss the permissions required by the team members to work with reports.

In general, all team members have read access to all reports on a team project. Modifying or creating new reports is an activity that should be restricted to an individual such as the project manager, or lead roles.

A good approach is to make team members who need to modify reports part of the Team Project Lead role. For more information on the Team Project Lead role and configuring security for reports, see the Setting Permissions in Team Foundation white paper.

Work Products

In general, work products provided by a process template are stored on the project portal when the team project is created. Team members will be granted access to the project portal automatically when the team project is created. Modifying the project portal is an activity that should be restricted to someone such as the project manager, or leads.

A good approach is to make team members who need to modify the project portal part of the Team Project Lead role. For more information on the Team Project Lead role and configuring security for Windows SharePoint Services, see the Setting Permissions in Team Foundation white paper.

Source Control

The process template configures source control permissions for its security groups. If the team decides that additional permissions or security groups are required for source control after the team project is created, the permissions will need to be configured using Visual Studio Team Foundation.

For more information on configuring source control security, see Administering Team Foundation Source Control in the Team Foundation Administrators Guide.

Work Item Types

The team should review the work item types available in the process template. Additional work item types can be imported to the team project after it is created. Also, new fields can be created. However, keep in mind that work item fields and global lists are global across a Team Foundation Server, so care should be taken to design them properly for consistency and cross-project reporting and queries. For more information see the Authoring Work Item Types Lab in the Visual Studio 2005 Team System Extensibility Kit for Beta 2. The extensibility kit can be downloaded from http://msdn.microsoft.com.

Project Areas and Iterations

The process template configures initial project areas and iterations, but inevitably, these will change during the team project. One or a few people on the team should be put in charge of managing the project areas and iterations. They will need special permissions configure for them after the team project is created.

To configure security for project areas and iterations, select the team project in Team Explorer, and from the Team menu, click Team Project Settings, Classifications. In the Classification dialog box, select the project or iteration node to configure security and click the Permissions button.