|
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.
1. Fields
2. Layout, and
3. 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 |
|
