How Microsoft DevDiv uses TFS - part 2

One of the problems that Microsoft encountered when working with large amounts of data was this: when we managed 1200 different ones. jobs, they all worked on the basis of a single basic code. With such volumes, it is incredibly difficult to control the quality of the base code, while individual teams are focused on performing 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 like this:

When the team that develops the new functionality starts its implementation, the life cycle looks like this:

1. The team creates a new brunch based on the main source brunch to isolate the changes being made. Thus, the new work does not mix with the existing one, and is also isolated from changes made by other teams.
2. Since work is being done on new functionality, developers have two important checkpoints. These points are needed for project management, to be sure that management is not only aware of the work being done, but also capable of transmitting information higher up the hierarchy. Checkpoint number 1 concerns design: the team shows how it is going to solve a specific problem.
3. Checkpoint number 2 concerns the implementation of the functional. Here the team demonstrates what was actually done to solve the problem.
4. As soon as the implementation of the declared functionality is completed, the team integrates all changes from the main branch into their own branch.
5. Before they “upload” their changes to the main brunch, the team must meet and discuss the qualitative 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 makes sure that they have achieved the established quality characteristics, they can “pour” their changes into the main branch. Qualitative characteristics protect the main code, ensuring that it is always in the state of highest 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 “Finish”. Some of the most important are listed below:

Setting quality requirements is the method we use when more than 3,000 people work on more than 700 new features in the base code that includes * ards of strings (I don’t know the actual size, but you can imagine for yourself) ... that's all we can make decentralized work done with the required quality.
While all teams performed their own tasks, the entire unit as a whole was in charge of 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 later was integrated back. Development teams overlap, as do iterations.

At the subdivision level, we performed integration reviews, in which all the teams reported to their superiors that they plan to perform in the next iteration and what was really done in the past.

Next chapter: implementing a process using TFS.