Developer Product Briefs

Using Development Methodologies With TFS

Using Team Foundation Server and the methodologies it supports can greatly improve the software development experience and lead to successful projects with repeatable processes.

• By Jeff Levinson
• 07/01/2006

Using Development Methodologies With TFS
Team Foundation Server turns Visual Studio into a full-featured development platform.
by Jeff Levinson

June 28, 2006

Team Foundation Server (TFS), the "core" piece of Visual Studio Team System, turns Visual Studio into a full-featured development platform as opposed to just another Integrated Development Environment (IDE). TFS integrates a development methodology (of your choice), a SharePoint team site, requirements and bug tracking (work item tracking), automated builds, and a powerful reporting capability.

It's a good bet that when companies first implement Team System, they will use it for Team Foundation Version Control and little else (see the article, "Better Version Control With TFVC"). However, when used properly, TFS can improve your processes, improve communication, increase traceability, and provide better metrics for estimating virtually all aspects of a development project.

To use TFS properly, you must set up your project the right way. You do this using the development methodology of your choice, which is implemented as a template. These templates contain work item types, development guidance, pre-made project schedules, and a SharePoint site template. Before you begin a development project, you need to ensure that your template is set up correctly. You can edit your process templates using the Process Template Editor, which is available from www.gotdotnet.com. Make sure to set up the available work items and templates beforehand. Making changes after the fact, while possible, requires more work.

Currently there are five templates available for Team System: Microsoft Solutions Framework (MSF) for CMMI (included), MSF for Agile Software Development (included), Scrum (free from www.scrumforteamsystem.com), Macroscope (for purchase from www.fujitsu.com), and Rational Unified Process (for purchase from www.osellus.com).

Project Management Is Key
The project manager must know how to use TFS. Setting up the project schedule first, assigning resources, creating work items (see Figure 1), and linking those work items appropriately is the key to maximizing Team System's capabilities. Team System allows you to set up "Areas" and "Iterations" to further subdivide and manage your project. Areas allow you to specify sections of the project such as "Database," "Business Logic," and "User Interface." The Iterations allow you to have a long-running but continuous project. You can proceed from Release 1 through Release n and continuously track a system from its inception to its latest incarnation.

Possibly the most welcome feature is that project managers do not need to use Visual Studio's Team Explorer, the VS add-in that allows a client to interact with TFS. They can use Microsoft Project or Microsoft Excel to create the schedule and work items. (For more on project management, see "Managing a Project With Visual Studio Team System" by Peter Varhol.)

Take Advantage Of Workflow
There is no "workflow" built into Team System per se. However, each work item comes with states. These states allow a project to move an item through a process tailored for that item—and you can customize the process to suit your needs. For example, the Task item begins its life as a "Proposed" task. Once the Task has been accepted, it enters the "Active" state. When the Task is completed, it becomes "Resolved."

Tests are performed on a resolved Task; if they fail, the Task can enter the "Active" state again. If the tests pass, the Task becomes "Closed" (see Figure 2). This allows team members—and more importantly, the project manager—to know exactly what states the work items are in and when they are complete. The project manager can gather this information without having to pester the developers. You can enforce this process through the use of check-in policies, which require team members to associate any item checked in with a work item.

TFS is integrated with SQL Server Reporting Services (SSRS) to provide reporting off the Team Foundation Data Warehouse. Stakeholders can subscribe to these reports for increased project visibility, work-item tracking from the end-user perspective, and the like. Project managers can use the reports to track information such as remaining tasks, build status, changeset information (from Team Foundation Version Control), code churn, and project velocity.

Working With the Process
Now that you have seen what you can do, here's a brief overview on how you can use the TFS development process on a project. I'll discuss the pre-project phase, the requirements phase, the development phase, and the testing phase.

In the pre-project phase, the project manager creates a new Team Project through Team Explorer, which creates the basic SharePoint site and Version Control repository. The project manager then adds all the project stakeholders to TFS in the appropriate groups (or creates groups first as needed).

Next, the project manager creates the schedule. Each item in the schedule is a type of work item. Work items can be associated with other work items. At this point, the project manager would also set any check-in policies for the project.

In the requirements phase, the analysts designated to work on requirements will gather the requirements in documents and store them in SharePoint (or Version Control) and link them to the appropriate work items. By doing this, they can run reports on the Requirements (a type of work item) and view the associated requirements documents. These linked items can be URLs, documents, pictures, other work items, or virtually anything at all.

Once the requirements have been gathered, the project manager can create a more detailed schedule breakdown and assign the work items to developers for estimation. These same work items can be linked to the requirements for which they are being coded.

If you are using a Test-Driven Development methodology, you would create your unit tests in the development phase. Once the unit tests are created, development can begin. Each class you create is associated with a particular requirement; as you write code, test it and confirm that the requirement is nearing completion. Here you can take advantage of Team Foundation Build, which allows you to do automated builds. You can also implement Continuous Integration, which performs builds before each check-in to ensure that a code check-in doesn't break the build. You can do this using either Cruise Control.NET or the CI demo (available from http://go.microsoft.com/fwlink/?LinkId=58543).

In the testing phase, you can use the testing tools in the Testers edition to complete functional testing (for Web applications). For more information on Visual Studio 2005 Team Edition for Software Testers, see "Use VSTS for Advanced Testing."

Now you've seen what TFS is and how you can use it. But there's even more good news: TFS integrates with Eclipse, so developers can access TFS methodology, version control, work items, and reports from within the Eclipse IDE. You can use several free, commercial, and open source tools to accomplish this integration, such as VSTSEclipse and Tortoise, Personify Design, TeamPlain, and Teamprise (see "Resources for VSTS and TFS" for more information).

Using Team Foundation Server and the methodologies it supports can greatly improve the software development experience and lead to successful projects with repeatable processes.

About the Author
Jeff Levinson is a solution design and integration architect at a Fortune 500 company. He is a Microsoft Architect MVP and holds the MCAD, MCSD, MCDBA, SCJP, and Security+ certificates. He is a coauthor of the new book, Pro Visual Studio 2005 Team System.