Как проводил Backlog Refinement

Проведение Backlog Refinement в Agile процессе

Backlog Refinement (уточнение продуктового бэклога) — это регулярная встреча, где команда разработки вместе с Product Owner подробно разбирают, уточняют и подготавливают задачи к спринту. Вот как я проводил этот процесс:

1. Частота и организация встреч

Когда:

• Обычно проводится раз в неделю или раз в две недели
• За 1-2 дня до Planning встречи спринта
• Длительность: 1-1.5 часа для типичной команды из 5-6 человек

Кто участвует:

• Product Owner (инициатор обсуждения)
• Tech Lead / Architect (для технических вопросов)
• Разработчики (2-3 представителя)
• QA (опционально, для уточнения критериев приемки)

2. Подготовка к встрече

По примерно за день до refinement:

1. PO подготавливает список приоритизированных задач
2. Задачи должны быть описаны: название, описание, требования
3. Прикрепляются дизайны, макеты, ссылки если есть
4. Определяется примерная сложность (очень грубая оценка)

Пример структуры задачи перед уточнением:

Title: "Добавить авторизацию через OAuth 2.0"
Description:
  "Пользователи должны иметь возможность входить через Google"
  "Это повысит конверсию на 15% по прогнозам"
Acceptance Criteria:
  - [ ] Кнопка "Sign in with Google" на странице входа
  - [ ] Пользователь переходит на Google consent screen
  - [ ] После разрешения создается/обновляется профиль пользователя
  - [ ] JWT токен сохраняется в localStorage
Depends on:
  - API endpoint для OAuth callback (BACKLOG-234)
Estimated Complexity: Medium

3. Процесс refinement встречи

Вот как я обычно структурировал саму встречу:

Этап 1: Обзор (5 минут)

PO кратко объясняет, какие задачи из бэклога мы будем уточнять и почему они приоритизированы.

Этап 2: Детальное обсуждение каждой задачи (основное время)

Для каждой задачи:

1. PO рассказывает:
   - Чего хочет бизнес
   - Почему это важно (контекст)
   - Что будет успехом

2. Разработчики задают вопросы:
   - Какие интеграции нужны?
   - Есть ли edge cases?
   - Нужны ли изменения БД?
   - Какой стек технологий?

3. Уточняем Acceptance Criteria:
   - Критерии должны быть measurable
   - Не быть техническими деталями реализации
   - Быть проверяемыми QA

4. Определяем зависимости:
   - От других задач
   - От внешних сервисов
   - От инфраструктуры

5. Делаем черновую оценку сложности (Story Points):
   - Это еще не финальная оценка на Planning
   - Просто понимаем, сложная ли это задача

4. Практический пример refinement

Рассмотрим реальный пример уточнения одной задачи:

ПО говорит:
"Нам нужна система рекомендаций товаров на главной странице."

Разработчик 1 спрашивает:
"А сколько товаров показывать?"
ПО: "Обычно 10-15 товаров."

Разработчик 2:
"На основе каких данных делать рекомендации? На истории пользователя?
На категории? На популярности?"
ПО: "Основы на истории покупок и просмотров. Если истории нет,
показываем популярные товары."

QA спрашивает:
"Какие критерии приемки? Как мы проверим, что рекомендации работают?"

Вместе формулируют:
✓ Система отправляет GET /api/recommendations с user_id
✓ API возвращает до 15 товаров, отсортированных по релевантности
✓ Для нового пользователя - топ 15 по популярности
✓ Для старого - 70% из истории + 30% из популярного
✓ Загрузка не более 2 секунд
✓ Товары не повторяются

Razrabochik 1:
"Есть ли уже алгоритм рекомендаций или это новый код?"
ПО: "Есть ML модель в Python, вам нужно обернуть в Java API."

Tech Lead:
"Это зависит от завершения ML модели (BACKLOG-456).
Добавим эту зависимость."

Результат уточнения:

Title: "Рекомендации товаров на главной странице"

Description:
  Реализовать REST API endpoint для получения персональных
  рекомендаций товаров. Рекомендации основаны на истории
  пользователя и популярности товаров.

Acceptance Criteria:
  ✓ GET /api/v1/recommendations?limit=15 возвращает товары
  ✓ Для авторизованного пользователя - персональные рекомендации
  ✓ Для анонимного - топ популярных товаров
  ✓ Товары не дублируются в ответе
  ✓ Загрузка endpoint < 2 сек
  ✓ Пагинация поддерживается (offset/limit)
  ✓ Тесты покрывают 90%+ кода

Technical Notes:
  - Используется ML модель из BACKLOG-456
  - Обновить класс RecommendationService
  - Добавить Redis кэш на 1 час
  - Миграция БД для логирования просмотров

Dependencies:
  - BACKLOG-456: ML рекомендации (должна быть готова)
  - BACKLOG-789: User tracking system (в работе)

Estimated Complexity: 5 Story Points (Medium)

5. Документирование результатов

После refinement я обновляю:

1. Описание в Jira:
   - Acceptance Criteria заполнены
   - Зависимости указаны
   - Примечания для разработчиков добавлены

2. Ссылки:
   - На дизайны в Figma
   - На API спецификацию
   - На связанные задачи

3. Метаданные:
   - Story Points (примерно)
   - Labels (frontend/backend/devops)
   - Epic (если есть)

6. Результаты refinement

После успешного refinement:

✓ Задачи готовы к Planning встречи

• Разработчики понимают, что нужно делать
• Риски и вопросы уже обсуждены
• Оценка примерно известна

✓ Меньше вопросов во время спринта

• Нет необходимости уточнять задачи на standup
• Разработчик может сразу начать работу

✓ Лучше предсказуемость

• PO знает, какие задачи попадут в спринт
• Можно планировать релизы

7. Частые ошибки, которые я избегал

❌ Не детализировать в техническую реализацию

• Неправильно: "Используем Hibernate для запроса в БД"
• Правильно: "Получить список активных пользователей"

❌ Не делать refinement сразу перед спринтом

• Нужно время на обдумывание
• Разработчики должны придти домой, подумать, и могут вернуться с вопросами

❌ Не пригашать всю команду разработчиков

• Достаточно 2-3 представителей
• Остальные могут прочитать результаты

❌ Не давить на оценку

• Story Points на refinement - это примерно
• Точная оценка на Planning встречи
• Если нет консенсуса - это признак, что задача нужна более подробная информация

8. Tools и процесс

Я использовал:

• Jira: основной инструмент для хранения задач
• Confluence: для документирования сложных требований
• Miro/Mural: для whiteboard сессий если нужны диаграммы
• GitHub/GitLab: для ссылок на код

Заключение

Backlog Refinement — это инвестиция в скорость разработки. Час потраченный на refinement экономит 5 часов во время спринта благодаря меньшему количеству неточностей и переделок.

Ключевое правило: если задача требует обсуждения во время спринта, значит она плохо подготовлена на refinement.