Original link: https://sund.site/posts/2023/large-software-team-structure/
For large software R&D teams, one of the most troublesome problems is that it becomes increasingly difficult to modify and add functions in the later stages of project maintenance.
Because some unexpected interactions will produce many unnoticeable bugs, testing will be very time-consuming. Therefore, the cost of system components with the same functions is at least three times that of independent programs. ——”The Myth of the Man and the Moon”
Whether a system is easy to maintain depends on:
Coupling degree of technical architecture design Complexity of interaction design Communication cost within the software team Surgical team The author of “The Myth of the Man-Month” proposed that when a software system is large enough, it requires more human investment, but human investment leads to internal communication Cost and design complexity have risen dramatically. Therefore, the author recommends that the software team should not split different modules into different teams and individuals, but should be composed of a “surgical” team composed of a small number of core members and auxiliary members.
Although this book was published nearly 50 years ago, its core ideas are hardly out of date for the field of software development. The personnel of the agile development team are almost designed according to the personnel composition in the figure. (I have used different colors to mark the roles of different roles in the agile development team, some of which have been replaced by automation tools)
The completeness of the system concept determines the ease of use. Ideas and features that do not integrate with the basic concepts of the system are best set aside and not considered. If there are many important but incompatible ideas, the original design should be abandoned, the different concepts should be merged, and the new system should be started again.
Unfortunately, most software teams do not pay attention to “system integrity” and split tasks (it doesn’t matter the granularity, but vertical splitting instead of horizontal splitting), resulting in inconsistencies in various parts of the system.
On the other hand, the pursuit of so-called “democracy” and one-sided unity within the team, while ignoring the fact that software development is a “master-apprentice model”, leads to disagreements and arguments and the inability to quickly converge; and the mediocre system design ability, but the old scalpers Promote “old people” who are conventional and have poor information into the main developers. Problems like these contribute to the mediocrity of software teams.
How to Reduce the Information Gap in a Team I recently heard someone say: “Agility is not an end, it is a means.” This is completely wrong. Agility is the culture of a team. Agility is the end, not the means. It is for the team to achieve an agile flow state (focus on problems; quickly converge differences; minimize communication costs).
From my personal point of view, the fundamental direction to reduce team differences and reduce the cognitive gap between members is to “eliminate the private ownership of knowledge”:
Use collective code review to eliminate the private ownership of technical knowledge by evaluating points, splitting stories and ACs to avoid the emergence of key persons in the team. Master too much business context, eliminate the private ownership of business knowledge CI/CD and automated testing, and eliminate the private ownership of operation and maintenance knowledge through iterative planning, Processes such as retrospective eliminate private ownership of management knowledge References https://ift.tt/o38Bhs6 https://twitter.com/way2steve/status/1697296025550205067
This article is reproduced from: https://sund.site/posts/2023/large-software-team-structure/
This site is only for collection, and the copyright belongs to the original author.