Все статьи
Быстрый старт в 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-мастеров, которые помогают им справляться с неопределенностью и сложностями во время обучения при переходе к новым рабочим подходам.
Уточнение бэклога
В бэклоге команды хранятся пользовательские истории и энейблеры, созданные для реализации фич в бэклоге ART или содержат локальные задачи команды.
Уточнение бэклога – это командное мероприятие, которое происходит один или несколько раз за итерацию, в ходе которого команда уточняет детали истории.
Узнайте больше о цели встречи и о том, кто участвует во встрече по уточнению бэклога.
Доработка и уточнение бэклога позволяет командам доводить истории и энейблеры до состояния готовности к взятию в работу, снижая риски и выявляя зависимости. Выполняя уточнение бэклога, команды обеспечивают потоковый подход в работе с бэклогом. Это помогает команде выстроить согласованность уже разработанного с предстоящими историями, энейблерами или фичами, в зависимости от обстоятельств.
В мероприятии по уточнению бэклога участвуют владелец продукта, Scrum-мастер и участники команды. Команда может приглашать экспертов или представителей бизнеса по мере необходимости для внесения ясности в элементы бэклога и уточнения бизнес-требований.
Владелец продукта фасилитирует мероприятие по уточнению бэклога, а Scrum-мастер может помочь фасилитацией процедуры оценки историй.
Как проходит встреча по уточнению бэклога
- Регулярно, а не много. Проводите уточнения бэклога чаще и готовьте истории только на одну итерацию, если приоритеты в вашей организации быстро меняются.
- Всегда актуализируйте бэклог. Используйте уточнение бэклога, чтобы понять и оценить предстоящие истории, даже если у вашей команды есть элементы бэклога, готовые для следующей итерации.
- Время — деньги. Старайтесь не тратить слишком много времени на каждую историю, ограничивая разговор тем, что нужно сделать, а не тем, как это сделать.
Мероприятие по уточнению бэклога включает в себя следующие шаги:
- Владелец продукта предоставляет набор приоритетных историй в качестве кандидатов для следующей итерации и проводит краткое обсуждение каждой истории с командой.
- Команда обсуждает критерии приемки, определяет зависимости и оценивает истории до конца встречи.
- Если история слишком большая, команда разбивает ее на части и повторяет процесс.
Оценка историй
Для оценки элементов в бэклоге Agile-команды используют стори поинты (story points).
Истории — это короткие описания небольшого компонента желаемой функциональности на понятном пользователю языке.
Стори Поинт — это целое относительное число, используемое для оценки пользовательских историй с точки зрения объема, сложности, знаний и неопределенности.
«Оценка в стори поинтах» или «оценка истории» означает присвоение числового значения, которое представляет собой совокупный показатель:
- Объем – сколько работы предстоит сделать?
- Сложность – насколько это сложно?
- Знания – что известно?
- Риски – что неизвестно?
Чем больше работы или чем сложнее работа, тем выше оценка истории. Аналогично, неопределенность и риски обычно увеличивают размер. Оценка истории направлена на определение объема работы, границ и рисков, связанных с реализацией элемента бэклога, чтобы команда могла более предсказуемо планировать поставку ценности.
Команды используют модифицированную последовательность Фибоначчи для оценки размера историй. Модифицированная последовательность Фибоначчи – это определенный набор чисел (1, 2, 3, 5, 8, 13, 20, 40, 100), который позволяет оценивать истории относительно друг друга. Вот как это выглядит:
- 1 – размер самой маленькой истории и истории, относительно которой оцениваются все остальные элементы бэклога;
- 2 – в два раза больше, чем история в 1 стори поинт;
- 5 – в пять раз больше, чем история в 1 стори поинт;
- 8 – в восемь раз больше, чем история в 1 стори поинт.
И так по всей дальнейшей последовательности.
Модифицированная последовательность Фибоначчи применяется потому, что она отражает неопределенность в оценке, особенно при присвоении больших чисел (например, 20, 40, 100). Это означает, что по мере роста значений точность естественным образом снижается
Как проводится оценка в стори поинтах
Эта процедура известна под названием «покер планирования»:
- Владелец продукта зачитывает описание истории.
- Участники команды разработки обсуждают необходимые моменты, чтобы перейти к оценке.
- Каждый участник команды разработки для себя определяет то значение в стори поинтах, которое он готов присвоить истории.
- Когда все будут готовы, по команде Scrum-мастера или владельца продукта все в команде одновременно показывают число стори поинтов, которое, по их мнению, требуется для реализации истории.
- Во многих командах участники показывают нужное число пальцами.
- Значения показываются одновременно, чтобы оценка была максимально независимой.
- Команда обсуждает оценки.
- Участники, поставившие самую высокую и самую низкую оценки, объясняют причину.
- После обсуждения каждый участник пересматривает свою оценку при необходимости.
- Если мнения сильно расходятся и вскрылись важные аспекты, появились новый аргументы, команда проводит еще один раунд голосования.
- И так до тех пор, пока оценки не станут одинаковыми или близкими по значению.
Несмотря на множество связанных с процедурой шагов, оценка и переоценка историй не должна занимать больше нескольких минут.
- Декомпозируйте любую историю, которую команда оценивает в 8 или более стори поинтов, потому что она, вероятно, слишком большая или содержит слишком много неизвестных и рисков, чтобы закончить ее за одну итерацию.
- Если члены команды не могут выбрать между двумя оценками, близкими по значению, зафиксируйте договоренность в команде — всегда выбирать наибольшую. Это сэкономит массу времени и нервов всей команде.
Пример оценки в стори поинтах
Чтобы помочь вам лучше понять стори поинты, прочитайте следующую простую пользовательскую историю, чтобы ознакомится с примером различных компонентов, которые нужно учитывать для определения размера истории.
При оценке учитывайте следующие факторы:
- Объем: дистанция забега. Подготовка к марафону требует больше времени, чем к забегу на 5 км.
- Сложность: насколько вы подготовлены? Если вы не бегали годами, потребуется больше усилий, чтобы привести свое тело в форму для забега на такую большую дистанцию. Если вы бегаете три раза в неделю, подготовка к забегу может оказаться не такой сложной.
- Знания: какую самую длинную дистанцию вы уже пробегали когда-то? Марафон — это 42,2 км, поэтому вам нужно будет спланировать свои тренировки таким образом, чтобы преодолеть эту дистанцию.
- Неопределенность: какая будет погода и где находится трасса? Трасса может иметь перепад высоты в 1500 м или проходить на уровне моря. Погода может внести дополнительную неопределенность. Что если будет холодно и дождливо?
Рассмотрим пример. Два бегуна готовятся к марафону, им потребуется пробежать 42,2 км. Трасса ровная, а мероприятие состоится весной, когда погодные условия могут быть непредсказуемыми, но, как правило, более мягкими, чем осенью.
- Андрей оценивает историю на 8 стори поинтов: он мало тренируется и не бегал уже много лет, что усложняет его тренировки.
- Оксана оценивает эту историю на 3 стори поинта: она бегает три раза в неделю. Она в отличной форме и регулярно занимается спортом.
Как видите, задача перед бегунами стоит одна и та же, но оценки сильно расходятся. И этому есть логичное объяснение — один участник будущего забега плохо подготовлен и мало тренируется, второй — занимается регулярно, и, вероятно, потребуется лишь сохранить ритм тренировок и, возможно, небольшая корректировка плана подготовки.
Как нельзя выбрать единую оценку для двух разных бегунов, так и команды никогда нецелесообразно сравнивать друг с другом на основе тех значений в стори поинтах, которые они используют для оценки.
Планирование итерации
Планирование итерации — это мероприятие, на котором участники команды планируют работу на предстоящую итерацию. В зависимости от продолжительности итерации это может занять от одного до четырех часов и происходит регулярно, непосредственно перед началом следующей итерации.
Узнайте больше о цели встречи и о том, кто участвует в планировании итераций.
Цель состоит в том, чтобы спланировать работу для следующей итерации и сфокусировать команду на целях итерации. Выстройте работу бизнес- и технических целей, которые команда ставит перед собой и к достижению которых стремится.
Владелец продукта, Scrum-мастер и команда разработки регулярно проводят планирование итераций и являются обязательными участниками встречи. Также могут участвовать заинтересованные лица и эксперты в данной области (решение о том, кого пригласить на планирование, принимает команда разработки).
Scrum-мастер может фасилитировать встречу по планированию итераций.
Цели итерации
Цели Итерации — это высокоуровневое описание бизнес- и технических целей, которые Agile-команда готова достичь в течение Итерации.
Цели итерации обеспечивают следующие преимущества:
- Выравнивание понимания команды общего направления развития.
- Согласованность планов команд с общими PI-целями и управление зависимостями.
- Обеспечивают прозрачность и информацию для менеджмента.
Цели итерации обеспечивают Agile-командам, заинтересованным лицам Agile Release Train (ART) и руководству общий контекст и фокус для поддержания согласованности, управления зависимостями и внесения необходимых корректировок в ходе итерации и выполнения PI.
Постановка целей итерации применима ко всем Agile-командам, независимо от того, используют ли они SAFe Scrum, SAFe Team Kanban или гибрид того и другого.
Как проходит планирование итерации
Scrum-мастер завершает предыдущую итерацию в конце временного интервала и до начала планирования следующей итерации. Когда предыдущая итерация завершена, команде доступен новый временной интервал итерации для планирования.
Последовательность шагов:
- Определите емкость (capacity) команды. Команда определяет значение своей метрики «емкость», учитывая отпуска, календарные праздники и т.п.
- Проанализируйте и оцените истории. Команда и владелец продукта выбирают наиболее ценные истории, доуточняют и переоценивают их при необходимости. Некоторые команды разбивают истории на задачи и планируют их на следующую итерацию.
- Остановите планирование при достижении вашей командной емкости. Команды прекращают процедуру планирования итерации, когда сумма оценок выбранных историй достигает значения емкости команды.
- Сформулируйте цели итерации. Владелец продукта может предоставить набор целей итерации в качестве входных данных, или владелец продукта и команда определяют цели итерации совместно.
- Зафиксируйте цели итерации. Вся команда подтверждает согласие с выбранными целями итерации в конце планирования. Если команда, или хотя бы один участник, не готовы взять на себя обязательства по достижению целей итерации, то необходимо пересмотреть и переформулировать цели итерации.
- Команды, которые знают значение своей емкости и в чьих бэклогах содержатся проработанные и оцененные истории, могут довольно быстро завершить планирование итерации.
- При планировании оставляйте небольшой буферный объем вашей емкости. Такой подход помогает командам оперативно реагировать на непредвиденные обстоятельства и меняющиеся приоритеты. Рекомендацию, какой процент емкости заложить как буфер, может предоставить руководство ART.
- План не обязательно должен быть точным. Вместо этого сосредоточьтесь на согласованности и разработке приблизительного плана.
- Важно обращать внимание не только на количество запланированных стори поинтов, но и на нагрузку отдельных сотрудников, чтобы вы могли определить ситуации, когда отдельные участники команды оказываются перегружены.
Ежедневный стендап
Ежедневный стендап (Daily Stand-Up, DSU) – это встреча, ограниченная 15 минутами, которая проводится каждый день итерации в одно и то же время и в одном и том же месте. При этом часто команды не проводят DSU в те дни, когда они планируют итерацию или проводят ретроспективу и другие стандартные мероприятия (например, обзор или демонстрацию).
Несмотря на то, что в настоящее время многие команды работают удаленно, идея «участия стоя» помогает сфокусироваться на главном и укладываться в короткий временной интервал. Когда возникают сложные вопросы (а они часто возникают), их следует отложить до обсуждения после встречи.
DSU служит для корректировки при необходимости плана работы команды на следующие 24 часа и выявления проблем с заблокированными задачами и зависимостями.
В DSU участвуют Scrum-мастер, владелец продукта и команда разработки. Другие могут присутствовать по усмотрению команды, но обычно не участвуют.
Как правило, Scrum-мастер фасилитирует мероприятие.
Как проходит ежедневный стендап
Команда собирается для блиц-обсуждения, чтобы определить:
- Что было завершено вчера и что будет выполнено сегодня для достижения целей итерации.
- Трудности и препятствия, которые необходимо устранить.
Детальные обсуждения проблем по задачам выносятся за рамки DSU, но крайне желательно дискуссию ограничивать специально отведенным под это временем.
- Вопросы типа: «Что осталось доделать, чтобы завершить эту историю?» – могут заставить участников команды, впервые знакомящихся с Agile, почувствовать себя некомфортно, под пристальным надзором.
- В зависимости от часовых поясов DSU может происходить тогда, когда удобно команде. Помните, что это не единственная точка синхронизации с участниками вашей команды.
- Удаленная работа часто приводит к тому, что команды мало двигаются. Если вы Scrum-мастер, вы можете предложить команде проводить DSU стоя.
- DSU – это не статусное совещание. Вместо этого его цель состоит в том, чтобы не терять фокус в достижении целей итерации.
- Следите за своим расписанием и не тратьте слишком много времени на обсуждение статуса по задачам. Встречайтесь после DSU, чтобы глубже погрузиться в конкретные вопросы.
Обзор итерации
Обзор итерации – это регулярное мероприятие, на котором команда показывает истории, которые они завершили, и анализирует результаты итерации. Эта встреча проходит в конце каждой итерации перед ретроспективой.
Узнайте больше о цели встречи и о том, кто участвует в обзоре.
Обзор итерации создает возможность получить обратную связь от заинтересованных лиц о поставленном инкременте ценности.
Обзор итераций посещают Владелец продукта, Scrum-мастер, команда разработки и любые заинтересованные лица или другие команды, которые хотят видеть прогресс команды.
Scrum-мастер может фасилитировать мероприятие.
Как проходит обзор итерации
Обзор итерации – это командное мероприятие, которое обеспечивает следования ценностям SAFe: согласованность и прозрачность. Подготовка к обзору дает командам возможность понять, как работа, выполненная ими в ходе итерации, способствует достижению более высокоуровневых бизнес-целей и какие проблемы были решены.
Команды, работающие совместно, могут посещать обзоры итераций друг друга, чтобы узнать о прогрессе команды и предоставить обратную связь.
- Команда анализирует цели итерации и обсуждает их статус.
- Затем команда демонстрирует итоги работы по каждой истории, взятой в итерацию, и собирает отзывы участников.
- Наконец, идёт обсуждение незаконченных историй.
- Скрам-мастера могут фасилитировать обзор итерации. Они делятся такими данными, как общее количество стори поинтов, выполненных («сожженных») за итерацию, известное как velocity (скорость). Отсюда название популярного графика Burn-Down Chart (диаграмма «сгорания» стори поинтов).
- Провести обзор результатов может оказаться непосильным для нового члена команды. Не спешите, просмотрите несколько обзоров и обратитесь за поддержкой к своему Scrum-мастеру.
- Если команде нечего продемонстрировать, Scrum-мастер предложит команде провести разбор ситуации. Не слишком ли большие истории берет команда? Представляют ли они ценность сами по себе? И так далее.
Ретроспектива итерации
Ретроспектива итерации – это регулярная командная встреча продолжительностью 1 час или меньше. В конце каждой итерации Agile-команда делает остановку, чтобы поразмыслить над результатами работы за прошедший период.
Узнайте больше о цели встречи и о том, кто участвует в ретроспективе.
Ретроспектива направлена на поиск областей улучшений в работе команды и заключения договоренностей по реализации этих идей в предстоящей итерации.
Ретроспективы – это командное мероприятие на этапе «Корректируй» цикла PDCA. Эти встречи обеспечивают реализацию принципа постоянного совершенствования SAFe.
Ретроспективы, проводящиеся регулярно в определенное время, дают возможность остановиться, оглянуться назад и сосредоточиться на том, как команды могут улучшить свои процессы.
Владелец продукта, Scrum-мастер и члены команды посещают ретроспективу итерации. Это частное командное мероприятие, и его участниками могут быть только члены Agile-команды.
Scrum-мастер может фасилитировать ретроспективу.
Как проходит ретроспектива итерации
Вот пример повестки для ретроспективы итерации:
- Представление целей ретроспективы, данных и формата встречи.
- Сбор идей по улучшения в ходе мозгового штурма.
- Выбор лучших идей голосование и закрытие ретроспективы.
Существует множество форматов для достижения одного и того же результата. Фасилитаторы могут использовать разные в зависимости от обстоятельств, чтобы поддерживать интерес к ретроспективам и обеспечивать достижение командой различных целей.
Ниже приведен простой пример сбора идей:
- Помните, что ретроспектива итерации является ключом к постоянному совершенствованию команд, поэтому избегайте соблазна пропустить ее.
- Если на ретроспективе каждый раз фиксируются одни и те же идеи для улучшения, это может означать, что они слишком велики, чтобы команда могла реализовать их самостоятельно или находятся вне зоны влияния команды. Разбейте такие улучшения на ряд более мелких шагов или эскалируйте проблему.
Тест — проверьте, насколько хорошо вы усвоили материал
