Visual Studio 2005 Team System: Software Project Management

 

David Chesnut and Lori Lamkin
Microsoft Corporation

May 2004

Applies to:

   Microsoft Visual Studio® 2005 Team System

Summary: This article examines software project management tools available in Visual Studio 2005 Team System. (9 printed pages)

Note   This document was developed prior to the product's release to manufacturing, and as such, you may find inconsistencies with the details included here and those found in the shipping product. The information is based on the product at the time this document was created and should be used for planning purposes only. Information is subject to change at any time without prior notice. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Contents

Introduction
Challenges of Project Management for Software Design
Our Solution
Conclusion

Introduction

The Visual Studio Project Management Tools enable better planning, scheduling, collaboration, communication, reporting, and process control. The Visual Studio Project Management Tools are integrated with the Visual Studio integrated development environment (IDE), Microsoft Office, Windows SharePoint Services, and SQL Server 2005 Reporting Services. Visual Studio Project Management Tools will revolutionize the way IT departments manage their projects by allowing non-intrusive visibility and instrumentation into the project data and the process.

Challenges of Project Management for Software Design

There are a number of problems faced by a project manager or lead when building a software project.

Gaps in Translating Work

There is a gap between the customer requirements and the work planned on the development team. There is another gap between the scheduled work and the actual work. Vital information gets lost in these gaps. Requirements aren't fully met and work is done that doesn't affect customer requirements. Requirements management tools attempt to solve this problem by providing links through these gaps to form a traceability matrix. These links quickly become outdated and meaningless and form a large maintenance burden on the project lead.

Poor Team Collaboration and Communication

Team collaboration and communication is hampered by the presence of disparate documents that might or might not be up to date or synchronized with actual work efforts. A project lead must spend time gathering status from different plans and lists, and team members must spend time sending status reports and updating documents. This interferes with team productivity, especially when team members are interrupted to provide status on their work. The team workflow is inefficient because a team might be waiting for work to be complete before they begin, but they lack a reliable mechanism to know for certain that the work is complete. Sometimes, full-time jobs are created just to transfer work between team members, track issues or collect status.

Difficulty Correcting Systemic Problems

Even when the project lead discovers that a course correction must be made, implementing the appropriate changes in the project team is very difficult. Rolling out process change is an intrusion on the team's productivity. Team members trying to get work done have to go out of their way to find the process information or the right document template.

Finding the right process information is even more difficult for team members who are assigned to multiple projects with different processes. The burden of deciding which policies and rules to apply falls on team members who must remember which process to use. As a result, team members develop an aversion for process and ignore process changes, eroding the project lead's effectiveness.

Tracking, but not Managing

Getting crucial metrics about the project is important to track status, and to make decisions. Most of the metrics generated by tools are not stored or accessed in a uniform manner. Creating reports becomes a manual and intensive effort of cutting and pasting information from different tools into one report format.

As a result, the project lead spends too much time collecting metrics from many different tools for the purpose of keeping the project plan up to date, and the project team informed. Often, the project lead becomes lost in the details of tracking and is not analyzing project risk or making course corrections on the project.

Our Solution

Visual Studio Project Management Tools are designed to solve these problems based on the software that project managers already know: Microsoft Excel, Microsoft Project, Microsoft Word, and Windows SharePoint Services.

Shared Data and Custom Views

As the project lead decomposes requirements into components or scenarios and then to tasks assigned to development teams, the Visual Studio Project Management tools capture the views along the way. These views store the relationships between work products such as functional specifications, risk assessments, and project plans. The views provide contextual information on the reasoning behind the established relationships, and this information is shared among all the different views so that updates in any view are reflected throughout all project work products.

Project leads are offered a high level of flexibility in organizing their work and are not forced into one hierarchical view of the project. A project lead can create views on the project according to features, scenarios, and components by selecting and organizing the same data accordingly in different views. Project leads can create many-to-many relationships between elements in the project that can reflect accurate project status, yet not get lost in a meaningless traceability matrix.

