Overview on TFS
Tools & Modern Software Development
An approach to design tools is to create a separate tool for each part of the development process. Everyone in the team might then agree to use a particular tool for versioning the source code, another for tracking bugs, and a third for managing tests. This approach can certainly work—it’s much better than having no tools at all.
Deciding an Approach on using a tool
But what happens when a developer needs to determine which test found a particular bug in code that addresses a specific requirement? Or what if a project manager wants to get a view of the project’s overall code quality over time, looking at bug counts, test progress, code churn, and more?
Answering these kinds of questions requires integration across the team’s tool set. Even though each tool might be great at what it does, development with a set of disconnected tools has limits.
An Alternative Approach
An alternative approach is to create an integrated set of development tools explicitly designed to work together. While a particular member of this tool set might not have every feature found in a standalone version of that tool, the connections between the tools let the team work more effectively.
The Goal
The goal is to optimize the development process as a whole, this integrated approach can make the process of creating software significantly more effective
What's in with TFS
The intent of using TFS is to be useful in a range of situations, from a large development team spread across three continents to a solo developer working on her own. It’s meant to be a modern foundation for what’s become known as Application Lifecycle Management (ALM).
Components of Visual Studio
Visual Studio has several distinct parts. These parts can connect with one other, with other Microsoft technologies, and with non-Microsoft technologies. Figure 1 shows the main Visual Studio components and some of the other technologies that are most often used with them
The main components of Visual Studio (shown in red) are the following:
Visual Studio Team Foundation Server (TFS): As Figure 1 suggests, TFS is at the center of the Visual Studio story today. Every other part of the product connects to TFS, which acts as a central hub for information throughout the development process. It provides a place to store and manage requirements and other information, version control for source code, build management, bug tracking, test case management, reports based on this information, and more. TFS also provides an application programming interface (API) that lets other software access its services.
The Visual Studio IDE: Millions of developers use this integrated development environment (IDE) today, either on its own or with earlier versions of TFS. The tool allows creating, compiling, and running code, along with support for testing and other development functions.
Visual Studio Team Explorer: This tool focuses on letting its users access information in TFS, such as reports and build status. It can run on its own, as Figure 1 shows, or inside the Visual Studio IDE.
Visual Studio Team Explorer Everywhere: While some development teams work solely in a Visual Studio world, many don’t. Plenty of organizations build applications using both .NET and Java, for example. To help developers using Eclipse-based IDEs work effectively with Visual Studio, the product includes an Eclipse plug-in that allows connecting with TFS.
Microsoft Test Manager (MTM): Testing is a critical part of software development. While the Visual Studio IDE includes a range of testing support, it’s focused on testing done by people with development skills. MTM focuses more on manual testing, providing a tool for generalist testers rather than developers.
Visual Studio Lab Management: This component allows creating and managing virtual machines (VMs) for a test lab. While it’s certainly possible to do testing on real physical machines, using VMs can be simpler, faster, and cheaper. Lab Management is accessed through Microsoft Test Manager, and as Figure 1 shows, it’s implemented as part of TFS.
Other Microsoft technologies (shown in green in Figure 1) are also commonly used with Visual Studio. They include the following:
Expression Studio: This product suite includes tools such as Expression Blend to help designers create user interfaces (UIs) for Silverlight and Windows Presentation Foundation (WPF) applications. These interface definitions can be stored in TFS, then used by the Visual Studio IDE.
Internet Explorer (or another Web browser): Using an aspect of TFS called Team Web Access, people can access TFS through a Web browser. This allows making TFS information accessible to a broad range of participants in the development process, including customers.
SharePoint: Visual Studio lets a team create a SharePoint-based team project portal for accessing information such as documentation, team calendars, and dashboards with TFS information. As with Team Web Access, this lets people access information about the development process without requiring them to install any component of Visual Studio itself.
Microsoft Excel: Many project managers (and even some developers) use Excel to keep track of progress. To help them do this, Visual Studio lets Excel directly access TFS. The product also provides a range of Excel workbooks and reports for project managers and others to use in the development process.
Microsoft Project: Along with (or instead of) Excel, many project managers use Project. This tool can also access TFS, allowing things such as creating Gantt charts based on requirements stored in TFS.
A closer look at TFS
TFS sits at the center of Visual Studio, which makes it the place to start in understanding this product family. In a fundamental sense, TFS is a database. In fact, TFS is built on SQL Server, and it can be clustered for high availability. Yet while TFS does store lots of information, it also provides a variety of useful functions using that data. Figure 2 shows a summary of what TFS contains.
As the figure shows, TFS has several parts:
Work item tracking: The development process uses many different kinds of information: requirements, tasks to be done, bugs, test cases, and more. TFS holds all of this information in work items. Each work item is actually a record in the TFS database, and like database records, work items can be related to one another in various ways. They can also be customized, letting organizations create work items that fit their development process.
Version control: A fundamental challenge in software development is keeping track of changes. TFS version control manages updates to source code and other information used in the development process.
Test case management: Testing is a hugely important part of the development process. The goal of this TFS component is to help developers and testers create, use, and manage their test cases and test results. The section on testing later in this paper takes a look at what this aspect of TFS provides.
Lab management: As was shown in Figure 1, Visual Studio Lab Management is implemented as part of TFS. This component is also described in more detail in the section on testing later. (Lab Management was called out separately in Figure 1 because it’s purchased independently from the rest of TFS, as described later.)
Build management: Creating a runnable application from source code and the other artifacts a development team creates can be remarkably complicated. And once an application has been built from these various parts, it’s useful to run tests to verify the quality of the build. TFS build management provides an automated mechanism for doing these things and more.
Reports and dashboards: Whether a team is small or large, the development process creates a mountain of information. The reports and SharePoint dashboards that TFS provides help the people involved in that process understand and make sense out of this mass of data.
Figure 2 also shows one more component: process templates. To understand their role, think about how teams work today. Many different development processes are in use, each with its defenders and detractors. Some approaches, such as waterfall processes, place people in quite distinct roles: architect, developer, tester, project manager, and more. Others, such as Scrum and other agile processes, define multidisciplinary teams with each team member performing a range of functions. Visual Studio isn’t expressly designed to support Scrum or waterfall development or any other particular process. Instead, this tool family is meant to be useful with whatever development process a team is using.
To make life simpler, however, Visual Studio itself includes two process templates. They are:
Deciding an Approach on using a tool
But what happens when a developer needs to determine which test found a particular bug in code that addresses a specific requirement? Or what if a project manager wants to get a view of the project’s overall code quality over time, looking at bug counts, test progress, code churn, and more?
Answering these kinds of questions requires integration across the team’s tool set. Even though each tool might be great at what it does, development with a set of disconnected tools has limits.
An Alternative Approach
An alternative approach is to create an integrated set of development tools explicitly designed to work together. While a particular member of this tool set might not have every feature found in a standalone version of that tool, the connections between the tools let the team work more effectively.
The Goal
The goal is to optimize the development process as a whole, this integrated approach can make the process of creating software significantly more effective
What's in with TFS
The intent of using TFS is to be useful in a range of situations, from a large development team spread across three continents to a solo developer working on her own. It’s meant to be a modern foundation for what’s become known as Application Lifecycle Management (ALM).
Components of Visual Studio
Visual Studio has several distinct parts. These parts can connect with one other, with other Microsoft technologies, and with non-Microsoft technologies. Figure 1 shows the main Visual Studio components and some of the other technologies that are most often used with them
 |
