Before You Create a New Team Project

Before you can use Visual Studio Team System for your team, you must first create a Team Project. A Team Project will be your repository for everything related to a project such as work items (including scenarios, bugs, tasks, and risks), work item queries, source code, a Microsoft Windows SharePoint Services site used to maintain all of your project documents, and report definitions.

Team Project Creation Checklist

Not all team projects are created equally, and therefore, you will need to address a few issues before creating a new team project. Before creating your project, you should have the following information:

• The process template You should select the process template best suited for your project. During the process of template selection, you should also evaluate the need to extend or customize a process template to fit the needs of your project. For example, your project might require additional information, such as a task-tracking code or customer identifier, to be tracked for each work item, requiring the work item definition to be changed within the process template. In addition, you should also evaluate the workflows that are specified for each work item. These workflows specify the mini-processes of your project, such as the change-management process or the defect-management process. You should also evaluate the default reports that are specified within the process template to determine if they fit the needs of your project. If they do not fit your needs, you will need to modify the process template work item type definitions and report definitions to meet your metrics gathering and reporting requirements. More information on this topic can be found in Chapter 7, “Tailoring Visual Studio Team System.”

• The name of your project This may seem like a trivial decision; however, you really should consider naming guidelines for the Team Projects that you create. In some organizations, the job of considering naming conventions for your projects may not be your responsibility; however, in smaller organizations, the software project manager will likely be responsible for or at least consulted when establishing naming conventions.

  Considering that you may be using a shared Team Foundation Server architecture and that dozens of different teams might be using the same infrastructure over a long period of time, you will likely want to name your projects to ensure that they are unique over time and easy to find by your project team. Some organizations have chosen to use project codes to identify their team projects; others use a combination of department and project title. Whatever you choose, it should be consistent and make sense to your organization, and it should be resilient enough to last for at least five years. You should also take into consideration how your team members will find your project. The initial release of Team Foundation Server does allow you to delete projects but provides no ability for Team Project archival. For this reason, many organizations simply leave existing projects on computers running Team Foundation Server, even after they have been completed. In addition, a single Team Foundation Server infrastructure can literally support hundreds of projects. If you now consider that when connecting to a Team Project, you must choose from an alphabetically sorted list of Team Projects, you can easily see the importance of naming conventions. Here are some examples:

  • 06-Accounting-TaxAnalysis: 06 denotes the year of the project start, Accounting represents the internal department the software is being constructed for, and Tax-Analysis represents the name of the project.

  • 07-MySalesForce-CRMv1: 07 indicates the year of the project start, MySalesForce is a suite of products, and CRMv1 indicates the first version of the CRM application within the MySalesForce suite of applications.

• Source control structure During the process of creating a new project, a decision must be made on whether to base the new project on existing source code or to start with an empty source code pallet. In this case, if the Team Project represents a new version of an existing application, you will likely choose to branch from an existing Team Project’s source code repository. If your project represents a new application, you will probably instruct the Project Creation Wizard to create a new source code repository for your team. Consult with your development team on this and any decision on your source code structure.

  Note 

  Most organizations place security restrictions on who can create new Team Projects, and in a lot of cases, this list will exclude project managers. If you do not have enough permissions to create a Visual Studio Team System project on your organization’s Team Foundation Server, you should still be familiar with the process and what is required prior to the operation.

Selecting a Process Template

Chapter 2 painted a picture of all of the pieces of Visual Studio Team System, from Team Foundation Server as it applies to the role of the project manager to project tracking and analytical services that come that come out of the box, to the client side components, such as Visual Studio Team Suite, that your team members will likely be using. In Chapter 2, we also talked about how Process Templates act as a blueprint for your project, specifying the type of work items available to your team, the structure and default content of the Windows SharePoint project site, and some default tasks, work item classifications, and report definitions. Obviously, the project template you will choose for your project will be determined by the type of project you will be running. To refresh your memory, Visual Studio Team System ships with two process templates: MSF for Agile Software Development and MSF for CMMI Process Improvement. It is important to note that both built-in process templates are considered to embrace Agile software engineering principles, which are becoming more of the standard than the exception because they encapsulate a great many proven best practices for managing the software construction process.

