Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Getting to know the benefits of Project Server for Software Development Teams

· Understanding scenarios where integration may be helpful

· Introduction to the key steps necessary to integrate Team Foundation Server and Project Server

· Review the necessary software to be installed on a project manager's machine

In some organizations, working with traditional project managers or project management offices (PMOs) is a fact of life for development and software engineering teams. Many of those software engineering teams wonder how they can better interact with project managers or PMOs without having to enter project tracking data twice or even worry about another system.

Project Server, and Project Client, which connects to it, have become popular tools of choice for those in the PMO community just as Team Foundation Server has been leveraged by software development teams. This chapter discusses the key parts of both products and how to begin integrating them for a better overall project planning and tracking experience.

Overview

Software development tasks may also be part of a larger project that contains activities and tasks outside software engineering work. Those tasks outside the software engineering process could have dependencies on software engineering milestones and deadlines. For example, after a software project is “done,” it still needs to be deployed to an IT environment, users need to be trained, marketing updated, and so on. Teams could certainly track those non-software development tasks in Team Foundation Server, but it may not always be the appropriate solution depending on the project. This is a place where the integration between Project Server and Team Foundation Server really shines and gives you the best holistic approach for everyone involved.

There certainly are useful and innovative project management features in Team Foundation Server, including many of the purpose-built Agile planning tools for managing software releases. There are also really great tools and features built into Project Server that do not necessarily make sense to be implemented in Team Foundation Server. Finally, there is a middle ground of features common to both platforms. Integration provides the ability to utilize those features that are great in each toolset.

The integration between Team Foundation Server and Project Server was initially shipped in Service Pack 1 for Team Foundation Server 2010. It's now included natively in Team Foundation Server since the 2012 release and supports integration with Project Server 2010 with Service Pack 1, or Project Server 2013.

If you want to try this integration, a demo environment is available to download at http:// aka.ms/ProjectServerTFSIntegrationVM2012, which includes a set of step-by-step walkthroughs of how to use the tools. It was originally built for integration in Team Foundation Server 2012, but it is very easy to take that environment and upgrade it to use Team Foundation Server 2013 and Visual Studio 2013. Those simple upgrade steps are available in a blog post at http://aka.ms/UpgradeProjectServerTFS2013VM.

Project Server Essentials

Project Server is particularly great at solving a few scenarios that some development and testing teams are facing. Not all teams and organizations need these types of scenarios addressed, but those that do might find some comfort with leveraging them in Project Server. The following list describes some scenarios that have come from organizations that have software development teams contributing to their projects:

· Budgeting and cost of projects—Project Server is able to apply costs to resources used, which can include people and other material resources. It can then use those costs at a project level to track an overall budget, especially across an organization's portfolio of projects in progress.

· Visibility into tracking shared resources—Because an organization may have multiple projects in progress, some team members might need to contribute to multiple projects. Project Server is able to help “book” shared team members and has tools to track when a particular team member will be over-used across multiple projects.

· Portfolio analysis—Project Server provides an organization with deep insight into its overall portfolio of projects. This also includes the ability to customize the project request life cycle from the early inception phases to include project costing estimates all the way to the completion of selected projects. Project Server's portfolio analysis features also allow organizations to help address a situation in which you have a certain budget available for projects in a given year, but you're wondering which projects to select for approval to deliver the highest value to the organization for the budget we have available?

· Cross-project dependencies and deliverables—Project Server is able to track the effects of your current project when another project's deliverables are starting to fall behind.

· Schedules — Project Server is very much date-aware so that project managers are able to schedule tasks and get estimates of project completion dates and task critical paths to meet deadlines.

· Timesheets and administrative time—Teams that need to perform time tracking can do so with Project Server.

· Vacation, holidays, and time off—By tracking when team members will not be available because of company holidays, vacation, and other types of time off, Project Server is able to help project managers with tracking overall project schedules and team members' availability based on that information.

· Non-people project resources—Certain projects may have non–people-related resources, such as manufacturing equipment, event locations, and so on, that need to be tracked within a project's schedule and budget. Project Server can track those along with people-related tasks and resources.

If any of these benefits sound particularly interesting to your organization then you may want to look into integrating Project Server with your Team Foundation Server instance. The integration of the two becomes an extremely powerful platform for tracking your projects and software releases.

Bidirectional Synchronization

One of the nice parts about the Team Foundation Server and Project Server integration is that it is a two-way synchronization once it is set up. This means that project managers can make changes and publish them to Project Server, which then gets pushed over to Team Foundation Server. Then developers/testers can make changes in Team Foundation Server that are sent over as project change requests to Project Server, which a project manager can approve and include in his or her projects.

