Все о SCRUM. Изучение, разработка, интеграция

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

21.3.2 Сезоны с фиксированной датой начала и завершения

Точно как и спринты, сезоны команд синхронизированы: одна дата начала, одна дата завершения. Все следуют одному ритму.

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

Рисунок 21.5 – Корректировка в космической программе

Все команды следуют сезонному ритму.

В конце сезона два момента, на которые стоит обратить внимание.

✓ Для ретроспективы и планирования нужен высокий уровень синхронизации между командами.

✓ Состав команд может меняться.

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

21.3.3 Прелюдия

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

21.4 Бэклог и доработка несколькими командами

Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главами 6 «Структура бэклога», 7 «Доработка бэклога» и 8 «Определение критериев завершенности».

Философия заключается в сохранении концепции единого бэклога для нескольких команд.

21.4.1 Общий бэклог поставки

Паттерн рабочего бэклога/бэклога поставки предполагает использование kanban-таблицы функциональностей, что интересно и в масштабе одной команды. Если же в процессе задействовано несколько команд, такая таблица становится обязательным инструментом. Упорядоченность элементов в таблице имеет фундаментальное значение для общего понимания приоритетов.

Также при помощи такой таблицы можно разделить работу между командами. Функциональность, как правило, – это ответственность одной команды, на что указывает какой-либо атрибут (например, цвет), добавленный к каждому элементу.

Рисунок 21.6 – Таблица функциональностей для трех команд

Итак, у команд есть бэклог поставки (представленный в виде таблицы функциональностей). Он один для продукта, даже если продукт большой.

21.4.2 Адаптированный рабочий бэклог

Должны ли команды, работающие над одним и тем же продуктом, иметь общий бэклог со всеми историями? Или у каждого есть своя часть в общем бэклоге? Это решать командам!

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

Командам важно знать, что они будут делать во время спринта. Поэтому у каждой из них должен быть свой собственный план спринта.

21.4.3 Доработка в больших масштабах

Традиционная доработка (помимо того, что выполняется каждой командой) проводится еще и на более высоком уровне – уровне функциональностей. Во время сессии доработки решается, какие новые функциональности команды возьмут в работу.

Рисунок 21.7 – Доработка в больших масштабах практикуется в Авероне[63]

Это собрание предшествует сессии доработки на уровне каждой команды.

В нем участвует группа Владельцев продукта, эксперты и представители команд (в случае, если у команды нет своего собственного Владельца продукта).

Действия во время крупномасштабной доработки следующие:

✓ разбить большие функциональности на части,

✓ обсудить, какие пойдут в работу, выявить зависимости и риски, определить готовность,

✓ упорядочить функциональности,

✓ определить, какая команда отвечает за реализацию функциональности; другие, соответственно, участвуют в роении.

21.4.5 Критерии готовности и завершенности в больших масштабах

Критерии готовности и завершенности одни для всех команд – так обеспечивается единый уровень качества. Роль критериев не меняется с увеличением количества команд.

Критерии разрабатываются коллективно во время прелюдии. Особое внимание следует уделить критериям завершенности для функциональности.

21.5 События спринта в больших масштабах