Share →
Buffer

Introduction

Team Foundation Server 2012 brings a ton of new features that are revolved around the software team. Software team is pretty subjective, but for this blog post we can define it to include anyone that has anything to do with the development lifecycle. This isn’t limited to the immediate team (developers, testers, ops, etc.), but extends to the people that don’t directly touch the code, such as end users and business analysts. The new features in 2012 brings the story of the Application Lifecycle Management solution beyond the traditional development team to the people that are hard to get direct involvement into the development process such as end users. That being said, there are a few features that have brought in the process template to be a huge part of customizing these features to fit into each company’s specific process, naturally. Process templates have been, over the years, the keystone to tying the end to end process together within TFS. Yes, it is a static definition for a project’s process, but starting a project off on the right foot is essential to further improvement and success as a team grows.

My Work

One major feature added to the Visual Studio side of TFS 2012, but interacts directly with TFS and many areas of the process, is the new view in the Team Explorer called My Work. Not all of the new view is completely tied to the process template; however, the main basis of this view is the ability to drag and drop your work items into different sections to signify where in the development process you are with your work.

In the My Work view in Figure 1, you can notice all the different sections that hold an array of information and ties to other parts of TFS. Brian Harry has a blog post on the new Team Explorer in TFS 2012 here. This is an extensive coverage of the features of everything in the Team Explorer, but we’re going to focus mainly on what happens behind the scenes of the My Work view and how we can use this to our advantage when customizing Process Templates.

 Let’s go into depth on each one, what they mean, and where they fit into a team’s process. First, let’s take a look at Available Work Items because this is where one would start when first getting new work for their current iteration. Under this section, you will see the tasks that you can associate with changes made to the source control and work against. You can either right-click to get the various options you can do with that specific work item. Optionally, you can also click any of the options at the beginning of the section (Start, New, Open Query, and Iteration Selector) or drag and drop the work items into the In Progress Work Items & Changes. This automatically changes the state from the generic term of To Do to the next logical state of In Progress. This does it behind the scenes and saves the work item change without you even seeing it.

Now, moving into the In Progress Work Items & Changes section of the My Work view of Team Explorer, we can see that there are different options to choose from. First off, once a work item is in this section and you start working on something, it is automatically associated with any changes that you make and it shows up in this view (look at the Suspended & Shelved Work section to get an idea of what this would look like).This option to associate work items and changesets was an option previously, but instead of finding the work item at check in time and associating it then, you can now easily do it prior to working on it. As well, it helps visualize what you’re working on and how it is explicitly traced back to your actual work. Once you are done, or even if you’re in the middle of finishing your work, there are a few options that you can choose from in the In Progress section. You can choose to do one of these three actions:

  1. Suspend and Shelve your work. This will put all your work into a shelveset as well as the work items into that shelveset. This means that if you shelve your work and start working on something else, then your new work will not be associated with those work items that were previously in the In Progress section.
  2. Finish your work. This will check in your pending changes as well as automatically change the work items from the generic In Progress state to the Done state. It will bring you to the Pending Changes view of Team Explorer where you can finish commenting your check in and actually check in your code.
  3. Request Review of your work. Requesting a code review will sent all your work, and associated work items, to whomever you want to send it to. This package is then delivered in the format down in the Code Reviews & Requests section. Opening this up brings you to another view that shows the changes and work items. You can also sent comments, and comment on those comments, much like a comment thread on blog posts. Also, requesting a code review opens up a special Code Review Request work item and responses create Code Review Response work items.

Process Template

This all seems lovely, but how does it tie back to the Process Template (our original topic of conversation)? All of these features of automatic state changes, work item creation, association, etc. that can be customized, will be defined within a process template. Before I mentioned the three generic states of To Do, In Progress, and Done. These states can be defined as any state within a work item type, but they must have valid transitions between the states. Below is an XML excerpt from the out-of-box Microsoft Visual Studio Scrum 2.0 – Preview 4 template in the file labeled CommonConfiguration.xml (WorkItemTracking/Process):

<TaskWorkItems category=”Microsoft.TaskCategory”>

               <States>

                              <State type=”Proposed” value=”To Do”/>

                              <State type=”InProgress” value=”In Progress”/>

                              <State type=”Complete” value=”Done”/>

               </States>

</TaskWorkItems>

 

This defines what each of the generic states in TFS will map to in the work items in the Task Category. For instance, if a state of a new task is New and that was your way of saying that it is in the To Do state, this is where you would map those. You can also add multiple mappings per generic value. For instance, if you have two work item types that were in the Microsoft.TaskCategory, you would map the To Do state of each work item type to the appropriate value. This would give you four State elements instead of four.

 

Being able to customize this behavior with the new features of 2012 can really enable teams to not become stuck on out-of-box process templates, and still benefit from the new, fantastic features of 2012. Not only do these metastates have major flexibility, but they’re also used in another part of TFS that helps us visualize our work, and keep our process in a good shape. On the completely re-done team web access, there is a board that helps visualize our work (both from the perspective of the team members, or from individual requirements themselves). Here is a screenshot of the board (in team member view). Again, you see the three metastates. You can drag and drop these work items from each state, and TFS will automatically change the states for you, according to the definition in the XML document of the process template.

Conclusion

The new features are already lit up by using one of the out-of-box process templates that come with TFS 2012; however, there is nothing stopping someone from customizing their own template and still have the ability to integrate it into the ALM solution and features that have become available in TFS 2012. Some of these features are brand new, like code reviews and being able to merge when unshelving a changeset, but a lot of them build on older features. The ones that were built on top others make it much easier to do in 2012. As well, it visualizes work much more to the end-client (i.e. developer) instead of making it only easily usable when reviewing reports.

 

Print Friendly