How big is BIG? (Development team)

Question

I am interested in what constitutes a large team and what is the attitude of developers, architects, testers, managers, etc.

Does anyone have group size data for famous projects like Windows or SQL Server?

Answer 1

It depends on what you mean by "team." I worked in a large American bank in a .NET team of more than 60 developers, as well as architects, managers and QA.

My current “team” is about 12 developers of different levels, several QA and one solution architect.

But in both situations, I never work with more than three people at a time. Usually only 1 or 2. Thus, in this sense, we are divided into teams 2-4 depending on the tasks. For one project, this roughly corresponds to the limit.

Answer 2

If you ask Jeff Bezos , you optimally want a " pizza team :" If you can't feed a team with two pizzas, it's too big. This limits you from five to seven people, depending on their appetites.

Answer 3

I dream about the day when all the different stages of development are part of one team, instead of the team "conveniently" violating the job description. This organizational view tends to strongly outline processes toward a terrible waterfall (God, I hate this process!).

But in order to answer your question, I think that a team should not exceed 10 people with a few more gravitations around it, not being at full time (training, marketing, customers, implementation, support). In all 80% - 20%, developers against management / QA should strive for good performance. If your architects can also dig in the code a little better. Frequent design reviews with the entire team should also allow everyone to have good oversight of the entire project, not just their bunch of bananas.

Here is an example of a detachment of a team that worked very well for me:

• 2 Sr developers who are well versed in architecture
• 4 junior developers who can handle the grunt work
• 1 ninja code that can carry out some technological research (while participating in everything)
• 1 project manager, team leader, interface to the outside world to bring 2 pizzas.
• 1 noisy QA guy to poke around the application, write acceptance tests, etc. The noisy part was for the WTF / day indicator. The quieter it was, the better we did our job and the less we consumed ibuprofen.

Around this weighed down by some customers on whom we often tested usability.

ha good old days !!!

Answer 4

You can find the following article of interest.

http://www.qsm.com/process_01.html

But, to answer your question, it is difficult to understand the process that you are using. For example, a waterfall model will require a larger team than the flexible XP method.

I was in a team with 13 members, but this usually breaks down into smaller teams, each of which works on specific tasks. If a team is large enough that politics comes into play, it is too large. You can have a large number of people who can work well together, all of them are focused on completing the project and are not looking for their own interests, and a large number may not cause problems, but having these types of people is unlikely.

Everything that is more than 9 people is probably too large, because it is divided into smaller teams, so if the team is large enough to break into small teams, then just small teams will be the size of the team and understand that what you started, it was too big.

Answer 5

The teams should be as large as necessary for the project, when I read "big", I get the impression that you are looking for "how much is too big." I worked on projects with hundreds of developers to develop telephone switches, but they always stood out in groups of 5 or 6 with each of the team leaders - hardware, software, documentation, testing and QA, installation, training, etc. For the teams themselves, nothing more than 5 is hard to handle.

Answer 6

What I usually saw is the ratio of 2 developers for each 1 architect (analyst) and 1 QA (tester), so 25% of architects, 50% of developers, 25% QA - depending on how the team is broken

• function - you will have 1 manager in each area for every 6-9 people - so 1 for architects, 1 for developers 1 for the minimum minimum timestamp.
• project - you have 1 manager leading each project, if the project exceeds 9 people, you will divide it into groups with group leaders (part manager / part architect or developer or tester).

The team usually changes over time, you will have more architects, and then go to more developers and closer to the end of the project life cycle. Testers will come aboard.

I ran teams from 6 to 100, and the ratio is usually about the same.

Answer 7

Where I work using Scrum and having a 15-minute effective Standup, there can be no more than 6 or 7 developers, along with several other managers, each of which takes about 1.5 minutes to meet the deadlines. Other managers include some end users of our systems, quality assurance, and the team provides several examples.

I think that if the team was much larger, the work should have been more precisely defined, since I have a small problem that is already trying to keep in mind all the materials of the current project.