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

  • Hands On: New VS Code Insiders Build Creates Web Page from Image in Seconds

    New Vision support with GitHub Copilot in the latest Visual Studio Code Insiders build takes a user-supplied mockup image and creates a web page from it in seconds, handling all the HTML and CSS.

  • Naive Bayes Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the naive Bayes regression technique, where the goal is to predict a single numeric value. Compared to other machine learning regression techniques, naive Bayes regression is usually less accurate, but is simple, easy to implement and customize, works on both large and small datasets, is highly interpretable, and doesn't require tuning any hyperparameters.

  • VS Code Copilot Previews New GPT-4o AI Code Completion Model

    The 4o upgrade includes additional training on more than 275,000 high-quality public repositories in over 30 popular programming languages, said Microsoft-owned GitHub, which created the original "AI pair programmer" years ago.

  • Microsoft's Rust Embrace Continues with Azure SDK Beta

    "Rust's strong type system and ownership model help prevent common programming errors such as null pointer dereferencing and buffer overflows, leading to more secure and stable code."

  • Xcode IDE from Microsoft Archrival Apple Gets Copilot AI

    Just after expanding the reach of its Copilot AI coding assistant to the open-source Eclipse IDE, Microsoft showcased how it's going even further, providing details about a preview version for the Xcode IDE from archrival Apple.

Subscribe on YouTube

Upcoming Training Events