How to better combine a small project team

Project Team = main process (inspection design) + auxiliary process + documentator (Inspection Service) + test (check version management) How is this combination?
One main user, One reviewer (Inspection Service), one test (version check management), and at least one auxiliary user.

* It depends on how many people there are and what people have to do if there are fewer people.

* Many small companies do everything in this way, which is not very efficient.

* The team is too small to be omnipotent

* It is reasonable for four people.

* Within 10 employees, 8-10 people. How can we minimize the cost?

* Your statement is classical and ideal.
In general, if it is small, Management 1 (often part-time by SE) + SE1 (Design) + 1 ~ 2pg (encoding) + 1 ~ 2. Testing (QA ).
The software development industry should not be all-powerful, but you must be at least "Tie Ren"
Ability to design (requirements, Gui, system), write code (thousands of lines per day, no insects written), and work overtime (wearing the stars and months )...

* Is it a small team or a small company?
I think document and version management should be implemented by the company in a unified manner. Is it necessary to assign a dedicated person to such a mini team?

In any case, there should be a person in charge of requirement and Progress Management in the project. I think it is better to have two developers, one focusing on demand and management, the other focusing on architecture and design, and the other looking for another test.

* In general, if it is small, Management 1 (often part-time by SE) + SE1 (Design) + 1 ~ 2pg (encoding) + 1 ~ 2. Testing (QA ).
The software development industry should not be all-powerful, but you must be at least "Tie Ren"
Ability to design (requirements, Gui, system), write code (thousands of lines per day, no insects written), and work overtime (wearing the stars and months )...
IT elites

* I think document and version management should be implemented by the company in a unified manner. Is it necessary to assign a dedicated person to such a mini team?

In any case, there should be a requirement and progress manager in the project.
In this way, we can understand:
The tester can package and release the version if he knows what the problem is.
The service personnel can organize documents to understand what the customer understands.
The product manager or project manager focuses on requirements and management,
The architecture and design focuses on architects. I think there is only one person in the company, and the team can be absent.

* Is testing and debugging not one?

* How to understand small project teams

Is it a small project? Or a small team? How to define a small project (smaller? Man-month )? How do small teams define (smaller? Persons)
Small projects can be developed by large teams, and small teams can also develop large projects.

* Small companies all work on projects, such as testing and architects. It is estimated that they do not have such specialized positions. Although multiple projects can be shared.

* See what the project is. Some projects have very low requirements on documents and do not require specialized document personnel. The ratio of developers to testers is 2 to 1.

* More experts
We can see who contributes a lot!

* A team of 10 members

1 architect
1 DBA
1 UI + webpage
2 System Analyst (and Senior Programmer)
2. Advanced program Meta
2 programmers
1. Project Manager

And divide it into three groups.
1. Architects + DBAs + UI determine the core of the project
2 Team A system analyst + 1 Senior Programmer + 1 Programmer
3 Team B system analyst + 1 Senior Programmer + 1 Programmer

Team A and Team B are testers of each other.

The project manager is responsible for coordinating three groups. The project manager has multiple roles. Quality control and coordination

* If the team is too small, I will not have such a detailed division of labor.
Generally, after dividing the modules, I will arrange for two people to take charge of the same modules. The two are actually co-developed, and the efficiency seems low, but the white box test of RD is very effective.
Of course, a system analyst is indispensable, but I like meetings when I assume this role.
Our rule is that when two people communicate together, they are called meetings. Each meeting must have results. If the two people cannot get the results, they will join in to discuss the results. Every meeting must have a record. The program notes should be reflected, =
Well, we are engaged in transmission, and there are many distributed programs. We have also played role-playing games, that is, everyone is acting from the perspective of their own modules, and everyone is standing on the podium, who started to say what data I entered here, what processing, what details, and who then, the next person, then said...
This is an excellent result. Many people did not listen carefully or are confused during the pre-meeting. For such a drill, what modules, functions, key algorithms, and why are we responsible, the game helps you understand who you are, who you are, and how you interact.
Haha. If you are interested, you can play.

* Generally, after dividing the modules, I will arrange for every two persons to take charge of the same modules. The two are actually co-developed and seem inefficient, but RD's white box testing results are very good.

Long knowledge. High.

* Generally, after dividing the modules, I will arrange for every two persons to take charge of the same modules. The two are actually co-developed and seem inefficient, but RD's white box testing results are very good.
Communication between two people is a bit like Pair programming.
It is indeed not a small innovation to pass through the game.