What Is an Agile Method?

Use of Agile Software Development sometimes causes the formation of project teams that have problems predicting cost, quality, or delivery dates. In short, an Agile method is iterative, incremental, self organizing, and ever evolving. Agile methods make it possible for developers to expect and embrace change, not to fear or ignore it. Developers using Agile methods believe that it is better to adapt to changing conditions so they can focus on the value they deliver to their customers rather than attempting to prevent change and sacrifice the additional value the customer would have realized as a result of the change. Proponents of Agile methods believe that it is better to adapt to changing conditions so they can focus on the flow of value delivered as a result of the software than it is to prevent change and sacrifice value.

The following sections describe MSF Agile, MSF for CMMI, and third-party solutions.

MSF for Agile Software Development Process Template

In an MSF Agile–based project, your team will gather requirements in the form of scenarios. A scenario is similar to a story that describes a user’s interaction with your solution as the user attempts to achieve a particular goal. Successful teams capture scenarios that ultimately lead to the user achieving his or her goal (positive scenarios) and scenarios that prevent the achievement of a user’s goals (negative scenarios). Another key concept behind MSF Agile is that it promotes the creation of small teams of highly motivated and skilled individuals. MSF Agile specifies a small number of project roles such as Business Analyst, Project Manager, Architect, Developer, Tester, and Release Manager. MSF Agile doesn’t mandate that you have one person for each of these roles; in fact, it assumes that you will likely assign multiple roles to individuals on your team and provides guidance on more likely scenarios for multi-role positions. The MSF Agile team model scales by either adding people to the relatively small number of preset roles or breaking the project into sub-projects and sub-teams, essentially creating a “team of teams” environment.

Scenarios, as we have just defined them, are not enough to describe to the software developer how to construct the software. MSF Agile uses the concept of Quality of Service work item types to capture certain required characteristics of the resulting system such as expected performance, ability to handle load, availability, accessibility, and maintainability. Essentially, Quality of Service requirements don’t describe the functionality of the software but instead help to set constraints on the functionality, the way that functionality is presented and implemented, and the environment under which the functionality should operate.

In short, MSF Agile is an ideal starting point for competitive development environments such as research and development projects, or even off-the-shelf product companies that want to release high-quality software incrementally and are more concerned with being able to adapt to a changing market rather than tracking change. MSF Agile also embraces more of a “ walking into the cloud” approach, in which teams plan as they go rather than attempt to plan up front. Projects based on MSF Agile will produce working results quickly but must be highly iterative to continually adjust for newly discovered needs. With this in mind, when you have a project with a relatively short life cycle and a team that can work without a great deal of documentation and that focuses on achieving working software and continual customer validation, choose the MSF Agile process template.

MSF for CMMI Process Improvement Process Template

Capability Maturity Model Integration (CMMI) was developed at the Software Engineering Institute (SEI) to provide organizations with a framework of process improvement. CMMI was formed to provide guidance around improving an organization’s processes and their ability to manage the development, acquisition, and maintenance of products and services. MSF for CMMI Process Improvement (MSF CMMI) is an extension to MSF Agile that targets CMMI Level 3–compliance, and for this reason is the world’s first CMMI-compliant process based on Agile principles! You shouldn’t assume that by simply adopting Visual Studio Team System and using MSF for CMMI that your organization will be compliant with CMMI Level 3. In fact, MSF for CMMI truly provides only process guidance designed to accelerate your achievement of the staged representation of CMMI Level 3 (also known as Defined Process) because MSF for CMMI specifies only 17 of Level 3’s 21 process areas.

Note 

For more general information about CMMI, refer to Appendix A, “Capability Maturity Model Integration (CMMI).”