Both clients have additional information displayed to the team member so that they can view details about the integration. For example, team members using Visual Studio and Team Foundation Server will notice a new tab on the work item form named Project Server, which contains fields related to the integration, as shown in Figure 16.1. Additionally, the history of the work item will begin to show all of the different synchronization events that occur for that work item.

Figure 16.1 Project Server tab on the work item form

Similarly, when the integration is set up and an enterprise project is mapped in Project Server, a project manager will be able to open his or her enterprise project in Microsoft Project and notice a few fields related to Team Foundation Server. Figure 16.2 shows a project plan including fields that identify whether the plan should be published to the Team Foundation Server Team Project and as what work item type. There is a new view added to the project plan called “Team Foundation Gantt (Project Server),” which is where the additional fields are added.

Figure 16.2 Microsoft Project Plan with Team Foundation Server-specific columns

Work Item Synchronization Life Cycle

A Team Foundation Server administrator should understand the life cycle of a Team Foundation Server work item, as it is synchronized with a task in an enterprise project stored in Project Server. Let's begin the discussion with a simple example showing the steps a project manager would take to add a task to the project plan in Project Server and wanting to submit it to Team Foundation Server.

1. The project manager opens his or her enterprise project from Project Server in Microsoft Project.

2. The project manager then adds a new task (or chooses an existing task) and changes the field value of “Publish to Team Project” to Yes and provides a value for the Work Item Type field, such as Requirement, User Story, Product Backlog Item, or Task depending on the process template being used.

3. The project manager then saves and publishes the enterprise project plan back to Project Server. Project Server then takes the line marked to publish and creates a work item in Team Foundation Server. At that point, any changes will be synchronized across.

4. For example, now that the work item is created in Team Foundation Server, the development manager can make changes such as creating children implementation tasks and updated assignments and effort fields. Those changes will then get submitted to the Project Server to be approved.

5. However, the update changes have not been made to the enterprise project plan just yet. Enterprise projects in Project Server have a concept of Status Update Approvals before they are committed to the project plan. The project manager visits the Approval Center in Project Server to approve each of the status updates that have come from Team Foundation Server.

6. The project manager will open the enterprise project again, which includes the new status updates, and then save and publish the enterprise project back to Project Server, which then completes the synchronization life cycle.

The last two steps may not seem obvious if you have not interacted with Project Server before. By default, all status updates not made by the project manager need to be approved. As mentioned previously, this is done by the project manager in the Approval Center, as shown in Figure 16.3.

Figure 16.3 Approval Center in Project Server web app

The second item that may not be obvious is the publishing step. After any changes by the project manager, those changes need to be published back to Project Server before they are completely committed. This step allows project managers to make interim draft changes to their project plan without making it “final.”

These two steps may seem to be burdensome to some project managers, so they can set up an auto-approval rule to remove one of the steps. Beginning in Project Server 2010 Service Pack 1, project managers can also add an auto-publish rule as well, which will remove the second step. However, some project managers prefer the granularity of this approach. These two concepts are important for administrators of the integration to understand because this will likely come into play when team members are concerned that something has completely synchronized from Team Foundation Server.

The steps of the second life cycle covered here occur when the items start with the development team and are synchronized over to Project Server. There are a few differences from the life cycle mentioned previously:

1. A development manager creates a new product backlog item and children tasks for the individual work that will be done to implement that product backlog item. The development manager then opens the Project Server tab on the product backlog item's work item form and sets the value of the Submit to Project Server field to Yes, and then chooses the name of the enterprise project in the Enterprise Project field. The development manager will then save the work item and notice in the history field submitted to Project Server for approval.

2. The new item has not appeared on the project plan yet. The project manager needs to open up the Approval Center in Project Server and approve the status updates.

3. The project manager then opens up the enterprise project plan from Project Server and saves and publishes the project plan to incorporate the newly synchronized item. At this point, the work item in Team Foundation Server will show as fully approved and synchronized. The project manager will also notice that the single summary item will have a roll-up from all of the child tasks, including the assigned-to list and how many hours are remaining/completed for each of those team members.

You will notice in step 1 that the development manager chose to submit only the parent product backlog item and not the product backlog item and the child tasks. The development manager could have taken the latter approach, but by sending over only the parent, the synchronization process will roll-up the resource information automatically, and updates from the children are automatically synchronized to the parent level as a summary to Project Server. That way, teams can work with their project managers and choose to send over only summary level information updates or send over even the details of the implementation tasks.

Default Field Mappings

By default, a limited number of fields are synchronized between Project Server and work items in Team Foundation Server. Some fields depend on the work item type and which process templates are used for team projects in Team Foundation Server. Table 16.1discusses a sampling of the default field mappings that you will find.

