Chapter 11 - Project Management Explained

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode, Kevin Jones

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:
  1. Generating a vision statement. This step involves creating view of the desired end result of your project, shared by all project stakeholders.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:
  1. Choose a process template. You can either use a default template out of the box or you can customize your own.
  2. Create a team project. Your team project will be based on your process template.
  3. Add appropriate groups and members to your team project.
  4. Decide on your iteration cycle duration for the project. This includes creating iterations in your team project.
  5. Capture your scenarios as work items in TFS.
  6. Determine which scenarios need to be completed for each iteration.
  7. Define the quality of service (QoS) requirements. Link the quality of service requirements to your scenarios.
  8. Break your scenarios down into stories to provide manageable work items for developers. Obtain estimates from the developers for each work item.
  9. Create a project schedule. Create a project schedule (by using Microsoft Project) and adds it to the Team Project.
  10. Define acceptance criteria. Define acceptance criteria for the work items (correlated to the QoS requirements).
  11. 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

Last edited Aug 6, 2007 at 5:27 PM by mycodeplexuser, version 2

Comments

No comments yet.