| Figure 1: The components of Visual Studio rely on Team Foundation Server to connect with each other |
The main components of Visual Studio (shown in red) are the following:
Visual Studio Team Foundation Server (TFS): As Figure 1 suggests, TFS is at the center of the Visual Studio story today. Every other part of the product connects to TFS, which acts as a central hub for information throughout the development process. It provides a place to store and manage requirements and other information, version control for source code, build management, bug tracking, test case management, reports based on this information, and more. TFS also provides an application programming interface (API) that lets other software access its services.
The Visual Studio IDE: Millions of developers use this integrated development environment (IDE) today, either on its own or with earlier versions of TFS. The tool allows creating, compiling, and running code, along with support for testing and other development functions.
Visual Studio Team Explorer: This tool focuses on letting its users access information in TFS, such as reports and build status. It can run on its own, as Figure 1 shows, or inside the Visual Studio IDE.
Visual Studio Team Explorer Everywhere: While some development teams work solely in a Visual Studio world, many don’t. Plenty of organizations build applications using both .NET and Java, for example. To help developers using Eclipse-based IDEs work effectively with Visual Studio, the product includes an Eclipse plug-in that allows connecting with TFS.
Microsoft Test Manager (MTM): Testing is a critical part of software development. While the Visual Studio IDE includes a range of testing support, it’s focused on testing done by people with development skills. MTM focuses more on manual testing, providing a tool for generalist testers rather than developers.
Visual Studio Lab Management: This component allows creating and managing virtual machines (VMs) for a test lab. While it’s certainly possible to do testing on real physical machines, using VMs can be simpler, faster, and cheaper. Lab Management is accessed through Microsoft Test Manager, and as Figure 1 shows, it’s implemented as part of TFS.
Other Microsoft technologies (shown in green in Figure 1) are also commonly used with Visual Studio. They include the following:
Expression Studio: This product suite includes tools such as Expression Blend to help designers create user interfaces (UIs) for Silverlight and Windows Presentation Foundation (WPF) applications. These interface definitions can be stored in TFS, then used by the Visual Studio IDE.
Internet Explorer (or another Web browser): Using an aspect of TFS called Team Web Access, people can access TFS through a Web browser. This allows making TFS information accessible to a broad range of participants in the development process, including customers.
SharePoint: Visual Studio lets a team create a SharePoint-based team project portal for accessing information such as documentation, team calendars, and dashboards with TFS information. As with Team Web Access, this lets people access information about the development process without requiring them to install any component of Visual Studio itself.
Microsoft Excel: Many project managers (and even some developers) use Excel to keep track of progress. To help them do this, Visual Studio lets Excel directly access TFS. The product also provides a range of Excel workbooks and reports for project managers and others to use in the development process.
Microsoft Project: Along with (or instead of) Excel, many project managers use Project. This tool can also access TFS, allowing things such as creating Gantt charts based on requirements stored in TFS.
A closer look at TFS
TFS sits at the center of Visual Studio, which makes it the place to start in understanding this product family. In a fundamental sense, TFS is a database. In fact, TFS is built on SQL Server, and it can be clustered for high availability. Yet while TFS does store lots of information, it also provides a variety of useful functions using that data. Figure 2 shows a summary of what TFS contains.
 |
