Inside VSTS

Managing Change with Team Foundation Server

Jeff walks you through best practices when using Team System.

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].

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube