Modifying Work Items
Before starting to modify work items, it's worth exploring why
you would want to modify them in a process template. Many teams will find that one or more additional work item types are necessary to support their
development process. For example, you may find that a given work item type does not provide fields to capture the relevant details of the item. You may also decide to limit the transitions that are allowed between the various states of a work item to aid in support of a process flow, or make certain fields required to submit a work item. These are but a few of the possible reasons to modify the work items in a process template.
Work items are defined in the process template using an XML file. You can find them in the \WorkItem Tracking\TypeDefinitions
directory in the downloaded process template directory. Notice that the list of work item types provided in the TypeDefinitions
directory matches the types that can be created inside Visual Studio. Figure 5
demonstrates the process used to create new work items from within Visual Studio.
|Figure 5. Creating Work Items in Visual Studio: The figure shows the various default work item types that Visual Studio users can create when using the MSF for Agile Software Development process template.|
The type definition file for each work item uses the same overall structure. Open the bug.xml
type definition file to observe how the file is organized (see Listing 1
). First, you'll see the work item type's name and description, followed by the list of fields for that work item. Each field can include help text and rules. The rules help by providing default values for fields, forcing values to be entered in required fields, providing lists of acceptable values for dropdown fields, etc.
The next section of the type definition file defines the workflow for the work item. The item's workflow is based heavily on the state field assigned to the work item. In fact, unlike the manner in which other fields' acceptable values are defined, the allowable states for a workflow item are defined in the workflow element of the type definition file. The Agile process template defines Active
, and Closed
states. Each state contains a list of field rules. The type definition specifies that a bug in the Active state will have the Resolved Date
, Resolved By
, Resolved Reason
, Closed Date
, and Closed By
fields empty. These rules make sense because an active issue is neither closed nor resolved. Other states define similar rules.
Finally, the last major section of the type definition file describes how Visual Studio should render the fields on the form. If you compare the element hierarchy under the Layout element to the visual layout of the bug work item form, it is easy to see how the Layout section of the XML document relates to the rendered form.
The real workflow magic comes in the definition of transitions between states for a work item. By modifying the rules defined for transitions, your team can define a workflow based on the team's existing processes. As an example, the bug work item type definition specifies that when a bug work item is moved from the Active to the Resolved state, several things should happen.
- The file defines a list of reasons that allow users to specify why the state is changing. In this case, the acceptable values are Fixed, Deferred, Duplicate, As Designed, Unable to Reproduce, and Obsolete.
- The Assigned To field will be populated with the value of the Created By field.
- The Activated Date field will be made read-only.
- The Activated By field will be made read-only.
- The Resolved By field will be made required, must be set to the name of a valid user of the system, and will be defaulted to the name of the current user.
- The Resolved By field will be set to the current time on the server.
Other transitions are defined, but all are similar to the functionality defined for the Active