Ответ
На последнем проекте я работал в кросс-функциональной команде по методологии Scrum. Общий размер команды составлял 8 человек.
Состав и роли:
- Product Owner (PO) — 1 человек.
- Scrum Master (SM) — 1 человек (часто совмещал роль одного из разработчиков).
- Backend-разработчики (Java) — 3 человека.
- Frontend-разработчики (React) — 2 человека.
- QA Automation Engineer — 1 человек.
Организация работы:
- Спринты: Длительность 2 недели.
- Церемонии: Ежедневные стендапы, планирование спринта, ревью, ретроспектива.
- Инструменты: Jira (таски), GitLab (CI/CD, код-ревью), Confluence (документация).
Пример процесса код-ревью, характерного для такой команды:
// Коллега оставляет комментарий в Merge Request (GitLab/GitHub):
// "Рассмотри возможность использовать @Transactional(readOnly = true) для методов только для чтения."
@Service
public class UserService {
private final UserRepository userRepository;
// После ревью метод был улучшен
@Transactional(readOnly = true) // Добавлено по совету коллеги
public UserDto getUserProfile(Long userId) {
return userRepository.findDetailedProfileById(userId)
.map(this::mapToDto)
.orElseThrow(() -> new UserNotFoundException(userId));
}
}Такой размер команды (5-9 человек) считается оптимальным для Scrum, позволяя поддерживать эффективную коммуникацию и скорость разработки.
Ответ 18+ 🔞
Да ты посмотри, какие у нас тут коллективы собираются, просто ебать мои старые костыли! На прошлом проекте, значит, вкалывали мы по этой вашей Scrum-методологии, в кросс-функциональной команде. Всего народу — 8 человек, как раз по канону, не перебор и не недобор.
Кто был кто, и кто что делал:
- Product Owner (PO) — один чувак, главный по хотелкам. От него все фичи и приоритеты летели.
- Scrum Master (SM) — тоже один. Хотя частенько он был полупидором, совмещал свою роль с разработкой, потому что «экономия, блядь».
- Бэкендеры на Java — три самурая, которые всё на сервере крутили.
- Фронтендеры на React — два художника, которые кнопочки красиво рисовали.
- QA Automation — один человек, который писал скрипты, чтобы всё само падало и ломалось, пока мы спим.
Как мы работали, а точнее, выживали:
- Спринты: По две недели, ровно столько, чтобы успеть накосячить и частично исправить.
- Церемонии: Ежедневные стендапы, где все говорили «вчера работал, сегодня буду работать, проблем нет», а потом после созвона выяснялось, что всё горит. Плюс планирование, ревью и ретро — без этого никуда.
- Инструменты: Jira, чтобы задачи терять, GitLab для священных войн в мердж-реквестах, и Confluence, где документация благополучно устаревала через день после написания.
Вот, например, как выглядело наше «культурное» общение в код-ревью, характерное для такой команды:
// Коллега оставляет комментарий в Merge Request (GitLab/GitHub):
// "Рассмотри возможность использовать @Transactional(readOnly = true) для методов только для чтения."
@Service
public class UserService {
private final UserRepository userRepository;
// После ревью метод был улучшен
@Transactional(readOnly = true) // Добавлено по совету коллеги
public UserDto getUserProfile(Long userId) {
return userRepository.findDetailedProfileById(userId)
.map(this::mapToDto)
.orElseThrow(() -> new UserNotFoundException(userId));
}
}Вот так, с подсказки, код и становился чуть менее говённым. А размер команды в 5-9 человек, он и правда оптимальный, ёпта. Больше — уже сборище, где все друг другу мозги выносят на стендапах, меньше — не потянуть объём. В общем, золотая середина, хоть и с причудами.