Table 16.1 Default Field Mappings

You might notice from the table that two fields are stored for certain fields in Project Server. This is because of the “approvals” workflow for a particular item in an enterprise project. The value may be different from what is contained in the fully published enterprise project and what is currently in the status approval queue.

You can also customize these field mappings, including adding additional fields to synchronize. Also, additional steps are required if you are using the Scrum process template for your team project in Team Foundation Server. More information about how to customize the field mappings and what additional steps are necessary if you are using the Scrum process template can be found in the MSDN article at http://aka.ms/CustomizeTFSPSFields.

Mirror Fields

Because of the “approval” cycle in Project Server, there are times when the value of the work item field may differ from what is currently in Project Server. This can be more prominent when a project manager declines a status update approval. These types of situations can be monitored and are the reason that work item types in Team Foundation Server have additional work item fields called mirror fields.

Mirror fields are used to store the intermediate value before status updates are approved. Mirror fields are essentially a “second set of books.” For example, the mirror field for the Remaining Work field is named Project Remaining Work. Whenever the values of those two fields are not the same then it is an intermediate state where a status update has not been approved yet or has been declined.

Monitoring Work Item Submissions to Project Server

As an administrator, you will likely want to monitor the flow of status updates between Team Foundation Server and Project Server. You can create a work item query to find problems in the synchronized-by filtering on Project Server Last Submit Status = Failure. This will return a list of work items that have an issue in the synchronization that you can then troubleshoot.

For more information about this process, you can read about additional troubleshooting steps at http://aka.ms/MonitorTFSPSIntegration.

Team Foundation Server Global Workflows

A new concept was introduced for work item type definitions and process templates called global workflows, which simplify the Project Server and Team Foundation Server integration. Global workflows are not dedicated to this integration only, but can be used in other scenarios as well.

Global workflows define a certain set of fields and rules that should exist on every work item type, even if not defined in the work item type definition. Global workflows can be scoped to either a team project or a team project collection. They can also define global lists that should exist and be used by fields defined in the global workflow fields.

Global workflows are used for several Project Server integration-specific fields that are needed and simplify the process of easily defining those fields. Those administrators able to customize work item type definitions need not worry about specifying the fields defined in the global workflow, which simplifies maintenance of those definitions. If you are customizing what fields are mapped to Project Server, you may also want to make appropriate customizations to the global workflow for your team project collection as well.

You can find out more about Global Workflows by reading the MSDN article at http://aka.ms/TFSGlobalWorkflow.

Relationship between Team Projects and Enterprise Projects

Each team project in Team Foundation Server can have multiple Project Server enterprise projects mapped to it. However, it is important to know that an enterprise project in Project Server can be mapped only to a single team project in Team Foundation Server. This relationship should be considered as your company forms its team project structuring strategy, as discussed in Chapter 2.

Initial Configuration

Configuring integration between Team Foundation Server and Project Server has some fairly simple initial steps that you must perform only one time. One step needs to be performed any time a new enterprise project is created that will contain tasks synchronized with Team Foundation Server. This section covers the essentials for setting up the integration.

Necessary Permissions

As an administrator, you want to make sure that the proper permissions are provided to the service accounts used to run both Team Foundation Server and Project Server. This is one area that you will want to make sure is completely implemented. It is commonly overlooked and will cause problems if not set up correctly. The following list provides a summary of the necessary permissions:

· For Project Server 2010 and Project Server 2013, you must grant the Team Foundation Server service account Full Control permissions for the Project Server Service Application so it can be accessed properly.

· You must also grant the Team Foundation Server service account the permissions required to access each mapped instance of Project Web Access (PWA). These differ by Project Server version, so see the reference link in the paragraph following this list for the specific details.

· Team members assigned tasks in enterprise projects in Project Server synchronized to Team Foundation Server should be recognized as Contributors to the team project.

· Team members assigned to work items in Team Foundation Server synchronized to Project Server should exist in the Enterprise Resource Pool in Project Server and should be granted permissions to log in to Project Web Access.

Be sure to double-check the last two bulleted items. They both seem to be an area that many teams forget to ensure. You can find out more information about the necessary permissions for the integration and how to provide those permissions by reading the MSDN article at http://aka.ms/TFSPSPermissions.

Command-Line Tool for Configuration

The command-line tool used to administer the integration between Team Foundation Server and Project Server is named TfsAdmin.exe. It is available whenever you install any version of Visual Studio 2013 because all versions include the Team Explorer components. You will find the tool by opening a command prompt window and navigating to the following directory for 32-bit operating systems:

cd %ProgramFiles%\Microsoft Visual Studio 12.0\Common7\IDE

