Сколько разработчиков занимались одной фичей?

Командная разработка: опыт работы в команде

Сколько разработчиков на одну фичу?

Это зависит от сложности и времени.

Размеры команд для разных фич

Small Feature (1-3 дня работы):

• 1-2 разработчика
• Пример: добавить новый эндпоинт, bug fix
• Workflow: один пишет, второй review

Medium Feature (1-2 недели):

• 2-3 разработчика
• Пример: новый модуль (auth, payment)
• Workflow: фронт + бэк + дб-миграции

Large Feature (3-4 недели):

• 3-5 разработчиков
• Пример: полная интеграция с внешним сервисом
• Workflow: требует координации между компонентами

Epic (1-3 месяца):

• 5-10 разработчиков
• Пример: миграция на микросервисы, новая платформа
• Workflow: несколько параллельных фич, много coordination

Из моего опыта

Платформа подписок (2 года, 10+ разработчиков):

• Core subscription engine — 2 senior разработчика

  • Архитектура, database design
  • 3-4 месяца

• Billing integration — 2-3 разработчика

  • Интеграция Stripe
  • Обработка платежей
  • 4-6 недель

• Admin dashboard — 2-3 разработчика

  • Фронт-енд (React)
  • Бэк-енд API
  • 2-3 месяца

• Analytics & reporting — 1-2 разработчика

  • MRR, churn rate, ARPU
  • 1-2 месяца

High-load API optimization (3 месяца, 4 разработчика):

• Database optimization — 1 DBA + 1 backend

  • Индексирование, partitioning
  • 2-3 недели

• Caching layer — 1 backend

  • Redis, cache invalidation
  • 2-3 недели

• Performance testing — 1 qa + 1 backend

  • Load testing, profiling
  • 1-2 недели

Как координировать команду

1. Daily standups (15 минут)

Что я вчера делал? Что буду сегодня? Есть ли блокеры?

2. Clear task breakdown

Feature: Payment Integration
├── Task 1: Stripe API integration (Ник, 5 дней)
├── Task 2: Payment validation (Маша, 3 дня)
├── Task 3: Error handling (Паша, 3 дня)
└── Task 4: Tests (Ирина, 4 дня)

3. Code ownership

• Один человек = один компонент
• Но code review от других

4. Regular sync meetings

• 2-3 раза в неделю
• Обсуждаем архитектурные решения
• Решаем блокеры

Когда один разработчик — не вариант

Причины нанимать больше:

1. Timeline — нужно быстро

   • 2 разработчика вместо 1 не дают 2x скорость
   • Но дают ~1.5x скорость (за счёт параллелизма)

2. Complexity — фича сложная

   • Нужны разные специальности (фронт, бэк, дба)
   • Один человек не может быть экспертом везде

3. Knowledge sharing — обучение

   • Junior + Senior
   • Передача знаний
   • Но это медленнее в краткосрочке

4. Risk mitigation — важная фича

   • Если один заболеет/уйдёт?
   • Лучше 2 человека для critical features

Проблемы больших команд

1. Communication overhead

С 3 разработчиками: 3 коммуникационных канала

• A ↔ B
• A ↔ C
• B ↔ C

С 10 разработчиками: 45 каналов (10*9/2) Это создаёт bottleneck!

2. Interface problems

Когда 3 разработчика пишут 3 разных модуля, их interface должны совпадать.

// Backend 1 (Ник) написал:

POST /api/v1/payments {"order_id": "uuid", "amount": 100}

// Frontend (Маша) ожидает:

POST /api/v1/orders/{id}/pay {"amount": 100}

// Несоответствие! 1 час потеряно на согласование.

3. Merge conflicts

Когда много людей пишут в один файл.

// git merge конфликт

<<<<<<< HEAD

return user.getName();

=======

return user.getFullName();

feature-branch

Развитие: инкапсулировать изменения в разные файлы.

Best practices

1. Четкие boundaries

Если 3 разработчика работают на одной фиче:

• Разделяем на компоненты
• Каждый отвечает за свой
• Interface описан заранее

2. Early integration

Вместо того, чтобы 3 неделе писать отдельно:

• Интегрируем каждый день
• Видим проблемы рано
• Синхронизируем interface

3. Clear ownership

Это не значит, что других нельзя трогать! Но значит: если что-то сломалось в твоём компоненте, ты отвечаешь.

4. Documentation

Когда люди работают параллельно:

• API контракты в Swagger/OpenAPI
• Database schema в диаграмме
• Architecture decision records

Оптимальный размер команды

По research (Jeff Bezos's "two pizza rule"):

Теам должен быть такого размера, чтобы можно было накормить 2 пиццами.

• Small team: 2-5 человек
• Medium team: 5-8 человек
• Large: 8+ (нужны lead, scrum master, etc.)

Для большого проекта: несколько small teams, а не одна large.

Мой опыт

Лучше всего работается в команде 3-5 человек:

• Достаточно разнообразия (фронт, бэк, qa)
• Достаточно коммуникации (все знают друг друга)
• Достаточно скорости (параллельная работа)
• Не слишком много overheads

Больше 8 человек на одну фичу — требуется скаффолдинг (Scrum Master, Lead), что добавляет overhead.

Вывод

Велик — не всегда хорошо. Оптимум: 2-4 разработчика на среднюю фичу.