Настоящий Product Backlog Refinement: 4 этапа правильной работы над фичами
Привет, Хабр! Я Екатерина Колесникова, agile coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement (PBR). Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании.
Уверена, многие проблемы, с которыми я столкнулась, знакомы и вам:
Давящее авторитетное мнение. На PBR говорил один человек: техлид, senior, product owner или другой лидер. Остальные члены команды оставались в тихом согласии, не высказывали мнение, плохо вовлекались и не понимали задачу.
«Потом разберемся». Задачи уточнялись уже после запуска спринта.
Задачи в Jira без описания. Не было фиксации и разбора.
Нет оценки. Планирование спринта шло хаотично, а результаты было сложно прогнозировать.
Нет продуктовой и технической декомпозиции. Делали то, не зная что.
Мой сценарий подходит для продуктовой команды от 8 человек. Сам процесс PBR я разделила на 4 этапа:
Этап 0. Делаем все заранее
Минимум за 3 дня, а лучше за неделю до PBR product owner скидывает информацию о фичах, которые хотим взять в работу. Команда разработки знакомится с информацией, заранее готовит вопросы и предлагает варианты решений. Это значительно сокращает время встречи.
На этом этапе появляется понимание, какие задачи простые, а какие точно займут много времени для проработки. Это помогает лучше спланировать тайминг будущего PBR. Чтобы уменьшить время, простым задачам можно асинхронно поставить оценку и сравнить ее на встрече. Если команда не новая, коллеги сходятся в едином мнении, и обсуждение таких задачек занимает максимум 10 минут.
Артефакты и документация по фиче включают в себя:
Проблему пользователя, которую мы решаем.
Гипотезу для решения этой проблемы.
Результаты исследований или эксперимента, подтверждающие эту гипотезу.
Целевую аудиторию фичи.
Продуктовые метрики, на которые мы хотим повлиять.
Макеты.
USM (User Story Map), СJM (Customer Journey Map).
Ключи для переводов (при необходимости).
События для аналитики, которые необходимо добавить.
Продуктовую декомпозицию и описание задачи.
Хорошая практика — иметь в бэклоге продукта детально проработанные элементы как минимум на 2 спринта вперед. Так планирование спринта упрощается, поскольку product owner и скрам-команда начинают планирование с понятным, прошедшим этап анализа и аккуратно оцененным набором пользовательских историй.
Если же задача попадает в спринт без проведения PBR, планирование спринта растягивается во времени, вызывает много вопросов, требует уточнений и/или выявляет несоответствия.
Этап 1. Продуктовый челлендж
Discovery Team, в нашем случае это product owner, аналитик, дизайнер, техлид и представители бизнеса, еще раз лично рассказывают и знакомят нас с историями, которые хотим взять в работу.
Продуктовый челлендж занимает не более 30 минут. Обсуждаем фичи с точки зрения продукта («что делаем?», «зачем делаем?»).
Ребята озвучивают заранее подготовленные вопросы. Во время обсуждения выписываем новые проблемы, риски и барьеры к реализации фичи, которые невозможно решить оперативно. Когда продуктовый челлендж заканчивается, Development Team (DevTeam) обращает внимание на все это и принимает решение:
Оставить дальнейшую работу, пока Discovery Team не решит возникшие вопросы. В таком случае назначаем новый продуктовый челлендж.
Продолжить процесс PBR, если неразрешенные вопросы не критичны. В таком случае DevTeam может:
Накинуться на обсуждение фичи всей командой — не лучший способ с точки зрения эффективности взаимодействия.
Выбрать рабочую группу — кросс-функциональную команду, компетенции которой позволяют полностью проработать техническую реализацию фичи.
Выбрать несколько рабочих групп (фича-команд), чтобы каждая команда взяла в работу несколько декомпозированных user story одной большой фичи. После завершения работы фиче-команды презентуют друг другу выбранные решения.
По моему мнению, последний вариант — идеальный для команды из 8 и более человек. Мы разбивались так, что в каждой фича-команде было по одному представителю от платформы. Это помогло вовлечь всех участников и ускорить проработку фич.
В зависимости от выбранного формата работы и сложности обсуждаемой фичи DevTeam может:
Начать техническую проработку в рамках текущей встречи (не более 50 минут).
Договориться о последующей работе. Например, новая встреча, асинхронный режим работы через мессенджеры — команда сама выбирает любой подходящий ей формат.
Визуально описанный процесс продуктовый челлендж выглядит так:
Этап 2. Технический челлендж
DevTeam прорабатывает декомпозированные фичи в одном из форматов: всей командой, рабочей группой или несколькими фича-командами. Важное условие: в любом формате техническая команда кросс-функциональна, автономна и наделена полномочиями самостоятельно принимать решения. Продакт, техлид, продуктовый дизайнер и скрам-мастер могут участвовать в техническом челлендже как внешние эксперты по запросу команды.
Чек-лист вопросов, которые помогут команде с разбором задачи на PBR:
Сколько модулей затрагивает задача.
Сколько внешних взаимодействий и зависимостей: сформирован контракт с backend, работа с другими командам, верхнеуровнево проработана архитектура.
Сколько внутренних взаимодействий: работа в пределах архитектуры платформы.
Техническая декомпозиция.
Оценка SP (Story Points): учли ли тестирование? Заложили время на переводы?
Риски: что может пойти не так, какой наихудший расклад событий?
AC (Acceptance Criteria).
Контроль DOR (Definition of Ready).
Также можно пользоваться чек-листом DoR для всех продуктовых команд:
Есть описание, постановка по задаче.
Есть AC.
Есть оценка в SP.
Есть макеты UI.
Есть аналитические метрики.
Есть ключи локализации, если нужны.
Технический челлендж длится 50 минут, если команда продолжает продуктовый челлендж, или час-полтора, если это отдельная встреча. Продолжительность также зависит от сложности фичи.
Если фича-команда не может «отпибиарить» фичу менее чем за полтора часа — значит, фичу плохо декомпозировали. Это стоит обсудить на ретроспективе.
Этап 3: Финальный челлендж
Это общее мероприятие продолжительностью не более 30 минут, на котором фича-команды презентуют друг другу (если разделялись), продакту, техлиду и дизайнеру техническое решение фичи.
Цель данного этапа — получить апрув от вышеперечисленных участников по дальнейшей реализации фичи в рамках следующих спринтов, а также засинхониться, если над фичами работали несколько команд.
В процессе обсуждения команда проверяет каждую фичу по DoR и паркует возникшие в рамках встречи вопросы на отдельную доску. В конце принимаем решение: фича готова к спринту (переводится в Ready for development) или необходимы дополнительные уточнения/обсуждения. Также мы выбираем одного ответственного, который все переносит всю информацию с Miro в Jira.
Что говорят участники процесса
Я поговорила с участниками нашего PBR-эксперимента. Вот какую обратную связь дали члены моей команды:
Backend-разработчик
Раньше разбор того, что хочет бизнес, был без обсуждения моментов. А это влекло изменение задач на лету. Когда мы начинали обсуждать на PBR задачу, из-за того что команда была большая, это скатывалось в не очень эффективную историю по времени и понижало качество внутренней коммуникации. Сейчас, когда делимся на встрече на относительно небольшие команды, все работает достаточно хорошо, но всегда есть моменты, которые хочется улучшить.
QA-инженер
Плюсы:
Вникаем суть задач до разработки.
Тестирование документации стала ответственностью команды, а не тестировщиков.
Появилось понимание в приоритезации задач.
Каждый может высказать свое «фе».
Минусы:
Android-разработчик
До прихода agile coach мы понятия не имели, что такое Story Points и что задачи надо оценивать! Отсюда у нас были спринты по 1–2 месяцу без итогов. Не было обсуждений, а было что-то вроде «тут есть задачки, давайте посмотрим». Ценой нервных клеток фасилитатора появилась структура встречи. Мы понимаем, что все можем оценить, а после запланировать спринт.
Product Owner
Была непрогнозируемая разработка, не было понимания по срокам разработки многих задач — исправили за редким исключением.
Непопадание по срокам разработки — исправили, думаю, на 80% попадаем.
В обсуждении участвовали только несколько человек — исправили.
Не было единого понимания по оценке задач — плюс-минус, нужно калибровать постоянно.
Не было подготовки к PBR и вовлечения в обсуждение. Команда не брала ответственность за задачу — сейчас все вовлечены, но иногда выполняют более формально.
Качество проработки задач — стало лучше.
