Inside VSTS

Inside TFS: Streamlining Development

• By Jeff Levinson
• 06/16/2010

Developers and application lifecycle management (ALM) go together like oil and water. Developers typically (I'm speaking from my experience) see anything that takes away from time spent developing as a waste of time. The problem here is that they are right. Time spent in meetings, time spent answering e-mails -- even if the e-mails are related to what they are doing -- and time spent reporting status is not time spent developing. Reducing the amount of time a developer spends on non-essential items is a key goal of Team Foundation Server (TFS) and it performs very well in delivering this efficiency to the developers.

Developers typically get assignments from project managers through meetings, e-mails or just desk drive-by's. All of these take time away from a developer and confuse an already confusing schedule. In many cases there are no priorities to this work, there is no context for the requested work and rarely is the rest of their workload taken into account. That's where TFS comes in.

The first benefit provided by TFS is requirements and tasks in context -- developers can see and understand where the work fits in. The second benefit is that the person entering the work items (presumably the project manager) can see everything else that is assigned to the developer. They can change priorities or re-assign work to other developers at the same time. The key point here is that they don't continue to give a developer work when that work is overloaded.

At the same time, if a customer asks a developer to perform some work and the developer accepts it, they can create a work item and the project manager will know that things are being added to their plate that haven't gone through them. Or, if you are working on an agile team, maybe in discussion with a customer some new tasks have to be added or the scope changes. This can be easily seen by the project manager.

Note that in both of these situations there were no meetings. No time was taken out of the developers schedule to find out what changed or anything of that nature. All of the information flowed to the people it needed to flow to. And the information flows in reverse also.

Tracking Time
Let me be clear, tracking time is a royal pain for all developers. It isn't something we like to do, it isn't something we want to do and typically we report it wrong anyway. Whenever you see hourly burndown charts (as opposed to story point or task burndowns) you are almost guaranteed to be looking at somewhat invalid data. Sure, the developer may have worked that amount of time but not on the tasks listed there. The main reason is that the data is gathered after the fact. Project managers send out time sheets or developers fill out their time at the end of the week and developers have to remember what they worked on.

With TFS, when you check code in against a work item you can simply open up the work item and enter your time as you do the work. This means that project managers don't have to send you anything and you don't have to send anything back. The information is accurate and up-to-date. And it's very simple to do.

To a certain extent, this built-in functionality extends to application traceability as well. If you are a developer working in an environment where you must create a traceability matrix (think life-critical or heavily regulated systems) then the mere act of checking code in and associating it with a work item satisfies this criteria.

This extends to release manifests for software as well. What requirements went into the release? What files and what versions? It is possible to create a set of reports that answers these questions and more without having to do manual work. I have talked with many release managers who spend hours maintaining a complex Excel spreadsheet with everything they need in it. It is usually accurate, but is the amount of time spent on it worth it when you can just run a report?

How about requirements documentation? Here is an anecdotal story about how the requirements change process typically works. I was on a project and a developer came to me and told me that the requirement was finished. I looked it over and it looked good. The developer had printed out the requirement about a month ago when they started working on it. We took it to the business analyst to demonstrate and review it. The first thing out of the business analyst was "this is wrong." She looked at the document and said that it was the old requirements document and that she had an updated version that she had forgotten to put anyplace we could get to it and forgot to let us know it had changed. Whoops. Requirements that change out from under developers are a common occurrence.

TFS solves this problem by allowing analysts to store documents in SharePoint, which is directly accessible to the developer from within Visual Studio and for which developers can get e-mail alerts when the documentation changes. In addition, the documents could be stored in TFS or linked directly to the work item so the developer is always opening the latest version of the document. Once again, anything that keeps a developer in the development environment and ensures that they have up-to-date information is a more efficient system.

Everyone is trying to be more efficient and process is a key part of this. But technology helps smooth the way for many efficiencies -- at least the right technology does. TFS is the right technology to ensure that developers are part of the solution to overall ALM inefficiencies and that they benefit from the process. But it also ensures that the process benefits from them and gets the information from them in a timely manner and surfaces it to the people who need it. This is TFS at its finest.