How Microsoft DevDiv Uses TFS - Part 2

One of the problems that Microsoft faced when working with large amounts of data was this: when we controlled 1200 different ones. tasks, they all worked on the basis of a single base code. With such volumes, it is incredibly difficult to control the quality of the base code, while individual teams are focused on completing their own tasks at the same time. Our answer is a team functioning model. We borrowed this model from the Microsoft Office development team. And it looks something like this:

When a team developing a new functional starts to implement it, the life cycle looks like this:

1. The team creates a new brunch based on the main brunch of sources to isolate the changes being performed. Thus, the new work is not mixed with the existing one, and is also isolated from changes made by other teams.
2. Since work is underway on new functionality, developers have two important milestones. These points are needed for project management in order to be sure that management is not only up to date with the work being done, but is also capable of transmitting information higher in the hierarchy. Milestone number 1 relates to design: the team shows how it is going to solve a specific problem.
3. Checkpoint No. 2 concerns the implementation of the functional. Here the team demonstrates what was actually done to solve the problem.
4. As soon as the execution of the declared functionality ends, the team integrates all the changes from the main brunch into their own branch.
5. Before they “upload” their changes to the main brunch, the team should meet and discuss the quality characteristics. Such characteristics can be “Without a drop in performance” and “70% of the code should be covered by automated testing”.
6. After the team make sure that they have achieved the established quality characteristics, they can “upload” their changes to the main branch. Quality features protect the core code, ensuring that it is always in the highest state of readiness.

NOTE: the goal is to complete the specified functionality in 4-6 weeks (which is not always possible, but, nevertheless, it is necessary to maintain this period as accurately as possible).
We used 16 different quality requirements that we had to fulfill before saying “Done”. Some of the most important are listed below:

Setting quality requirements is a method that we use when more than 3,000 people work on more than 700 new functions in the base code, which consists of * line ards (I don’t know the actual size, but you can imagine for yourself) ... that’s all we can do to ensure that decentralized work is carried out with the required quality.
While all teams performed their own tasks, the whole unit was engaged in iteration management. As far as I remember, there were about 14 iterations. The picture below shows the brunch for the new functionality, isolated from the main branch, which was later integrated back. Development teams overlap, as do iterations.

At the unit level, we performed integration reviews, at which all teams reported to their superiors what they planned to do in the next iteration and what really had been done in the past.

Next chapter: implementing a process using TFS.