Building Work Item Lists in Microsoft Excel

Project managers typically use Microsoft Excel to store lists of issues, work items, or even to schedule work. The Visual Studio Project Management tools provide a Microsoft Excel add-in that ties a list object in the spreadsheet to the work item database. The work item database is a where all work items such as bugs, risks, and tasks are stored.

Consider a scenario where a project manager creates a spreadsheet that includes the top 10 risks. As the project manager makes changes to the assignment, priority, and other fields on those risks, team members receive the updated information in their work item queues. The project manager no longer needs to query for status on the work item, but can pull that information directly from the work item database into the spreadsheet.

There are two ways to create a work item list. From the Portfolio Explorer (a view of the project in the Visual Studio IDE) a project manager can select a work item query or the documents node and create a new data-bound spreadsheet. The new spreadsheet will contain a work item list that is populated with the data from the query.

The project manager can also create a work item list from within Excel using the add-in to select a project and import work items.

Maintaining the Project Plan Using Microsoft Project

Project managers use Microsoft Project to lay out task dependencies, load balance resources, and estimate end dates. The Visual Studio Project Management tools provide a Microsoft Project add-in that connects the project plans with the project team data. After work is scheduled in a project plan, the project manager can publish the data to the work item database. New work items are created for the task assignments made in Microsoft Project, and the tasks show up in the appropriate developer's work item queue. As the developer resolves the issues and reflects new status in the work item database, the project manager simply needs to refresh the project plan to get the latest information. Project managers can now effectively use Microsoft Project views to track task status without holding status meetings and manually updating their project plans.

In fact, project leads can monitor task status in several different project plans. For example, a project lead may want to look at project status by requirement. However, the developer lead may want to look at project status by component. Both people can take the same set of tasks and organize them differently in two different project plans. When status is updated on the work item, the developer lead can see the component progress in the development project plan, while the project manager can see the requirement progress in the requirements project plan.

Data-bound project plans are created in the same way that data-bound Microsoft Excel spreadsheets are created: through a query in the Portfolio Explorer, the documents node in the Portfolio Explorer, or from within any .MPP file.

Portfolio Explorer

Software projects in Visual Studio Project Management Tools are called portfolio projects. The portfolio project is the central concept that holds together the team endeavor of creating a specific software technology or product. When a project manager creates a new portfolio project, several key configurations occur to centralize team efforts on that portfolio project. A team project Web site is created containing document templates, and stock reports. A work item database is created for tracking all effort on the project. A methodology template is installed that determines rules, policies, security groups, and queries for all work effort. And optionally, a source code branch is created for source control.

The Visual Studio Project Management Tools feature a Portfolio Explorer that provides easy navigation into work products such as functional specifications, risk assessments, and project plans, from within the Visual Studio IDE. Team members can view information on the product builds, launch to source, query on tasks assigned to them, view overall project status, locate documents, view reports, and create work products associated with the project.

Project Site

The project site stores and versions work products, and is a team Web site hosted by Windows SharePoint Services (WSS). The same work products available through the Portfolio Explorer are also available through the project site as a dashboard for project stakeholders. In fact, if you create a new documents node in the Portfolio Explorer, a new document folder is created on the project site.

The project site comes pre-populated with document templates, stock reports, and a web version of the project process. The project site also includes a Web part for hooking up RSS feeds, and the Microsoft SQL Server 2005 web part for viewing reports.

Because the project site is hosted by WSS, the project site is extensible with additional SharePoint web parts such as Announcements, or Events. This allows teams to customize their project site to whatever look and style is most suitable for their project.

Team Communication and Collaboration

Work Item Database

Visual Studio Project Management Tools maintain a work item database that stores work items for each portfolio project. A work item is a unit of work that can be assigned, and tracked through a specific work flow. For example, a bug work item tracks work to resolve a suspected problem or issue in the software product. A typical work flow for a bug is Active, Pending, Resolved, and Closed. The work items available out of the box are bug, risk, requirement, scenario, feature, and task. Additional work item types can be created at any time.

