Understanding the process template and its components
Learning about the MSF for Agile Software Development v5.0 template
Learning about the MSF for CMMI Process Improvement v5.0 template
A process is a method or a system used by teams while developing software applications. Most of us have had our fair share of experience working on projects using the waterfall method. And there is no shortage of other documented processes as well. A quick search online could get you a list of various development processes. These processes rely on the members of the team to comprehend the value that this process offers, and to follow the steps or procedures laid out by these processes.
As most of us could attest, many times the processes that were documented in binders and handed off to team members stayed largely untouched. You might argue that this was because of the sheer complexity of the process itself, or because of the amount of context-switching required by the team members to adhere to some of these processes. The list of potential reasons goes on. Sam Guckenheimer and Juan Perez, in their book Software Engineering with Microsoft Visual Studio Team System (Upper Saddle River, N.J: Addison-Wesley Professional, 2006), talk about the fact that most processes and tools force a one-size-fits-all approach, and hence, do not factor in the varying needs of teams.
Visual Studio 2010 Ultimate edition and Team Foundation Server 2010 provide a customizable environment for teams to choose and adopt a process (and set of practices) that matches the needs of the team, and does so by integrating the process enactment within the tool. This reduces context-switching enormously, and significantly raises the probability of process adherence by team members.
Process templates provide the fabric that brings together the key components of Visual Studio Team Foundation Server 2010 for process enactment. As a colleague used to describe it, process templates are the files to get Team Foundation Server configured to fit the way your team works well.
This chapter looks into the various components of a process template. The discussion in this chapter helps you understand the process templates that ship with Team Foundation Server and reviews a few of the process templates that are available from partners and the community.
Process templates are built around the concept that a process should enable you rather than hinder you. If you implement too little of a process, you must expend significant effort to stay on track. The inroads you make on a project will fully depend on the organizational skills of your team. The infrastructure will not support or enforce your process. Too much process inhibits productivity and velocity.
Process templates in Team Foundation Server 2010 provide a way to introduce the process to the entire team without getting in the way. When you create a new team project, process templates are used to set up the work items, work item queries, several shared documents, dashboards, reports, and more.
Figure 23-1 shows the contents of the Microsoft Solutions Framework (MSF) for Agile Software Development process template in a folder view. As you can see, it contains the various key elements for a team project, including work item tracking, version control, reports, and so on. A process template is a collection of files, including XML files, documents, and spreadsheets.
Team Foundation Server process templates contain components to support a software development process. As mentioned earlier, while setting up a new team project, a process template is used to create and configure the various parts of the team project, including the following:
Work items
Work item types and definitions
Link types
Work item queries
Team project portal
Project documents
Samples and templates
Planning workbooks
Reports that are included in a particular template
Work item field and Microsoft Project field mappings
Predefined areas and iterations
Version control settings (including check-in policy settings)
Team Foundation Server 2010 ships with two process templates out of the box:
MSF for Agile Software Development v5.0
MSF for Capability Maturity Model Integration (CMMI) Process Improvement v5.0
As mentioned earlier, for many teams, one of these two templates will serve as a starting point. Obviously, one size does not fit all, and that is especially true for software development processes, but teams can customize the process template to meet their specific needs.
See Chapter 26 for details on process template customization. It is advisable to start from one of the pre-defined process templates (that is, either of the two shipped in the box, or one from a partner or the community, as described later in this chapter). Your custom in-house processes (usually a combination of an established development process and policies, processes, and conventions used within your own company) can also be integrated into Team Foundation Server process template. That means you can work within a recognizable framework, making it easy for your team to adapt to Team Foundation Server.
Let's start by looking at the two process templates shipped in the box.
Agile development has gained significant momentum in the recent years. From the famous meeting at a resort in Utah that led to the Agile Manifesto (see www.agilemanifesto.org) to the broad adoption of eXtreme Programming (XP) and Scrum, agile development techniques have become mainstream in the software development world.
XP (with its focus on engineering practices) and Scrum (with its focus on project management practices) complement each other. Agile techniques are no longer just a favorite of developers, but also a favorite of many project managers, business analysts, and users. A quick search of agile development on the Web will provide you with a significant amount of literature to read on this topic.
Microsoft has many internal teams (including teams building Visual Studio and the Microsoft patterns and practices team) using agile methodologies and processes, including XP, Scrum, Feature-Driven Development (FDD), and other agile techniques and practices.
Note
The "Microsoft patterns & practices: Agile Development Showcase" page has links to content and videos at http://msdn.microsoft.com/en-us/practices/dd128747.aspx.
MSF for Agile Software Development process template is primarily designed for an agile development team. Following are a few key characteristics of this process:
Open communication between team members — Freely sharing information within the team is a marker of project success. The work item tracking, reports, and dashboards all work together to open channels within your team.
Shared vision — Everyone on your team must have the same vision of the project.
Agility and adaptation — The capability to document every possible event that might occur within a software development project would result in volumes of documentation. Adaptation uses mindsets and principles as a basis for dealing with unlikely or infrequent events.
Focus on the customer — Communicating with the customer is key to achieving the business goals in any software project.
People come first — Tools and processes will only get you so far. The most important factor in any project is the people involved — your team members. Team Foundation Server increases the productivity of your team by organizing your process in a central team portal, tracking workflow using work items, and providing an easy work environment by facilitating process through tool-process integration. If you want a project to succeed, the best thing you can do is create an empowering environment for your team.
End-to-end quality — Quality can be achieved using the iterative process and tests to maintain the highest levels of security and performance. You can also enforce quality by setting tool-driven quality gates in your development process. Quality gates are policies that ensure that your code meets a certain standard (mostly through extensive testing) before it can be checked into the source tree.
Frequent deployment — The best software products are designed out of a need to maintain the highest level of quality. Highly iterative processes and frequent testing will help in reaching that goal. The product should be used internally and fit the customer's requirements. Tools such as the Unit Test Framework and Team Foundation Build can drive your team to reach a high caliber of quality.
Customize template to your needs — As explained earlier, the process templates are designed to provide you with a base template. There is no doubt that guidance is required for any successful project, but you have the option to integrate as much or as little as you want.
Figure 23-2 shows the main page of the MSF for Agile Software Development process guidance.
What you see in Figure 23-2 is the view of the process guidance within a browser. You will learn more about this later in the chapter, in the section "Process Guidance."
MSF for Agile Software Development has gone through a major overhaul in Team Foundation Server 2010. MSF for Agile Software Development v4.2 and prior versions had terminologies and guidance that were different from the terminologies and guidance used by agile teams, or that were familiar to agile practitioners. The Microsoft product team heard this feedback from the community and made significant changes to the template to make it a good base template for agile teams.
The MSF for Agile Software Development v5.0 template in Team Foundation Server 2010 has several new additions, including work item types (for example, user story work item), reports (for example, burndown), and planning workbooks (for example, product planning and iteration planning) that are familiar to users of agile practices and planning workbooks. That is on top of the new features of Team Foundation Server 2010, including the hierarchical work items and work item links. These new capabilities make the agile template very useful and compelling for agile teams.
There is not a way to migrate existing projects that use one of the process templates from Team Foundation Server 2008 to the new process templates in Team Foundation Server 2010. There are many fundamental changes to the new template. Obviously, the best way to take advantage of these new capabilities is to start with a new team project based on this new template.
In cases where you want to leverage some of these new capabilities, there is not an automated way to accomplish this. But you can take advantage of some of these features by performing a series of manual steps. The blog post at http://blogs.msdn.com/allclark/archive/2009/10/13/enabling-new-application-lifecycle-management-features-for-visual-studio-2010-beta-2-in-upgraded-team-projects.aspx shows how you can enable the planning workbooks, reports, lab management, and test management on team projects that were upgraded from an earlier version of Team Foundation Server.
Table 23-1 shows a quick summary of changes between MSF for Agile Software Development in Team Foundation Server 2008 and Team Foundation Server 2010.
Table 23.1. Differences in MSF Agile Software Development
FEATURE | MSF FOR AGILE SOFTWARE DEVELOPMENT V4.2 (TEAM FOUNDATION SERVER 2008 VERSION) | MSF FOR AGILE SOFTWARE DEVELOPMENT V5.0 (TEAM FOUNDATION SERVER 2010 VERSION) |
|---|---|---|
Work Items | Scenario | User Story |
Task | Task | |
Bug | Bug | |
Issue | ||
Risks | Removed in 2010 | |
Quality of Service Requirements | Removed in 2010 | |
Shared Step | ||
Test Case | ||
Link Types | None | Parent/Child |
Tests/Tested By | ||
Reports | RDL reports | Both RDL and Excel reports. (RDL reports have undergone a major revision in 2010.) |
Planning workbooks | Not available | Product Planning and Iteration Planning workbook |
Dashboards | Team Portal | Two versions of portal — Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS) based. |
Team Foundation Server uses work items to track assignments and work. Work items are the key entities that represent the work; hence, the data associated with work items is used to track and monitor project progress.
Note
See Chapter 22 for more information on work items and work items tracking.
MSF for Agile Software Development v5.0 contains six work item types:
User Story
Task
Bug
Issue
Test Case
Shared Steps
User stories are no strangers to software teams using agile techniques. User stories made sticky notes and index cards must-haves in an agile team's toolbox. Often, a team room may be decorated with sticky notes and index cards showing user stories on the story wall.
User stories are a representation of customer requirements similar to use cases but different in the amount of information captured. Agile teams value communication with a customer. Rather than trying to capture every edge scenario of a requirement on a piece of paper, many teams have started using small-sized index cards and sticky notes instead of regular office printer paper to capture the user requirements. The level of information captured in a user story provides enough detail for the development team to estimate the cost for implementing the user story.
Note
Mike Cohn's book, User Stories Applied: For Agile Software Development (Upper Saddle River, N.J.: Addison Wesley, 2004) is a great book on user stories. Particularly, Chapter 7 and Chapter 12 will be helpful, both if you are new to user stories or if you have been using user stories in your projects and need a refresher.
Obviously, user stories in the form of sticky notes on a wall do not work well when you have teams that are geographically distributed. With its integrated work items tracking system and the associated backlog worksheets, Visual Studio Team Foundation Server 2010 helps the whole team get on the same page with respect to project status. There are also partner tools that integrate with Team Foundation Server to provide a digital story wall that can be used by teams dispersed across geographical boundaries.
Note
A few implementations of story boards are integrated with Team Foundation Server. These story boards (or story walls) provide an experience closer to the physical story boards, which scales quiet well, even for distributed teams. Following are two Microsoft partner Web sites that provide examples of such implementations:
A user story work item captures information including a title, description, priority, stack rank and story points. The title field of the user story work item has a template to describe the user story. The format of the title field is "As a <type of user> I want <some goal> so that <some reason>."
The implementation of a user story is captured using child tasks that are associated with the user story. As you can see in the example shown in Figure 23-3, there are several user stories with associated child tasks.
A user story work item has the following three states:
Active
Resolved
Closed
A user story work item also has the following five tabs:
Details — This tab provides the information that you would typically write down on a index card or sticky note, including the acceptance criteria for this user requirement.
Implementation — This tab shows the list of related work items, including the parent and child work items. Typically, task work items that are used to implement a user story would be listed here. (Task work items are discussed in more detail later in this chapter.) You could also add a link to an existing work item, or add a new linked work item from within this tab.
Test Cases — This tab shows the list of test case work items that are used to test a particular user story. You could also link to an existing test case work item, or add a new test case work item that is testing the user story. This link between test cases and user stories shows the test coverage of user stories.
Note
Chapter 12 provides more information on test cases.
All Links — This tab shows all the links to other work items.
Attachments — You can use this tab to attach any associated documents (such as wireframes, mockups, and so on).
You create task work items within a project to assign and complete work. Tasks provide the implementation details for a user story. A task work item has the following two states:
Active — Once a new task work item is created, it is automatically set to the Active state. The Active state denotes that there are work requirements that must be completed. Tasks can be reassigned to other team members.
Closed — This state means that a task has been completed. Development tasks are completed once code updates have been implemented. Test tasks are completed when all tests have been executed for a specific feature or component.
A bug is a work item used to track and monitor problems within a software product. To be effective, a bug must be well-documented, including the steps to reproduce the issue. From the work item, the impact of the bug should be easily and clearly recognized.
In MSF for Agile Software Development v5.0 template, bugs have the following three states:
Active — This is the default state of a bug. An active bug means that the bug has been documented, but not yet dealt with.
Resolved — A Resolved state means that a bug has been handled by a developer or tester. Once resolved, a bug can be classified as "Fixed" or included "By Design."
Closed — A Closed status means that the bug has been completely dealt with, including a verification process.
The Reason field value, combined with the state, gives you a better sense for the status of a bug. The Reason field values will depend on the value of the state field. For example, a bug with a Closed state could be put into Active state, and the Reason field would contain the following two values to choose from:
Reactivated
Regression
Similarly, a bug in the Active state could be changed to a Resolved state, and Reason field would show the following six values:
As Designed
Cannot Reproduce
Deferred
Duplicate
Fixed
Obsolete
Unfortunately, the Reason field does not include the value "Undocumented Feature." When a bug is moved to a closed state from a resolved state, the Resolved Reason field (which is a read-only field) will show the reason the bug was closed.
A bug work item has the following tabs (in addition to fields such as priority, severity, stack rank, and effort estimates):
Details
System Info
Test Cases
All Links
Attachments
The information captured in a bug work item goes a long way toward an understanding of the problem and then finding a fix to address the bug. Visual Studio Ultimate 2010 provides key capabilities to enhance the quality of information that could be captured when reporting a bug. This should help in getting past the "No repro" scenario.
The capabilities start with simple additions such as rich text capabilities to highlight text in the bug work item. But the major additions include the capability to collect data on a test execution, and attaching that data automatically to a bug work item. This includes a list of steps to reproduce a bug. These steps can be marked green to indicate a successful execution of a step, or red if it resulted in a failure.
There is also a link to a video file with the location index to show you the steps as followed by a tester. This should help you understand exactly what happened as the test case was executed to validate a particular feature of the system. This step-by-step walkthrough is available in the Details tab of the bug work item.
The trace log from IntelliTrace could also be attached to a bug work item to help in debugging.
Note
Chapter 11 provides more information on IntelliTrace.
Visual Studio 2010 gets this information from a new tool introduced in 2010 called the Test and Lab Manager. This tool provides vital information to make the bug easy to reproduce, and hence, increase the probability of finding a resolution quickly.
Note
This information will be shown in the Attachment tab of the bug work item.
In addition, important information about the system under test will be captured in the Systems Tab. This includes the build in which the bug was found, which OS was used, which OS version was used, and so on.
An issue work item captures obstacles or items that must be addressed during the current (or future) iteration. An issue could result in associated work items such as tasks or bugs, but not necessarily. It could simply be used to track an item that the team needs to address. For example, an issue could be dealing with an external dependency, availability of a subject matter expert (SME) on a project, implementation decisions for future reference, and so on.
An issue work item has only two states:
Active
Closed
In addition to capturing the details, links, and any attachments, you could also specify a due date for the issue work item.
A test case work item captures a series of steps that make up a test to verify a feature, a set of features, or part of a feature. The Steps tab in the test case work item contains the series of actions to be performed and the expected result for each of the actions.
The Tested Stories tab shows the list of user stories that this test case is testing. This association gives you the capability to generate a report on test coverage of user stories.
Note
Chapter 14 provides more information on test case work items.
You create a series of steps in the test case work item that are used to walk through and verify a feature or functionality. But there are often steps (such as visiting the home page, logging in to the application, and logging out of the application) that are repeated prior to executing the steps unique for the feature you are testing.
A shared steps work item is used to capture these steps that are repeated often. As the name states, steps created in this work item can be shared across several test cases. In the test case work item, you could use the Insert Shared Steps action to include a shared step work item as part of the test case.
Note
Chapter 14 provides more information on the shared steps work item.
In Team Foundation Server 2010, the process guidance is now entirely available online and integrated into MSDN. In the 2008 version, the process guidance files were part of the process template, and the Microsoft product development team chose to integrate the guidance and make it available online on MSDN. This choice was made for multiple reasons, including discoverability, integration between guidance topics with online help content, and the capability to share the guidance among multiple team projects.
Note that the guidance is also available in an offline version in the form of a wiki library. You will make the changes to the location of the process guidance (that is, either the wiki library, or the MSDN Web site) using the project portal settings.
Team Foundation Server reports are the window through which you look into the progress of the project. There are several reports that are available out-of-the-box. The MSF for Agile Software Development v5.0 template includes the following RDL reports. In 2010, the reports are categorized and presented in groups as shown here:
Several of these reports are used commonly by agile teams, including Burndown and Remaining Work.
Note
Chapter 24 provides more details for each of these reports, and also examines how to add new reports and customize existing reports.
In addition to the SQL reporting services report listed previously, Team Foundation Server 2010 provides a set of very useful Microsoft Excel reports, as shown in Figure 23-4.
The MSF for Agile Software Development v5.0 includes two agile planning workbooks:
One to organize, estimate, and manage user stories in the product backlog
Another to analyze a user story, break it down into tasks, estimate tasks, and plan the work for the iteration
The Product planning workbook and the Iteration planning workbook provide a template that aids in both levels of planning.
Note
Chapter 25 discusses these two workbooks in detail.
You might find several of the sample documents and templates included in the MSF for Agile Software Development template useful in your project. For example, having a retrospective meeting following each iteration (and following a release) helps agile teams get a report of how the particular iteration (or release) went. Typically, retrospectives are used by agile teams to discuss what worked well and what didn't, thus identifying the root cause of issues, and the steps that must be taken to address these issues.
In the Samples and Templates folder under the team project, you will find a document template for iteration retrospective that you can use during your retrospective meeting, as well as a sample retrospective document for reference. Figure 23-5 shows the Samples and Templates folder, and the various documents contained in this folder.
Team Foundation Server includes a template called MSF for Capability Maturity Model Integration (CMMI) Process Improvement. CMMI was originally developed by the Carnegie Mellon Software Engineering Institute (www.sei.cmu.edu/cmmi/) to assess defense, aerospace, and government contractors in a regulated environment. The MSF version of CMMI is partially based on the work of W. Edwards Deming, a renowned statistician in the area of quality control and statistical process.
Deming popularized statistical process control in the field of business and manufacturing in his theory of profound knowledge. To properly implement process controls, you must be able to identify the difference between common cause variations (CCVs) and special cause variations (SCVs). CCVs are natural fluctuations found in any process. SCVs are caused by special occurrences, environmental factors, and problems that affect a process. The challenge as a project manager is to correctly identify an instance of a SCV and reduce it. Complicating this goal is the fact that these variations usually occur on a random basis.
The reporting component of Team Foundation Server provides visual metrics to measure factors such as project health. These charts can help you determine whether the Upper Control Limits (UCLs) and Lower Control Limits (LCLs) are within operational boundaries. Figure 23-6 illustrates the two types of variation, and the attainment of process improvement.
Process within a project is vitally important to bring down costs and increase productivity, which is why you are first selecting a process template to create a team project in Team Foundation Server.
System and hardware engineering processes have matured over the decades. Relative to manufacturing, software engineering is still in its infancy. CMMI is based on quality assurance ideas that came out of manufacturing. This makes sense from an operational perspective — most hardware manufacturing companies rely on software on the production line. For that reason, there are many varieties of CMMI specifications.
In a nutshell, CMMI is used to track the maturity of any software design organization, from requirements to validation. The CMMI has six maturity capability levels outlined in Table 23-2.
Table 23.2. CMMI Maturity Capability Levels
LEVEL | MATURITY | DESCRIPTION |
|---|---|---|
0 | Incomplete Process | |
1 | Performed Process | You have little to no controls in your project. The outcome is unpredictable and reactive. Frequent instances of SCVs. All of the process areas for performed process have been implemented and work gets done. However, the planning and implementation of process has not yet been completed. |
2 | Managed Process | You have satisfied all of the requirements for the implementation of a managed process. Work is implemented by skilled employees according to policies. Processes are driven according to specific goals such as quality and cost. Planning and review are baked into the process. You are managing your process. |
3 | Defined Process | In the defined process, you have a set of standard processes (or processes that satisfy a process area) within your organization that can be adapted according to specific needs. |
Quantitatively Managed Process | All aspects of a project are quantitatively measured and controlled. Both your operational and project processes are within normal control limits. | |
5 | Optimizing Process | CMMI Level 5 focuses on constant process improvement and the reduction of SCVs. The project process is under constant improvement. |
Warning
There are two models for implementing CMMI: the continuous model and the staged model. In the continuous model, elements such as engineering, support, project management, and process management are each composed of a set number of process areas. A process area is a description of activities for building a planned approach for improvement. Using the staged model, the process areas are set up according to the six maturity levels. The MSF for CMMI Process Improvement template was designed to support the staged model.
The CMMI template included in Team Foundation Server is designed to help you accelerate the appraisal to Level 3 compliance. The CMMI specifications are quite detailed (more than 700 pages long). Here are the characteristics of CMMI Level 3 (boiled down to three main points):
CMMI Level 3 is customized to the organization's set of standard processes according to the organization's guidelines.
CMMI Level 3 has a process description that is constantly maintained. This is implemented in Team Foundation Server using work items and iterations.
CMMI Level 3 must contribute work products, metrics, and other process improvement information to the organization's process assets. Process templates and the Project Site enable project managers to share metrics and documents with the rest of the team.
Business analysts and managers can benefit from utilizing pre-established planning and management processes based on lessons learned and best practices. Projects contain templates and historical metrics that apply regardless of what project you are working on, which help in the estimation phase of the project. You can detect and reduce defects early in the process and before you ship. From a business perspective, you can establish a project schedule and measure costs, which enables you to negotiate better contracts with your clients.
CMMI Level 3 provides a solid process framework for developers, testers, and architects. With process, the knowledge and experience gathered during the project is quantifiable. This means that any lessons learned can help improve the process, bugs are avoided, and code is enhanced. All of this information can then be leveraged on future projects. This also builds processes that are derived from best practices, much like MSF is derived from Microsoft's collective experience.
In a process-driven environment, the roles and tools are better defined because it is a more detail-oriented methodology. This helps team members stay focused within your organization. CMMI provides a focus on process and project management — in fact, the entire team shares the responsibility of making decisions, managing risk, and shaping and meeting requirements. CMMI emphasizes training and integrated teams to create an environment that facilitates the integration of end-to-end features, and a verification process to lower bugs and keep the project on track in terms of QA and feature requirements.
Formal processes have a reputation of being too bureaucratic and lacking agility. The traditional way of planning software is using the waterfall method. The plan is central to the process, and usually a lot of ceremony is attached to the handing off of the project (for example, a project plan sent to developers for a coding phase).
MSF enables your team to operate at CMMI Level 3. The MSF for CMMI Process Improvement template adds work items such as requirement, risk, change requests, and issues. The MSF for CMMI Process Improvement template also includes a set of reports to help monitor and track the project.
The MSF for CMMI Process Improvement template is designed to be flexible. In fact, The MSF for CMMI Process Improvement template out of the box will not "auto-magically" transform an organization into Level 3 — it must be augmented with training. If you need a formal process architecture, MSF for CMMI Process Improvement template provides a light and flexible meta-framework that you can customize to your needs.
The MSF for CMMI Process Improvement template provides an example of an agile interpretation of CMMI when, more often than not, the interpretation is traditional, waterfall, command-and-control, and documentation centric. It is designed to be light, with almost no overhead or bureaucracy. David J. Anderson (one of Microsoft's leading architects for the CMMI for Process Improvement Framework) describes this hybrid in his book Agile Management for Software Engineering (Upper Saddle River, N.J.: Prentice Hall, 2003) as "the Learning Organization Maturity Model." The CMMI version of MSF has the following characteristics:
It is geared toward larger-scale projects with a greater emphasis on breaking a project into phases and groups. MSF for Agile Software Development, conversely, is designed for smaller groups with quicker iterations.
It is designed to conform to a process, rather than plans and specifications. Process improvement is implemented in two ways: by reducing variations within baseline operating conditions and by instituting constant improvement using cyclical process structures.
It does not support project management artifacts by default, such as time tracking. However, the specification can be extended to include earned value (EV), the critical path method (CPM), and other enterprise project management features into the framework.
Everyone on the development team is responsible for issue and risk management. The goal is to eliminate special cause variation.
The MSF for CMMI Process Improvement template focuses on automation through Team Foundation Server's toolset and the CMMI appraisal model via the reporting tools to measure quality, velocity, and productivity.
All team members are empowered to make decisions and take responsibility for the success of a project. This includes status meetings and log, risk, and operations reviews.
All software development contains constraints. They include time, personnel, functionality, resources, and budget. The MSF for CMMI Process Improvement template has the means to help you buffer uncertainties (SCVs) within your project, and measure events and activities outside the scope of your project. The MSF for CMMI model is geared to reduce variation.
The MSF for CMMI Process Improvement template expands on CMMI with the concepts of release management, risk management, and iterative cycles.
It includes custom work items, reports, and process guidance. Like the MSF for Agile Software Development template, the framework is highly extensible and customizable.
This version of MSF uses metrics such as remaining work (or cumulative flow) and burn down (measuring work completed to track project health).
MSF for CMMI Process Improvement template v5.0 has the following work item types:
Requirement
Change Request
Task
Review
Bug
Issue
Risk
Test Case
Shared Steps
These are essentially the same set of work items from the v4.2 template, with the addition of two new work items (Test Case and Shared Steps).
In Team Foundation Server 2010, the process guidance is integrated and made available on MSDN for online viewing. The guidance for MSF for CMMI Process Improvement v5.0 is available at http://msdn.microsoft.com/en-us/library/dd997574(VS.100).aspx.
Team Foundation Server reports are the window through which you look at the progress of the project. There are several reports that are available out-of-the-box. The MSF for CMMI Process Improvement v5.0 template includes the following RDL reports. In 2010, the reports are categorized and presented in groups as shown here:
Project Management
Burn down and Burn Rate
Remaining Work
Requirements Overview
Requirements Progress
Status on All Iterations
Tests
Test Case Readiness
Test Plan Progress
Bugs
Bug Status
Bug Trends
Reactivations
Builds
Build Quality Indicators
Build Success Over Time
Build Summary
Dashboards
Remaining Work
Note
Chapter 24 provides more details for each of these reports, and also examines how to add new reports and customize existing reports.
In addition to the SQL reporting services report listed previously, Team Foundation Server 2010 provides a set of very useful Microsoft Excel reports as shown in Figure 23-7.
In addition to the two process templates shipped with Team Foundation Server, there are additional process templates available from Microsoft partners and the community. This demonstrates the ability to customize Visual Studio Team Foundation Server to enact the process/methodology of your choice.
Note
Chapter 26 provides more information about the tool and the techniques to customize process templates.
Table 23-3 shows a list of some of the process templates from partners and the community. Refer to http://msdn.microsoft.com/process for more information on third-party process templates.
Table 23.3. Partner and Community Process Templates
NAME | DESCRIPTION |
|---|---|
Conchango ( | |
Feature Driven Development | Cognizant ( |
Lightweight Scrum | This community-driven template (available at |
This process template (available at | |
This project (available at |
Note
Check out a series of blog posts on how the Team Foundation Server team uses the MPT internally. Start with the first post of this series at http://blogs.msdn.com/teams_wit_tools/archive/2008/03/27/how-microsoft-devdivuses-tfs-chapter-1-our-process.aspx.
Process Templates are a key component of Team Foundation Server and Visual Studio Application Lifecycle Management. The templates configure the team project and set the infrastructure that enables the team to adhere to certain process and practices. Process and associated guidance were available to software teams, but, in most cases, it existed outside the tool used by team members, or it was so complex that it was a non-starter for many teams. By integrating the process into the tooling, Team Foundation Server helps the team be more successful in adhering to these practices, and ultimately in delivering the value that is critical to the business.
The choice of the process template (whether between the two templates shipped with Team Foundation Server, or a template available from a third party or the community, or even a customized version) will largely depend on the environment of your team and the processes and practices that are in use. If your current practices are reflected closely in one of the process templates, it is recommended that you start with that template, and customize as needed. You will find more information on process customization in Chapter 26. Remember that the key here is to start with a good base template, and evolve it on an on-going basis.
In this chapter, you learned about process templates and their components. You also learned about the two process templates that are shipping with Visual Studio Team Foundation Server 2010: MSF for Agile Software Development and MSF for CMMI Process Improvement. This chapter discussed the various parts of these two process templates, including work items, reports, and documents.
Chapter 24 delves into the reports, portals, and dashboards that are key to monitoring and tracking projects.