Хенрик Книберг - Scrum и XP: заметки с передовой
Оптимальный размер команды
Практически во всех книгах, которые я читал, утверждается, что «оптимальный размер» команды составляет примерно 5–9 человек.
Исходя из того, что я видел, остаётся только согласиться с этим мнением. Хотя, как по мне, всё-таки лучше иметь команду от 3-ёх до 8-ми человек. Поднапрягитесь, но создайте команды такого размера.
Допустим, у вас есть одна Scrum-команда из 10-ти человек. Подумайте, может быть стоить выкинуть двух наиболее слабых участников команды. Ой-йо-йой, я что — правда, сказал это?
Предположим, вы разрабатываете два разных продукта, у вас по три человека в каждой команде, однако обе команды работают очень медленно. Может быть, их следует объединить в одну команду из 6-ти человек. И пусть эта команда одновременно создаёт оба продукта. В этом случае одному из двух product owner'ов придётся уйти (или начать играть роль консультанта, ну или ещё что-то наподобие этого).
Допустим, у вас одна Scrum-команда из 12 человек, которую нереально разбить на две независимые команды только потому, что исходный код страшно запущен. Вам придётся приложить максимум усилий, чтобы отрефакторить (вместо того чтобы клепать новый функционал) исходный код до такой степени, чтобы над ним могли работать независимые команды. Поверьте мне, что, скорее всего, ваши «инвестиции» окупятся с лихвой.
Синхронизировать спринты или нет?
Предположим, есть три Scrum команды, которые работают над одним проектом. Должны ли их спринты быть синхронизированными, т. е. начинаться и заканчиваться одновременно? Или же они должны пресекаться друг с другом?
Сначала мы решили, что нужны пересекающиеся спринты (по времени).
Это звучало круто. В любой момент времени у нас был бы спринт, который вот-вот закончится, и спринт, который вот-вот начнётся. Нагрузка на Product owner’а была бы распределена равномерно по времени. Постоянные релизы продукта. Демонстрации каждую неделю. Аллилуйя.
Да-да, утопия… но тогда это действительно звучало убедительно!
Мы только-только начали так работать, но тут мне подвернулась возможность пообщаться с Кеном Швабером (Ken Schwaber) (в рамках моей Scrum-сертификации). Он указал на то, что это неправильно, и что было бы гораздо лучше синхронизировать спринты. Я точно не помню его доводов, но в ходе нашей дискуссии он меня убедил в этом.
С тех пор мы использовали это решение и ни разу об этом не пожалели. Я никогда не узнаю, провалилась бы стратегия пересекающихся спринтов или нет, но думаю, что да. Преимущества синхронизированных спринтов в следующем:
• Появляется естественная возможность перетасовывать команды между спринтами! При пересекающихся спринтах нет возможности реорганизовывать команды так, чтобы не побеспокоить ни одной команды в разгаре спринта.
• Все команды могут работать на одну цель в течение спринта и проводить планирование спринта вместе, что приводит к лучшему сотрудничеству между командами.
• Меньше административной мороки, например меньшее количество встреч для планирования спринта, демонстраций и релизов.
Почему мы ввели роль «тимлида»
Предположим, что у нас над одним продуктом работают три команды.
Красным помечен product owner. Чёрным — Scrum Master. А остальные это пехота… ну то есть… почтенные члены команды.
Кто при таком распределении ролей должен решать, какие люди будут отнесены к какой команде. Может, product owner? Или может все три ScrumMaster'а вместе? Или вообще каждый человек сам решает, в какой команде работать? Но если так, то что делать в случае, когда все захотят в одну и ту же команду (потому что там красивая ScrumMaster'ша)?
А что если потом окажется, что над этим кодом больше двух команд работать не смогут, и нам придётся трансформировать три команды по 6 человек в две по 9? Это значит, что будет всего 2 ScrumMaster'а. Так кого же из трёх текущих ScrumMaster'ов надо лишить титула?
Во многих компаниях эти вопросы надо решать очень деликатно.
Есть соблазн отдать распределение людей по командам и их последующее перераспределение на откуп product owner’у. Но ведь это не совсем то, чем должен заниматься product owner, правда же? Product owner это специалист по предметной области, который указывает команде направление движения. В общем случае его не должно волновать всё остальное. Особенно, учитывая его роль «цыплёнка» (это если вы слышали про метафору «свиней и цыплят», а если не слышали, то погуглите).
Мы решили проблему вводом роли «тимлид». Человека в этой роли можно описать как «Scrum-of-Scrums master», «босс» или «главный ScrumMaster». Ему не нужно возглавлять какую-либо команду, но он отвечает за вопросы, не входящие в компетенцию команд, такие как, например, «кого назначить ScrumMaster'ом», «как распределить людей по командам» и т. д.
Придумать действительно подходящие название для этой роли у нас так толком и не получилось. А «тимлид» оказалось наименее неподходящим, из тех, что мы перепробовали.
Такой подход сработал в нашем случае, и я его рекомендую (не зависимо от того, как вы решите назвать эту роль у себя).
Как мы распределяем людей по командам
На случай, когда у вас несколько команд работают над одним и тем же продуктом, существует две стратегии распределения людей по командам.
• Позволить специально назначенному человеку провести распределение, например «тимлиду», про которого я писал выше, product owner’а или любому другому менеджеру (если у него достаточно информации, чтобы с этим справиться).
• Позволить командам каким-то способом самоорганизоваться.
Мы попробовали все три стратегии. Три?!? Ну да — стратегию № 1, стратегию № 2 и их комбинацию. И оказалось, что комбинация двух стратегий работает лучше всего.
Перед планированием спринта тимлид приглашает Product owner’а и всех ScrumMaster'ов на совещание по поводу формирования команд. Мы обсуждаем прошлый спринт и решаем, есть ли необходимость в переформатировании команд. Возможно, нам нужно объединить две команды или перевести несколько человек из одной команды в другую. Мы решаем, что именно нам нужно, записываем это на листик и несём на планирование спринта как предварительное распределение по командам.
Первым делом на планировании спринта мы проходимся по наиболее приоритетным историям из product backlog’а. А потом тимлид говорит что-то вроде:
«Всем привет. Вот как мы предлагаем сформировать команды на следующий спринт».
«Как видно, мы собираемся уменьшить количество команд с четырёх до трёх. Составы команд указаны. Пожалуйста, сгруппируйтесь согласно спискам и выберите себе подходящую стену для планирования».
(тимлид ждёт пока народ побродит по комнате, и через некоторое время появляются три группы людей, каждая соберётся возле своей части стены).
«Текущее распределение — только прикидка! Просто чтобы было с чего начать. По мере планирования спринта любой из вас волен переходить в любую другую команду, можно разделять команды, можно, наоборот, объединять их… В общем, делайте всё, что подскажет здравый смысл, учитывая приоритеты, которые озвучивает product owner.»
Описанный выше подход оказался для нас наиболее эффективным. Немного директивного управления, которое оптимизируется разумной долей самоуправления.
Нужны ли узкоспециализированные команды?
Предположим, ваша система состоит из трёх основных компонентов:
Клиент
Сервер
БД
Допустим, что над вашим продуктом работают 15 человек, и вам не очень хочется собирать их в одну Scrum-команду. Как же разделить людей на команды?
Подход № 1: команды, специализирующиеся на компонентах
Можно создать команды, специализирующиеся на конкретных компонентах. Тогда мы получим «команду для клиентской части», «команду для серверной части» и «команду для базы данных».
Именно с этого подхода мы когда-то начинали. Работает не очень хорошо, по крайней в том случае, когда большинство историй затрагивают сразу несколько компонентов.
К примеру, возьмём, историю, которая называется «доска объявлений, где пользователи могут оставлять друг другу сообщения». Для создания такой доски объявлений нам придётся обновить пользовательский интерфейс в клиентской части, добавить бизнес-логику на стороне сервера, и добавить парочку таблиц в базу данных.
Это значит, что всем трём командам придётся довольно плотно сотрудничать, чтобы закончить эту историю. Не очень удобно.
Подход № 2: универсальные команды
А можно создать универсальные команды, то есть команды, которые не заточены на работу всего лишь с одним специфическим компонентом.
