As I said in the previous post, the Work Item feature of the current version of TFS is already great, but everybody knows there’s room for improvement.
So far, here are the pros and cons I see in the current state.
- Integrated in the Development Environment as well as Web Client: developers, PMs and stakeholders can all have access to them.
- Can be linked to code: the code is no longer the referential or entry point of you evolution and fixes.
- Highly extensible and customizable: you make them fit YOUR process and not the opposite.
- User friendly: it’s always better for a quick adoption because the learning curve is really smooth.
- Traceability of changes: for CMMI lovers (or slaves!?).
- Workflow based: simple but there’s no such things on Words for instance.
- The linking system is too limited concerning Work Items: all you can do is create an unversioned, two ways link between two Work Items.
- No MS Project Server integration.
- Rich editing too limited to store high level information.
- The Query system is good, but it’s hard to get a good visibility when you have a lots of Work Item, issue mostly due to the first stated one.
- Lacks some automation between them: for instance it could be nice to automatically “activate” a Code Review Work Item when a given Task is ready to be reviewed in order to notify automatically the reviewer.
Most of the feedback I had from PMs and Lead developers was that Work Items was great, but it was hard to have a clear global view of what was going on and maintaining everything to keep it synced was a costly task. In other words: “one by one it’s great, but when we have a bunch of them, it’s harder and we are lost!”
I honestly don’t know if this is an issue a lot of users have or not. If I speak for myself, I always tried to make the Work Items a “Project database/view” of the developments, organized the same way as MS Project but with all the features the Work Items can offer and it wasn’t really possible.
I know you can use them from Project, most companies/team I’ve seen were working with Project Server, with many MS Projects for one Team Project, and Resources spread across multiple projects. Well, something you can’t achieve with the current state of things.
Ok, so let’s finally start with concrete stuffs! [:D]
So what’s new now? Many things including: Link types, typed link view control (in the Work Item Form), queries using links, hierarchical representation, etc.
The new link system
Finally, something that many people waited for is arriving, a real linking system for Work Item. I wished I had it for the 2005 version then I wouldn’t have to write that…
As stated above, the current version of TFS have a simple linking system, all you can do is link a Work Item 100 to another one, say 90 (then 90 references 100). A link will be created, it won’t appear in the history (because it’s not versioned) and finally your Work Item 90 will automatically be linked to the 100 too (100 will reference 90)! If you go looking in the databases of TFS, you quickly understand why it’s done that way…
When before you only have one choice to link together two Work Items, you now have infinity of choices through the creation of your own Work Item Link Types.
Of course, there’s already some predefined ones, let’s summarize them briefly.
|Reference Name||Friendly Name||Forward Name||Reverse Name||Description|
|System.LinkTypes.Related||Related||Related||Related||Bidirectional link of two Work Items. Pretty much the same behavior as the current link type.|
|System.LinkTypes.Hierarchy||Hierarchy||Child||Parent||Create hierarchy between Work Items through the Parent/Child relationship.
Note that children are unordered.
|System.LinkTypes.Dependency||Dependency||Successor||Predecessor||Create a dependency between two Work Items through a Predecessor/Successor relationship.
You typically have to fulfill the Predecessor before working on the Successor
These are the three system types defined so far. If you look deeper, you will find in both Agile and CMMI process templates a definition of a custom link type:
<LinkType ReferenceName=”Microsoft.VSTS.Common.TestedBy” ForwardName=”Tested By” ReverseName=”Tests” Topology=”Dependency” />
The attributes speak of themselves…
The Links Control
Speaking of Link Types, how do we link Work Items together now? Well, there’s a new Work Item Link Control named “LinksControl”.
Among its new particularities:
- You can have more than one of these controls in your Work Item Type definition.
- The control will display links based on a preconfigured filter (still declared in the WIT definition).
- You can create a WIQL (Work Item Query Language) from its content. This one may looks not much useful at first, but as far as I saw, only direct links are displayed in the Links Control, which can be very limited concerning viewing the hierarchy. We’ll see later than converting to a WIQL can solve this issue easily.
There’s also a new dialog to create a link:
You can see in the dropdown all the types of links you can create, it should fulfill the needs of almost every projects, don’t you think? [:)]
Ok, I will create three Work Items: a Requirement, a Change Request and a Task, linked all together.
Looking in the Links control of the Requirement, we can see only the Change Request work item, as suspected only direct children are displayed.
So what can we do if we want to display the full hierarchy? Apparently the only way is to use the Queries.
Let’s try that quickly!
First we create a Query from the Work Item by clicking on the View As Query button from the Links toolbar:
The result is not quite what we expected:
The query still shows only two Work Items, and not the child of the 336 one.
If we click on the Edit Query button on the Query Window toolbar, we will maybe able to tweak things.
Here is the top part of the Query Editor Window
Sounds like the Type of Query being Work Items and Direct Links is the reason why we can’t see more.
The different choices available are:
I guess the last choice is the good one! So I change my type of query to Tree of Work Items and refresh my query.
After saving the query, the displayed result is what one would expect:
Finally I have my full hierarchy displayed, great!
Now look a bit closer to the four little buttons I highlighted in read, using the first one will change the layout of your query window to a more explorer friendly one:
The result is pretty cool, but you better have a wide screen to get all the information you need. Using a grid to display hierarchical information has the inconvenient to take a lot of space.
To conclude, I think the hierarchy will be useable for real life projects, and that’s the most important thing!