В ScrumGuide указано, что команда ограничена размером от 3 до 9 человек. У многих возникает вопрос: не слишком ли это мало? Разве работа не пойдёт быстрее, если людей больше? В некоторых случаях это действительно так. Например, если вам нужно закинуть 10000 писем в 10000 почтовых ящиков. Но при разработке программных продуктов всё работает немного не так.
В этой статье мы расскажем, откуда возникло ограничение на количество человек в команде и почему, работая по Scrum, лучше разделять большой проект на подпроекты, чем вести один большой проект целым отделом.
Работодателей, как никого другого, волнует вопрос эффективности и распределения ресурсов.
Во второй половине XX века проводилось немало исследований по этому поводу. Первые прогнозы трудозатрат на исследования проходили в IBM, и позже Лоуренс Патнэм переложил полученные графики на разработку ПО. Также известна книга Фреда Брукса — «Мистический человеко-месяц». Автор вывел свой закон: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
Исследование Лоуренса Патнэма и Уэйра Майерса рассматривало около 500 программных проектов средней величины. Авторы пришли к выводу, что команды с 9 и 20-ю участниками требуют в четыре раза больше человеко-месяцев, чем команда из 3-7 участников. Размер проекта при этом не менялся.
Scrum не противоречит этим эмпирическим выводам. Вот какие преимущества получает маленькая команда:
Более лёгкая самоорганизация
Scrum-процесс направлен на то, чтобы создать самоорганизующуюся команду, которая способна поставлять ценный продукт. Команда сама решает, как выполнять поставленную задачу.
Чтобы самоорганизация работала, каждый в команде должен синхронизироваться с другими участниками. Разработчики должны знать, что делает коллега, чтобы вовремя предложить свою помощь или обменяться опытом.
Для самоорганизации и взаимопомощи также потребуется, чтобы члены команды хорошо друг друга знали и постоянно общались. Если вы знаете своих коллег, их навыки и привычки, вы будете лучше ориентироваться, к кому и когда обращаться. Вы также будете знать, когда за этой помощью уместно обратиться — насколько загружен коллега и насколько приоритетны его задачи. В свою очередь, другие участники тоже будут знать, с какими вопросами идти к вам.
Это помогает разработке и самоощущению членов команды.
Команда из 5 человек требует 10 цепочек отношений между её участниками. Значение растёт экспоненциально. Для команды из 6 человек нужно уже 14 связей, а для 8 человек — 28.
Когда команда становится больше, большой коллектив делится на подгруппы по степени общения или по личным симпатиям. Это осложняет работу над общей целью.
Если внутри команды (с общей целью) есть группы или подгруппы, они вынуждены координироваться друг с другом дополнительно. В итоге даже большая команда делится на мелкие, так почему бы сразу не установить такое деление?
Меньше времени впустую
Scrum помогает сократить накладные расходы за счёт маленьких команд. Происходит оптимизация времени, которое тратится на встречи. Собрания между небольшой группой людей идут результативнее и быстрее.
Нам нужно прийти к большому результату за меньшее время.
Вовлечённость небольшой группы выше, каждый может принимать участие, не тратя на это целый день.
Например. В нашей scrum-команде 5 разработчиков. Обычно они завершают по 4 пользовательские истории за спринт. К обсуждению выносится 20 историй. За 4 часа, которые отводятся на планирование, команда успеет подробно разобрать каждую задачу.
Теперь представим, что наша команда вмещает в себя 9 разработчиков. Они также успевают сделать по 4 истории. Нужно обсудить 36 историй за те же 4 часа. Или пострадает качество разбора, или придётся увеличить время обсуждения.
Эту закономерность можно отследить не только на планировании, но и на других встречах.
Снижение количества документации
Если команда не очень большая, то, как мы выяснили выше, люди могут сохранять связи друг с другом. Это приводит к тому, что документацию по проекту можно вести через пользовательские истории и другие типы карточек.
Принципы Agile гласят:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Команда приходит к понимают деталей продукта в процессе разговора с Product Owner’ом, она может рисовать схемы, использовать стикеры и доску — всё, чтобы вникнуть в задачу. Это сокращает время на ведение документов, которые не несут никакой ценности. Кроме этого, личное обсуждение снижает риск непонимания.
Если команда большая, документацию придётся вести более тщательно или тратить время на передачу сведений, играя в сломанный телефон. Те, кого не касается конкретная история (а в большой команде этот процент выше), вообще не будут вникать.
Личная ответственность и вовлечённость
В небольшой команде вклад каждого человека выше. В команде из пяти разработчиков каждый вносит 1/5 в ценность продукта. В команде из 20 человек на каждого приходится только 1/20. Чем больше вероятность, что без тебя проект справится, тем ниже мотивация и больше поводов побездельничать.
Возможность видеть, что наш труд принёс успех, сильно мотивирует, а с мотивацией работать легче.
Какой же должна быть команда
Когда вы запускаете новую команду, начните с минимально возможного размера для вашей области. Убедитесь, что в команде достаточно навыков для всех сфер, которые постоянно нужны в разработке продукта. Единичные вопросы лучше решаются через приглашённого эксперта или t-shaped члена вашей команды.
Когда команда проведёт несколько спринтов и поймёт, что ей критически необходимы новые работники, добавьте ещё одного человека. Но помните, что добавление нового сотрудника не увеличивает скорость работы пропорционально. И не поддавайтесь желанию расширить штат за 9 человек, указанных в ScrumGuide.
Если у вас уже большая команда, проведите эксперимент. Разделитесь на две-три группы на несколько спринтов вокруг частей продукта и посмотрите, как увеличатся темпы вашей работы.