Introduction

I currently been working on a piece that deals directly with Team Foundation Server (TFS) 2010, namely work item tracking, that is quite unconventional. Normally, when one thinks of TFS 2010 software development immediately pops into their head. TFS was developed, and is still being developed, to integrate the entire process of software development (development, work tracking, testing, bug tracking, etc.) into one system. The integration with all of these different elements brings out very rich reporting and transparency within a company, especially with the data that can be recorded and used via the work item tracking.

This is all fantastic for software development teams, but when a team doesn’t write any code, how could they leverage the power of TFS 2010?

Context

For the sake of context, this particular customer releases products that need to comply with specific compliances to be able to release and be sold. These compliances can range from a variety of different things (ISO, PCI, HIPAA, etc.) which, at times, can be audited. As one could imagine, as a system becomes complex, as this one is, tracking everything down to the fine print is quite difficult.

During some of the initial meetings of the project, one of Northwest Cadence’s consultants showed this customer one of our own internal projects that are currently developing (we have deemed it Skillsaw). In short, it extends TFS 2010 into a view of tracking a different type of work, knowledge transfer. After seeing a short demo of our internal project, our customer wanted something very similar for their team.

Process Template

To begin with, tracking knowledge transfer compared to tracking compliance of a product is radically different. In the world of compliance, there exists specific compliances that one might want their product to adhere to. In these circumstances, certain requirements exist that must be reached for the product to comply, and within these requirements there are activities that, upon completion, will satisfy that particular requirement. Now, throughout the process of getting a product up to speed on a compliance, there are two irregular actions that can come into play. Exceptions are planned out to exempt a specific requirement from having to be done for it’s compliance, and Findings are what are found after a requirement has been tested and failed (a remediation plan is drawn up and revised until accepted). As one can see the complexity is starting to unravel, and there are plenty more bits that come into play later on, but lets focus on these ones right now.

Initial Phase

One of the major differences between our internal Skillsaw project and this new one is that Skillsaw is restricted to one TFS project while leveraging areas to divide work, whereas the complex nature of working with compliances and the multitude of products requires me to widen the breadth of the application to a project collection with different projects.

For this team, we are now assigning a product to a team project in TFS 2010. This will give us more latitude to use area paths for yet another way to divide up work and sectionalize compliances for a product. This doesn’t seem important now, but it will play a bigger role as we continue through this solution. At this point it seemed clear that a custom TFS process template will need to be made to mimic the compliance process.

Work Item Types

Compliance

This is the most obvious type to have. We need this to be able to tie everything together and roll-up any data we may want from the subsequent work items. There won’t be too much information stored at this level, it is used, mainly, to act as a place holder and tie all the strings together.

Requirement

This one is also quite obvious. Here, the information from the compliance itself is stored, and any supporting documents, links, diagrams, etc. will be stored here for future reference. There is one thing about the Requirement that may seem odd to most, there is only one state with no transitions (the state name is “Static’). It does seem odd at first, but a look at the next work item type will shed some light into this architecture choice.

Control Objective

This one is not mentioned as a part of the compliance part, but it will play a major role in this TFS customization. The company is starting to shift to company wide standards. These standards are in the first few stages of being born, and, therefore, have not become widespread. The whole idea of a Control Objective is to be that company standard, and these standards will encompass the requirements needed to achieve in order for a project to be compliant. To further illustrate this concept, imagine having a handful of Control Objectives to complete, instead of two or three dozen different requirements to go through. A Control Objective (standard) will continuously morph to be able to encompass many different requirements.

A Control Objective is where all the work is to be done and has all the states/transitions that one would assume would go along with a  process. These control objectives will support a compliance, while still encompassing a bunch, or only one, requirements. Hopefully, by forcing the team to use control objectives, instead of transitioning through requirements, they will adopt this concept much faster.

Figure 1: View of how a Compliance, Control Objective, and Requirements fit together

From the above figure, you can see the specific requirements for each of the compliances. Requirements 1.2, 1.4, and 2.4 are linked to Control Objective 1, which in turn is linked to the compliances that are tied to the requirements it encompasses.

Control Activity

These are linked only to Control Objectives. Control activities are very similar to tasks. One control objective will spawn multiple activities to complete it. Much of the hands-on work done by the people completing the compliance will be done at this level in the hierarchy.

Exception & Finding

Exceptions and Findings, as mentioned previously, could play a major role in the actual work of making a product adhere to a compliance, but from the customization point of view they are very similar to bugs that need to be dealt with. Simple work item types that use security customization for sign offs and remediation plan acceptance.

Work Item Link Types

I believe getting these correct (topology and name) are just as important as the work item types. The links are what are going to tie each products’ work together, as well as tie it back to the original, template compliance (more on this later in the article). The linking of everything is very important, and getting it right will yield powerful and useful reports.

NWC.SupportedBy

This link uses the Dependency topology and links both the Control Objectives to a Compliance, as well as Control Activities to a Control Objective. This creates a many-to-many relationship between Control Objectives and Compliance work items. This is handy because we will want the directionality and the prevention of circular relationships, but we also want to be able to link control objectives to multiple compliances.

NWC.Encompasses

This link will be defined by a Tree (parent/child) relationship. This will be used to link a control objective to many requirements. We don’t want there to be multiple parents to these requirements (in essence we want to make sure we have one, and one only, control objective that will encompasses a particular requirement), so again we want the directionality, but we only want one parent for each of the children.

NWC.Linked

The Linked link will be defined as a network link type. This is merely to link a control objective that is being worked on to the one that is sitting in the template project (again, I will get to template projects later on in the article). There is no direction, nor is there a prohibition of circular references.

