How Microsoft/DevDiv uses TFS - Chapter 2 (Feature Crews)

  • 發行項

One of the issues that Microsoft has to deal with on a very large scale is that while they are managing 1200 individual features, all of this works on a single code base. With all that activity going on, how do you maintain the quality of the code base, while allowing individual teams to focus on their features.

Our answer is feature crews. Its a model we adapted from the Microsoft Office team. It looks something like this:

image

When a feature crew (a team of people) is assigned to work on a feature, the lifecycle looks like this:

  1. The feature crew creates a branch of the main source branch, to provide an isolated environment to work on their feature. They are isolated from any churn going on in the source branch, and they isolate everyone else from their work
  2. As they work on the feature, there are two checkpoints. Checkpoints are when they present to management, to ensure management is in the loop of what is being done, and allows management to provide feedback on direction. Checkpoint #1 is about design. Here the feature crew presents how they plan to solve the problem.
  3. Checkpoint #2 is about demoing the functionality. Here the feature crew presents what they actually did to solve the problem.
  4. Once they've completed the feature, the feature crew integrates any changes that have taken place in the main source branch into their branch.
  5. Before they check their changes back into the main source branch, all feature crews needed to meet a set of quality gates. Quality gates included things like "No performance regressions" and "70% code coverage through automated testing".
  6. Once the feature crew had verified they had met the quality gates, they can then check their changes into the main source branch. The quality gates protected the main source branch, ensuring it was always in a near-releasable state.

NOTE: The goal was that a feature crew could complete within 4-6 weeks. (Didn't always happen, but the goal was to keep them short)

We had 16 different quality gates we needed to meet before a feature crew could be called "Done". Some of the meatier ones are below:

image

Quality Gates were the method we chose to ensure that 3,000+ people working on 700+ features on a code base of a bagillion lines of code (I really don't know how big it is, but you get the picture) ... that all that decentralized work could go on, yet maintain a consistent quality level overall.

While all the feature crews were working on their individual features, the entire division was managed to a set of iterations. I believe their were 14 iterations overall. The picture below depicts feature crews branch of the main branch, and integrating back into the main branch. Feature crews overlapped each other and overlapped iterations.

image

At the divisional level, we had Iteration Reviews, were all the teams would tell upper management what they expected to complete in the next iteration and what they actually completed in the prior iteration.

Next Chapter: Implementing the Process using TFS

Comments

  • Anonymous
    April 11, 2008
    Grant Holliday on TFS Performance Heat Map Reporting Services Report. Martin Woodward on Radio TFS #4...

  • Anonymous
    April 20, 2008
    Gregg Boer, a program manager on the TFS work item tracking team has started a series of posts outlining

  • Anonymous
    April 20, 2008
    先月より、なぜか、Chapter 3 が二つありますが、それはご愛敬として・・・まだまだ続きがあるようですの Teams WIT Tools という TFS の開発チーム（主に WIT： Work Item

  • Anonymous
    April 22, 2008
    Подгруппа разработчиков Visual Studio Team System, работающая над отслеживанием рабочих элементов в TFS,

  • Anonymous
    April 22, 2008
    英語原文: http://blogs.msdn.com/teams_wit_tools/archive/2008/04/03/how-microsoft-devdiv-uses-tfs-chapter-2-feature-crews.aspx

  • Anonymous
    April 29, 2008
    Before we talk about tracking progress, it might be useful to review the feature crew lifecycle as described

  • Anonymous
    May 06, 2008
    In a previous post , I talked about the electronic status report. Basically, our status report was filling

  • Anonymous
    May 10, 2008
    Can you elaborate on the size of the branch? Do feature teams branch out the full code or is the code structured in a way that they can branch out only small parts?

  • Anonymous
    June 08, 2008
    Kes veel ei tea, siis Workitem Tracking vahendite meeskond Visual Studio Team System -i arendusmeeskonnas

  • Anonymous
    July 20, 2008
    Hay una serie interesante de posts que nos explican de que modo la Division de Desarrollo de Microsoft

  • Anonymous
    August 17, 2008
    A good read: Applying Value Up at Microsoft by Sam Guckenheimer (also available as 60-minute-webcast

  • Anonymous
    October 20, 2008
    Part of my job is evangelizing Team Foundation Server adoption within Microsoft. A colleague recently

  • Anonymous
    February 27, 2009
    In December, I had the privilege to be the “MVP in Residence” with the Team System product group.