I continue my journey on the evaluation of the latest CTP of Visual Studio 2010 (formally known as Rosario), now is the time to play with one of my favorites part of TFS: the Work Items.
I can really say that the Work Items were for me the main reason I start evangelizing Team System in its early days. I really saw into them the possibility (finally!) to gather all information about a project development into one unique repository, and let people from any kind of role access to them.
I know this is not totally the case, but it tends to be more and more at each release of the ALM platform.
I’ve seen a lot of projects managed with many tools, with the same information found multiple times across them, with people having to move it or synchronize it from one to another. Working this way has a cost and is risky too, and I have suffered from these many times.
So Work Items were for me the light for better days coming, nothing can be perfect at first, but I was a strong believer they will fill all the needs through time: what I saw was great, the potential was there, and well, it’s built by Microsoft and we were already pretty surrounded by Microsoft software, it can only help! [:D]
Nowadays in projects, Work Items don’t store everything. The reason behind that is a mix of technical limitations and the fact that the team is not prone to change its way of working.
For these reason, they were most of the time introduced to contribute to a limited part of the process, coexisting around already long time adopted software, trying to steal data from them! [:)]
With TFS 2005 and 2008, I intend to use the Work Items when the following criteria are met:
- Need a workflow, potentially involving many people.
- Need for traceability of the information.
- Need to link the information with the code.
In practice, I ended most of the time using Work Items in these scenarios:
- Task driven development, with an optional Code Review.
- Previous scenario plus defect tracking and change management.
- Previous scenario plus risk and issue management.
Depending on the teams and projects, these different scenarios were using Work Items to take care of different things. Take the Task one for instance: it could handle Triage, Work Partitioning, Planning, Time Tracking, Scoping (through Iteration and Area Path), etc. The task could be interoperating with MS Project for Planning and Time Tracking if the team used the software.
I of course tried to use Work Item for “everything”, considering that having relationship and full traceability between Requirement, Specification, Design, Development, Review, Testing and Code would be, well, nice!
For instance, storing requirements and specifications in Words document won’t give you traceability matrices, a good management of history, and won’t be a part of the common repository for project information (i.e. the Work Item Store), etc. Every change leads to human actions to update the related artifacts, this is error prone, and time consuming, in other words: not good !
So it would have been nice to use Work Items to store those information decomposed at a very small level, to have the possibility to build a traceability matrix that warns you of broken/out-of-data specs when requirements change.
So, this preamble is meant to explain what I expected from Work Items, how I use them (because I don’t think there’s only one way to use them).
The following posts will be in depth evaluation of the news features, and we’ll see if Work Items can solve problems we had, do more things than before.