and the following directory for 64-bit operating systems:

cd %ProgramFiles(x86)%\Microsoft Visual Studio 12.0\Common7\IDE

Project Server Installation Components

Additionally, you will need to install the Team Foundation Server Extensions for Project Server on each web-tier and application-tier server that hosts a Project Server 2010 or Project Server 2013 installation that will synchronize with Team Foundation Server.

The Team Foundation Server Extensions for Project Server are available as part of the Team Foundation Server 2013 ISO image, as shown in Figure 16.4.

Figure 16.4 Team Foundation Server ISO/DVD image with Project Server Extensions folder

One-Time Integration Steps

As mentioned earlier, some one-time steps are necessary to map the Project Server and Team Foundation Server instances so that they know about each other for synchronization. The following is a quick overview of each of these steps; more information can be found in the MSDN article at http://aka.ms/TFSPSConfiguration.

1. Register the Project Web Access (PWA) instances that will contain enterprise projects for synchronization with Team Foundation Server. You perform the first step by running this command line, using the appropriate values for your setup:

2. TfsAdmin ProjectServer /RegisterPWA

3. /pwa:http://project.contoso.local/pwa

/tfs:http://tfs.contoso.local:8080/tfs

4. You will want to map the Project Web Access (PWA) instance to the team project collections it will synchronize with. You can perform this step by running the following command line and replacing the appropriate values for your setup:

5. TfsAdmin ProjectServer /MapPWAToCollection

6. /pwa:http://project.contoso.local/pwa

/tfs:http://tfs.contoso.local:8080/tfs/DefaultCollection

7. You will then define the field mappings for each of the team project collections that will participate in the synchronization. You can use either the default field mappings or a customized set of field mappings as described earlier in this chapter:

8. TfsAdmin ProjectServer /UploadFieldMappings

9. /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection

/useDefaultFieldMappings

Once these three steps are finished, the synchronization will be ready, and you should not need to run these commands again in the future. You have one more step for each enterprise plan, which is covered in the next section.

Mapping Enterprise Projects to Team Projects

Now that the initial integration has been configured for Team Foundation Server and Project Server, there is one final action for each enterprise project that you want to participate in the synchronization. You need to do this step each time project managers create new enterprise projects, so you need to communicate to your project managers that they must let a Team Foundation Server administrator know when they have created new enterprise projects.

This step needs to be done only once for each enterprise project. The enterprise project needs to be mapped to a team project, and you should specify the types of work items that should participate for synchronization with the particular mapping:

TfsAdmin ProjectServer /MapPlanToTeamProject

/collection:http://tfs.contoso.local:8080/tfs/DefaultCollection

/enterpriseproject:"E-Commerce Site Project Plan"

/teamproject:"Engineering"

/workitemtypes:"User Story,Task"

The final option for work item types will change depending on the process template used by your team project. The previous example's command-line entry used the MSF Agile process template. If you are using the Scrum process template, you may want to specify for Product Backlog Items and Tasks to be used. For the MSF CMMI process template, you might specify Requirements and Tasks.

You might also notice that the list of work item types includes a comma to separate each of the work item types but does not include a space character between each list entry. Spaces are not accepted, so be sure to watch for the proper syntax when you run this command-line entry in the future.

Necessary Software for Project Managers

The next thing to remember is that project managers using Project Server will need to have the appropriate software installed on their machines if they want to open enterprise projects that are published. The minimal install necessary for a project manager's machine is as follows:

· Microsoft Office Project Professional 2007, Microsoft Project Professional 2010, or Microsoft Project Professional 2013

· Team Explorer for Visual Studio 2013 (http://aka.ms/TeamExplorer2013)

Team Foundation Server CAL Requirement for Project Managers

Even though Team Explorer needs to be installed to get the proper add-ins available in Microsoft Project, a Team Foundation Server Client Access License (CAL) is not needed for project managers if they will be connecting only to Project Server. If they need to look at details and interact in other ways with Team Foundation Server that require a CAL, then you will still need a CAL for the project manager. You can find out more information about this requirement in the MSDN article athttp://aka.ms/TFSPSConfiguration.

Summary

As you can see, the Project Server and Team Foundation Server integration can be extremely beneficial for certain teams and organizations to bring their project managers and software engineering teams better in line with one another.

In this chapter, you learned about the integration between Project Server and Team Foundation Server. You reviewed the scenarios about when Project Server makes sense and where it excels, as well as the types of situations in which the integration might be beneficial.

You also reviewed the features and benefits of the integration and the steps necessary to set up the integration. Finally, you reviewed what was necessary for project managers to have installed on their machines.

You begin the next part of the book in Chapter 17, which discusses the automated build system of Team Foundation Server.