In the current (August 2011) issue of MSDN Magazine, Mohammad Jalloul wrote a feature titled “Build a Ticketing System Using Exchange and Team Foundation Server,” which looks at how Team Foundation Server and Exchange can be used together to bridge the gap between work item tracking and email correspondence. MSDN Magazine Features Editor Sharon Terdeman caught up with Mohammad and posed a few questions to him after the August issue hit the street.
MSDN Magazine: How did you get interested in TFS in the first place?
Mohammad Jalloul: My initial interest in TFS stemmed from the fact that it provided an easy-to-manage version control system in addition to an extensible and powerful work item tracking system. Prior to that, I used enterprise-level products like ClearCase and ClearQuest from Rational (now part of IBM). However, they were not well integrated even though they were built by the same company. TFS provided clean integration between the version control and the work item tracking system.
MSDN Mag: What made you start using TFS?
MJ: Being at a company that wanted to adopt Scrum at the time, TFS was a natural choice as it enabled linking the work items with the checked-in code. That choice was further solidified when we decided to utilize the Scrum for Team System TFS Template, which included Scrum-oriented work items.
What problems did it solve for you?
MJ: “Why TFS?” is a question I get asked very often. It is usually followed by: “Why don’t you use Subversion or Git? They are cool and free, and everyone uses them!” My simple answer is typically: “Yes, Subversion and Git are free. Yes Git has support for distributed source control management that TFS 2010 currently lacks. But, the fact remains that there is no one product in the market right now that has the same or equivalent set of Application Lifecycle Management (ALM) tools well-integrated into one single product.” TFS 2010 offers integration between source control, work-item tracking, test case management, reporting and SharePoint dashboards.
What exactly are work items in TFS?
MJ: TFS work items are a mechanism by which work can be tracked by project members, whether they are developers or business users. A work item’s definition consists of the fields constituting the work item, a simple user interface layout definition that helps Visual Studio and Team System Web Access (TSWA) in displaying a work item, and a workflow that consists of simple state transitions that give the work item a true, albeit simple, lifecycle.
Work items also support linking to other artifacts in TFS. A work item can be linked to other work items, to file attachments or even to checked-in code. This means a Bug work item, for example, can be used to track the lifecycle of a product defect from inception until it gets resolved, and the work item gets linked to the source code that was checked in to fix the defect. A work item supports revision history. So, anyone can add comments to the work item throughout its history or even link it to documents.
The TFS product team has done a great job of exposing the different features that work items support, and people have been creating their own customized work items. Probably one of the most customized work item types is the Bug work item. Different organizations have different structures for a bug template, which they typically translate into their TFS version of the Bug work item. Third-party companies have been great at utilizing work items. For example, there are work items for representing and utilizing different agile processes, like Scrum.
What made you pursue this topic the way you did in your article?
MJ: My article demonstrates a different approach for implementing a simple ticketing system. Using work items as support tickets is actually not a new scenario or use case. Many people have already done that. However, every one of the implementations I’ve seen involved building a complete system around work items, and forcing the different people that are part of the support ticket lifecycle to either use Visual Studio or TSWA, or use a custom-built user interface to update the work item. This means they have to learn how to use a new tool.
This should not be required. Software should exist to simplify the process and not to create an additional burden. It should make an existing process more efficient rather than create yet another new process and force you to learn that. The article presents an approach that helps maintain an existing process and uses the magic of software to tie the pieces together without the users having to be aware of all that integration.