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

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

  • What's New for Python, Java in Visual Studio Code

    Microsoft announced March 2024 updates to its Python and Java extensions for Visual Studio Code, the open source-based, cross-platform code editor that has repeatedly been named the No. 1 tool in major development surveys.

Subscribe on YouTube