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.
Back to top