Сроки горят, релиз срывается, и бизнес заливает проблему деньгами, нанимая еще пятерых программистов. В итоге разработка встает намертво, баги множатся, а старая команда перестает писать код, превращаясь в нянек для новичков. Закидывать отстающий спринт новыми людьми — верный способ окончательно его похоронить.
Ловушка масштабирования: почему 1 + 1 ≠ 2
Закон Брукса гласит: добавление рабочей силы в отстающий проект делает его еще более отстающим. Scrum Guide 2020 ограничивает размер Скрам-команды до 10 человек. Меньше людей — быстрее коммуникация.
Когда вы заводите нового инженера, бьют два разрушительных фактора. Сеньоры бросают свои тикеты и тратят часы на объяснение архитектуры и раздачу доступов. Формула N(N-1)/2 показывает, что в команде из 5 человек существует 10 линий общения, а при 10 инженерах их уже 45. Синхронизация съедает время, предназначенное для написания кода.
Разработка программного обеспечения требует глубокого погружения в контекст. Новички неизбежно ломают хрупкий баланс, генерируют дефекты и заставляют опытную часть команды тратить ресурс на код-ревью и исправление чужих ошибок.
Таблица
| Действие | Антипаттерн масштабирования | Оптимизация потока (Agile) |
|---|---|---|
| Реакция на срыв сроков | Нанять трех новых разработчиков | Урезать скоуп задачи, выкинуть лишнее из бэклога |
| Коммуникация | Экспоненциальный рост чатов и созвонов | Быстрая синхронизация на Daily Scrum |
| Онбординг | Сеньоры не пишут код, обучая новичков | Стабильный состав сохраняет Velocity |
| Код и архитектура | Код конфликтует, мерж-реквесты висят днями | Код пишется быстрее за счет парного программирования |
Как тушить пожар без найма
Перестаньте раздувать штат. Если команда не тянет объем, режьте Бэклог Спринта. Владелец Продукта (Product Owner) обязан выкинуть из релиза все, кроме критического ядра.
Ограничьте WIP (Work in Progress). Заставьте разработчиков доделывать начатое, а не плодить новые ветки. Внедрите парное программирование. Два инженера за одним монитором решат сложную задачу быстрее и без багов, чем пять человек, пишущих изолированные куски кода.
Если продукт требует больше рук, создайте новую кросс-функциональную ячейку. Выделите ей независимый кусок архитектуры (Bounded Context), чтобы команды не блокировали друг друга при деплое.
Золотое правило Брукса
Девять женщин не выносят ребенка за один месяц. Разработка ПО — это не копание траншей, здесь нельзя линейно масштабировать скорость количеством лопат. Защищайте размер команды, режьте скоуп и оптимизируйте поток, иначе вы просто купите себе более дорогую и медленную пробку из тикетов.
Часто задаваемые вопросы (FAQ)
Покажите метрики. Рассчитайте падение Velocity на время онбординга. Предложите альтернативу: нанять людей в новую команду для будущего функционала, а не бросать их в горящий релиз.
Scrum Guide рекомендует до 10 человек (включая PO и Скрам-мастера). В индустрии также популярно правило «двух пицц» Джеффа Безоса — команда должна быть такой, чтобы ее можно было накормить двумя пиццами (обычно 5-7 человек).
Автоматизируйте рутину. Настройте скрипты для развертывания локального окружения и используйте парное программирование с первого дня, чтобы новичок сразу вникал в контекст боевых задач.
Больше людей — больше конфликтов при слиянии (merge conflicts). Никто не видит архитектуру целиком, ответственность размывается, и ревью кода превращается в формальность.
Используйте фреймворки вроде LeSS. Делите продукт на независимые домены. Каждая небольшая команда получает свой кусок бизнес-логики и поставляет Инкремент без жестких зависимостей от соседей.