Inside VSTS
What Can You Use TFS For?
You can repurpose it as a help desk software, for one -- but it takes a little know-how. Jeff walks through the steps.
- By Jeff Levinson
- 07/29/2008
OK, on the surface this seems like a fairly ridiculous question to ask. The
answer is obvious, of course: version control, rudimentary work flow, work item
tracking and notifications.
But lately, many companies have been looking at alternate uses for Team Foundation
System, and guess which one shows up at the top of the list: a help desk replacement.
First, it's important to note the differences between help desk software and
bug tracking software. This will help you understand what roles TFS can fulfill,
as well as what roles it can't fulfill and why.
Help desk software is a bug reporting tool, bug tracking tool, customer relationship
management tool -- that is, it provides updates, keeps histories, and manages
contacts and status -- and knowledge base. It's also used across a wide range
of scenarios: infrastructure tickets, password resets, software bugs, general
help, etc.
A bug tracking tool, on the other hand, handles the technical needs of fixing
a bug. It's a bug reporting tool and a bug tracking tool, and it provides detailed
views into the changes made, who made them, when they made them and why. It
also tracks the status of tests performed on the bug fix, the builds that the
fix is in and the release that contains the bug fix.
In short, a help desk tool is a customer-facing tool while a bug tracking tool
is a technical (development team)-facing tool. Knowing this, what can one piece
of software do that the other can't?
Help desk tools don't track the status of a technical fix (you'd almost never
report to a customer that the bug was fixed in Build 135 but then failed testing
and had to be fixed again). They don't usually understand the internal workings
of a development team and know that bugs get triaged, then fixed, then tested,
then built and finally released. Bug tracking tools don't typically have a CRM
portion; in other words, they don't provide notification to end users and they
don't maintain a knowledge base. And there's hardly ever a relationship between
help desk software and bug tracking software in terms of one system updating
the other and vice versa.
Whew. OK, now that you know what each piece of software is used for, how does
TFS come into play?
TFS handles the role of tracking bug fixes extremely well. It understands your
development process and has definitive flow. In one sense, it does have a knowledge
base because you can search for other bugs of a given type or see how many bugs
have been noted against a given module in an application. Additionally, it can
provide notifications, especially with the release of the July TFS Power Tools
(which you can read more about here
on Brian Harry's blog).
But because TFS was built for a specific purpose (software development), it
doesn't do some things well at all. For one, it doesn't maintain customer contact
information. A bug work item contains the person who created it and the person
to whom it's assigned, but it doesn't contain information on the person who
reported it. Also missing are the nice screens that most help desk software
have with lists of prior incidents the customer called about, the average resolution
time of issues, a listing of all prior and related incidents, as well as "help
scripts." So it would seem that out-of-the-box, it doesn't quite fit as
a piece of help desk software.
Using the customization features of TFS, you can recreate quite a bit of the
help desk software -- but you have to understand that you're using it for a
purpose other than what it was created for and it will require a bit of work.
You can customize work items to allow for the name of the person who called
in and filed the bug. Because TFS integrates with Active Directory, you can
create a custom control which will look up the person's contact information
(or you have to enter it again every time, which tends to make customers upset).
You can also fix the notification tool such that it could send updates to the
customer who filed the bug.
But does it make sense to do that?
In a small company, using separate help desk software is usually not necessary
and TFS can support the role well enough. However, in a larger company, I would
advise against it.
A better solution is to use the available TFS API to plug TFS into a larger
help desk software system to allow for an easy flow of information from technical
systems and back again to provide a seamless experience.
The one thing to consider before you repurpose TFS (even for something other
than a help desk system) is to consider the cost both in customization and maintenance.
Is it better to buy a specialized piece of software? That will depend on your
specific situation, but it does bear some thought as TFS is already a great
bug tracking tool.
About the Author
Jeff Levinson is the Application Lifecycle Management practice lead for Northwest Cadence specializing in process and methodology. He is the co-author of "Pro Visual Studio Team System with Database Professionals" (Apress 2007), the author of "Building Client/Server Applications with VB.NET" (Apress 2003) and has written numerous articles. He is an MCAD, MCSD, MCDBA, MCT and is a Team System MVP. He has a Masters in Software Engineering from Carnegie Mellon University and is a former Solutions Design and Integration Architect for The Boeing Company. You can reach him at [email protected].