Настоящий 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) обращает внимание на все это и принимает решение:

1. Оставить дальнейшую работу, пока Discovery Team не решит возникшие вопросы. В таком случае назначаем новый продуктовый челлендж.

2. Продолжить процесс PBR, если неразрешенные вопросы не критичны. В таком случае DevTeam может:

• Накинуться на обсуждение фичи всей командой — не лучший способ с точки зрения эффективности взаимодействия.

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

• Выбрать несколько рабочих групп (фича-команд), чтобы каждая команда взяла в работу несколько декомпозированных user story одной большой фичи. После завершения работы фиче-команды презентуют друг другу выбранные решения. 

По моему мнению, последний вариант — идеальный для команды из 8 и более человек. Мы разбивались так, что в каждой фича-команде было по одному представителю от платформы. Это помогло вовлечь всех участников и ускорить проработку фич.

В зависимости от выбранного формата работы и сложности обсуждаемой фичи DevTeam может:

• Начать техническую проработку в рамках текущей встречи (не более 50 минут).

• Договориться о последующей работе. Например, новая встреча, асинхронный режим работы через мессенджеры — команда сама выбирает любой подходящий ей формат.

Визуально описанный процесс продуктовый челлендж выглядит так:

Этап 2. Технический челлендж

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

Чек-лист вопросов, которые помогут команде с разбором задачи на PBR:

1. Сколько модулей затрагивает задача.

2. Сколько внешних взаимодействий и зависимостей: сформирован контракт с backend, работа с другими командам, верхнеуровнево проработана архитектура.

3. Сколько внутренних взаимодействий: работа в пределах архитектуры платформы.

4. Техническая декомпозиция.

5. Оценка SP (Story Points): учли ли тестирование? Заложили время на переводы?

6. Риски: что может пойти не так, какой наихудший расклад событий?

7. AC (Acceptance Criteria).

8. Контроль DOR (Definition of Ready).

Также можно пользоваться чек-листом DoR для всех продуктовых команд:

1. Есть описание, постановка по задаче.

2. Есть AC.

3. Есть оценка в SP.

4. Есть макеты UI.

5. Есть аналитические метрики.

6. Есть ключи локализации, если нужны.

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

Если фича-команда не может «отпибиарить» фичу менее чем за полтора часа — значит, фичу плохо декомпозировали. Это стоит обсудить на ретроспективе.​​

Этап 3: Финальный челлендж

Это общее мероприятие продолжительностью не более 30 минут, на котором фича-команды презентуют друг другу (если разделялись), продакту, техлиду и дизайнеру техническое решение фичи. 

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

В процессе обсуждения команда проверяет каждую фичу по DoR и паркует возникшие в рамках встречи вопросы на отдельную доску. В конце принимаем решение: фича готова к спринту (переводится в Ready for development) или необходимы дополнительные уточнения/обсуждения. Также мы выбираем одного ответственного, который все переносит всю информацию с Miro в Jira.

Что говорят участники процесса

Я поговорила с участниками нашего PBR-эксперимента. Вот какую обратную связь дали члены моей команды:

Backend-разработчик

Раньше разбор того, что хочет бизнес, был без обсуждения моментов. А это влекло изменение задач на лету. Когда мы начинали обсуждать на PBR задачу, из-за того что команда была большая, это скатывалось в не очень эффективную историю по времени и понижало качество внутренней коммуникации. Сейчас, когда делимся на встрече на относительно небольшие команды, все работает достаточно хорошо, но всегда есть моменты, которые хочется улучшить.

QA-инженер

Плюсы:

• Вникаем суть задач до разработки.

• Тестирование документации стала ответственностью команды, а не тестировщиков.

• Появилось понимание в приоритезации задач.

• Каждый может высказать свое «фе».

Минусы:

• Занимает время.

• Заставляют думать.

Android-разработчик

До прихода agile coach мы понятия не имели, что такое Story Points и что задачи надо оценивать! Отсюда у нас были спринты по 1-2 месяцу без итогов. Не было обсуждений, а было что-то вроде «тут есть задачки, давайте посмотрим». Ценой нервных клеток фасилитатора появилась структура встречи. Мы понимаем, что все можем оценить, а после запланировать спринт.

Product Owner

• Была непрогнозируемая разработка, не было понимания по срокам разработки многих задач — исправили за редким исключением.

• Непопадание по срокам разработки — исправили, думаю, на 80% попадаем.

• В обсуждении участвовали только несколько человек — исправили.

• Не было единого понимания по оценке задач — плюс-минус, нужно калибровать постоянно.

• Не было подготовки к PBR и вовлечения в обсуждение. Команда не брала ответственность за задачу — сейчас все вовлечены, но иногда выполняют более формально.

• Качество проработки задач — стало лучше.

Огромная благодарность в написании статьи выражаю Александру Саликову, без тебя я бы не смогла так визуализировать и описать свои мысли.