Scrum и XP: заметки с передовой (Книберг) - страница 60

.

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

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

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

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

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

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

Нужны ли узкоспециализированные команды?

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

Клиент

Сервер

БД

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

Подход № 1: команды, специализирующиеся на компонентах

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

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

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

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

Подход № 2: универсальные команды

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

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