Collaborative development has been very difficult in the past. Although knowledge workers have used computer-aided collaboration tools for several years, such tools are practically non-existent among developers. Most developers work in temporary vacuums, only interrupted by file sharing through a source control system, such as Visual SourceSafe or a third-party offering. Lifecycle tools are often complex and disjointed.

Development teams need to use tools from various third party vendors, most of which are not integrated. And to make matters worse, different groups of people involved in the development process have to use tools that are not just disjointed, but often follow entirely different paradigms. Tools used by the quality assurance group are probably entirely different from the tools used by developers or by project management.

Luckily, Microsoft is just about to deliver a great solution to this mess.

Visual Studio 2005 Team System

I write these lines fresh from Microsoft's TechEd 2004 in San Diego, California. One of the major announcements Microsoft made was Visual Studio 2005 Team System. Team System (formerly known by its "Burton" code name) is a suite of tools that can be used by all people involved in a software project, including management, development, quality assurance, architecting, customers (users), and more. The actual number of components involved is mind boggling.

Team System also allows third-party additions. Microsoft clearly realizes the size of the collaboration and integration problem and that a single company (even if it is large as Microsoft) is not likely to solve the issue alone.

A major complication of collaboration is that there are as many different development processes as there are development teams. The palette of processes ranges from ad-hoc "code slinging" to extremely strict processes such as RUP (Rational Unified Process). Team System accommodates all of these processes by allowing a very large degree of customization. Microsoft will ship a number of templates with Team Systems, allowing teams to simply install it, pick a process, and hit the ground running. But those are just default options that can be changed completely.

So what exactly is Visual Studio 2005 Team System and what can it do for you? This question is a bit hard to answer, as the answer varies depending on your role in the development process. Let's take a look at some of these roles in more detail.

Project Management

If you are a project manager, Team System accompanies you throughout the entire project lifecycle. From a project manager's point of view, a large part of Team System revolves around "work items." Work items can be any type of information that can be kept in a list, such as requirements, bug reports, change requests, and so forth. Microsoft will ship a number of work item templates, but those can also be customized, and teams will be able to create completely different types of work items if they so desire.

The work items system provides a large range of functionality that is not immediately obvious. For instance, Microsoft has so far not emphasized that Team System includes a complete bug tracking system under the work items umbrella.

Project managers can deal with work items in a number of ways. Work items can be synced into Excel spreadsheets as well as MS Project. Work items can also be used for real-time reporting and for information sharing through Share Point portals. And work items can also be synced into third-party offerings, such as Borland's CaliberRM.

What makes work items extremely valuable is their up-to-date nature. In the past, project managers were forced to draw the entire team into status meetings to have a somewhat current view of the project. Work items, on the other hand, are integrated throughout all tools and used across all roles. This means that project managers (as well as other team members) always have an up-to-date view of what is going on in a project.

Note: Many of these features are provided through a server-based application that can be installed on your own server infrastructure. This service is known as Team Foundation Server (TFS). Although TFS is not a required part of Team System, it is what provides the tight integration between various components of the system. Small teams may prefer a slightly less formal and less interconnected approach without TFS.

Designers and Analysts

If your job is to design applications, Team System is the greatest news since sliced bread. There are a number of analysis and design tools, including class diagrams, deployment diagrams, and application diagrams. (This suite of tools was formerly known as "Whitehorse"). What is unusual about all these diagrams is that they are live representations of underlying architecture or code. A class diagram, for instance, is simply a visual designer for a class that exists in source code. No synchronization is required.

The same is true for deployment models. A Web server in a diagram can be connected to underlying servers. Let's assume you design a Web server that uses SSL (HTTPS). This requires the server to support that technology. Using Whitehorse, the architect can immediately evaluate the design and discover whether the server supports required components. Similarly, Whitehorse is aware of policies and other restrictions that may apply to a server.

Of course, all this technology ties directly into the work item system, providing up-to-date information to the rest of the team.

Developers

Developers get a very large suite of tools from Team System. Of course, developers have access to all the work items just like all other team members. For developers, this typically means access through the Visual Studio IDE. Developers also can benefit from the tools available to the modelers, as many of the Whitehorse tools are just a different way to view code. As developers update classes, they can immediately look at the impact their changes have on the design. They can verify whether technologies used in programming are valid based on the infrastructure the code is designed to run within.

