• Позволить специально назначенному человеку провести распределение, например «тимлиду», про которого я писал выше, product owner’а или любому другому менеджеру (если у него достаточно информации, чтобы с этим справиться).

• Позволить командам каким-то способом самоорганизоваться.

Мы попробовали все три стратегии. Три?!? Ну да — стратегию № 1, стратегию № 2 и их комбинацию. И оказалось, что комбинация двух стратегий работает лучше всего.

Перед планированием спринта тимлид приглашает Product owner’а и всех ScrumMaster'ов на совещание по поводу формирования команд. Мы обсуждаем прошлый спринт и решаем, есть ли необходимость в переформатировании команд. Возможно, нам нужно объединить две команды или перевести несколько человек из одной команды в другую. Мы решаем, что именно нам нужно, записываем это на листик и несём на планирование спринта как предварительное распределение по командам.

Первым делом на планировании спринта мы проходимся по наиболее приоритетным историям из product backlog’а. А потом тимлид говорит что-то вроде:

«Всем привет. Вот как мы предлагаем сформировать команды на следующий спринт».

«Как видно, мы собираемся уменьшить количество команд с четырёх до трёх. Составы команд указаны. Пожалуйста, сгруппируйтесь согласно спискам и выберите себе подходящую стену для планирования».

(тимлид ждёт пока народ побродит по комнате, и через некоторое время появляются три группы людей, каждая соберётся возле своей части стены).

«Текущее распределение — только прикидка! Просто чтобы было с чего начать. По мере планирования спринта любой из вас волен переходить в любую другую команду, можно разделять команды, можно, наоборот, объединять их… В общем, делайте всё, что подскажет здравый смысл, учитывая приоритеты, которые озвучивает product owner.»

Описанный выше подход оказался для нас наиболее эффективным. Немного директивного управления, которое оптимизируется разумной долей самоуправления.

Предположим, ваша система состоит из трёх основных компонентов:

Клиент

Сервер

БД

Допустим, что над вашим продуктом работают 15 человек, и вам не очень хочется собирать их в одну Scrum-команду. Как же разделить людей на команды?

Можно создать команды, специализирующиеся на конкретных компонентах. Тогда мы получим «команду для клиентской части», «команду для серверной части» и «команду для базы данных».

Именно с этого подхода мы когда-то начинали. Работает не очень хорошо, по крайней в том случае, когда большинство историй затрагивают сразу несколько компонентов.

К примеру, возьмём, историю, которая называется «доска объявлений, где пользователи могут оставлять друг другу сообщения». Для создания такой доски объявлений нам придётся обновить пользовательский интерфейс в клиентской части, добавить бизнес-логику на стороне сервера, и добавить парочку таблиц в базу данных.

Это значит, что всем трём командам придётся довольно плотно сотрудничать, чтобы закончить эту историю. Не очень удобно.

А можно создать универсальные команды, то есть команды, которые не заточены на работу всего лишь с одним специфическим компонентом.

Если большая часть всех историй предполагает работу над несколькими компонентами, тогда такое разделение на команды работает намного лучше. Каждая команда сможет реализовать историю целиком: клиентскую часть, серверную и базу данных. Благодаря чему команды смогут работать намного более независимо друг от друга, что на самом деле ОЧЕНЬ ХОРОШО.

Когда мы начали внедрять Scrum, первым делом мы сделали из всех наших специализированных команд (подход № 1) универсальные команды (подход № 2). Это уменьшило количество ситуаций «мы не можем закончить задачу, так как ждём, пока эти ребята закончат серверную часть».

Однако иногда нам всё-таки приходится собирать временные команды, специализирующиеся на разработке отдельных компонентов.

Обычно каждый спринт обладает своими собственными особенностями в зависимости от того, какого рода задачи мы пытаемся решить. Как следствие, оптимальный состав команды для каждого спринта может отличаться.

Фактически, почти каждый спринт нам приходилось говорить себе что-то вроде: «этот спринт не совсем обычный спринт, потому что (ля-ля-ля)…». Через некоторое время мы прекратили использовать понятие «обычный» спринт. Обычных спринтов просто нет. Так же как нет «обычных» семей или «обычных» людей.

Для одного спринта может показаться хорошей идеей, создать команду, которая занимается клиентской частью приложения и включает в себя всех, кто хорошо знает код клиента. Для другого спринта хорошей идеей может быть создание двух универсальных команд и разделение специалистов по клиентской части между ними.

Одним из ключевых аспектов Scrum'а является «сработанность команды», т. е. если члены команды работают вместе в течение многих спринтов, они обычно становятся очень сплоченными. Они научатся входить в групповой поток, и достигнут невероятного уровня продуктивности. Но чтобы достичь этого требуется несколько спринтов. Если вы будете часто изменять состав команды, то вы никогда не достигнете настоящей командной сработанности.

Поэтому, если вы решили изменить состав команды, учитывайте все последствия. Будут ли это долговременные или кратковременные изменения? Если кратковременные, стоит их пропустить. На долговременные изменения можно пойти.

Есть одно исключение: большая команда, которая только-только начала работать по Scrum’у В этом случае возможны некоторые эксперименты с разделением команды на подкоманды, пока не будет найден вариант, который полностью устраивал бы всех. Удостоверьтесь, что все понимают, что отрицательный результат — тоже результат, что первые несколько итераций могут быть комом — и это нормально, при условии, что вы работаете над улучшениями.

Могу только подтвердить то, что говорят книги, посвящённые Scrum’у наличие в Scrum-команде участников с частичной занятостью — не очень хорошая идея.

Предположим, вы рассматриваете возможность взять Джо в свою команду как участника с частичной занятостью. Сначала хорошо всё обдумайте. Действительно ли Джо необходим вашей команде? Уверены, что не можете заполучить его на полный день? Какие у него ещё обязанности? Можно ли передать обязанности Джо кому-то другому и перевести его на роль консультанта? Можно ли заполучить Джо на полный день, начиная со следующего спринта, а пока передать его обязанности кому-то другому [6]?

Но иногда просто нет выбора. Вам позарез нужен Джо потому, что он единственный администратор баз данных (DBA) во всём здании. Другим командам он нужен так же сильно, как и вам, поэтому он никак не может работать с полной занятостью в вашей команде. Кроме того, компания не может себе позволить нанять ещё одного DBA. Ну и ладно. Это аргументированный случай, чтобы взять его на неполную занятость (что, кстати, было у нас). Но прежде, чем сделать это, всегда проводите подобный анализ.

В обычной ситуации я бы предпочёл команду, состоящую из трёх участников с полной занятостью, чем из восьми, но с частичной.