Freigeben über

Customizing TFS

  • Artikel

As I previously mentioned, I've been collecting data from current TFS users to understand what sorts of customizations to TFS they are currently making in preparation for my upcoming TechEd talk.  I've received quite a few responses (thanks to everyone who responded!) and while no two are identical, patterns have emerged which are pretty interesting (at least to me).  Hopefully you agree.

Here are some of the reasons offered up for why people customize TFS...they appear to fall into two broad categories:

  • Integrate with existing tools, systems and process
    • compatibility with existing process
    • comply with external regulations
    • enact company standards
  • Innovate incremental process improvement
    • track new kinds of work
    • establish deeper integration and traceability between artifacts
    • automate process

Let's look at each in turn:

Integrate with existing tools, systems and process

Very few of us live in a world where we can start completely from scratch and store everything we need in a single place such as TFS.  Instead, we're part of larger organizations which influence and, in some cases, dictate how we need to operate.  I'm sure it'll come to no surprise to anyone that we have many existing tools and systems here at Microsoft.  Before adopting TFS to track our work, we used something known internally as Product Studio.  Some of the teams within DevDiv still use that system so for now we mirror bugs between both systems using a predecessor to the Migration and Synchronization toolkit.  To keep those systems in sync with one another, we had to customize our definition of "bug" to track the corresponding ID in Product Studio.  This is a simple example of a very common sort of customization we're seeing.

Many teams are actually a small part of larger organizations which have existing process already in place.  It could be as simple as having a tradition of tracking a bug's severity instead of it's priority.  So, in order to use the MSF Agile Process Template, the customer would first want to make that change to the "bug" work item within the process template.  Internally, because our process has evolved over many years and is influenced by the many teams involved in our divisional releases, our process around bugs is quite complicated.  It seems that each team has their own specific needs which we have worked hard to support within our overall definition of bug.  Here's a glimpse at our current bug form:

image

Some customers have to comply various external regulations such as SOX or something known as CFR 21 Part 11 (related to medical research).  In these cases, the the customer's ability to influence the standard is often much lower and the criticality of compliance is much more important. Often, this implies additional levels of work flow often implemented as additional work item states.  In some cases, only a handful of approved team members are allowed to change the work item state or assign work items to other team members.  All of this can be achieved through the customization of work item types.

Another common customization pattern we've seen relates to the initial state of newly created Team Projects.  Some companies have established a standard version control tree that they want to be used for each project.  Others have established a common set of area and iteration paths for projects depending on the overall type of project.  These changes are encoded into the Team Project templates which helps ensure consistency across all projects without requiring significant work after creating each project. 

Innovate incremental process improvement

Many customers come to us looking for advice on how to improve their development process.  As you might expect, we encourage them to start with one of the variants of MSF which are available as part of TFS. For some, that's sufficient.  Others are interested in building their own process from scratch while others want to take advantage of existing process implementations such as Conchango's SCRUM, or Ivan Jacobson's Essential Unified Process.  You can see a more complete list of TFS Process Template providers here.

One of the innovations that we've observed is to use TFS to track more work than the standard set of work items in MSF allow.  For instance, within my team, we use TFS to help us track exit criteria for each of our major releases such as betas during a product cycle. This allows us to effectively track many aspects of our release readiness  by aggregating data from the many involved teams regarding many different aspects of our quality gates.  I wrote about this in detail a few months ago if you'd like to learn more.  

We also track our feature development through a series of new work item types and reports.  This has been done in conjunction with a sweeping change in the way we plan, develop, test and track features.  As we've implemented these process improvements, we've iterated on the associated work item types, reports and guidance necessary to successfully make the cultural shift.  

I collected the following list of custom work item types currently running on our dogfood server to give an idea of the breadth of additional aspects of the software development lifecycle which we track:

Exit criteria OGF Test case Test issue
Experience Feature Product idea Value proposition
Backlog Help topic KB article Release note
Patent Build request Change request TAP site

Another reason customers customize TFS is to establish even deeper integration and traceability between artifacts.  I've seen examples where customers annotate their code and tests with Requirement work item IDs and then are able to identify which requirements have sufficient amount of testing based on code coverage results.  Needless to say, as we look forward, we want to enable this type of traceability out of the box since the progress and readiness reporting that this enables would be super valuable.  We've also seen customers implement various types of work item hierarchies which helps them understand and manage the relationship between work items.  This is another area that we want to enable without customization in future releases. 

 

I'd like to hear from you on this topic.  Are you seeing these patterns as well?  Are there other forces at play that should be called out? 

Also, now that I've discussed the 'why customize' question, it's clear that I need to discuss the question of 'how to customize' as well.  Look for information about that in the near future.

Comments

  • Anonymous
    June 04, 2007
    Så er præsentationerne fra seminaret "Fra Versionsstyring til Processtyring med Team Foundation Server"

  • Anonymous
    June 04, 2007
    I'd recommend a progress bar when doing a checkin. Frequently I get a timeout before a checkin has completed. If a timeout occurs, it would be nice if I could resume the checkin.

  • Anonymous
    June 04, 2007
    Also, when doing a TFS checkin, the progress bar maintains focus. It would be nice to be able to continue to use Visual Studio while a checkin is in progress. I meant to say add details to the progress bar. Like upload rate, %completion per file.

  • Anonymous
    June 06, 2007
    We use the Process Editor powertool to define our own workflows and methodology - love it! But we find "process guidance" isn't quite powerful enough for our needs.   e.g. We too have created a work item type called feature (with an optional client sign-off state), but a feature could follow one of many different processes (depending on the type of feature). Coming from a strong process background we created an application we've been dogfooding for a while called TFSTrudy which allows us to drag/drop processes onto work items, or create multiple work items from rollup processes.  We also integrate our timesheets with TFS this means that when a developer starts a work item the process is shown, when they stop logging we display a process improvement page. Our distribution partners may market this as a product later on, so please excuse what may be blogvertising (although as you can't buy TFSTrudy at the moment - I don't feel like a dirty marketeer yet!). We created this using only the published TFS APIs, .net and Ajax and it might give others an idea for what can be done with the TFS APIs. The process bits are: http://www.devprocess.com/process.htm Timesheet and process tracking: http://www.devprocess.com/tracking.htm