With MSF CMMI you have more comprehensive work items such as a Requirement, which can be many types, including Functional, Interface, Quality of Service, Safety, Security, and Scenario. In fact, a Requirement work item blends together Scenario and Quality of Service work item types found in MSF for Agile while adding a few more important requirement types. In addition to the enhanced versions of the Bug, Risk, and Task work items, MSF for CMMI provides the Change Request work item, which helps project teams explicitly track and manage the change control process of your project; Issues work items, which are used by project teams to help track any condition that is blocking productivity, quality, customer valued features, or schedule; and the Review work item type, which is responsible for documenting the results of a project or code review. You will also see that MSF for CMMI has also built upon the roles specified in MSF Agile as depicted in Figure 3-2.

Figure 3-2: Many more team roles are specified in MSF for CMMI.

Understanding that MSF for CMMI focuses more on process and the understanding of variance and the management of process, you should also expect a great deal in terms of reporting. In addition to the reports you get with MSF Agile, CMMI will also give you reports such as Issues and Blocked Work Items, Requirement Details, Requirements Test History and Overview, and Triage. These extra reports provide a heightened ability to track your project by allowing you to better understand issues you must resolve to allow work to continue or quality to increase and helping you to monitor the effectiveness of your quality assurance activities as your project progresses.

Where does MSF for CMMI fit in? Well, to start with, it certainly does not replace a corporatewide process-improvement infrastructure; in fact, it should work side by side with one. Even though MSF for CMMI has many more steps than MSF Agile, you can still consider using MSF for CMMI even when your organization does not aspire to achieve any CMMI certifications. MSF for CMMI relies more on process and planning than does MSF for Agile. In fact, MSF for CMMI is ideal for any regulated environment and environments which considerable planning needs to be performed up front and in which change, risk, and issues need to be explicitly managed and controlled. For these reasons, the MSF for CMMI process template is also commonly used in software consulting practices, which are typically contract focused and therefore have a greater need for auditing, tracking, and the greater ceremony provided by the template. Many organizations simply use the MSF for CMMI as a more formalized version of MSF Agile.

Other Process Template Options

One of the key benefits of Visual Studio Team System is that the product is not functionally bound by a particular set of process templates. In fact, you have a great deal of opportunity to either modify existing process templates to fit your needs or acquire other custom process templates from Microsoft Partners who have invested in Visual Studio Team System extensibility and customization.

The process templates that you use to create new Visual Studio Team System projects are completely customizable. Each process template specifies the contents and structure of the project portal created for each Visual Studio Team System project in addition to work item definitions, work item queries, default project work items, default project classifications (areas and iterations), and report definitions and security settings. Microsoft encourages customization of the default MSF process templates they ship with the product, and they provide a great deal of documentation and tools to assist you in this process.

Note 

Many Microsoft partners also provide process templates for Scrum, Feature Driven Development (FDD), and the Unified Process. To see a list of partners and their offerings with regards to customized process templates, visit http://www.microsoft.com/msf.

Scrum Process Template

Perhaps one of the more popular process templates available is from a company called Conchango, which provides a Scrum process template for Visual Studio Team System. The Scrum process template provides extensive support for the Agile-based Scrum methodology, because it was produced in conjunction with Ken Schwaber, one of the founding members of Scrum, and the Microsoft Technology Centre in the United Kingdom. Conchango’s Scrum process template for Visual Studio Team System is free and can be found at http://www.scrum-master.com.

Our Focus Is MSF Agile

As mentioned, MSF for CMMI is based upon all of the goodness of MSF Agile, yet it contains a great deal of specific processes and project artifacts required to help organizations achieve CMMI Level 3 certification and compliance. CMMI compliance with Visual Studio Team System can be a topic for an entire book, so this book will focus on MSF Agile because this flavor of MSF embodies the core principles of MSF for CMMI and can be used as a basis for all future MSF for CMMI learning.