| Figure 2: Team Foundation Server provides work item tracking, version control, test case management, lab management, build management, and the ability to create reports and dashboards. |
As the figure shows, TFS has several parts:
Work item tracking: The development process uses many different kinds of information: requirements, tasks to be done, bugs, test cases, and more. TFS holds all of this information in work items. Each work item is actually a record in the TFS database, and like database records, work items can be related to one another in various ways. They can also be customized, letting organizations create work items that fit their development process.
Version control: A fundamental challenge in software development is keeping track of changes. TFS version control manages updates to source code and other information used in the development process.
Test case management: Testing is a hugely important part of the development process. The goal of this TFS component is to help developers and testers create, use, and manage their test cases and test results. The section on testing later in this paper takes a look at what this aspect of TFS provides.
Lab management: As was shown in Figure 1, Visual Studio Lab Management is implemented as part of TFS. This component is also described in more detail in the section on testing later. (Lab Management was called out separately in Figure 1 because it’s purchased independently from the rest of TFS, as described later.)
Build management: Creating a runnable application from source code and the other artifacts a development team creates can be remarkably complicated. And once an application has been built from these various parts, it’s useful to run tests to verify the quality of the build. TFS build management provides an automated mechanism for doing these things and more.
Reports and dashboards: Whether a team is small or large, the development process creates a mountain of information. The reports and SharePoint dashboards that TFS provides help the people involved in that process understand and make sense out of this mass of data.
Figure 2 also shows one more component: process templates. To understand their role, think about how teams work today. Many different development processes are in use, each with its defenders and detractors. Some approaches, such as waterfall processes, place people in quite distinct roles: architect, developer, tester, project manager, and more. Others, such as Scrum and other agile processes, define multidisciplinary teams with each team member performing a range of functions. Visual Studio isn’t expressly designed to support Scrum or waterfall development or any other particular process. Instead, this tool family is meant to be useful with whatever development process a team is using.
To make life simpler, however, Visual Studio itself includes two process templates. They are:
- MSF for Agile Software Development, defining work items, reports, and more for an agile development process.
- MSF for CMMI Process Improvement, defining work items, reports, and more intended to be used in projects that need to record more information about the development process.
And don’t be confused: Even though both template names begin with “MSF”, neither one requires adopting the Microsoft Solutions Framework. Along with these two, Microsoft also makes available a downloadable process template for Scrum, today’s most popular agile process.
Work Item Tracking
Creating software requires keeping track of lots of information. What requirements must the software meet? What tasks are remaining for the project, what’s the status of each one, and what are their relative priorities? What test cases have been created, and what bugs have those tests found? And perhaps most important, how are all of these individual pieces of information related to each other?
In Visual Studio, all of this and more is done with work items. The exact set of work items available for a particular project depends on which process template is used. Both the MSF for Agile Software Development template and the MSF for CMMI Process Improvement template contain work items for requirements (called “user stories” in the Agile template), tasks, test cases, and bugs, for example, but each also adds a few more. For instance, the CMMI template adds work items for risks, reviews, and change requests, all things that make sense for the development style this template supports.
Whatever work items are used, TFS allows linking them together in useful ways. For example, a requirement work item can be linked to the task work items that spell out what must be done to implement that requirement. It might also be linked to one or more test case work items that verify the correctness of the requirement’s implementation. Each test case work item, in turn, can be linked to one or more bug work item that this test has uncovered. Figure 3 illustrates this idea.
To see why this is important, think about what happens when information about the development process is not grouped together in a single place. Without this, answering important questions such as how well-tested the software is gets hard. There’s no simple way to work out what tests have been run against each requirement and what bugs are outstanding for each of those tests. With a unified approach, answering these questions is straightforward: Each requirement is connected directly to its test cases, their bugs, and more, as Figure 3 shows. Providing this kind of traceability is a fundamental reason why unifying software development tools makes sense.
Work items can be created, examined, and modified using various tools. A project manager might choose Excel, while a developer accesses work items from within the Visual Studio IDE. If the team decides to allow it, even customers can access work items from a Web browser. This allows the people who are paying for a project to check progress, file bugs, and otherwise participate in the development process.
Version Control
When multiple developers are working on the same code base, storing that code in a version control system makes life significantly easier. Each developer can now check out the code she needs, work on it, then check it back in. Conflicts with changes made by other developers are handled by the version control system. This functionality is referred to by various names, including source code control and software configuration management. Whatever it’s called, it’s an essential part of software development today.
Visual Studio provides this with TFS version control, a shared repository for source code and other artifacts used in the development process. For example, both a developer writing source code with the Visual Studio IDE and a designer using Expression Blend to create a XAML user interface file can store their work in TFS version control. TFS also supports versioning of database schema, something that helps keep code and the data it uses in sync with each other.
TFS version control allows branching and merging, letting different groups work on the same code, then later combine their changes. And to make life easier for geographically distributed teams, developers in a remote location with a slow network link can use a local TFS proxy server. This proxy server provides a local cache for version-controlled information that gets regularly synced with the master copy in a central TFS server.
Like most things in TFS, the information in version control can be accessed via reports and dashboards. For example, a project manager can use these to see what has been checked in to version control by each developer. This is more efficient for the project manager, and it also helps reduce the time developers need to spend writing progress reports.
Build Management: Team Foundation Build
Throughout the life of a development project, a team will use the source code, database schemas, and other information in TFS version control to build executable versions of the application. TFS supports this using a technology called Team Foundation Build. Even though it’s considered part of TFS, Team Foundation Build is typically installed on a separate machine from the other TFS components. Compiling software, a key part of many build processes, is a resource-intensive task, and so moving it off of the main TFS machine avoids slowing down everything else that this server does.
Build processes can be quite complex, with many steps. Once a build is complete, for example, Team Foundation Build can run build verification tests (BVTs) to check the build’s quality. It can also deploy the newly built software to specific machines, automatically making the code available to testers. To help define these processes, Team Foundation Build allows specifying the steps in a build as a workflow implemented using Windows Workflow Foundation. The product includes a wizard for visually laying out the steps in a build process, a tool that’s meant to make it easier to create and modify complex builds. And as usual with TFS, data about build processes and their results can be accessed via reports and dashboards.
Team Foundation Build supports several approaches: manual builds on demand, scheduled builds (such as nightly builds), and building whenever a change is checked into TFS version control. While frequent builds are useful—running a build for each checked-in code change is the cornerstone of continuous integration—what happens if a change breaks the build? If Team Foundation Build can’t complete the build, no other developer or tester on this project can get a working executable until the error is corrected. This can be a significant problem, since one developer making a single mistake can stop all progress. To avoid this, Visual Studio can require gated check-in for some or all of a team’s developers. With this option, changes submitted to version control undergo their own separate build (including BVTs) to make sure they’re okay before the changes are committed. This significantly reduces the chance that errors in these newly checked-in changes will break the main build.
Reporting and Dashboards
The three aspects of TFS described so far—work item tracking, version control, and build management—create lots of data. The fourth aspect, reporting and dashboards, focuses on making this data available in useful ways. Reports can be created using either Excel or SQL Server Reporting Services, and they can present current or historical views of a development project. Dashboards, created using SharePoint,provide a direct way to monitor a project’s status in various areas. For both, having all of the project’s information available in one place allows a broad view, correlating data from different areas.
As with work items, exactly which reports and dashboards are available depends on the process template a team uses. For example, the Agile template provides more than 30 reports, including Stories Overview, Builds Status, Test Plan Progress, Bugs by Priority, and Bug Trends, all of which can help team members see where the project stands. Figure 4 shows an example of the Stories Overview report viewed in the Visual Studio IDE.
On the left in this report is a list of the project’s user stories (i.e., its requirements). For each one, the report shows the work remaining to complete it, a summary of test results, and the number of outstanding bugs. Notice how this report makes use of a range of information stored in TFS, including work items containing requirements, the bugs associated with each one, test results, and more. The pane on the right lists other available reports. It’s possible to customize these reports or create entirely new reports using Excel or the Report Designer in SQL Server Reporting Services.
Reports can provide historical context, which makes them quite useful in understanding a project’s status. If 90% of the project’s tests passed today, is that good? It’s impossible to know unless you can also see what percentage of tests passed two weeks ago or two months ago. Because TFS maintains historical data about a development project, then makes it accessible via reports, the people in charge of a project can have a broader, more accurate view of its progress. And because TFS collects much of this data automatically, keeping track of code check-ins, builds, and more, project managers need no longer harass team members for status reports, then cut and paste the results.
Dashboards are created with SharePoint, and so they’re accessed through the team project portal. As usual with SharePoint, a dashboard can be customized, letting team members display information from outside the TFS world such as important upcoming events. Both the Agile and CMMI process templates provide predefined dashboards, including Bugs, Build, Quality, Test, and Project. The templates also include an option called My Dashboard, which gives each team member a customized view showing just his tasks, his bugs, and other information that’s relevant solely to him. Figure 5 shows an example of the Project dashboard for an agile development project.
This dashboard lets its user see several important metrics for the current iteration of an agile project, including a burndown chart showing the team’s progress, the product backlog, the status of relevant work items, and recent code check-ins and builds. Most of the information in this dashboard is drawn from TFS. Much of it, including the status of project work items and recent check-ins/builds, is created automatically. Because all of these aspects of the development process are handled in a unified server, creating accurate, timely status displays is straightforward. This is one of the primary benefits of a unified tool set like Visual Studio.
Work Item Tracking
Creating software requires keeping track of lots of information. What requirements must the software meet? What tasks are remaining for the project, what’s the status of each one, and what are their relative priorities? What test cases have been created, and what bugs have those tests found? And perhaps most important, how are all of these individual pieces of information related to each other?
In Visual Studio, all of this and more is done with work items. The exact set of work items available for a particular project depends on which process template is used. Both the MSF for Agile Software Development template and the MSF for CMMI Process Improvement template contain work items for requirements (called “user stories” in the Agile template), tasks, test cases, and bugs, for example, but each also adds a few more. For instance, the CMMI template adds work items for risks, reviews, and change requests, all things that make sense for the development style this template supports.
Whatever work items are used, TFS allows linking them together in useful ways. For example, a requirement work item can be linked to the task work items that spell out what must be done to implement that requirement. It might also be linked to one or more test case work items that verify the correctness of the requirement’s implementation. Each test case work item, in turn, can be linked to one or more bug work item that this test has uncovered. Figure 3 illustrates this idea.
 |