Work Items are integrated with Visual Studio, so a developer can query for all bugs assigned to him or her without having to leave the Visual Studio IDE. Or, a tester can create a new bug, again, inside the Visual Studio IDE. Because the work item database is centralized, the status of work is always up to date.

Relating Code Check-ins to Work Items

Another Visual Studio Project Management Tools feature that improves collaboration is support for associating a code check-in with a work item. A common scenario is when a developer fixes a bug. The developer reads the bug work item, checks out the code, makes the fix, and checks the code back in.

Visual Studio Project Management Tools uses a Pending Check-in window to control code check-ins. When the developer checks in the code, he or she can associate the check-in with a work item, in this case the bug that is fixed. There is no need for the developer to use another tool to update bug status. Furthermore, a policy can be set that forces all code check-ins to be associated with a work item. This ensures that code development does not occur without that code being associated with assigned work.

Managing the Software Process

Visual Studio Project Management Tools make the software process an integrated part of software project development efforts. By integrating the software process into the tools, the process and handoffs are automated between team members. The elements that make up a process are: document templates, work items and workflow, reports, security groups, check-in policies, and process guidance. These elements are packaged in a methodology template that can be rolled out and standardized in an organization.

Each portfolio project is based on one methodology template. Process tuning is easy to roll out to the team through modifications to the methodology template even while the project is under way.

Out-of-the Box Methodology Templates

Visual Studio Project Management Tools include methodology templates based on the Microsoft Solutions Framework (MSF). MSF is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. There are two methodology templates available out-of-the box: MSF Agile, and MSF Formal. MSF Agile is a lightweight process for small or informal software projects while MSF Formal is designed for more mature software projects. The project manager can pick and choose from the proven practices in these methodology templates to manage the process in their projects.

Process Guidance

Process guidance for each methodology template is seamlessly integrated with the Visual Studio Help system. When a team member needs help, they are taken to the appropriate process guidance for the context of the task at hand. For example, if a developer presses F1 on a bug form using the MSF Agile methodology template, help information is displayed describing the fields specific to the MSF Agile bug form, and the workflow to be followed on that bug. The process guidance also cross references with other Help topics such as procedures for using the tools, and conceptual information. Furthermore, the process guidance help source is included, so organizations can customize it by adding new topics, modifying steps, and making any necessary changes to support their particular processes.

Document Templates

The methodology template includes document templates that the team uses on a project. Document templates are integrated into several tool areas. A team member can use document templates from the project site, and the Portfolio Explorer. Examples of document templates are specifications, risks, and project plans. New document templates can be added or created at any time.

Work Items and Workflow

Which work item types are in use on a project is determined by the methodology template. Each work item has its own set of fields and rules which determine the workflow of the work item and how team members can assign and perform work. Work items are integrated across the Portfolio Explorer, Microsoft Project, and Microsoft Excel. Furthermore, team members who do not have Visual Studio can also interact with work items through a browser over the intranet. Bug, risk, task, scenario, feature, and requirement are the work item types included with the Visual Studio Project Management tools. If needed, new work item types can be added or created at any time.

Exit Criteria

Exit Criteria are special tasks that must be completed before exiting a particular activity or milestone. For example, the stabilization activity might be considered incomplete until the exit criteria named Project Plan Updated and Approved is complete. Which exit criteria are initially in use is determined by the methodology template, and there is a special view provided by the Microsoft Excel add-in that allows the project manager to view and update all exit criteria on a project.

Reports

The methodology template also determines the reports in use on a project. The reports list metrics describing the status and health of the project. They are accessible from the Portfolio Explorer and the project site, and, if needed, new reports can be added or created at any time.

Security Groups

The project manager can create security groups without needing a Windows administrator. The Visual Studio Project Management tools synchronize groups and permissions with the project site, the work item database, and other databases. The project manager can control who views or manipulates the reports, work products, and work items on the project.

