Что такое Planning Poker и как его использовать?

Что такое Planning Poker?

Planning Poker — это консенсус-ориентированная техника оценки трудоёмкости задач (обычно в story points или идеальных часах), используемая в Agile-командах, чаще всего в рамках Scrum или Kanban. Её основная цель — устранить эффект якоря (когда первая озвученная оценка влияет на мнения остальных) и стимулировать активное обсуждение требований и потенциальных рисков. Каждый участник оценки получает набор карт с числами, часто соответствующую последовательности Фибоначчи (например, 0, 1, 2, 3, 5, 8, 13, 21, ∞, ?), которая отражает нелинейный рост сложности.

Ключевые принципы и преимущества

• Коллективное владение: Оценку даёт вся команда (разработчики, тестировщики, иногда аналитики), а не только тимлид или менеджер.
• Фокус на обсуждении: Разногласия в оценках — не ошибка, а ценная возможность выявить "тёмные" места в требованиях, технические риски или разные интерпретации задачи.
• Относительная оценка: Задачи оцениваются не в абсолютных единицах времени, а относительно друг друга (эта задача сложнее той, которую мы взяли за 3 story points).
• Скорость и вовлечённость: Игровой формат ускоряет процесс и повышает вовлечённость участников.

Как использовать Planning Poker: пошаговый процесс

Подготовка к сессии

1. Определите модератора: Обычно это Scrum Master или владелец продукта (Product Owner). Он ведёт встречу, но не участвует в оценке.
2. Подготовьте backlog: Product Owner заранее приоритизирует backlog и готов детально отвечать на вопросы по пользовательским историям (user stories).
3. Выберите шкалу: Договоритесь, какую последовательность чисел использовать (Фибоначчи — самый популярный выбор). Объясните команде значение карт "∞" (слишком большая/непонятная задача, требует декомпозиции) и "?" (недостаточно информации для оценки).

   # Пример популярной шкалы для оценки в story points
   planning_poker_scale = [0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, '∞', '?']
   # На практике чаще используется укороченный набор: 0, 1, 2, 3, 5, 8, 13, 21, ∞, ?
   

4. Обеспечьте инструменты: Физические карты или цифровые аналоги (Jira, Miro, PlanningPokr.com).

Проведение сессии (цикл для каждой задачи)

1. Обзор задачи: Product Owner представляет пользовательскую историю, критерии приёмки (acceptance criteria) и отвечает на первоначальные вопросы.
2. Частная оценка: Каждый участник независимо и молча выбирает карту, отражающую его оценку сложности (усилия, риски, неопределённость). Это ключевой момент для избежания влияния авторитетов.
3. Раскрытие карт: По команде модератора все одновременно показывают выбранные карты.
4. Обсуждение расхождений:

    *   Если оценки совпали или близки (например, 5, 5, 8), **Product Owner** может уточнить, все ли согласны с усреднённым значением, и команда переходит к следующей задаче.
    *   Если есть значительный разброс (например, 3, 8, 21), **модератор просит высказаться участников с самой высокой и самой низкой оценкой**. Это самая ценная часть процесса!

1. Повторение раундов: После обсуждения (и, возможно, уточнения требований от Product Owner) команда проводит новый раунд оценки. Цикл повторяется, пока не будет достигнут консенсус или близкие значения.

После сессии

• Фиксация результатов: Оценки (в story points) вносятся в backlog.
• Декомпозиция: Задачи, получившие оценки "∞" или очень большие числа (например, 21+), должны быть разбиты на более мелкие.
• Ретроспектива процесса: В конце спринта команда анализирует, насколько точными были оценки, и корректирует подход при необходимости.

Важные нюансы и практические советы

• Оцениваем только усилия, не сроки: Story points — это мера относительной сложности и объёма работы, а не календарных дней. Переводить их в часы — антипаттерн.
• Базовый эталон: В начале работы команде необходимо определить эталонную задачу (benchmark story) на 3 или 5 story points, к которой можно будет привязываться.
• Вовлекайте всех исполнителей: Оценивать должны те, кто будет делать работу (разработчики, QA, дизайнеры).
• Контролируйте время: Ограничивайте обсуждение одной задачи 5-10 минутами. Если консенсуса нет, отложите задачу для дальнейшего прояснения.
• Избегайте давления: Product Owner не должен настаивать на снижении оценки. Его роль — прояснять, а не диктовать.

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