Conclusion

There is much, much more that goes into a full customization of a process template, but with these two bits we can move on and start fleshing out a non-software development environment.

Project & Project Collection Hierarchy

There isn’t much that goes into this particular section, but by laying down simple definitions and rules to follow throughout the collection and projects goes a long way for organization and scalability.

Project Collection

Again, not too interesting when looking at the project collection itself. We are going to define a Template Project (mentioned multiple times in previous sections) that will serve as a content holder for all the compliances. The rules within this project will differ from the projects that will represent the company’s products, but not by much. Beyond the template projects, I am going to make a hard rule that all projects used for the purpose of getting a product to a specific compliance must all reside within a single project collection. This will allow us to link to the template project work items and give us the power of tying everything together that we are aiming for.

Team Projects

As mentioned in the previous section, there will be two types of team projects:

• Product Project
• Template Project

I will first define the Product Project and move onto the Template Project because they have minor differences.

Product Project

The product project is where a specific product from the company will have all of its associated work items to get to compliance. There will only be the following work items within these projects:

• Compliance
• Control Objective
• Control Activity
• Exception
• Finding

The reason being, all the information about the compliance and requirements are to be static, and, if added to, we want this information to be accessible to any product that has that specific compliance. Also, these work item types are the only ones that will have true states and transitions to mark the flow and process of what is happening in the teams.

The area and iteration paths will also be used in these projects for specific reasons, also. First off, the area path will follow this standard:

TeamProject\Compliance\Version\Section

This is so we can have different versions of the compliance, and split the compliance up into the major sections of it. We are also going to control security ad the compliance level because there needs to be separation from the different compliance teams, for some of the compliances. Secondly, the iteration path will follow this standard:

TeamProject\Release\Milestone

The structure of the iteration path will help identify work items within those releases (Alpha, Beta, RC, RTM, etc.) and the milestones within each release.

Template Project

The template project conceptually differs greatly, but technically there is not much. Conceptually, this will hold all of the static text and documents that relate to each of the compliances. The requirement work items will reside in this project, and this project alone, and will have all supporting attached to them.

Instead of using both the area and iteration paths, the template project will only leverage the area path with the following structure:

TeamProject\Compliance\Section

Instead of having a version of the compliance, the template project will only store down to the compliance and section level of detail.

Automation-esque Extensions

With the setup, rules, and hierarchy all defined for TFS 2010 (high-level), there is the question that is still out there: what does this give us? To tell you the truth, not much. All of it really gives us a huge, complex framework that requires a TON of manual hours to get everything out to the TFS projects and project collections. Not to mention how much time it would take to copy over the work items to each of the projects. Or, what about when the product starts a new release? That requires a whole new set of work items

This is where the true power of TFS 2010, and its extensibility, comes into play. Creating work items that need to be finished or completed to track what has been done can be very laboring, especially when you have to do it over, and over again. In our internal project, since we were able to stay within one team project, it was really simple to be able to automate this process. We would merely “Copy work item…” and assign the new copy of the highest level work item to ourselves, and all the supporting work items and links would then be copied over for us and assigned to us. This was fantastic! We were able to pick what we wanted to do, and it would, behind the scenes, copy over everything we needed to do to complete it. Being able to quickly, and easily, create redundant work items like this not only benefits the direct users, but we can now pull out a ton of reporting information from the work items, once they’re being used.

Everything here is completely automated, and all the user has to do is copy one simple work item. All the steps and new work items are created, and automatic links to websites are on the work item UI to go look for more information. All of this automation was done using a couple of classes that inherit the ISubscriber interface. These are really cool event handlers that you can just throw up onto the TFS server (in DLL form), and TFS automatically picks it up and starts running it. However, this was all built on the assumption that we’re within one team project, which is not the case with our customer.

In our customer’s case, we needed to be able to stretch across projects and “grab” compliances from the template project and add them to their own projects. As some of you may know, the pains of moving a work item from one project to another in TFS 2010, is no simple task. In fact, no matter how you do it, the original work item CANNOT be moved from one project to another. There are plenty of work around methods that can keep data and history, but still no way to move the original work item over.

To solve this minor issue, I had to create a small application that I have deemed the “Compliance Grabber.” This app lets you select a template project, which it then populates a list of compliances it finds in that template project (this is where the strict area path rules come into play). The user can then select a target project, check the compliances it wants to grab, and then click “Grab Compliance(s).” This will then look through all of the sections and grab all the Control Objective and Control Activity type work items, copy them to the target project, and add all the necessary links to tie back into the original compliance.

This is my first step to automating the process of adding a compliance to a product. Creating these work items makes it simple and easy to add a compliance and start running right away on adhering to that compliance. I am continuing to automate a number of things, such as when a new release is to happen, it has to be checked of to comply with a standard again.

Conclusion

The whole idea of customizing and extending TFS 2010 in this fashion, forks from the traditional outlook of what TFS is: an end-to-end software development platform. Setting up the framework for a process, and automating the creation of work items to simplify, and track, what someone is doing brings a huge deal of value to the table. No longer is there a huge excel sheet that has a bunch of columns and rows to check off what needs to be done, and what is done. There is a prescribed methodology on how to do things, and capturing that data over time is trivial. Data input to get reports is non-existent because TFS already does this for us. If the team were to decide to put Estimated Hours, Hours Remaining, and Hours Completed they could start getting burndown charts and average velocity to complete a control objective, or even a compliance. The possibilities start to become endless as one thinks about how TFS can be customized to fit their particular need.