Все статьи

Людмила Баварова

Agile-коуч. Практик Scrum, Kanban и SAFe®.

Быстрый старт в SAFe® #4 – Командные события

Дата: 25.01.2024

Четвертая статья серии «Быстрый старт в SAFe®». В этом обзоре Scaled Agile Framework® (SAFe®) знакомимся с событиями Agile-команды, которые проводятся каждую итерацию. И разбираемся, как в них интегрирован производственный цикл «Планируй-Делай-Проверяй-Корректируй».

Командные мероприятия в SAFe®

Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.

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

Изучив материалы вы сможете:

  • Запускать проведение командных мероприятий.
  • Понимать предназначение каждого командного мероприятия.
  • Чётко формулировать преимущества совместной работы в Agile-командах.

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

Итерации – это временные рамки фиксированной продолжительности, в течение которых Agile-команды обеспечивают поставку ценности, как спринты в Scrum. В SAFe итерации обычно длятся одну или две недели, причем чаще всего две.

В Agile-подходах команды следуют эмпирическому циклу «Планируй-Делай-Проверяй-Корректируй» (Plan-Do-Check-Act, PDCA), чтобы поставлять ценность небольшими шагами. Специальные мероприятия помогают команде достичь состояния потока, при котором команда обеспечивает ценность непрерывно.

  • Планируй – Планирование итерации.
  • Делай –  Работа в итерации.
  • Проверяй – Обзор итерации.
  • Корректируй – Ретроспектива итерации.

Тех, кто не имеет опыта работы в Agile-среде, может удивить, сколько времени команда тратит на планирование и совместную работу!

Каждое командное мероприятие имеет свою цель и ритмичность повторений. В целом командные мероприятия направлены на обеспечение работы цикла «Планируй-Делай-Проверяй-Корректируй». Команды создают ценность, используя итеративно-инкрементальную подход с быстрыми циклами обучения, как описано в принципе SAFe №4: инкрементальные поставки с быстрыми встроенными циклами обучения.

Вот пример календаря мероприятий Agile-команды:

Могут быть различия в том, как работают команды, например, какие мероприятия и практики они применяют. Вместо того, чтобы предписывать методы и практики, SAFe рекомендует командам внедрять те из них, которые помогут работать эффективно и обеспечивать поставку ценности.

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

Уточнение бэклога

Решение о его продолжительности принимает команда. Обычно это мероприятие длится 1-2 часа и помогает команде подготовиться к итерации и планированию PI. 

В бэклоге команды хранятся пользовательские истории и энейблеры, созданные для реализации фич в бэклоге ART или содержат локальные задачи команды.

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

Узнайте больше о цели встречи и о том, кто участвует во встрече по уточнению бэклога.

Как проходит встреча по уточнению бэклога

Мероприятие по уточнению бэклога включает в себя следующие шаги:

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

Оценка историй

Для оценки элементов в бэклоге Agile-команды используют стори поинты (story points).

Истории — это короткие описания небольшого компонента желаемой функциональности на понятном пользователю языке.

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

«Оценка в стори поинтах» или «оценка истории» означает присвоение числового значения, которое представляет собой совокупный показатель:

  • Объем – сколько работы предстоит сделать?
  • Сложность – насколько это сложно?
  • Знания – что известно?
  • Риски – что неизвестно?

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

Команды используют модифицированную последовательность Фибоначчи для оценки размера историй. Модифицированная последовательность Фибоначчи – это определенный набор чисел (1, 2, 3, 5, 8, 13, 20, 40, 100), который позволяет оценивать истории относительно друг друга. Вот как это выглядит:

  • 1 – размер самой маленькой истории и истории, относительно которой оцениваются все остальные элементы бэклога;
  • 2 – в два раза больше, чем история в 1 стори поинт;
  • 5 – в пять раз больше, чем история в 1 стори поинт;
  • 8 – в восемь раз больше, чем история в 1 стори поинт.

И так по всей дальнейшей последовательности.

Модифицированная последовательность Фибоначчи применяется потому, что она отражает неопределенность в оценке, особенно при присвоении больших чисел (например, 20, 40, 100). Это означает, что по мере роста значений точность естественным образом снижается

Как проводится оценка в стори поинтах

Эта процедура известна под названием «покер планирования»:

  • Владелец продукта зачитывает описание истории.
  • Участники команды разработки обсуждают необходимые моменты, чтобы перейти к оценке.
  • Каждый участник команды разработки для себя определяет то значение в стори поинтах, которое он готов присвоить истории.
  • Когда все будут готовы, по команде Scrum-мастера или владельца продукта все в команде одновременно показывают число стори поинтов, которое, по их мнению, требуется для реализации истории.
  • Во многих командах участники показывают нужное число пальцами.
  • Значения показываются одновременно, чтобы оценка была максимально независимой.
  • Команда обсуждает оценки.
  • Участники, поставившие самую высокую и самую низкую оценки, объясняют причину.
  • После обсуждения каждый участник пересматривает свою оценку при необходимости.
  • Если мнения сильно расходятся и вскрылись важные аспекты, появились новый аргументы, команда проводит еще один раунд голосования.
  • И так до тех пор, пока оценки не станут одинаковыми или близкими по значению.

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

Пример оценки в стори поинтах

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

