общая проблема и она характерна не только для Scrum'а. Чем больше разработчиков, тем больше проблем.
Мы и с этим экспериментировали (как обычно). Максимальный размер команды, работавшей у нас над одним проектом, был порядка 40-ка человек.
Как оказалось, ключевыми являются следующие вопросы:
• Сколько сформировать команд?
• Как распределить людей по командам?
Сколько сформировать команд
Если настолько сложно работать по Scrum'у с несколькими командами, то зачем вообще заморачиваться? Почему просто не собрать всех в одну команду?
Самая большая Scrum-команда, которая у нас когда-либо была, состояла из 11-ти человек. И это работало, правда, не очень хорошо. Ежедневный Scrum всегда длился больше 15-ти минут. Членам команды было сложно держать в голове информацию о том, чем каждый из них занимается, из-за этого могли возникать недоразумения. ScrumMaster'у тоже было сложно направить работу в нужное русло, и было сложно найти время, чтобы разобраться со всеми возникшими трудностями.
Как вариант, можно выделить две команды. Но будет ли это лучше? Не факт.
Если команда опытная, ей комфортно работать по Scrum'у, и вы знаете, как правильно разделить работу на два отдельных направления, что позволит избежать одновременной работы над одними и теми же исходниками, тогда я скажу, что это хорошая идея: разделить на отдельные команды. В противном же случае, не смотря на все минусы работы в большой команде, я бы подумал о том, как оставить одну большую команду.
Мой опыт показывает, что намного лучше иметь несколько больших команд, чем много маленьких, которые постоянно будут мешать друг другу. Создавайте маленькие команды только тогда, когда они не нуждаются во взаимодействии друг с другом.
Виртуальные команды
Как же понять, насколько правильно были оценены преимущества и недостатки при выборе между «большой командой» или «несколькими командами»?
Будьте предельно внимательны, и вы заметите формирование «виртуальных команд».
Пример 1: Вы остановились на одной большой команде. Но как только начнёте наблюдать за тем, кто с кем общается на протяжении спринта, то заметите, что команда фактически разбивается на две подкоманды.
Пример 2: Вы решили сделать три небольшие команды. Но как только начнёте прислушиваться, кто и с кем говорит в ходе спринта, то заметите, что первая и вторая команды общаются между собой, тогда как третья работает сама по себе.
Что бы это значило? Что ваша стратегия разделения была неправильной? И да (если виртуальные команды постоянные) и нет, (если виртуальные команды временные).
Взгляните ещё раз на первый пример. Если состав обеих виртуальных подкоманд меняется (т. е. люди переходят из одной виртуальной подкоманды в другую), тогда возможно вы приняли правильное решение, создав одну большую Scrum-команду. Если же две виртуальные подкоманды в ходе спринта остаются неизменными, то, возможно, для следующего спринта их следует разбить на две настоящие независимые Scrum-команды.
Теперь вернёмся ко второму примеру. Если первая и вторая команды общаются друг с другом (но не с третьей) на протяжении всего спринта, тогда возможно для следующего спринта следует объединить первую и вторую команду в одну Scrum-команду. Если первая и вторая команда очень плотно общаются в первой половине спринта, а во второй половине спринта уже первая и третья команды ведут оживлённые беседы друг с другом, тогда думаю, вам стоило бы рассмотреть возможность объединения всех трёх команд в одну, или всё-таки оставить эти команды как есть. Поднимите этот вопрос на ретроспективе и дайте возможность командам самим решить его.
Разбиение на команды — это действительно одна из самых сложных задач в Scrum'е. Не пытайтесь копать очень глубоко или заниматься очень сложной оптимизацией. Экспериментируйте, наблюдайте за виртуальными командами, и не забывайте уделять обсуждению этого вопроса достаточно времени на ретроспективах. Рано или поздно вы найдёте для себя правильное решение. Однако запомните, что вам следует сделать всё, чтобы команды чувствовали себя комфортно и не мешали друг другу слишком часто.
Оптимальный размер команды
Практически во всех книгах, которые я читал, утверждается, что «оптимальный размер» команды составляет примерно 5–9 человек.
Исходя из того, что я видел, остаётся только согласиться с этим мнением. Хотя, как по мне, всё-таки лучше иметь команду от 3-ёх до 8-ми человек. Поднапрягитесь, но создайте команды такого размера.
Допустим, у вас есть одна Scrum-команда из 10-ти человек. Подумайте, может быть стоить выкинуть двух наиболее слабых участников команды. Ой-йо-йой, я что — правда, сказал это?
Предположим, вы разрабатываете два разных продукта, у вас по три человека в каждой команде, однако обе команды работают очень медленно.
Допустим, у вас одна Scrum-команда из 12 человек, которую нереально разбить на две независимые команды только потому, что исходный код страшно запущен. Вам придётся приложить максимум усилий, чтобы отрефакторить (вместо того чтобы клепать новый функционал) исходный код до такой степени, чтобы над ним могли работать независимые команды. Поверьте мне, что, скорее всего, ваши «инвестиции» окупятся с лихвой.
Синхронизировать спринты или нет?
Предположим, есть три Scrum команды, которые работают над одним проектом. Должны ли их спринты быть синхронизированными, т. е. начинаться и заканчиваться одновременно? Или же они должны пресекаться друг с другом?
Сначала мы решили, что нужны пересекающиеся спринты (по времени).
Это звучало круто. В любой момент времени у нас был бы спринт, который вот-вот закончится, и
