Life Without Visual Studio 2005 Team System

Life Without Visual Studio 2005 Team System

We've all been there. The rollout deadline is upon us, the developers are at odds with the architects about something, the testers are sitting around doing nothing, and programmers are busy adding features that don't map to requirements. To make matters worse, the customer is calling. Does this sound familiar?

Building software these days is very difficult. Enterprise developers can no longer generate a single Microsoft® Visual Basic® executable and deploy it with a Microsoft Office Access database on a floppy disk. No, today's enterprise-scale applications have many layers and services. These projects require more development effort and are held to a higher standard than similar projects from a few years ago. You must consider also that more and more customers, Chief Information Officers (CIOs), and other stakeholders are reading magazines and Weblogs. Although they might not be as technical as the developers, they know what they want, and, more importantly, they probably know what they don't want: a simple .exe and .mdb combination.

Enterprise-scale software has significantly more moving pieces than it did 10 or 15 years ago. Web-based applications, XML, and Web services might make systems easier and better, but this is from the architect's, stakeholder's, or user's point of view. The reach, interoperability, and extensibility benefits cannot be matched. The downside is that these systems are not easy to build. All of these services, stacks, versions, and application programming interfaces (APIs) known as “XML Web services” make it challenging for any sized team to plug the various elements together and make them work efficiently.

Global Communication

Geographically separated teams are a roadblock to successfully building and implementing enterprise-scale applications. In a modern-day environment that includes telecommuting and outsourcing, the chances are good that you have at least one team member who is performing project management, design, development, or testing from a remote workstation. Not everyone on the team can access the LAN or enjoy virtual private network (VPN) access. It can be advantageous to have team members who work remotely. A physical separation between the development team and the daily business noise is a key benefit in most development methodologies. When a project has team members working remotely, however, it's important for all communication, including code, to flow smoothly through any firewalls. Using LAN-based tools such as Microsoft Visual SourceSafe® 6.0 to work remotely has historically not been practical. Anyone who has attempted this will know what I am talking about. It was doable, but only after you established a VPN connection to your SourceSafe database. Visual SourceSafe was never intended to be used as a thin-client application over port 80 and through firewalls.

NOTE
That said, one of the new features with Visual SourceSafe 2005 is the ability to use it remotely through port 80, via an HTTP Web Service interface.

Whether the team is distributed across the globe, country, city, or cubical farm, communication is never easy. Team members tend to live in their own silos, seeing the project through their own personal portal. Hopefully, e-mail, telephone, or instant messaging (IM) is being used for communication—especially IM. I can't tell you how easy it is to collaborate remotely using this tool. Copying and pasting code, transferring files, and just getting a quick question answered from a teammate are all tasks that IM handles with ease. When I was first learning Microsoft .NET, I regularly pinged my online buddies to ask quick and simple questions such as, “In which namespace would I find the StringBuilder class?” If it's not abused, instant messaging can greatly increase the efficiency of communication among like-minded professionals on a project. Online live meetings and conference calls can be productive as well, and e-mail serves as a great archive for questions asked in the past and resources provided by other teammates.

One drawback to all these various forms of communication is that they force developers to use a tool outside of Visual Studio. Visual Studio is supposed to be our primary development environment. Many developers will spend eight or more hours per day inside this interface. Leaving Visual Studio and launching a separate tool such as Microsoft Office Outlook®, or some other custom task or bug-tracking utility, isn't an efficient use of your time. It's a fact that managers and other developers will send tasks in lots of different ways: e-mail, instant message, voice mail, or even a sticky note on the door. It requires a lot of effort to properly aggregate and organize these work items.

Rather than requiring you to embed Outlook or another collaboration tool inside Visual Studio, Microsoft has developed Team System, which integrates the sending and receiving of tasks, bugs, and accomplishments right inside the integrated development environment (IDE). As you'll see later, you don't have to leave Visual Studio to communicate with other team members about a project. If everyone on the team uses it, everyone wins.

Too Many Tools

If you study any sized software development team, you'll find an array of products in use. Project managers use Microsoft Office Project and Microsoft Office Excel® to track requirements, iterations, phases, milestones, and deliverables. Architects use Microsoft Office Visio® or third-party tools to diagram their datacenters, networks, application services, and classes. The developers have it easy. They have and will continue to use Visual Studio to implement these services and classes. Developers and testers who want to test their software will also need tools to perform unit tests, code coverage, static analysis, load and Web testing. If the testers are lucky, these testing utilities will plug into Visual Studio or at least run in managed code. The end result of using so many tools is a hard drive full of software from various manufacturers. Newly hired team members will need weeks of training to gain experience on all these niche applications. Welcome to life without Team System.

Another potential weakness to a project is a lack of guidance. This is not to say that the project managers or team leads are weak individuals. Quite the contrary. Consider what I said earlier about how complex today's systems can be. Guidance can be the best way to assemble all those services and frameworks. Guidance can also be the methodology to follow to successfully create the software, specifying the team members, phases, and deliverable items.

