Inside VSTS
What Is TFS?
As Jeff shows, it's all about process, process, process.
- By Jeff Levinson
- 06/30/2009
On the surface, this is a ridiculous question. Everyone knows what TFS is. At least, that's what I thought.
Then I realized that maybe there needs to be a better understanding of what it is and why you want it. I decided to devote this article to a discussion of what TFS is and how you go about accepting it into your organization -- and it is an acceptance, because TFS is not just another tool.
Team Foundation Server (TFS) at its heart is a process improvement tool. Oh, sure, there isn't any guarantee that your process will improve because you're using it, but if that isn't your goal then you may need to rethink your decision to use it. TFS is not just a version control tool. Or rather, it is a version control tool -- and an excellent one at that -- but using a version control tool isn't difficult and really doesn't require a lot of thought or acceptance. A version control tool is used by a team or teams and versions their files. That's it. If you're using TFS only for version control, then you're wasting your investment. It's the rest of TFS that makes it truly special.
TFS is all about process. It helps you implement your process to increase efficiency. It tracks your process to tell you if everyone is following the process and whether you're making progress. And this is a key thing to note: It is all about the progress, not the tool. We are software developers, which means every tool we use should advance the goal of making software, as TFS does.
TFS also collects metrics -- all kinds of metrics. Metrics not used equals wasted time, in both their collection and their reporting. Being able to show cool reports doesn't provide value. But being able to show a report that says "We have a problem, let's fix it" is cool. Better yet, being able to show a report three months later that says "We had a problem, but we fixed it -- see!" is very, very cool. I would pay money for that. That's what you paid for when you bought TFS.
The question is, are you using the money you invested wisely? Is TFS giving you that return on investment? Have you saved more through efficiency gains, productivity gains, higher quality and higher customer, developer and management satisfaction, than you're paying for in licenses? If not, the answer isn't to say that TFS hasn't lived up to its reputation. Ist's that it isn't being used appropriately.
So how do you use it the "right" way? The first is to determine where you need to make improvements. That's easy; every developer usually knows what the problems are. It isn't a secret.
Next, you need to figure out what information is going to help you quantify the problem. That is, what metric identifies the problem and would show an improvement. There's a fairly old saying that goes something like "If you can't measure it, you can't improve upon it." Start measuring -- that's what TFS is for. Make a change that is going to bring about a positive impact on the item you're having a problem with. And repeat your measurements over time. If you've set a goal for where you want to be, and that goal is quantifiable, then you can determine your progress.
That's what TFS is for. That's what it does well. A discussion of TFS always has to include a discussion of process. If you are talking about TFS and not talking about process, then you're wasting your time.
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].