In-Depth

5 Best Practices to Improve Process and Methodology

Get best practices for using TFS and Team System to improve process and methodology.

• By Jeff Levinson
• 06/01/2007

Team Foundation Server (TFS) and the Visual Studio 2005 Team System client components are nothing more than tools. They are not silver-bullet solutions for organizations that lack physical processes to back up their software development. However, companies can avoid typical implementation problems. For example, they can use the Microsoft Solutions Framework (MSF) methodologies as a base to start using physical processes. In this article, you will explore best practices for using TFS and Team System in a way that will reduce your chances for failure.

1. Start off small. Implement TFS as a version-control tool and take advantage of work-item tracking.
Do not implement all of Team System at one time. If you do, you will struggle to make any of the pieces work in a beneficial way. You will find that there is just too much to learn and execute at once, and it's not worth the time, money and frustration.

By first implementing work-item tracking, you will see the benefits of traceability, reporting metrics and better communication. These features are all tied in with version control in TFS, and they are the smallest steps that you can take to begin benefiting from Team System.

After you've successfully implemented work-item tracking, implement unit testing. Initially, you only need to perform unit testing — not Test-Driven Development (TDD). TDD is a highly structured engineering practice that only qualified teams can perform. While its benefits are great, the learning curve can be difficult for a team that's just beginning to adopt Team System (although, if you feel your team is qualified, go for it!). Unit testing alone will improve the quality of your code almost overnight.

2. Ensure that you can write unit tests to verify a given requirement.
You also gain another benefit from unit testing — you will definitively know when you meet your given requirements. If you can't write a unit test that verifies your requirements, then the requirement probably isn't testable. Therefore, it is an incomplete or poorly defined requirement. The unit testing tools in Team Edition for Software Testers and Team Edition for Software Developers are first rate.

3. Perform unit testing daily, using Continuous Integration if possible.
Continuous Integration is the process of running unit tests against your code before each check-in. This process makes sure the code still works. Unit tests are the prerequisite for Continuous Integration.

Implement builds nightly using Team Build. A nightly build process will catch errors early and often, which is when you want to catch them. It is more expensive to catch bugs after the software has been released or just before it is going to be released.

4. Even if you are using an external build tool (such as Automated QA or NUnit), launch your builds using Team Build so that you can capture metrics.
Team Build gathers comprehensive metrics on your code, including code churn, changesets associated with a build and work items associated with the changesets. By gathering such metrics, you can better trace when a given change request or bug fix made it into a release.

5. Gradually incorporate nightly builds. Try running nightly builds on a single assembly, and then add in more code if things are working well.
Implement builds nightly using Team Build. A nightly build process will catch errors early and often, which is when you want to catch them. It is more expensive to catch bugs after the software has been released or just before it is going to be released.

Once your build process is working well, you can start using the metrics you gathered from the build to gauge the best way to improve your software development processes.

When do you implement these best practices? Not all at once! Start slowly. The rate at which you bring on new changes will ultimately be determined by your organization, but you may want to push for implementing new features every three months.

Start off with work-item tracking and version control. Let your team and the project manager get used to these changes and evaluate improvements.

If all is going well, implement unit testing. This will take the most time as you'll need to go back and write the code for the unit tests. Don't test everything at first. You can probably skip simple properties, but you should exhaustively test methods that implement business rules or data access.

Finally, add nightly builds into your process. At the beginning, this will be difficult to implement because there are so many variables involved. You may need to perform merges, gather resources from other locations, deploy code and ensure reference paths are correct before run the tests. It is best to appoint a "build master" to control the nightly builds.