Yesterday I attended a session about Visual Studio 2005 Team System at Tech-Ed 2005 Europe. Microsoft's goal is to make the developing proces more productive with the help of Team System.
Developers adding features that don't map to requirements, they argue with the architects and testers are sitting around workless, while the deadline is coming near. This kind of scenario is what Team System should help prevent.

A point was made out of the notion that the Source Control part of Team System ISNOT Visual Sourcesafe. Visual Sourcesafe was designed for small teams. The sourcecontrol part of Team System is being designed and built from the ground up.
Microsoft wants the Windows team to use Team System eventually, to show they are committed to this product. In this mindset they even offer small developingteams (I believe up to 5 developers) Team System for free, if they only have client licenses. This to show how much they like us to use Team sytem.
The idea is to let every member of the developingteam use the tools they are familiair with. The projectmanagers use MS Project or Excel, developers use Visual Studio and they all can continue to do so with Team System.

Visual Studio 2005 Team System is designed to achieve four goals:

  • Be productive by reducing the complexity of delivering modern service-oriented solutions;
  • Be integrated with all tools and facilitate better team collaboration;
  • Be capable by being robust, secure and scalable and by having the ability to work remotely
  • Be extensible by allowing processes to be customized

The last goal means that third parties must be able to introduce Team System addins. The presentation showed a third party Linux tool that works with the Team System Server (same functionality as the windows client over https). So it looks like that goal is being taken seriously.

Team System supports methodologies and two are being included with Team System:

  • MSF for Agile Software Development
  • MSF for CMMI Process Improvement

Microsoft Solution Framework for Agile Software Development
MSF Agile is intended for smaller shops (5 to 20 members) and the tenets that Agile agrees on are:

  • Individuals are more important than processes and tools
  • Customer collaboration is more important than contracts
  • Working software is more important than comprehensive documentation
  • Responding to change is more important than following a plan

Quality and constant delivarebles define an Agile process. Agile is the default methodology for Visual Studio 2005 Team System.

Microsoft Solution Framework for CMMI Process Improvement
CMMI stands for Capability Maturity Model Integration. It's goal is to provide a model for continuous process improvement. It should result in reduced software development-lifecycle times and improved quality. If your organization is trying to achieve a measured baseline competency in software development this is an excellent process to use. For the bigger organizations that need a more formal development process that reduces risk on large software projects this is a good process. It provides a measurable baseline that can be used to achieve certifications in ISO 9000/9001.

How does Team System support methodologies?
Team System takes a workstream approach.
It defines a process by offering a collection of activities and subactivities. This model fits well with most Agile methodologies.
For example, Team System knows about the WSF Agile elements: roles, activities, work streams and work items.
Roles: Project manager, developer, architect and tester.
Activities: Provide guidance to a task performed by a person playing a role in a project.
                 Activities are grouped together in work streams.
Work streams: Groups of related activities associated with one or more roles.
Work items: documents, spreadsheets, project plans, source code and other tangible output from activities.
                   Work items are created when certain activities are created.
                   They can also be prerequisites to perform an activity.

Methodology vs Tool
All this sounds really cool, finally developers will be forced to work only on requirements. Unit testing must pass succesfully before code can be checked in. Everybody knows what other teammembers are doing and why.
But all this only by buying a tool? I think that tools are the means not the target. The developing process must be in place, only then a tool can help to achieve more productivity and quality.

Henry Cordes
My thoughts exactly...

Add comment

  Country flag
  • Comment
  • Preview