Check-in Policies

Finally, the methodology template configures the check-in policies for a portfolio project. For example, a policy can require that developers always run static analysis on their code before check-in. This level of control is an excellent way to control code quality and auditing.

Customizing the Software Process

Project managers are not limited to the methodology templates that come with Visual Studio Project Management Tools because third parties will provide methodology templates that can be installed. Also, project managers, or the Project Management Office (PMO) can create custom methodology templates.

As an example of customizing the methodology, consider a scenario where a project manager named Carol has decided to implement specific controls to better comply with the Sarbanes-Oxley act. She decides that only a special security group will be allowed to check in code to the finance node in the source tree. She also decides that code changes must be associated with a work item, and include check-in notes.

Carol can administer portfolio project settings from the Portfolio Explorer. She creates a new security group which has permissions to check in code to the finance node. She also adds specific members of her team to the new security group. Anyone outside the group is denied access if they try to check in code to the finance node.

Next, Carol modifies the source control policy, again using the portfolio project settings. She enables a check-in policy that requires check-in notes to be submitted with each change set. She also configures a custom Sarbanes-Oxley check-in policy add-in that requires a work item to be associated with each check-in.

Later, she can use Visual Studio Project Management Tools reporting features to view a report of who has checked in certain component code, what work was done (the associated work items) and the check-in notes (why). A full audit log of everyone who has touched the component helps Carol comply with the Sarbanes-Oxley act. All of the changes were easily made through integrated administrative user interfaces.

Managing with Rich Metrics Reporting

Visual Studio Project Management Tools provide extensive reporting features by integrating with Microsoft SQL Server 2005 Reporting Services and providing out-of-the box reports. All metrics from all tools in the Visual Studio 2005 Team System are recorded in a central data warehouse. These metrics include information about work items, check-ins, and other project related information. Using the reporting services, the project manager no longer has to spend time cross referencing metrics across tools. A lot more data is available to the project manager, providing new angles on project health.

Out-of-the Box Reports

Predefined reports are available through the methodology template, and accessible through the project site and Portfolio Explorer. These reports are based on industry proven practices and actual reports used by Microsoft internal teams to manage successful projects.

The following list is a sample of some of the reporting capabilities across Visual Studio Project Management Tools. The ability to easily integrate metrics from multiple tools into one report is a powerful feature of these tools.

  • Code Quality Report: This report describes the quality of the code using bugs, test failures, and code churn.
  • Schedule Progress Report: This report is useful for describing how well the project schedule is progressing by looking at task completion, and task lateness.
  • Plan Stability Report: This report describes the stability of a project by looking at changes such as requirements and schedule churn.
  • Test Effectiveness Report: This report helps evaluate the effectiveness of tests by looking at test run details.

Integration with Microsoft SQL Server 2005 Reporting Services

Because Visual Studio Project Management Tools reporting uses Microsoft SQL Server 2005 Reporting Services, you can analyze data in a variety of formats. The basic reports are displayed in HTML format. However, you can also view data using Microsoft Excel Pivot Tables to look into specific areas of interest. Microsoft Excel templates are provided to assist in connecting to the data warehouse and analyzing data.

And finally, you can always use the Microsoft SQL Server 2005 Reporting Services directly to analyze project data.

Conclusion

Visual Studio 2005 Team System delivers a series of project management tools based on the software that project managers already know: Microsoft Excel, Microsoft Project, Microsoft Word, and Windows SharePoint Services. Through integration with Microsoft Office, project managers no longer need to map data from these applications to the data used by the development team. A project site gives the dashboard view and ability to explore project data to stakeholders. The Portfolio Explorer integrates work products into the Visual Studio IDE for effective team access. Rich reports open up the metrics collected throughout the natural workflow of the team. A customizable project process based on industry proven practices drives the life cycle.

For more information on the other members of the Visual Studio 2005 Team System, see: