A Preliminary Study on the "minimal mode" of software development and teams: 2-6 people model (II)

King Kong fit and giant shoulders

The six-person mode is required, and I try to use the "person" term instead of "role" here. Why? Many people think that roles allow part-time jobs, such as management and architecture, architecture and requirements, design and development, development and testing. in this way, a team can become 2-3 people and form a reasonable 6 "role" model.

Is that true? However, I would like to remind you that these six most basic people (or roles) face different content perspectives, and they are mutually influential and supervised, it is costly to easily integrate any role into one.

The team model of fewer people is not unsuccessful. Software success is a complicated concept, but incomplete teams cannot demand more or even perfect. For example: if there is no management, it is impossible to demand time and quality control. If there is no architecture, it is impossible to require unified and reasonable technology. If there is no demand, it is impossible to demand no rework and no dispute. If there is no design, it is impossible to demand a beautiful t uniform software interface, functionality is exquisite and easy to use; no encoding (this ..., It is basically impossible); without testing, we cannot demand extremely high quality and flawless quality.

However, I also know that many teams are in the dilemma of "being easy to understand". If there are no 6 people or six suitable people, how should we do it, can I develop a software with fewer people? In principle, I disagree with this question, but I will give my opinion.

If fewer people are needed, we generally have two solutions.

If one person assumes two or more roles, this is"King Kong fit".

In my opinion, there are two main principles for King Kong combination:

1: different types of work cannot be combined. Different types of work here mainly refer to the fact that communication-oriented work cannot be mixed with technology-oriented work because everyone should be able to understand the reasons, communication work is open and requires communication and initiative, while technology is closed and requires independent thinking in a relatively quiet environment. These two kinds of work are not easy to mix.

2: jobs with conflicting interests cannot fit together. Management and other roles are difficult to merge because of mutual supervision. Otherwise, they are managed by themselves? Architecture and development are not easy to merge. architecture can be involved in the development of the underlying layer or examples. This is no problem. However, if it is still the main development of the project, it undertakes a lot of work, then, it is inevitable that the Framework personnel will reduce the framework level to reduce the work pressure.

Management and other roles are not conducive to easy mixing. Management takes communication and coordination as the top priority, while technical work takes time and space, and management and other roles will inevitably affect each other, making it easier.Therefore, we recommend that the management must exist independently..

The architecture is a pure technical role. The requirements and design with communication attributes affect each other. However, it is feasible to develop the architecture in part, first, the Framework personnel's ability and main direction must constantly improve the project architecture level. Unless the project architecture is already very stable, it is not worth the candle to sacrifice a large amount of time for development, in addition, on the premise of alternative resources, let the architecture of such high-level resources to do the work of ordinary resources, regardless of the psychological feelings of high-level resources and the cultivation of general resources, is quite unfavorable.My suggestion is,The architecture can be used as the identity of a master program to participate in partial programming,For example, generic classes or underlyingCode,However, you must strictly control the workload,A large number of specific development tasks are prohibited.The demand design and architecture should not be merged.

Because the requirements also have communication characteristics, if combined with the architecture, development will inevitably affect the work effect. however, the communication of requirements is different from management. The communication of business logic is the communication of information and interpersonal relationships. In addition, there are still half of the technical analysis requirements, this and management are mutually affected. in addition, the requirements and design and development are mutually exclusive. if the demand is used for design and development, the demand personnel may fall into details too early, and reduce their grasp of the overall business; second, the difficulties in design and development will be counterproductive and demand, forcing demand concessions and difficulties in design and development.My suggestion is that the requirement should be as independent as possible.He can serve multiple projects,But do not assume a role in a project.

The design itself also needs to communicate with each other. As mentioned above, the design work is not conducive to merging with requirements, so many times this baton will be handed over to development, however, many developers are unwilling to communicate and prefer to design their own ideas. This is an example of the impact of technical work on communication. however, if developers are forced to develop design documents and turn them into self-developed and self-guided documents, coupled with time pressure, the design of developers is often in a rush, but it must be clear that, even if the design is merged, it does not disappear, but the design is hidden by developers and becomes uncontrollable and cannot be accumulated. this not only causes potential risks of the current project, but also sets obstacles for the continuous improvement of the team in the future.My suggestion is to allow human resources,Separate development and design,Let strong development do the design instead of the actual work,Then let them review whether the development work is reasonable.

For testing, the general method of merging is to work on behalf of developers, which I do not agree. the perfect code also needs to be tested, because the test angle is the requirement reviewer, and his responsibility is to confirm whether the demand is lost after the design and development; therefore, the design and development after the demand is not suitable for reviewing their work with their own understanding, so they are not suitable for testing. However, the demand can be tested, but unfortunately, generally, the demanders will not be willing to do this dirty work, and they also need to learn the skills again.My suggestion is,Either the demander tests,Or exists independently.

 

In addition to the combination of diamond, another way to reduce the role or its pressure is"Giant shoulders ".

Giant shoulders come from two aspects:

L Company Accumulation

L industry standards

Due to the uniqueness, management, needs, development and testing of software projects, even if there are standards available, they can only be used as work guides, it cannot be the work result itself. for example, a team that has reached the level of cmmi3 cannot remove management, because the management content of each project is different and the situation is also different;

I think the architecture and design that can leverage the shoulders of giants are. in a specific software field, if the company has already formed a considerable accumulation, or the industry already has a fairly mature standard, then the architecture and design do not have to be done by yourself, and can steadily stand on the shoulders of giants. for example, a mature game company can basically follow the previous architecture to develop a new game architecture. The design backend architecture of another website can completely follow the mature solutions in the industry.

So, if there is a giant's shoulder, can we omit the architects and designers? My answer is no.

First of all, the company's accumulation is definitely not out of nothing. It comes from the experience of the architecture and design personnel in each project of the company. The accumulation of the company and the existence of the architecture design personnel are a paradox, with their presence, the company can accumulate some wealth, and the increasing wealth will free up their pressure, A team that does not pay attention to architecture and development personnel from the beginning has no way to accumulate. The so-called "company accumulation" is just a giant.

So what about "industry standards"? Can we replace our own architecture designers? I think it is also inappropriate. newton's "giant shoulder" is actually just a humble word. Newton itself is a giant. Before riding on the giant's shoulder, you must be able to climb the giant's arm. the standard model in the industry, the architecture system is just a cooked dish. They are more advanced than lettuce, but they still need to be digested before they can enter the team and become a fortune for the team, this digested person is our framework and designer.

In short, I agree"Giant shoulder"The existence of architecture, if used properly, can greatly reduce the pressure on the architecture and design personnel, but I believe that the existence of giant shoulders is not a denial to the architecture designer, on the contrary, excellent architecture and design personnel are the prerequisite for a giant's shoulders. When a team can embark on the shoulders of giants, it is precisely when the framework designers work hard to return.

Simple team building Guide

Step 1:Find the navigator.

Find a manager in the team and give him some power. My advice for this manager is:

1. Have certain communication skills and cannot be "pure technical personnel" (everyone understands)
2. If you do not have any management skills, you must carry out certain project management training and sharpen your skills.
3. Development skills cannot be blank (this is slightly different from my theory, but I think the development skills of the leaders of small teams cannot be completely blank, and the managers selected from General teams cannot be blank)
4. Have certain qualifications and prestige.
5. The most important thing is to try to separate his non-management work as much as possible,Let him manage it!

 

Step 2:Determine technical heights

We are engaged in technology, and everyone has a scale in their hearts. Who is more powerful and clear at a glance. Therefore, it is not a problem to look for a team's Technical High. The problem is that it is difficult to turn this Technical High into a framework engineer. My suggestions for architects are:

1. Must be the most technically competent team (unless there are serious personality problems)
2. You can brainstorm on the architecture, but the architect is the decision maker and the technical leader.
3. Minimize specific development, so that he can think about, summarize, and write documents. If there are more people, let him teach others, review others, don't let him do it. (When the level of secondary personnel is too large, he can write General and background code)
4. He is encouraged to summarize, think, write documents, training, review as much as possible, rather than development.

 

Step 3:Demand Analyst

Select a person who has expertise in customer communication and is also a technical backbone in the team. It is best to have more than five years of experience and do not use new people for demands.

1. Willingness and expertise to communicate with customers.
2. The technical capabilities are not weak, so you can understand the technical options of the framework.
3. Good at requirement development methods and tools (such as UML ).
4. Do not participate in specific design and development as much as possible to maintain a global sense of requirements.

 

Step 4:Advanced Development to design

The design generally comes from relatively advanced development, but the Tangle is that development is often not enough, but this should not be the reason, because even if there is no design, all the development must also be designed by themselves, therefore, one or two developers are extracted for design. A complete and clear design can save half of the development time.

My suggestion is:

1: experts in development should have a reasonable understanding of system design.

2: prototypes can be made with the assistance of the artist

3: one design can be developed for two developers, and three to four teams with mature design specifications.

4: design code that can be reviewed and developed, and guide them to understand their own design.

 

Step 5:Cultivate our development

PreviousArticleI have already mentioned a rough idea.

1. Hone self-discipline through certain encoding rules. Especially comments.
2. Continuous self-check: code review and unit test.

 

Step 6:Add to the last line of defense

Join testers as much as possible to assist developers. My suggestion is:

1. The ratio of testing and development is or, and the stress is too high if the ratio is less.
2. Basic Testing skills are trained.

 

 

The six-person model is just a start

 
At the bottom of the cmmi3 team, there are 20 members, and the six teams are only a bit self-struggling with the lack of money and desire to live a good life. Others are targeting ten million RMB projects, we only use it to build a 0.1 million-level project.
 

 
Let's talk about cmmi2. cmmi2 has already required configuration management, requirement management, and QA supervision. If there are six teams, someone will say that configuration can be done without project management, can requirement analysis be used for requirement management and QA? I can only smile. "I want to run the horse again, but I want the horse to not eat grass". This is already a joke. Now I want the horse to fly. Do I want to create a myth? In my opinion, let's take a look at the horse first, at least it's still running. therefore, the six-person model is just a 1.5 level of cmme. It is just a matter of self-deception. But I don't feel discouraged. What I know is: the six-person model allows the team to get a glimpse of what the team should do and how to get into the room, so that everyone in the team can think slowly, learn carefully, and do what a truly healthy software team needs, what is your career direction? Opening a skylight for the further development of teams and individuals has achieved remarkable progress.
 

In conclusion, the long-term stable and healthy development of a team depends on two points:
 

 
L self-development and accumulation of the team
 

 
L personal ascending Channel
 

 
The six-person model I proposed also takes into consideration these two points to prepare for the future of the team: the team's accumulation comes from the continuous research on its unique skills from the roles with clear division of labor, in the actual work process, a model with clear division of labor and sufficient space provides an opportunity for people in each role to think independently and gather their experiences, formed the self-development and accumulation of the team. In addition, development-design-demand-architecture-management is a necessary development path. Only by being down-to-earth and step-by-step can we make solid footprints in our career.
 

Finally, I have a dream that our software developers can break through the constraints of the environment and conditions, build on their own lofty ideals, and have unlimited enthusiasm for software development, be brave enough to develop your own and the way your company should go. You must never go over and stick to it. No matter what kind of model you use, you must look for the true meaning of software development.

 

Note: The above is not the final conclusion. In the subsequent sections, I will expand some aspects of the process I am currently working on, and push the six-person model to practical use.