Surgical team model for project plan and Task Assignment-on the road

I have recently read The Mythical man-month and read the section "surgical team" to understand why this book is so popular.

The man-month theory cannot be applied to project plans. The number of people and time are not in a simple inverse proportion: the increase in the number of people means the increase in thinking and communication, when all these elements are together, the project is gradually sunk into the swamp.

The traditional way of project planning and task allocation is to divide a system into multiple subsystems, and allocate the design and coding of each subsystem to one or more of them. In this mode, I can see that no one in a very chaotic combination has the complete concept of this combination, including main-programer; every programer is just random (although they all think carefully and may have chosen the best position) to insert the subsystem into this combination. The only expectation is that the subsystem can work.

I think many people will feel this scene. This traditional model is still very common, because I am here.

The surgical team is one or two surgeon, main-programer or framework-designer, responsible for defining the concept, constraints, and control flow of the entire system, and hand over their work results to programer for implementation. It is like the architect has designed a uniform blueprint, and then the construction team is responsible for the construction. Imagine if every guy in the construction team is very interested in designing and implementing a part of the building and compromising each other for combination, what will the final building be?

Most people probably reflect on the surgical team model: "All the fun is deprived by main-programer and framework-designer", "programer is not a coder, there is no future ". But it is not. The surgical team is not as exaggerated as outsourcing. The surgeon only defines the concept, constraints, and control flow of the entire system, but does not come up with implementation such as design documents, in addition, tasks are still assigned in the form of subsystems (defined and restricted). Therefore, the programer can create and implement tasks under specified constraints.

I have had similar experience with surgical team models. A little-demo, with three people working together, I extracted all the classes required, specified interfaces for each class, and placed positions, that is, concepts, constraints, and control flow. I have a complete concept of the entire system, but I don't have any implementation. I can give every subsystem of the system to anyone for implementation, because I know who is responsible for everything that can work and cannot work. Each programer can select any implementation method and design the implementation method.

Okay. There are so many things about the Mythical man-month.

PS: Another consideration is refactoring. It seems that there are not many project teams that will reserve time for refactoring in their own project plans, mostly because of progress and cost, the traditional project planning model (non-surgical team model), the combination of the system itself is redundant defects, if there is no timely reconstruction, the disease will only become more and more serious. Therefore, I expect that the reconstruction time is retained for the project plan. When the project version is implemented to a certain extent, most of the team members think that the system needs to be restructured, A reconstruction version cycle is provided, and all members are involved in the reconstruction.
Reconstruction will affect the progress and cost, but there is little evidence to prove this conclusion: before people try useful things, they all intuitively refuse to waste time on reconstruction, this is just a way of looking at the short-term benefits-design and coding are not all about system development!

Http://www.cppblog.com/darkdestiny/archive/2007/07/08/27680.html