Исследования, анекдоты и личный опыт утверждают, что команды из 3–8 человек являются лучшими, но вот что я обнаружил
Идеальное количество программистов в проекте почти всегда один. - либеральная интерпретация закона (Фреда) Брука.
Я не уверен, действительно ли он это сказал, но он сказал:
«Если в проекте n работников, существует (n²-n) / 2 интерфейсов, через которые может осуществляться связь, и потенциально существует почти 2 ^ n команд. внутри которого должна происходить координация ».
Визуально проблема коммуникации выглядит так, как показано ниже (закон Меткалфа):
Вы тратите / тратите много времени на общение по мере роста команды - некоторые говорят, что до 40% вашего дня. Если вы один, вы можете тратить время на другие дела, но у вас гораздо больше времени на программирование. Означает ли это, что это оптимальный размер? Подробнее об этом позже.
Исследования говорят ‹9
В статье, посвященной анализу репозитория программных проектов Международной группы стандартов тестирования программного обеспечения (ISBSG), исследователи суммировали три фактора, влияющих на производительность программного обеспечения:
- Язык программирования
- Платформа разработки
- Размер команды
Данные показали, что средний размер команды составляет 8 человек, а в среднем - 5 человек из колоссального диапазона от 1 до 40 человек. Их вывод, относящийся к размеру команды, является довольно общим, несмотря на название статьи, в целом: команды из
Магия Миллера 7 ± 2, Закон Амдала и т. Д.
Большинство руководств по Scrum и Agile оправдывают числа вроде 7 ± 2, ссылаясь на знаменитое исследование Миллера о том, что это число является типичным пределом человеческого познания (более поздние исследования предлагают четыре фрагмента с точки зрения объема краткосрочной памяти). Это интересно, но это не совсем означает, что 4 или 7 применимы к размеру команды.
Но с этим связана проблема экспоненциального роста коммуникации, которая предполагает, что меньшие команды лучше сокращают накладные расходы - но насколько маленький оптимален?
Также Брукс отметил, что масштабирование с более крупными командами требует распараллеливаемой работы (задач), которая не требует особой координации с другими. Сегодня это может быть проще с микросервисами по сравнению с монолитами прошлого. Тем не менее, в команде разработчиков микросервисов у нас есть та же проблема. Еще раз процитируем легенду:
«Брукс также классифицирует задачи как (i) идеально разделяемые задачи; (ii) неразмеченная задача, (iii) разделяемая задача, требующая связи; и (iv) задача со сложными взаимосвязями ».
«По его мнению, большинство задач в программной инженерии относятся к последней категории, задачам со сложными взаимосвязями. [1] »
Судя по этим котировкам - чем меньше, тем лучше, но слишком мало - слишком медленно.
Марк Левисон связывает возможность масштабирования с законом Амдала, что мне интересно. Вы можете ускорить работу систем (разработчиков) за счет максимально возможного распараллеливания. Даже в этом случае существует предел или убывающая отдача, и все это зависит от способности находить задачи программирования, которые можно выполнять полностью независимо, что, к сожалению, как указывалось ранее, по словам Брукса, является наименее распространенной из задач программирования.
При этом обычно есть смысл в распараллеливании чего-либо значительного по масштабу. Поиск волшебного оптимального размера продолжается - давайте исследуем крайности.
Экстремальное / парное программирование == Команда из двух человек?
Популярность Кента Бека и парного программирования может означать, что команда из двух человек идеальна. Я не верю в это, но я бросил это просто ради удовольствия, потому что я действительно считаю, что самая маленькая команда является наиболее эффективной, причем одна немного одинока, поэтому двое - достойный компромисс. По моему собственному опыту, в типичной команде разработчиков программного обеспечения со средней мощностью одна суперзвезда выполняет основную часть программирования. Я видел это несколько раз, и это отчасти подтверждает, что команда из одного или двух человек может действительно работать (один занимается кодированием, другой покупает кофе и сообщает обновления руководству).
Проекты с открытым исходным кодом: размер команды 10 000
Противодействием небольшим командам является успех крупных проектов с открытым исходным кодом, таких как Linux, у которых было более 20 000 участников (4 000+ в последние годы). Оказал ли Linux, возможно, самый успешный проект с открытым исходным кодом в мире, неправильное направление работы небольшой команды?
Я думаю, что нет - поскольку в Linux происходит несколько уникальных вещей:
- Единый набор строгих утверждающих, особенно когда речь идет о работе на уровне ядра.
- Большое количество «дополнительных функций / модулей», с которыми можно работать полностью независимо
- Большинство участников, работающих неполный рабочий день, добавляют дополнительную функцию или исправляют ошибку.
При этом успех крупномасштабных проектов, таких как Linux, показывает, что недавние методы и инструменты сделали большую командную разработку намного более успешной, чем 20 лет назад (см. Мой предыдущий пост по этой теме).
Личный опыт говорит ~ 5
Я верю в небольшие команды, но я также знаю, что пользователи и менеджеры кричат поторопиться, поэтому мы должны найти золотую середину в виде масштабируемой продуктивности при приемлемом уровне потери продуктивности. Я бы предпочел начать со смешанной команды из пяти человек для «типичного» проекта ЕО. Архетипы могут включать следующее:
- Технический руководитель - опытный технический архитектор, сильное руководство людьми + опытность в продуктах и управлении.
- Старший разработчик - хотя бы один старший руководитель, который знает язык, инструменты разработки и поднимает планку эффективности команды.
- Core Developer - стандартный кодировщик, который знает, как делать вещи. Получите пару таких на случай, если у одного разрядятся батареи.
- Младший разработчик - команда захочет, чтобы кто-то тренировал и наставлял, а также выполнял повторяющуюся / младшую работу (и, возможно, пошел за обедом).
- Psuedo-DevOps - вам нужен кто-то, кто по-прежнему является сильным разработчиком, но имеет опыт и интерес в оптимизации инфраструктуры разработки между задачами разработки продукта, это будет еще одним подъемом планки.
Эта команда из пяти человек также удовлетворяет правилу двух пицц (хотя я клянусь, что могу съесть две самостоятельно), находится в пределах правила 7 ± 2, рекомендаций Scrum Alliance из 3–9 и всего на волосок выше последних четырех. правило памяти элементов и т. д. Большинство коллег и связанных блогов / статей согласны с однозначным диапазоном. Это оптимальный размер?
Резюме - команда из одного человека
Вернемся к исходному вопросу - оптимальна ли команда из одного человека?
Если цель - достичь максимальной производительности на человека, тогда ДА. Идеальна способность одного человека полностью понять проблему и предвидеть решение. Вы можете избежать накладных расходов (закон Меткалфа), связанных с необходимостью объяснять людям видение, а также времени на проверку и пересмотр кода, чтобы обеспечить соответствие видению.
Недостатком является невозможность параллельного выполнения задач и ускорения сетевой доставки (закон Амдала), а также отсутствие команды, которая могла бы отразить идеи и коллективно улучшить код.
Таким образом, ответ - НЕТ, команда из одного человека не оптимальна, если у вас нет неограниченного времени для завершения проекта. Кажется, что все согласны со средним уровнем от 3 до 9, в зависимости от размера вашего проекта.
