Managing Change with Team Foundation Server
Jeff walks you through best practices when using Team System.
- By Jeff Levinson
This topic seems like a no-brainer when discussed in relation to Team System. TFS records every change made to everything -- requirements, bugs, tasks, change requests, scenarios, et cetera, et cetera, and all of the code that's associated with these work items.
But this article talks about how you or your organization should handle change in relation to your requirements, change requests and bugs -- which covers a lot more ground than what TFS supports out of the box. For the most part, I'll focus on change management (CM) with a more formal process. Because of how agile development works, there's no real "change request" concept; a change is just another item on the backlog. However, even new backlog items need to be managed in the overall scope of a project.
The CM process is going to be largely based on how your organization works, but there are some common threads and good practices that can be applied to any process. So let’s start at the beginning.
You have an application that's in production and has just started the maintenance phase (note that these ideas can be used whenever a CM process is in place, not just in this scenario). You get an e-mail saying that Feature X doesn't work as advertised. The first step is to create a change request (CR) work item. By default, all work items start off as “Proposed” in the MSF for CMMI/Process Improvement template.
Once the team agrees to accept the CR, you set the state to "Active" with a reason of "Investigate." Should the CR prove to be a defect, you can copy the contents of the CR to a bug work item type and close the CR (to do this, right-click the work item, select Create Copy of Work Item, then select the bug work item type).
However, if Feature X is a new feature, you have your work cut out for you -- and some customization may be in order! You have a valid CR with the reason set to "Investigate." This is where the customization comes in. If you determine that the CR is going to be included in the next release, a number of things have to happen: The requirements have to be updated, the test cases have to be updated and the code has to be updated -- in that order.
The easiest way to ensure this is to add additional states to the workflow. The next state after "Active" should be "Update Requirements." The state after that is "Update Test Cases." And finally, you can set the state back to "Active" with a reason of "Accepted." As part of this process, the CR should be linked to the requirement with which it's associated. If you've gone the extra step of creating a custom "Test Case" work item type, associate the CR with the test case, as well.
This may seem like a bit of work just to handle a test case, but Team System gives you some major benefits in this area. By following this process, you can give detailed reports on the CR's progress and ensure that the appropriate documents get updated and that test cases get written. That way, when a developer gets the CR, they won’t have to ask, "Am I done yet?" -- they'll know.
There are additional benefits to this, as well. By subscribing to events, the people in charge of requirements can be notified when they have a requirement to update. The same goes for testers. The notifications are a powerful component of TFS and allow you to work smoothly throughout the development process.
About the Author
Jeff Levinson is the Application Lifecycle Management practice lead for Northwest Cadence specializing in process and methodology. He is the co-author of "Pro Visual Studio Team System with Database Professionals" (Apress 2007), the author of "Building Client/Server Applications with VB.NET" (Apress 2003) and has written numerous articles. He is an MCAD, MCSD, MCDBA, MCT and is a Team System MVP. He has a Masters in Software Engineering from Carnegie Mellon University and is a former Solutions Design and Integration Architect for The Boeing Company. You can reach him at [email protected].