You have three tools at your disposal to organize your project: Microsoft Project, Microsoft Excel, and Team Explorer. No matter what processes you choose to use for your project (agile approach, MSF, or other), a consistent theme should be always apparent. To this end, you need to come up with a vision statement of some sort along with a set of requirements that define the features of the application. In Extreme Programming, the story card is used for that purpose. In MSF, you use scenarios and personas to define the parameters of your project.
There are many ways you can define scenarios. On his blog, Randy Miller (the creator of MSF for Agile Software Development) provides his take on how to formulate a scenario. Please refer to http://blogs.msdn.com/randymiller/archive/2006/08/02/686701.aspx.
There is an mismatch with the ways Team System and Microsoft Project handle workflow. Microsoft Project is designed to handle complicated relationships, hierarchies, dependencies, managing tasks cross iteration, and time tracking. Team System, on the other hand, is designed to handle lists (for example, a backlog) only. This makes Team System perfect for managing agile projects but a little more challenging for more structured and complicated projects. You mainly have to rethink the techniques you are used to implement in enterprise project management (EPM).
Team System's project management infrastructure is quite simply a tool created by developers for developers. It is a good area for third-party partners and independent software vendors (ISVs) to fill in the gaps. This chapter provides several insider techniques to make the most out of the available project management tools.
Let's start setting up our workflow.
To load in your work items into Microsoft Project or Microsoft Excel, simply click the Choose Team Project button. The interface shown in Figure 13-3 should appear.
If you can't find the Choose Team Project button in Microsoft Project or Microsoft Excel, chances are that Team Explorer didn't install correctly, or you installed Microsoft Office after installing Team Explorer. The fix is to go into Start⇨Control Panel, Add/Remove Programs and reinstall or repair Team Explorer. The Team Explorer client application is available on the Team Foundation Server media (CD or DVD) or you can download a copy using the following link: http://download.microsoft.com/download/2/a/d//VSTFClient.img.
Once you have selected your Team Project, you can get a list of work items, publish the changes you made to the project plan or refresh the current view using the toolbar in Microsoft Project (as shown in Figure 13-4).
There are many additional options available in Microsoft Project including a link to your process guidance from the Help menu. From the Team menu, you can access the mappings between work items on Team Foundation Server and Project; add links and attachments to your work items; and edit your areas and iterations. Microsoft Excel has similar options.
There are a few points you should consider if you decide to use Microsoft Project to develop your work breakdown structure. Team System is currently designed to manage task list hierarchies really well. Figure 13-5 shows a summary task Requirement, associated to a list of dependent Tasks.
What happens when you try to synchronize this task list with Team Foundation Server? The information you entered in Project and Excel is for the most part preserved. For example, if you open up the Setup certificate on server Task in Team Explorer and click the Details tab, you'll notice a field called Task Hierarchy that has the following value: Login Entry Page with BLX code entry field⇨Setup certificate on server.
A problem occurs when you try to sync back the work items to a blank Microsoft Project worksheet. As shown in Figure 13-6, the summary tasks, time and date tracking, dependencies, and the rollup have all disappeared. Your nicely formatted Gantt chart also won't show up.
In light of these limitations as well as a best practice, it is recommended that you save and back up your Microsoft Project or Excel file once you have worked out the work breakdown structure (WBS) for your Team System software development projects.
In this chapter, we examine how to work around synchronization issues with the following Project file elements:
Start and Finish dates
Team System is configured to map out the value of specific Project fields with Team Foundation Server, based on an XML file found in your Classification process template folder, called FileMappings.xml. This file is quite important, especially when you want to create your own customized work items. To view the current mappings in your project, simply click Team⇨View Column Mappings (as shown in Figure 13-7).
Field mapping customization is covered in some depth on the MSDN Web site. You can view the documentation by visiting the following link: http://msdn2.microsoft.com/en-us/library/ms404684.aspx
When you update a Task work item in the MSF for CMMI Process Improvement process, the following fields are updated in the work item (as shown in Figure 13-8).
Let's take a look at some strategies for mitigating these issues, including unique names and work item management, managing summary tasks, time tracking and rolling up results, and using pivot tables to view result summaries.
One of the issues you may encounter when you are working with work items is similarly named tasks, requirements, or scenarios. They may appear because you need to accomplish the same task in two iterations. For example, in Figure 13-9, a requirement called "Ability to scan and link documents" appears twice.
There are two approaches you can take to get around this problem. The first involves changing the title of the work item and indicating the iteration. For example, "Iteration 0: Ability to scan and link documents" (as seen in Figure 13-10). By doing this, you will instantly be able to know where the work item belongs. With your team, you should establish good practices with the naming of your work items. For example, a work item called bug will not provide any context as to what bug it is and to what part of your application it applies.
The second approach to filter your work item results by iteration is by creating custom queries. The example in Figure 13-11 shows the query editor, which you can access by right-clicking the Work Items folder in your team project, and selecting Add Query. The query defines the team project, the work item type (which is a scenario in the example, but can be changed to any type you want), and setting the iteration path to the right value.
Once you have completed the query and you are ready to save it, you can provide a descriptive name for your query (in Figure 13-12, the query is called "Customer Scenarios for Iteration 0"). You can define if the query will be local or accessible to the entire team by picking the appropriate save location.
Customers commonly ask how to assign a work item to more than one individual. You can assign a work item to a group (such as all your developers) by making the following ALLOWEDVALUES modification to the AssignedTo field in your work item:
<FIELD refname="System.AssignedTo"> <ALLOWEDVALUES expanditems="true" filteritems="excludegroups"> <LISTITEM value="[Project]\Business Analysts" /> <LISTITEM value="[Project]\Developers" /> <LISTITEM value="[Project]\Testers" /> </ALLOWEDVALUES> </FIELD>
To learn more about work item customization, refer to Chapter 11.
The standard work breakdown structure in the Microsoft Solutions Framework (MSF) is arranged by a set of scenarios broken down in component tasks. As you learned earlier, Team Foundation Server records but does not maintain the hierarchy tasks. As such, you can specify not to publish the information over to the server in the column mapping settings without many repercussions.
When you create a summary task in Microsoft Project, the relationship is written into a field called Task Context. Team System supports writing to this field (when you synchronize your work items to Team Foundation); however the Office plug-in will not read from the field to reconstitute the relationship when you try to pull work items into Microsoft Project. Microsoft is looking into the possibility of building in this functionality in the next version of the product (codename Orcas).
One of the ways you can filter hierarchies and partition your tasks is by using areas and iterations. The main purpose for areas and iterations is to filter work items and provide structure for your process. Areas stand for feature area (or functional area). You can store categories for functional portions of your application (for example the data layer, user interface) in the areas. Some choose to add the names of their customers in the Area portion of the Team Project, so that they can divide their work items by customer.
If you do use regular summary tasks within Microsoft Project, one of the techniques to avoid strange results is to completely disable summary task synchronization with Team Foundation Server. Simply right-click your summary tasks, and select Task Information. Click the Custom Fields tab, and select the Publish and Refresh (Text 25) field. Change Yes to No, and click OK.
Iterations denote a scope of time for completing a set of tasks. Within each feature area, you may have a set of iterations. Therefore, you can organize your areas as shown below:
User Interface Business Logic Data Access Layer
Then you can organize your iterations to represent the iterative cycle within each area:
User Interface Iteration 0 Iteration 1 Iteration 2 Business Logic Iteration 0 Iteration 1 Iteration 2 Data Access Layer Iteration 0 Iteration 1 Iteration 2
You can even further break down your iterations to represent each scenario, use case, or requirement. For example:
User Interface Iteration 0 Create Work Breakdown Structure Business Logic Iteration 0 Create Work Breakdown Structure
Let's look at how we can set up these logical groupings within Team Foundation Server.
To begin, access the Areas and Iterations options within your Team Project by right-clicking on your Team Project and selecting Team Project Settings⇨Areas and Iterations. In Microsoft Project, you can access this window by clicking Team⇨Edit Areas and Iterations. If you click the Iteration tab, you'll see the following display (as shown in Figure 13-13).
Click Iteration 0 to highlight the node, and then click the little blue plus sign icon to add a subnode. In the subnode, type Create Work Breakdown Structure. Repeat as shown in Figure 13-14.
Adding and maintaining your requirements/scenarios may seem like extra work, but it provides an interesting benefit of enabling you to recreate the hierarchy in Microsoft Project with sync back from Team Foundation Server.
The next step involves changing the area and path of each scenario/requirement and task and assigning it appropriately (as shown in Figure 13-15).
To re-create the hierarchy:
Open Microsoft Project. Click Choose Team Project (and select the Team Project appropriate to you). Then click Get Work Items and the Get Work Items dialog box appears (Figure 13-16).
Select the query to pull in the appropriate tasks, scenarios, and requirements. Once the work items appear in Microsoft Project, click Project⇨Group By: No Group⇨Customize Group By. The Customize Group By dialog box appears (Figure 13-17).
Finally, when you click OK you will see your scenarios and tasks organized hierarchically (Figure 13-18). From this point on, you can resynchronize your work items from Team Foundation to a new worksheet; follow the preceding steps in the recreation process and you'll get consistent results every time.
From a functional perspective, if you need to view the Gantt charts, the best approach is to use a preconfigured Project file with your work breakdown structure, back it up, and work primarily through oneway synchronization with Team Foundation Server. In Microsoft Project, you have two views you can use: the Team System Gantt and the Team System Task Sheet. You can access both views by clicking the View menu. (Note that these views are context-sensitive and you must connect to a Team Project on Team Foundation Server for the options to appear.)
On a related note, if you choose to delete work items in your Microsoft Project or Excel file, be aware that the work item will not be deleted within the Team System data warehouse. For auditing purposes, work item data is persisted permanently. There are techniques for "expiring" work items - see Chapter 19 for more details.
Time tracking and time-to-task approaches aren't terribly effective techniques in software project management. Time boxing is ineffective unless you (a) have solid historical metrics on the velocity of your team, (b) you can completely assess the complexity of a task, and (c) you are a practitioner of process improvement. If your estimation is missing any of these elements, there is a good chance that your estimation and time boxing may be closer to guesswork than reality.
However, that said, in many circumstances time tracking may be a requirement in a process. The default MSF for CMMI Process Improvement Task work item has the following time tracking interface (shown in Figure 13-19).
By default, the Start and Finish dates are read-only for anyone using work item tracking. There may be circumstances where you would want members of your team to change the dates. Here is how you can manipulate the mapping file (FileMapping.xml) to make the Start and Finish fields fully configurable:
Open up the Visual Studio 2005 Command Prompt (Start⇨All Programs⇨Microsoft Visual Studio 2005⇨Visual Studio Tools⇨Visual Studio 2Command Prompt).
Type in the following command in the command prompt and press Enter (substitute TFS:8080 with your own Team Foundation Server, and TeamProject for the name of your actual Team Project on the server):
tfsfieldmapping download http://TFS:8080 TeamProject C:\ FileMappings.xml
Edit FileMappings.xml from your C:\ drive.
Change the "PublishOnly" attribute from "True" to "False" for both of the following date fields:
Save your changes.
Upload your file using the following command:
tfsfieldmapping upload http://TFS:8080 TeamProject C:\ FileMappings.xml
Here is a breakdown of each field within the task work item:
Estimate - This field is used to provide an estimation of work. It should never be used by your development team. Read the note below for more details.
Remaining work - Within the timeframe set by the project manager, the team member can indicate how much work has been done. You should indicate the value as a percentage, for example: 40.
Completed work - The team member (developer, tester, architect, database professional, or other) can indicate how much work is completed as a percentage. For example, if the remaining work value is 40 percent, an appropriate value to put in the Completed Work field is 60 to round out the total work to 100 percent.
Start date - This field has a READONLY value. As a project manager, you can set and change the start date, but your team members can only view it.
Finish date - This field also has a READONLY value.
Make it a best practice for your entire team to leave the Estimate field blank when working with task work items. The reason for this is that Project will inappropriately roll up the values of all the estimates and provide inaccurate information. This happens because Team System work item fields have no concept of a local value or a global value.
The default MSF for Agile Software Development task work item has this interface (which can be accessed by clicking on the Details tab) - minus Estimate. The CMMI has Estimate Remaining Work and Completed work. The scenario work item has the interface shown in Figure 13-20.
Notice that in the scenario work item in MSF for Agile Software Development, the Start Date and Finish Date fields are not available (and read-only). The Rough Order of Magnitude field (which is equivalent to the agile concept of Nebulous Units of Time) is used to assess the complexity of the feature on a scale of one to three. One denotes a scenario of light complexity; a three represents a scenario of heavy complexity. If you have too many threes in your project, you should decompose your scenarios down to smaller units of complexity (as shown in Figure 13-21):
The Remaining Work and Completed Work fields integrate nicely with Team Foundation Server. You should advise your entire team to use the feature and fill out the field when appropriate. In Figure 13-22, the developer has completed 60 percent of his (or her) tasks and has 40 percent remaining. As a project manager, you can judge the progress of work using the reports and the Gantt chart.
Note that Team Foundation Server has no support for predecessors. You can manage the dependencies between tasks manually. Another approach is to create an extensibility point where work items are automatically updated and assigned. The Work Item Tracking API and the Team Foundation Eventing service are the backbone for such an approach. Look at the Visual Studio 2005 SDK (http://msdn.microsoft.com/vstudio/extend/) and the following MSDN article on automating state transitions for further details: http://msdn2.microsoft.com/en-us/library/ms194990.aspx.
One of the issues with Microsoft Project is that it won't effectively roll up results from Team Foundation Server. Due to the technical architecture between both products, the roll-ups from work items will provide you with incorrect values for the most part.
It is here where Excel comes to the rescue. You can use Excel pivot tables to tally up several fields from work items and more effectively manage the process of your team.
The first step you have to undertake is to start up a new Excel worksheet and click the New List button. The New List dialog box appears as shown in Figure 13-23.
Select the appropriate query and click OK. Your worksheet will fill up (as shown in Figure 13-24).
Now the environment is ready. The first thing you need to do is add all the work item fields into the worksheet. You can pick columns by clicking on Team⇨Choose Columns option. The dialog box shown in Figure 13-25 shows up as a result. Highlight all the work item fields on the left (in the Available columns list) and click the top arrow button to bring all the fields to the right-most Selected columns list.
Next, you need to set up your pivot table. You can pivot by a number of fields including iterations, type, state, and tasks, for example. Highlight the first three rows of your work items in your work list (Work Item Type, Rank, and State) as shown in Figure 13-26.
Then you can select Data⇨PivotTable and PivotChart Reports. This launches the pivot table shown in Figure 13-27. For the Where is the data you want to analyze? option, select Microsoft Office Excel list or database. In the What kind of report do you want to create? option, select PivotTable. Click Next.
You can then click Next on the next screen (or you can change the range of values you want to pivot on). Then you will have the choice of selecting a new worksheet or use an existing worksheet. Pick the new worksheet option and click Finish (as shown in Figure 13-28).
The pivot table appears on the worksheet (shown in Figure 13-29). Notice the pivot table field list on the right of the screen.
The last step you need to make is to drag the work item fields into the appropriate spots on the pivot. Drag the Work Item Type field to the portion of the pivot that says "Drop Row Fields Here." You can then drag the State field into the part of the pivot that says "Drop Data Items Here." The result will look a lot like Figure 13-30 (assuming you have enough work items in your Team Project).