Customizing
TFS Work Items
Introduction
A
Work Item in common parlance is considered to be an instance of effort/work
being carried out by an individual. Multiple instances of Work Items eventually
culminate into the delivery of a service or a product that is meant for a
customer.
Team Foundation
Server Work Items
Depending
on the approach one adopts for managing an application life cycle i.e. from
requirement gathering to actual delivery/deployment, there are various work
item types that will be instantiated and persisted into a database. As business
needs and the processes thereof are dynamic, and disparate, customizing a Work
Item, hence seems to be inevitable. It is therefore essential to understand the
anatomy and thereby gain the basic understanding of customizing an existing
work item type, or even adding a new work item type.
The
Anatomy of a WIT(Work Item Type), in TFS has three essential parts, viz.
-
Fields
-
Layout, and
- Workflow
Fields
In
TFS there are approximately 57 “Field Reference Names”, mapping to base/native
types. This is an extensible set. In
keeping with the .NET namespace tradition, two namespaces are predefined:
System and Microsoft. The System namespace includes all system fields that are
mandatory for Team Foundation system functions. The Microsoft namespace defines
all required fields for work item types defined by Microsoft. Customers and
partners can create their own field namespaces for custom work item types. We
could define our own namespaces, for e.g. a WIT for tracking leads could have a
field with a reference name of “Synergetics.LeadManagement.CustomerName”. This
in turn could be of a base type “String”, having a name of “Customer Name”, as
shown in Figure 1.1
Figure
1.1
Layout
In
this section, you map the reference name of the field to a control. The control
is the user interface for capturing the required data, and can be customized
with a “Type” property to perform necessary validation and change the look and
feel, as shown in Figure 1.2. A “Type” property could a “FieldControl”, “DateTimeControl”, or even a “LinkControl”
depending on the data requirement.
Figure
1.2
Workflow
A
wok flow is a series of linked steps which would be used to declare transitions
to different states, in the life time of a work item. Transitions would be
declared, or provide links between states in a WIT work flow, using a graphical
UI, as shown in Figure 1.3
Figure
1.3
As
an example, the transition from “Active” to “Closed”, will occur for the
reasons:
Obsolete,
Chose Competitor, Project Cancelled, Too Expensive, or Offer Accepted;
Wherein default values and rules for the
fields Assigned To, Activated Date, Activated By, Closed By, and Closed Date
are also declared.
The
Actions, provides the events under which this transition is deemed to occur.
To
conclude customizing a WIT in TFS is a simple, code free effort and can be done
within a short period of time, actually hours if not minutes. The key is to
know the process and identify the flows, further to which each flow could be
encapsulated as a WIT.
Interestingly,
as may have been observed, the example used to explain the anatomy and steps,
are for a WIT which captures and tracks non development efforts. If you are
wondering why would I use TFS to do such a thing?! Well, think about support
calls that one would want to capture, post deployment of a product/application.
Thanks
for spending time in reading this blog, and sincerely hope it may have helped
clear some doubts on the WITs in TFS.
Cheers
& Have A Nice Day Ahead!!
About Author: Sanjay Jotwani is Technology Transformation Group Leader.
Synergetics India:
IT consulting and Training services on .NET 4.0, SQL server 2008 BI. Awarded as
the Best. NET Training Service Provider by Microsoft.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5