.gif)
Team Development with Visual Studio Team Foundation Server
J.D. Meier, Jason Taylor, Prashant Bansode, Alex Mackman, and Kevin Jones
Microsoft Corporation
September 2007
Applies To
- Microsoft® Visual Studio® 2005 Team Foundation Server
(TFS)
- Microsoft Visual Studio Team System
Objectives
- Learn what functionality Microsoft® Visual Studio® Team
System (VSTS) provides for project managers.
- Choose a strategy for team project creation.
- Create and manage projects with Visual Studio Team System
Overview
This chapter introduces you to the project management
features provided by Visual Studio Team System and how they help you to
overcome many of the common problems and challenges associated with managing
software development projects.
Visual Studio Team System and Team Foundation Server (TFS)
provide tools, templates and reports to help you monitor and support your
software development processes. As a result team communication is made easier,
handoffs required between team members are automated, work items such as tasks
are more easily assigned and tracked, and metrics that indicate project health
and progress are more easily monitored.
How to Use This Chapter
Use this chapter to learn about the specific features of TFS
and VSTS that are specifically relevant to project managers.
- Read the “Project Management Summary” and “Traditional
Project Management Issues” sections to understand the problems that TFS
project management is attempting to solve.
- Read the “Strategies for Team Projects” section to
identify your strategy for team project creation and organization.
- Use the remaining sections to better understand process
templates, work items, and other project management features.
Project Management Summary
Planning a project generally consists of some variation of the
following steps:
- Generating a vision statement. This step involves
creating view of the desired end result of your project, shared by all
project stakeholders.
- Generating scenarios. This step includes determining
the initial set of usage scenarios for the software. This involves using
customer inputs. It also involves validating the scenarios to make sure that
they are of value to your customer.
- Generating set of features to support those scenarios.
This step includes breaking the scenarios down into specific items of value
to your customers, so that you can talk to the customers about their
expectations regarding these items.
- Generating a set of work items. This step involves
breaking the scenarios and features down into specific tasks. Put another
way, when the work items are completed, the relevant feature or scenario
is implemented.
- Breaking tasks into areas. This step involves
breaking tasks down into areas. These areas could either be functional or
based on how specific team is organized.
- Scheduling the work. This step could involve
scheduling all the work up front, or breaking the work into iterations.
Traditional Project Management Issues
Most project managers today use a variety of different tools
to manage the software development process and these tools usually have little
if any integration with the tools used by software developers to do their job.
This lack of integration and cohesion across tools and teams leads to
significant challenges for the project manager. Typical issues include:
- Dealing with disparate information sources. Project
management tools are usually used in isolation, leading to separate
sources of information that are not easily integrated. Also, it is usually
difficult to integrate the data maintained by project management tools with
the data maintained by other team members such as bugs tracked within a
separate bug tracking system, in order to generate meaningful metrics.
- Difficultly capturing project-related metrics.
Obtaining project related metrics is critical to tracking status, making well-informed
decisions and answering fundamental questions such as “Will the project be
delivered on time and to budget?” To answer these key questions, project
managers typically rely on data obtained from Microsoft Office Project or
the bug-tracking system used by the development and test teams.
Consolidating data from these disparate systems is difficult, time-consuming
and error-prone. Most of the metrics generated by tools are not stored or
accessed in a uniform manner. Creating reports is usually an intensive
manual effort that requires much copying and pasting of information between
different tools.
- Difficultly ensuring that requirements are met.
There is often a gap between the work planed for the development team and
customer requirements and key non-functional requirements identified for
your system. There is another gap between scheduled work and actual work.
Vital information gets lost in these gaps which results in requirements
not being met.
- Managing processes and process changes.
Communicating the processes that your team should follow can be a
challenging task. Implementing changes to address systematic problems
without impacting team productivity can be even more difficult.
- Lack of auditable communication and task tracking.
Collaboration and team cohesion are normally addressed by holding team
meetings and by allocating task lists to developers to help them focus on
the right priorities. Tracking the progress of individual tasks can be
challenging. Also, project managers often spend a lot of valuable time
gathering status information from different plans and lists. Team members
also spend time completing status reports and updating a variety of
different documents and forms.
- Quality assurance. Predicting the number and
severity of bugs in the software you are producing is difficult and as a
result schedule estimates and costs are usually “best guesses”. These estimates
traditionally take into account contingency measures, the amount of which
usually depends on how confident the project manager is about the current
health of the project.
VSTS is designed to help address many of these traditional
problems faced by project managers. It does so by providing a set of integrated
tools to help teams improve their software development activities and to help
project managers better support the software development processes.
Project Management Features in Team Foundation Server
The key project management features provided by Visual
Studio Team System include:
- Process management. Team Foundation Server process
management includes Microsoft Solution Framework (MSF) process guidance as
well as process templates that set up new team projects with work item
types, reports, a project SharePoint portal, and source control settings.
- Security and permissions. New projects contain
default groups and permissions that map to common development team roles.
- Centralized work item management. Work items
including bugs, risks, tasks, scenarios and quality of service (QoS) requirements
are centrally recorded, managed, and maintained in the TFS work item
database. Centralizing their storage makes it easy for all team members to
view and access them.
- Microsoft Office Excel® and Microsoft Office Project
integration. By using the Office Excel and Office Project integration
features, project managers can continue to access the work item repository
and schedule information by using tools they already know.
- Metrics and reporting. TFS provides a reporting
service which transforms operational data such as work items, build
results, and test results into metrics stored within TFS data warehouse.
Predefined reports allow you to query a variety of project health and
quality metrics.
- Project portals. For every team project, TFS
creates an associated project portal that uses Microsoft Windows
SharePoint® Services. You use the portal to manage project-related
documentation, and to quickly view key reports and assess project’s current
status.
Benefits
The project management features of TFS provide the following
benefits:
- Centralized management
- High traceability
- Integrated project planning and scheduling
- Improved process control
- Improved team communication and cohesiveness
- Accurate progress reporting
Creating and Managing Projects with Team Foundation Server
The following steps summarize the general approach for
creating team projects in Team Foundation Server:
- Choose a process template. You can either use a
default template out of the box or you can customize your own.
- Create a team project. Your team project will be
based on your process template.
- Add appropriate groups and members to your team project.
- Decide on your iteration cycle duration for the project.
This includes creating iterations in your team project.
- Capture your scenarios as work items in TFS.
- Determine which scenarios need to be completed for each
iteration.
- Define the quality of service (QoS) requirements.
Link the quality of service requirements to your scenarios.
- Break your scenarios down into stories to provide
manageable work items for developers. Obtain estimates from the
developers for each work item.
- Create a project schedule. Create a project
schedule (by using Microsoft Project) and adds it to the Team Project.
- Define acceptance criteria. Define acceptance
criteria for the work items (correlated to the QoS requirements).
- Define reporting requirements. Define your project’s
key performance indicators and identify reporting requirements.
For more information on creating and managing a team project
see, “How To: Manage Projects in Visual Studio Team Foundation Server”
Strategies for Team Projects
You need at least one team project to start working with TFS.
When a project manager creates a new team project, an associated team project
Web site is created containing document libraries with document templates and
stock reports. A work item database is created for tracking all effort on the
project, and a methodology template is installed that determines rules,
policies, security groups, and queries for all work efforts. Additionally, a
source code branch is created for source control.
The structure you choose for your team project should be
guided by your requirements and might change as your software development
process evolves. There are three common strategies for creating new team
projects. You might use one of these strategies or a combination of several.
The three common strategies are:
- Team Project per application
- Team Project per release
- Team Project per team
Team Project per Application
This is the most common strategy for creating team projects.
This approach is useful for both large and small applications, as well as
multiple releases of applications being developed in parallel. With this
approach, you create one project for each application under development.
Team Project per Release
This approach is useful for large teams who are working on
long-running projects. After every major release, you create a new project and
have a clean start. With this approach you don’t have to worry about carrying
the previous release’s baggage forward, including work items. Also, this
approach provides you with the opportunity either to improve the process
templates or use new ones based on your newly acquired experience and
learning.
Team Project per Team
This approach is useful for large projects that span
multiple teams, where central control and activity monitoring is important.
With this approach, you create a project for each team. This approach closely
aligns a team with the workflows defined in TFS work item types and provides a
unit of reporting that spans the entire team.
Process Management
With VSTS, the software development lifecycle has been made
an integral part of the tooling to support software project development
efforts. By integrating the lifecycle processes into VSTS, the process and
handoffs for development team interaction are fully supported by the tooling
and can be automated in many areas.
Process Templates
VSTS uses process templates to define the set of
instructions and artifacts like process guidance documents, document templates,
default work items etc, for setting up a new project. A process template is a
self-contained set of instructions that provide development teams with the
methodology for a software development initiative. A process template contains
the following elements:
- Process guidance. This is supplied for each
template and provides contextual information, help, and direction for team
members who need assistance following or understanding a particular
activity. Process guidance is integrated into the Visual Studio Help
System.
- Document templates. These templates enable team
members to create new documents such as specifications, risks assessment
and project plans in a consistent manner.
- Work items and workflow. Work items have their own
set of fields and rules that determine the workflow of the work item and
how team members can assign and perform work.
- Security groups. These groups are used to define
who can control and manipulate reports, work products such as source code
and documentation, and work items. Project managers can administer
security groups without needing to be Windows administrators.
- Check-in policies. These policies can be used to
enforce rules and quality gates for all code checked into source control.
For example, you can enforce that checked-in code meets specific criteria,
such as conforming to your corporate coding standards, or passing unit
tests. For more information about how to create and configure custom
check-in policies, see “How To: Create Custom Check-in Policies in Visual
Studio Team Foundation Server.”
- Reports. These are used to monitor the ongoing
performance and status of the project. VSTS ships with many predefined
reports including code quality reports, schedule progress reports, test
effectiveness reports and many others. You can create your own report and
customize existing reports.
MSF for Agile Software Development and MSF for CMMI Process Improvement
Process Templates
The following two process templates are available out-of-the
box.
- MSF for Agile Software Development. This
lightweight process template for small, agile, or informal software
projects is based on scenarios and context driven actions and is project
and people centric.
- MSF for CMMI® Process Improvement. This process
template is designed for more mature software projects. It extends MSF for
Agile Software Development process template by providing support for
auditing, verification, and formal processes. It relies on process and
conformance to process and is organization centric.
If the provided templates do not match your specific process
requirements and methodology closely enough, you can add new process templates
to the system, and you can customize the supplied templates to fit the needs of
your organization. For more information about customizing existing templates,
see “How To: Customize a Process Template in Visual Studio Team Foundation
Server.”
Security and Permissions
When you create a project in TFS, four default groups are
created for that project regardless of your choice of process template. By
default, each of these groups has a set of permissions defined for it that
govern what members of those groups are authorized to do:
- Project Administrator
- Contributor
- Reader
- Build Services.
You can create security groups for your team project to
better meet the security requirements of your organization. Creating a security
group is an efficient way to grant a specific set of permissions to a group of
users on your team project. Make sure that you allow only the minimum
permissions necessary for the group, and add only those users or groups who
must belong to this new team project group
After you have created a team project group, you must add
the new group, give the group the appropriate permissions, and add members to
the group. By default, a team project group is created without any permission
granted.
Work Item Management
Work items are used as units of work for communication and
collaboration between the team. Your selected process template provides an
initial set of work item types and project managers then create and manage
additional work items that need to be completed on a development project. A
work item might define a task, risk, scenario, bug, or quality of service (QoS)
requirement. You can link work items together to provide better traceability.
For example, you could associate a specific work item task with the related
scenario or QoS requirement to which that work item relates.
The process template provides the definitions for the work
item types, including the set of fields defined for each work item type. Therefore
selection of the process template is important, because it can't be modified
during the project. If required, you should customize the process template to
include any additional work item types other than those provided by the base
templates.
A number of pre-defined work-items are generated in both the
MSF for Agile Software Development and MSF for CMMI Process Improvement process
templates when you create a new team project. These work items can be used to
jumpstart your use of the process, as they contain tasks that are necessary to
complete in order to begin the software development process.
MSF for Agile Software Development Process Template
The work item types provided by this process template
include:
- Scenario – Used to represent a user interaction
with the application system. It records the specific steps necessary to
reach a goal. When writing scenarios, be sure to be specific as there may
be many possible paths.
- Task – Used to represent a unit of work that needs
to be performed. Each role has its own requirements for a task. For
example, a developer uses development tasks to assign work.
- Quality of Service Requirement – Used to document
the system characteristics such as performance, load, availability,
stress, accessibility, and serviceability
- Bug – Used to communicate a potential problem in
the system.
- Risk – Used to identify and manage the inherent
risks of a project.
MSF for CMMI® Process Improvement Process Template
The work item types provided by this process template
include:
- Requirement – Used to capture the requirements defined
during the requirements gathering phase.
- Change Request – Used to capture any change
requests subsequent to the gathering of requirements.
- Issue – Used to capture issues to be tracked in the
projects.
- Task – Used to represent a unit of work that needs
to be performed. Each role has its own requirements for a task. For
example, a developer uses development tasks to assign work.
- Review – Used to represent the review work units
with in the projects, like code review, design review etc.
- Bug – Used to communicate a potential problem in
the system.
- Risk – Used to identify and manage the inherent
risks of a project.
Microsoft Project Integration
Installing VSTS or the Team Explorer application provides
extensions for Microsoft Project. For large projects that involve a large number
of resources, you can use Microsoft Office Project, to manipulate schedule data
within TFS.
For example, you can use Microsoft Project to manage and
plan, assign, balance and track work, and then publish the updates back to the
work item database when they are ready to be used by other team members.
For more information, see “Working with Work Items in
Microsoft Project” at http://msdn2.microsoft.com/en-us/library/ms244368(VS.80).aspx
Microsoft Excel Integration
Installing VSTS or the Team Explorer application provides
extensions for Microsoft Excel. For projects that involve a very large number
of work items, you can use the Excel integration feature to create work items
in an Excel spreadsheet and upload it to the work item database for use by
other team members.
For more information, see “Working with Work Item Lists in
Microsoft Excel” at http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx
Progress and Reporting
The reports provided with TFS help you quickly assess the
status of your team project, the quality of the software under development, and
the progress made toward project completion. These reports are generated from
data maintained within the TFS data warehouse, and they summarize metrics
derived from work items, source control, test results, and builds.
For example, you can use reports to find out how fast your
team is working from week-to-week, based on a team’s actual activities. The
goal of the TFS reporting system is to provide integrated data from across VSTS
components, to enable project managers and team members to understand the state
of the software development project, and take appropriate action to ensure its
success.
The process template you use to create your team project
determines which reports are available by default, but you can also add your
own custom reports. The content and use of each report created by the process
template is explained in the process guidance for that template. Team
Foundation Server is built on Microsoft SQL Server™ 2005 and uses SQL Server to
store all data related to work items, quality attributes, testing, test
results, and build results. TFS then uses SQL Server Analysis Services to
aggregate and analyze the data and drive the reports. The reports that are
created by the process template, or by individual team members by using
Microsoft Office Excel or Visual Studio 2005 Report Designer, are made
available through SQL Server 2005 Reporting Services and the team SharePoint
portal site.
For more information about customizing reports, see “How To:
Create a Custom Report for Visual Studio Team Foundation Server.”
Summary
Team Foundation Server provides project management features such
as centralized work item management, process management, security and
permissions management, project metrics, and reporting to improve your ability
to manage development projects in Visual Studio.
The software-development lifecycle has been made an integral
part of the tooling to support software project development efforts. TFS provides
the MSF Agile and MSF CMMI process templates, which support two very different
development methodologies. You can modify the supplied process templates or
create one from scratch in order to meet your team’s development process needs.
Additional Resources