I have met some extremely sharp developers and architects, both inside and outside Microsoft. The Microsoft Regional Director and MVP programs are full of such folks. However, no single person can know it all. With a good search engine, an appetite for reading, and plenty of spare time, a person can come close. Unless such a rare person joins your project, you'll need process guidance and best practices, preferably compiled by scores of domain experts. With this safety harness, you can go forward and write code, confident that you are proceeding according to published and agreed-upon best practices. Even then, any guidance implemented in the development process needs to be customizable. This requirement is important because it enables your team's patterns and practices to trump those compiled by Microsoft.

NOTE
Documenting and publishing best practices is exactly the job of the Microsoft Patterns and Practices team. This team is internally known as Prescriptive Architecture and Guidance (PAG). Their documentation gives best practice advice in every area imaginable: data, security, configuration, and deployment, just to name a few. You can find and download these Patterns and Practices online for free at http://www.microsoft.com/patterns.

Another problem with using multiple tools relates back to communication. Not between team members, but with the project. The project itself needs to communicate with the project manager and other stakeholders. These individuals need to have their fingers on the pulse of the project at all times. Today's managers have to rely on Project or Excel to provide them with such a detailed and accurate view. The status of the project presented by these tools, however, is only as accurate as the data recently typed into Project or Excel documents. This is a dependency that can cause problems when ad hoc reports are needed and the data is missing. Ideally, the project metrics should be relayed to the project manager in real time, without additional aggregation. Such metrics might include outstanding tasks, satisfied tasks, code churn, team efficiency, and bugs. These metrics should be available remotely and accessed in an easy-to-use way, such as from a Web browser.

Solving Your Problems

Some software development problems will never be solved. In many problematic situations, the customer, team, project, budget, and/or time frame difficulties are beyond the help of any tool or methodology. Straightening out such problematic situations is beyond the scope of this book and Team System. I suggest improving communication among all the people involved—and not just from a technical viewpoint, but also from a psychological or philosophical one.

What about the specific problems that I spent the last few pages enumerating? You know, the poor team communication, problems with working remotely, tools that don't integrate, lack of guidance, and lack of insight into the project's status. Your best chance for success comes from the following list of principles: adequate planning, good designs, following best practices, testing, and effective communication. Given that, wouldn't it be great if there were a tool that was available to guide you in achieving these goals? Wouldn't it be great if this tool plugged right into your familiar development environment that you already use for 8 to 18 hours a day? This tool now exists and it's called Microsoft Visual Studio® 2005 Team System.

Goals of Visual Studio 2005 Team System

Microsoft did something unique with Visual Studio 2005 Team System: It took a step back and studied the ways that software shops and teams successfully, and sometimes unsuccessfully, developed software. Then it tactically built a product that will increase the predictability of a successful project. From start to finish, Team System provides the guidance and collaboration to achieve this level of predictability. With Team System, Microsoft will also change the way we think about Visual Studio. No longer is Visual Studio just a slick IDE for development. Team System transforms it into a powerful tool that integrates the entire team with the entire solution across the entire life cycle.

At its core, Team System is based on the same suite of tools that Microsoft uses internally to successfully plan, build, and deploy its software to customers like you and me. Even though your company may not be a multibillion dollar software development firm, Microsoft knows that other software development teams face the same challenges it does. It made sense for Microsoft to polish up this suite of tools for resale and thereby share its internal best practices with the rest of us.

Visual Studio 2005 Team System is designed to achieve these primary goals:

• Increase the project's predictability of success

• Increase the team's productivity by reducing the complexity of delivering modern service-oriented solutions

• Increase the team's collaboration by integrating all the tools

• Increase the team's capability by allowing remote users to work in a robust, secure, and scalable environment

• Be extensible by allowing its tools and services to be customized and extended

The last goal means that third parties must be able to introduce Team System add-ins. If your team happens to use an alternate methodology, designer, source-code control, or testing infrastructure, then those tools can be integrated with Team System. This goal also reflects Microsoft's ongoing commitment to its partners and developer communities, such as those in independent software vendor (ISV) and Visual Studio Integrator Program (VSIP) programs today.

More Info
Be sure to read Chapter 9 for many ways to customize and extend Team System, including how to customize the guidance documentation and templates.

Providing Process Guidance and Methodology

Is having a tool that dictates a methodology a good thing? Some developers and architects I've talked with would caution Microsoft to stay out of the “how-to-build-software” business and stick to just providing the tools for building it. For the most part, I agree. People don't like having a methodology or process forced upon them. That's exactly the position that Microsoft took when building Team System. Going back to extensibility, Team System is customizable and extensible at every angle. If the guidance or methodology questions being asked by the tool aren't satisfactory or don't fit your team, you can change them. If your version control check-in policies are too restrictive or not restrictive enough, you can change them. If the number or types of tasks your team is receiving is causing strife, you can change them.

I've been teaching architecture, development, and best practices to software teams for many years. These people are the most demanding and fussy group of professionals out there. They know exactly what they want. More importantly, they know exactly what they don't want. They don't want tools, training, or advice that gets in the way of their work. They don't want a new methodology. They've seen too many come and go. They just want something lightweight that demonstrates best practice and a productivity increase. If this thing also happens to generate code, then that's a bonus for them. Microsoft, being made up of such personality types, knew from the beginning that Team System would only be successful if it was extensible.