Как большой является БОЛЬШИМ? (группа разработчиков) [закрывается]

Если вы спросите Джеффа Безоса , оптимальным вариантом будет « команда из двух пицц »: если вы не можете накормить команду двумя пиццами , он слишком велик. Это ограничивает вас до пяти-семи человек, в зависимости от их аппетитов.

Обычно я видел соотношение 2 разработчика на 1 архитектора (аналитика) и 1 QA (тестировщика), то есть 25% архитекторов, 50% разработчиков, 25% QA - в зависимости от о том, как разделена команда

• Функциональность - у вас будет 1 менеджер на каждую область на каждые 6-9 человек - то есть 1 для архитекторов, 1 для разработчиков 1 для QA мин.
• проект - у вас есть 1 менеджер, возглавляющий каждый проект, если проект превышает 9 человек, вы делите их на руководителей групп (менеджер по части / архитектор по части, разработчик или тестировщик)

Команда обычно меняется со временем - сначала у вас будет больше архитекторов, а затем вы перейдете к другим к разработчикам и ближе к концу жизненного цикла проекта появляется больше тестировщиков.

Я управлял командами от 6 до 100, и соотношение обычно примерно такое же.

Я мечтаю о том дне, когда все различные этапы разработки станут частью одной команды, вместо того, чтобы команда «удобно» разбивалась по должностным инструкциям. Этот организационный взгляд имеет тенденцию сильно склонять процессы к ужасному водопаду (боже, я ненавижу этот процесс!).

Но, отвечая на ваш вопрос, я думаю, что в команде не должно быть больше 10 человек с еще несколькими людьми, которые увлекаются этим, не будучи полностью занятыми. его часть (обучение, маркетинг, клиенты, внедрение, поддержка). В целом 80% - 20% разработчиков по сравнению с менеджментом / QA должны стремиться к хорошей производительности. Тем лучше, если ваши архитекторы могут немного покопаться в коде. Частые обзоры дизайна со всей командой также должны позволить каждому хорошо контролировать весь проект, а не только свою кучу бананов.

Вот пример распада команды, который мне очень понравился:

• 2 старших разработчика, которые хорошо разбираются в архитектуре
• 4 младших разработчика, которые могут справиться с тяжелой работой
• 1 ниндзя кода который может проводить некоторые технологические исследования (в то же время участвуя во всем)
• 1 менеджер проекта, руководитель группы, интерфейс с внешним миром, чтобы принести 2 пиццы
• 1 шумный QA-парень, который копается в приложении, пишет согласие тесты и т.д. Шумная часть была для метрики WTF / day. Чем тише он был, тем лучше мы выполняли свою работу и тем меньше потребляли ибупрофена.

К этому стремились некоторые клиенты, на которых мы часто проводили юзабилити-тестирование.

Ха, старые добрые времена !!!

• 2 старших разработчика, которые хорошо разбираются в архитектуре
• 4 младших разработчика, которые могут справиться с тяжелой работой
• 1 кодовый ниндзя, который может проводить некоторые технологические исследования (одновременно участвуя в целом)
• 1 проект менеджер, руководитель группы, интерфейс с внешним миром, чтобы принести 2 пиццы
• 1 шумный QA-парень, который ковыряется в приложении, пишет приемочные тесты и т. д. Шумная часть была связана с показателем WTF / день. Чем тише он был, тем лучше мы выполняли свою работу и тем меньше потребляли ибупрофена.

К этому стремились некоторые клиенты, на которых мы часто проводили юзабилити-тестирование.

Ха, старые добрые времена !!!

• 2 старших разработчика, которые хорошо разбираются в архитектуре
• 4 младших разработчика, которые могут справиться с тяжелой работой
• 1 кодовый ниндзя, который может проводить некоторые технологические исследования (одновременно участвуя в целом)
• 1 проект менеджер, руководитель группы, интерфейс с внешним миром, чтобы принести 2 пиццы
• 1 шумный QA-парень, который копается в приложении, пишет приемочные тесты и т. д. Шумная часть была связана с показателем WTF / день. Чем тише он был, тем лучше мы выполняли свою работу и тем меньше потребляли ибупрофена.

К этому стремились некоторые клиенты, на которых мы часто проводили юзабилити-тестирование.

Ха, старые добрые времена !!!

напишите приемочные тесты и т.д. Шумная часть была для метрики WTF / день. Чем тише он был, тем лучше мы выполняли свою работу и тем меньше потребляли ибупрофена.

К этому стремились некоторые клиенты, на которых мы часто проводили юзабилити-тестирование.

Ха, старые добрые времена !!!

напишите приемочные тесты и т.д. Шумная часть была для метрики WTF / день. Чем тише он был, тем лучше мы выполняли свою работу и тем меньше потребляли ибупрофена.

К этому стремились некоторые клиенты, на которых мы часто проводили юзабилити-тестирование.

Ха, старые добрые времена !!!

Там, где я работаю, я использую Scrum, и для 15-минутного эффективного Standup не может быть более 6 или 7 разработчиков вместе с несколькими другими менеджерами, каждому из которых требуется около 1,5 минут, чтобы соответствовать временные рамки. В число других менеджеров входят некоторые конечные пользователи наших систем, отдел обеспечения качества и руководитель группы, чтобы привести несколько примеров.

Я думаю, что если бы команда была намного больше, работу нужно было бы определить более точно, так как у меня есть немного проблема уже пытается удержать в голове все, что есть в текущем проекте.

Команды должны быть настолько большими, насколько это необходимо для текущего проекта, когда я читаю «большой», у меня создается впечатление, что вы ищете «насколько велико». Я работал с сотнями разработчиков над проектами телефонных коммутаторов, но они всегда распределялись по командам по 5 или 6 человек с руководителем каждой группы - оборудование, программное обеспечение, документация, тестирование и контроль качества, установка, обучение и так далее. Для самих команд становится трудно управлять чем-то большим, чем 5.

Вы можете найти следующую интересную статью.

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

Но, чтобы ответить на ваш вопрос, сложно без понимания того процесса, который вы используете. Например, модель водопада потребует большей команды, чем метод гибкой разработки XP.

Я был в команде из 13 членов, но это имеет тенденцию разбиваться на более мелкие команды, каждая из которых работает над определенными задачами. Если команда достаточно велика, чтобы в игру вступала политика, то она слишком велика. У вас может быть большое количество людей, которые могут хорошо работать вместе, все сосредоточены на завершении проекта и не заботятся о своих личных интересах, и большое количество людей может не вызвать проблемы, но,