While Visual Studio has always been the de-facto standard for writing solutions based on Microsoft technologies, savvy developers have often extended it with additional tools to help them better handle the increased complexity of today’s applications.
My team is no different, and, over time, we incorporated all sorts of extra tools, using a pretty aggressive “buy/build/open-source” strategy.
To my great surprise, early last year I heard about the plans to release Visual Studio Team System (VSTS) and Team Foundation Server (TFS); I was under non-disclosure agreement, and getting the news directly from the mouth of Somasegar (Corporate VP, Developer Division) contributed to create a certain level of expectations.
In the months that followed the release, I attended to a few presentations on the topic and the excitement was soon replaced by a bit of disappointment.
It was evident that Microsoft was mostly targeting enterprises that had already plenty of money to invest and was somewhat ignoring smaller realities.
I also felt that existing open source tools were already providing equivalent or better support for well known problems such as unit testing, code coverage, static analysis, version control, continuous integration, etc.
I started considering a slightly different perspective only recently, after I attended an excellent presentation organized by Microsoft Ireland on the subject of agile development, VSTS and TFS.
A few days after that event, I decided to download a trial version and take the system for a good spin.
This time, instead of focusing on the specific developer tools (which I already knew) I concentrated on the architecture, the customization capabilities, and the extensibility points.
I came to the realization that VSTS has a lot more to offer than a simple integration of tools; it simplifies the process of building software by providing better visibility across the various roles involved (e.g. developers, project managers, business analysts, testers, etc).
It is also a very extensible platform; if we don’t like a process or a tool we can bend the system to adopt a better one.
So, do we “need” VSTS?
As usual, it depends.
In our case, we have already created a process that we re-examine and refine frequently; we have tons of tools, workflow capabilities, reports, and excellent metrics we work with.
Although the early days are long gone (when we could simply track our progress on a whiteboard), we can still rely on a healthy dose of verbal communication; after all, the first commandment of the agile manifesto states that we value (more):
Individuals and interactions over processes and tools
Admittedly, building all this didn’t happen overnight, so I can see why other teams may choose a different path and consider using VSTS.
Have any of you guys seriously tried it yet?
