Work items are the drivers behind Team System's task management and time-tracking capabilities. In this section, you'll learn a little about work item internals, including how to create and manage work items in your development projects and how to design custom work item types (WITs).
In Team System, five kinds of work items are available by default (in the MSF for Agile Software Development process): Bug, Quality of Service Requirement, Risk, Scenario, and Task. In the MSF for CMMI Process Improvement process, there are seven default work item types: Bug, Change Request, Issue, Requirement, Review, Risk, and Task. All of the work items in your project are stored in the work item database (formerly code-named "Currituck") and accessible via the Team Foundation Server.
The Team System work item management system is loosely based on an internal Microsoft bug tracking product called Product Studio.
Table 19-3 describes some of the important fields found in work items (please note that this is by no means an exhaustive list).
Uniquely identifies each work item within the work item database.
Describes the status of a work item. The default setting is Active.
Depending on the process template you select, several default work item types are made available within a Team Project. Some examples include Task, Requirement, Scenario, or Bug Request. You can also define your own work item types. (See the section later in the chapter entitled "Creating and customizing work item types.")
Indicates the priority order for your work items. This enables your team members to prioritize their workload and rank work items in order of importance. Team System can also queue work items based on their priority level.
The title of the work item. Make sure you create a descriptive title because it is the first thing you will see when you design a work item query. For example, simply writing "Bug" will not help you assess the type or importance of the bug in the system.
The team member to whom the work item is assigned. You can change the value of this field when you want to reassign a work item to another team member.
The work item version. As you will see later, you can add fields and customize existing work items. The Revision field helps you maintain a parity match between versions.
The current state of a work item.
Work items can also contain durations (including a start date and end date) and descriptions (this feature is especially useful if you need to include lengthy steps to re-create a bug, for example). You can also associate a work item with a Structure node or iteration to indicate when it should be worked on. Work items contain a Sync field to indicate whether the work item has been synchronized with the database. All of the fields are contained on an easily accessible work item form that simplifies the task of entering the data.
Once you create a Team Project using one of Team System's default process templates, the process template will automatically populate your work item list with common tasks related to the process.
Suppose you wanted to create a Bug work item in Visual Studio 2005. All you would need to do is go to your project in Team Explorer, right-click Work Items, and select Add Work Item Bug. You can also click the Team option in the Visual Studio menu and select Add Work Item Bug.
A New Bug form, shown in Figure 19-18, will appear. Simply fill out the form and click Save (the little floppy disc icon). The bug will automatically be saved in the work item store and will be accessible to everyone on the team project.
By default, anyone on your team can change a work item. There may be scenarios where you may want to prevent developers from reassigning their work to someone else or changing other users' work items. Fortunately, there are two ways of controlling access to work items. First, you can specify security permissions by Area, restricting who can access them. By changing the Area path of a particular work item, it will inherit the permissions you've assigned to it. Another way of controlling access to a work item is by customizing your work item types and adding READ-ONLY rules to the work item fields. This process is documented on the Microsoft Forums at the following link: http://www.forums.microsoft.com/MSDN/ShowPost.aspx?PostID=172323&SiteID=1.
To reassign a work item to another team member, in Team Explorer simply double-click the Work Items All Work Items query. A split window will appear, with a work item list on the top and a preview pane at the bottom (see Figure 19-19).
As soon as you select a work item in the top pane, you can edit the work item in the bottom pane. Change the assignment to another member of your team and click the Save button. Regular work item management tasks are covered later in the chapter in the section "Creating and assigning work items using Microsoft Office."
To create a work item query, go to the Team Explorer pane. Right-click on Work Items Team Queries and select Add Query. In the query area, simply change the And/Or, Field, Operator, and Value fields.
Figure 19-20 features an example query. These queries are used to filter through your work item list to help you find specific work items. This feature is quite useful for organizing your work items in logical ways. For example, if you select the TeamProject field, the = operator, and the name of your project (@Project indicates the current project), you can filter the work items associated with your projects.
To run a work item query, simply select a query in the Team Explorer, right-click, and select View Results. Queries are useful for creating a triage of important tasks or bugs during team meetings.
Once you save a query, you will be prompted whether you want to make it visible to everyone on the team, visible only to yourself, or save it as a file. If you choose to make it visible to everyone on your team, the query will appear in the Team Queries folder in Team Explorer (and everyone on your team will be able to run it). If you choose to save it for yourself, it will appear in the My Queries folder in Team Explorer (and it will not be visible to the rest of your team). Personal queries are useful to organize your work items in useful views (for example, all the personal Tasks that were assigned by a particular project manager). If you are working on a customized process template, the Save as a File option is useful to extract queries as WIQ files.
Microsoft has created two Office add-ins to enable project leads to manage scheduling and issue tracking using familiar tools such as Microsoft Excel and Microsoft Project. It's a smooth transition: Most project management specialists use spreadsheet tools such as Excel to create Gantt charts and trace milestones.
Team System only integrates with Microsoft Office 2003 or later. The add-in is installed during the installation of Team Explorer. Therefore, you must install Microsoft Office before Team Explorer.
You can use Microsoft Excel to track and manage work items within your project. Your work item list (including tasks, scenarios, and bugs) is synchronized with the work item database tied to the Team Foundation Server (TFS). Excel is suitable for ad hoc or loose projects; you can easily update the status of each item. The main advantage is that the organization is not only visual, but also functional. All of the changes you make propagate throughout the project team.
The Excel add-in works in conjunction with the list object. You can output the results of the query into Excel or Project by right-clicking All Work Items and selecting Open in Microsoft Excel or Open in Microsoft Project from within the context menu.
To create a brand-new work item list, select the Add New List button within Excel, and then select a Team Project using the Team Project button. Pressing the Sync button will synchronize the changes you have made locally with the Team Foundation Server. Figure 19-21 illustrates the Excel add-in options and the basic structure of a work item list.
Once you click the Sync button, you'll get a dialog box to confirm that the synchronization process was successful. One of the core advantages of using Microsoft Excel as a project management tool is the fact that it is ubiquitous and easy to use. You would be hard-pressed to find a Windows desktop without a copy of Microsoft Office (including Excel). If you are comfortable with Excel, you can create visual representations such as reports and graphs using local work item data. Excel is also appropriate for bulk adding and editing work item data.
You don't have to be connected to the Team Foundation Server to work on work items. Simply import them into Excel or Project, work on them offline, and then synchronize back to the server once you are in a connected state.
You will sometimes encounter conflicts when you synchronize work items with the Team Foundation Server. By double-clicking each conflict, you can resolve whether the changes should cascade to the server or vice-versa. The dialog box shown in Figure 19-22 appears during the process.
Each work item has a schema with rules dictating required fields, workflow rules, and behaviors. When a work item appears that doesn't validate against the schema, you will receive a validation error. A dialog box will appear stating the cause of the error, and you will get the opportunity to add missing fields.
You must select a reason for the conflict (using a drop-down menu). Work item validation is a useful mechanism for maintaining the integrity of your data in the work item database.
Ideally, you should use the Project Checklist query to get a holistic view of your work load if you are using the MSF for Agile Software Development process. (The process comes with a handy "Project Checklist.xls" work product to manage your project.) Using MSF for CMMI Process Improvement, you can use a variety of queries to manage your workflow. CMMI comes with a MSF CMMI Reference (MSF CMMI Reference.xls) work product as a checklist to implement CMMI based on set workstreams, activities, levels, and goals.
Microsoft Project enables you to manage your project with more granularity and richness of information than Microsoft Excel. Microsoft Project excels at scheduling and breaking down tasks, and has been specifically designed to work out project plans. In terms of functionality, you can add and edit work items with the same ease as Microsoft Excel. You can also do project column mapping and track the entire project to a baseline. Figure 19-23 illustrates work items imported into Microsoft Project.
There are several ways you can organize your work items in Project. The first method is by using Summary Tasks. This approach is well outlined in the MSDN documentation. Another approach is by using the Group By option, specifically grouping by Iteration. To group your work items, select Project Group By Customize Group By. In the drop-down box to the right of Group By, select Iteration Path (Outline Code 10) and click OK. Your work items will then be sorted by iteration and will be easier to manage.
Custom work items are created using templates that define the behavior. If you edit a work item type, you will notice that the structure is defined using human-readable XML. You can easily add new fields, add restrictions, and rename fields. To edit work item types, the Edit Domain-level Information permission must be enabled on your account (please refer to the "Managing project security" section at the beginning of the chapter for more details).
You have two options for configuring your account to manipulate work items: place yourself in the Namespace or Project Administrator Group.
The work item types can be edited in any XML editor, including the built-in Visual Studio XML editor or Notepad/Wordpad. The following example shows the structure of a "vanilla" work item type. The first node is the Work Item Type Definition (WITD). In this particular instance, we've defined the authoring application as hand edit (you can change this value to your liking):
<WITD application="hand edit" version="1.0">
Next, name the work item type and give it a description:
<WORKITEMTYPE name="Vanilla WIT"> <DESCRIPTION>This is an example of a simple Work Item Type</>
Then define the structure and field type that will appear in the work item:
<FIELDS> <FIELD refname="ProVSTS.title" name="Title" type="String"></> </FIELDS>
Now you need to establish a workflow (which includes states and transitions). In this example, we indicate that the default state of the work item is Active (a work item would transition to Active when a new work item is generated). Depending on the work item type, a work item can have several states, including Active, Resolved, and Closed (among others):
<WORKFLOW> <STATES> <STATE value="Active" /> </STATES> <TRANSITIONS> <TRANSITION from="" to="Active" /> <REASONS> <DEFAULTREASON value="New"> </REASONS> </TRANSITIONS> </WORKFLOW>
Next, you have to define the physical layout of the work item form. You have many controls at your disposal, including the FieldControl, ExtendedComboBox, and LinkControl. The best way to learn about the different controls is by editing existing work items and comparing the XML with the physical layout of the fields when the work item is in edit mode. In the following example, the work item physically contains a single field named Title:
<FORM> <LAYOUT> <Control Type="FieldControl" FieldName="Title"/> </LAYOUT> </FORM> </WORKITEMTYPE> </WITD>
Custom work item types can be deployed in two ways: You can create/add your new work item type within a new process template, or you can import/export preexisting work item types (such as a task) and customize them by adding new features.
You can use the witimport and witexport to add and modify work items on the server in an existing project. The Visual Studio 2005 SDK has great documentation on how to use the tools. You can download the SDK at http://www.vsipdev.com.
The best way to get comfortable with customizing work item types is by examining the structure of preexisting types (such as the bug or requirement). Then you can get a feel for where your new fields are and how behaviors can be added.