But there also is a suite of tools for developers only. Source control has been given a lot of attention. A serious Visual SourceSafe overhaul has fixed many problems, such as remote teams who want to use the Internet for connectivity. However, Microsoft didn't leave it at that. In fact, TFS includes a completely new source control system that goes way beyond the capabilities of Visual SourceSafe. The sophistication of the new system is such that it should really be considered a "Source Asset Management System" rather than a source control system.

In addition, developers will access to a number of tools that are geared toward code quality improvement. A nifty little tool allows developers to define code snippets that can be used throughout the development effort. (Snippets do not just replace copy and paste operations, but can be scripted in many ways.) This is a great way to standardize on and implement certain approaches.

There is a coverage testing tool that is very well integrated into Visual Studio and can display coverage results through special source coloring options. There also is a static code analysis tool that can perform automated code reviews or aid code reviewers in their tasks. This tool has great flexibility in what is analyzed and what it looks for, which is great to find problems such as buffer overruns, forgotten Dispose() calls, coding convention adherence, and much more.

All these tools are very tightly integrated. For instance, team leaders can create policies that are applied to the check-in process, such as a policy that requires running static analysis on code before it is checked in. In addition, the policy may require a work item to be associated with the check-in and certain comment fields to be filled in, before the check-in can take place. (The exact rules laid out by the policy are up to the team manager.)

Quality Assurance

Testers also benefit greatly from Team System, as Microsoft has created?wait for it?a whole suite of tools for quality assurance. There is now integrated Unit Testing, which can be used by developers as well as testers. Of course that's only part of the QA story. Team System also features load testing tools that can test a system under all sorts of conditions. To enable testers to provide more sophisticated feedback to developers, .NET now provides a whole set of new performance measures. UI testing is not currently part of the suite, but integration with third party tools already exists.

As you can imagine, part of the power of the quality assurance process in Team System is the tight integration. Let's assume a test run has discovered performance bottlenecks. These might be hard to reproduce by the development team. In Team System, testers can simply include test results with work items (bug reports), allowing developers to find out more information about the discovered problem and even "replay" the exact test. An interesting detail here is that developers have access to information that testers may have overlooked. For instance, a developer may be interested in a certain performance counter that was not part of the information the tester looked at. Under the hood, that information was collected anyway, and developers have full access to all that data.

Developers will also make use of tools such as Unit Testing. In fact, Unit Testing can also be used for things such as check-in policies, allowing team leaders to ensure that no untested code is ever checked into source control.

Above and Beyond...

Team System has a lot more to offer. There is a whole new build process, for instance. The build process can be run server-side, making tasks such as automated nightly builds a piece of cake. By now you probably expect it: the automated build process is much more sophisticated than anything already available to most developers. The build process integrates with source control to make sure it utilizes the latest code. Once the build process has retrieved the appropriate source code version, it can perform a build, unit test the code, and run a static code analysis to make sure the build succeeded. If a problem with the build is discovered, the build process can take action, such as paging the project lead.

Thanks to the interconnectedness of all the subsystems involved in Team System, the whole team has access to a vast amount of real time data, reports and statistics. Did you ever wonder how much of your code base changed from one build to the next? Or perhaps you would like to know how the bug count relates to the amount of changed code. If a certain developer has a high bug count, is that due to bad habits, or does he simply inherit a lot of bad code from other team members? Or do the other team members have poor test coverage and fail to discover their bugs? Who managed to resolve the most bugs without causing other problems to occur? These sorts of questions can be answered by Team System without any extra effort for the project manager.

Conclusion

Visual Studio 2005 Team System is exciting! Not in the same way Longhorn or Avalon are exciting, but for everyone who strives to achieve higher software quality, this is incredibly cool. To me personally, Team System has been one of the most exciting announcements in years, as software lifecycle management is a topic that has been important for me for a long time. (In fact, the very first contracting job I ever did for Microsoft almost a decade ago had to do with object modeling in Visual Studio.)

The only bad part is that you will have to wait for Visual Studio 2005 to release, before you can take advantage of many of these features. You can make sure you are ready for that though, by downloading the latest technology preview build from Microsoft's MSDN site (http://msdn.microsoft.com). And as you would expect, you can also look forward to a number of articles on this very subject in the upcoming issues of CoDe Magazine.

And now, if you will excuse me, I have to go and teach my team of developers and consultants all about the great features of this new platform...

Markus Egger