| Figure 3: Work items can be linked together, letting team members and other project stakeholders trace the connections among them. |
Work items can be created, examined, and modified using various tools. A project manager might choose Excel, while a developer accesses work items from within the Visual Studio IDE. If the team decides to allow it, even customers can access work items from a Web browser. This allows the people who are paying for a project to check progress, file bugs, and otherwise participate in the development process.
Version Control
When multiple developers are working on the same code base, storing that code in a version control system makes life significantly easier. Each developer can now check out the code she needs, work on it, then check it back in. Conflicts with changes made by other developers are handled by the version control system. This functionality is referred to by various names, including source code control and software configuration management. Whatever it’s called, it’s an essential part of software development today.
Visual Studio provides this with TFS version control, a shared repository for source code and other artifacts used in the development process. For example, both a developer writing source code with the Visual Studio IDE and a designer using Expression Blend to create a XAML user interface file can store their work in TFS version control. TFS also supports versioning of database schema, something that helps keep code and the data it uses in sync with each other.
TFS version control allows branching and merging, letting different groups work on the same code, then later combine their changes. And to make life easier for geographically distributed teams, developers in a remote location with a slow network link can use a local TFS proxy server. This proxy server provides a local cache for version-controlled information that gets regularly synced with the master copy in a central TFS server.
Like most things in TFS, the information in version control can be accessed via reports and dashboards. For example, a project manager can use these to see what has been checked in to version control by each developer. This is more efficient for the project manager, and it also helps reduce the time developers need to spend writing progress reports.
Build Management: Team Foundation Build
Throughout the life of a development project, a team will use the source code, database schemas, and other information in TFS version control to build executable versions of the application. TFS supports this using a technology called Team Foundation Build. Even though it’s considered part of TFS, Team Foundation Build is typically installed on a separate machine from the other TFS components. Compiling software, a key part of many build processes, is a resource-intensive task, and so moving it off of the main TFS machine avoids slowing down everything else that this server does.
Build processes can be quite complex, with many steps. Once a build is complete, for example, Team Foundation Build can run build verification tests (BVTs) to check the build’s quality. It can also deploy the newly built software to specific machines, automatically making the code available to testers. To help define these processes, Team Foundation Build allows specifying the steps in a build as a workflow implemented using Windows Workflow Foundation. The product includes a wizard for visually laying out the steps in a build process, a tool that’s meant to make it easier to create and modify complex builds. And as usual with TFS, data about build processes and their results can be accessed via reports and dashboards.
Team Foundation Build supports several approaches: manual builds on demand, scheduled builds (such as nightly builds), and building whenever a change is checked into TFS version control. While frequent builds are useful—running a build for each checked-in code change is the cornerstone of continuous integration—what happens if a change breaks the build? If Team Foundation Build can’t complete the build, no other developer or tester on this project can get a working executable until the error is corrected. This can be a significant problem, since one developer making a single mistake can stop all progress. To avoid this, Visual Studio can require gated check-in for some or all of a team’s developers. With this option, changes submitted to version control undergo their own separate build (including BVTs) to make sure they’re okay before the changes are committed. This significantly reduces the chance that errors in these newly checked-in changes will break the main build.
Reporting and Dashboards
The three aspects of TFS described so far—work item tracking, version control, and build management—create lots of data. The fourth aspect, reporting and dashboards, focuses on making this data available in useful ways. Reports can be created using either Excel or SQL Server Reporting Services, and they can present current or historical views of a development project. Dashboards, created using SharePoint,provide a direct way to monitor a project’s status in various areas. For both, having all of the project’s information available in one place allows a broad view, correlating data from different areas.
As with work items, exactly which reports and dashboards are available depends on the process template a team uses. For example, the Agile template provides more than 30 reports, including Stories Overview, Builds Status, Test Plan Progress, Bugs by Priority, and Bug Trends, all of which can help team members see where the project stands. Figure 4 shows an example of the Stories Overview report viewed in the Visual Studio IDE.
 |
| Figure 4: The Stories Overview report summarizes an agile team’s progress in addressing the project’s user stories. |
Reports can provide historical context, which makes them quite useful in understanding a project’s status. If 90% of the project’s tests passed today, is that good? It’s impossible to know unless you can also see what percentage of tests passed two weeks ago or two months ago. Because TFS maintains historical data about a development project, then makes it accessible via reports, the people in charge of a project can have a broader, more accurate view of its progress. And because TFS collects much of this data automatically, keeping track of code check-ins, builds, and more, project managers need no longer harass team members for status reports, then cut and paste the results.
Dashboards are created with SharePoint, and so they’re accessed through the team project portal. As usual with SharePoint, a dashboard can be customized, letting team members display information from outside the TFS world such as important upcoming events. Both the Agile and CMMI process templates provide predefined dashboards, including Bugs, Build, Quality, Test, and Project. The templates also include an option called My Dashboard, which gives each team member a customized view showing just his tasks, his bugs, and other information that’s relevant solely to him. Figure 5 shows an example of the Project dashboard for an agile development project.
 |
| Figure 5: The Project dashboard displays the task burndown, product backlog, recent check-ins and builds, and other information about the current iteration of a development project. |
