icrosoft’s Visual Studio Team System (VSTS) focuses on the issue of dealing with complex software projects built by a large team. VSTS has all the ingredients needed for a distributed work team of architects, developers, documenters and testers. That’s great for large teams, but what about small teams? Do VSTS’s benefits apply equally to smaller teams? As you might suspect, the answer is, it depends. In this article, I’ll give you a look at VSTS from a “small-team” point of view.
Is VSTS Right for Your Team?
One of the best ways to determine if VSTS is right for your team is to understand what it does. Microsoft has a wealth of Team System information on its Web site, including white papers, case studies, and how-to documents. The Visual Studio Team System Developer Center includes specific sections for the distinct roles addressed by VSTS along with evaluation versions of the software.
VSTS defines roles by specific functions within a team, including predefined roles as database professional, software architect, developer, tester, and project manager. VSTS tailors the user experience and the different capabilities of VSTS to each particular role. Having all these different roles seems to imply that your team is likely to have one or more individuals to fill each role. That’s probably a fair assumption for large teams, but in smaller teams, individuals often fill multiple roles. How do you know if your small team will really benefit from a tool that was designed for much larger organizations?
One way to approach the question is by looking at the definite and possible benefits of VSTS for small teams, and also at features it supports that smaller teams or projects won’t need. After doing that, you’ll want to look closely at what each small team does to see how closely its needs match the listed benefits.
Definite Benefits
VSTS will definitely benefit any team with heavy auditing, bug tracking, reporting, and traceability needs. One example of an early-adopter company consisted of a three-person development team working on back-end credit card processing. This team adopted the full Team System suite and the client software mainly to take advantage of the work item tracking and reporting features. Using the automated reporting tools made it possible for them to provide their customers with a complete history of code changes and completed tests as a part of their QA process.
VSTS also provides huge benefits for any team that has to support multiple releases of a software product. Managing multiple releases of a software project is a task best handled with automation. VSTS has a sophisticated build/release management toolset that greatly simplifies the process of building specific software versions. It also makes it possible to initiate a build across the entire team. All check-in activity is sent to a data warehouse kept in a SQL Server database.
Companies who maintain a large source code base are also strong candidates for VSTS adoption. Source control in VSTS is joined at the hip to work items. New code can be associated at check-in to a work item, and any modification of existing code is automatically linked. Reporting tools use these links provide detailed reports, such as showing all changed modules tied to a specific work item (or bug).
Possible Benefits
Identifying specific benefits for your situation will help you decide whether it makes sense or not. Automation is one of the primary benefits of VSTS for any size team. For small teams this is especially useful in the testing arena. VSTS automatically generates code for unit tests to make the overall acceptance and testing process easier. Producing quality code is directly related to the amount and thoroughness of the testing performed against that code. VSTS makes that task easier and integrates it with the entire development process.
Another factor to consider is roles within your team. Small team members frequently change job functions in an agile fashion; a team member could be a coder one day and a designer the next. VSTS provides consistent menus and user interfaces to help make such transitions between roles much easier. The VSTS project portal lets team members and administrators to view any team system report directly from a standard Web browser. You can also get VSTS information directly into Microsoft Excel and Project for analysis or planning purposes.
Collaboration is something many smaller teams don’t often think about, because their team members often sit in close proximity to each other. But collaboration becomes critical for distributed teams?especially when the team members are separated by large distances. VSTS provides a number of unique capabilities, including the ability to access things such as events programmatically. For example, you can hook up the event system to an RSS feed so team members can easily view events such as code check-in, build, and test results in their news readers. Even for team members in close proximity, the ability to receive such notifications?and have a record of such events?can provide significant benefits.
Finally, SharePoint 2007 includes a number of new collaboration features currently unavailable to VSTS, including wikis, blogs and more. Even though VSTS can’t take direct advantage of these new features with the current version, integration with SharePoint is on the VSTS team roadmap for a future version, which will further extend its collaboration capabilities.
When VSTS is Unnecessary
Moving a legacy project over to VSTS that’s approaching or at its end-of-life and that won’t see any significant new development is really not worth the trouble. While you can migrate older projects to VSTS, it’s not a trivial task. This section on MSDN describes the process and provides step-by-step procedures for moving files from Visual SourceSafe, and for migrating work item tracking from ClearQuest.
Small software projects built for a small audience with Visual Studio are probably not worth the trouble either. Many of these sorts of projects don’t even use source control, so the features in VSTS are overkill. Still, projects do tend to grow?sometimes dramatically. For example, many teams come face-to-face with lack of source control, work items, and other management tools when a small project not originally intended for wide release suddenly gets picked up by the entire company. In such cases, adding VSTS might be just the prescription.
When Might VSTS Be Necessary?
The primary questions you need to answer to determine whether VSTS might be a good fit for a smaller team are:
- Do your team members serve in specific roles, and would they be comfortable in or switching between the role definitions that Microsoft defines for VSTS?
- Does the team work on large projects, with a large source code base?
- Does the team support multiple tailored releases of a project?
- Is the team comfortable with build/release automation?
- Does the team need robust bug-tracking, work item assignment and reporting, and the ability to trace code back to its source?whoever or wherever that might be?
- Is the team distributed? Alternatively, could the team benefit from VSTS’s collaboration features?
If the answer to one or more of those questions is “yes,” the team is a potential candidate for VSTS. If the answer to all the questions is “no,” then that team may not need VSTS now; however, if they’re working on a project that’s likely to continue to grow, you should revisit the questions in the future?at some point, small projects become large projects, and using small-team techniques becomes unwieldy.
Overall, deciding whether to move your team to VSTS is not a trivial problem. The cost difference along between a standard version of Visual Studio and a full-blown version of VSTS is significant. You should take the recommendations in this article into account and factor in the potential development time and reduced effort that VSTS can deliver before making a final decision. Then just do it.