При оценке учитывайте следующие факторы:

  • Объем: дистанция забега. Подготовка к марафону требует больше времени, чем к забегу на 5 км.
  • Сложность: насколько вы подготовлены? Если вы не бегали годами, потребуется больше усилий, чтобы привести свое тело в форму для забега на такую большую дистанцию. Если вы бегаете три раза в неделю, подготовка к забегу может оказаться не такой сложной.
  • Знания: какую самую длинную дистанцию вы уже пробегали когда-то? Марафон — это 42,2 км, поэтому вам нужно будет спланировать свои тренировки таким образом, чтобы преодолеть эту дистанцию.
  • Неопределенность: какая будет погода и где находится трасса? Трасса может иметь перепад высоты в 1500 м или проходить на уровне моря. Погода может внести дополнительную неопределенность. Что если будет холодно и дождливо?

Рассмотрим пример. Два бегуна готовятся к марафону, им потребуется пробежать 42,2 км. Трасса ровная, а мероприятие состоится весной, когда погодные условия могут быть непредсказуемыми, но, как правило, более мягкими, чем осенью.

  • Андрей оценивает историю на 8 стори поинтов: он мало тренируется и не бегал уже много лет, что усложняет его тренировки.
  • Оксана оценивает эту историю на 3 стори поинта: она бегает три раза в неделю. Она в отличной форме и регулярно занимается спортом.

Как видите, задача перед бегунами стоит одна и та же, но оценки сильно расходятся. И этому есть логичное объяснение — один участник будущего забега плохо подготовлен и мало тренируется, второй — занимается регулярно, и, вероятно, потребуется лишь сохранить ритм тренировок и, возможно, небольшая корректировка плана подготовки.

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

Планирование итерации

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

Узнайте больше о цели встречи и о том, кто участвует в планировании итераций.

Цели итерации

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

Цели итерации обеспечивают следующие преимущества:

  • Выравнивание понимания команды общего направления развития.
  • Согласованность планов команд с общими PI-целями и управление зависимостями.
  • Обеспечивают прозрачность и информацию для менеджмента.

Цели итерации обеспечивают Agile-командам, заинтересованным лицам Agile Release Train (ART) и руководству общий контекст и фокус для поддержания согласованности, управления зависимостями и внесения необходимых корректировок в ходе итерации и выполнения PI.

Постановка целей итерации применима ко всем Agile-командам, независимо от того, используют ли они SAFe Scrum, SAFe Team Kanban или гибрид того и другого.

Как проходит планирование итерации

Scrum-мастер завершает предыдущую итерацию в конце временного интервала и до начала планирования следующей итерации. Когда предыдущая итерация завершена, команде доступен новый временной интервал итерации для планирования.

Последовательность шагов:

  1. Определите емкость (capacity) команды. Команда определяет значение своей метрики «емкость», учитывая отпуска, календарные праздники и т.п.
  2. Проанализируйте и оцените истории. Команда и владелец продукта выбирают наиболее ценные истории, доуточняют и переоценивают их при необходимости. Некоторые команды разбивают истории на задачи и планируют их на следующую итерацию.
  3. Остановите планирование при достижении вашей командной емкости. Команды прекращают процедуру планирования итерации, когда сумма оценок выбранных историй достигает значения емкости команды.
  4. Сформулируйте цели итерации. Владелец продукта может предоставить набор целей итерации в качестве входных данных, или владелец продукта и команда определяют цели итерации совместно.
  5. Зафиксируйте цели итерации. Вся команда подтверждает согласие с выбранными целями итерации в конце планирования. Если команда, или хотя бы один участник, не готовы взять на себя обязательства по достижению целей итерации, то необходимо пересмотреть и переформулировать цели итерации.

Ежедневный стендап

Ежедневный стендап (Daily Stand-Up, DSU) – это встреча, ограниченная 15 минутами, которая проводится каждый день итерации в одно и то же время и в одном и том же месте. При этом часто команды не проводят DSU в те дни, когда они планируют итерацию или проводят ретроспективу и другие стандартные мероприятия (например, обзор или демонстрацию).

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

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

Как проходит ежедневный стендап

Команда собирается для блиц-обсуждения, чтобы определить:

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

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

Обзор итерации

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

Узнайте больше о цели встречи и о том, кто участвует в обзоре.

Как проходит обзор итерации

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

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

  1. Команда анализирует цели итерации и обсуждает их статус.
  2. Затем команда демонстрирует итоги работы по каждой истории, взятой в итерацию, и собирает отзывы участников.
  3. Наконец, идёт обсуждение незаконченных историй.

Ретроспектива итерации

Ретроспектива итерации – это регулярная командная встреча продолжительностью 1 час или меньше. В конце каждой итерации Agile-команда делает остановку, чтобы поразмыслить над результатами работы за прошедший период.

Узнайте больше о цели встречи и о том, кто участвует в ретроспективе.

Как проходит ретроспектива итерации

Вот пример повестки для ретроспективы итерации:

  1. Представление целей ретроспективы, данных и формата встречи.
  2. Сбор идей по улучшения в ходе мозгового штурма.
  3. Выбор лучших идей голосование и закрытие ретроспективы.

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

Ниже приведен простой пример сбора идей:

Тест — проверьте, насколько хорошо вы усвоили материал

Нажмите кнопку «Начать» для прохождения теста

Имя и фамилия
Email
SAFe® для команд
Тренинг SAFe® for Teams дает навыки работы в Agile-команде, которая в рамках Agile Release Train (ART) совместно с другими Agile-командами и заинтересованными лицами разрабатывает единое решение. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Practitioner (SP).

Поделиться

VK
Telegram