Как там сказал кто-то очень великий и мудрый? «Планы — это ничто, планирование — это всё». Каждая команда разработки планирует работу на год, квартал, спринт или даже неделю и регулярно оценивает задачи: в человеко-часах, story points, «майках», попугаях, питонах… Почти в каждой команде однажды появляется задача с оценкой «ну там работы на пару часов». В процессе выясняется, что под этой «парой часов» лежат права доступа, интеграция, странный статус в базе, недоописанный сценарий и вопрос от QA перед релизом: «А что должно произойти, если пользователь нажмет сюда два раза?»
Даже если задача кажется простой, редко бывает, что вся команда понимает ее одинаково. Разработчик сразу замечает интеграции и технические ограничения, тестировщик думает о нестандартных сценариях, аналитик вспоминает требования, которые не попали в описание, а кто-то видит перед собой простую доработку на пару часов.
Майк Кон считает, что, если попросить команду быстро назвать оценку, обсуждение часто сводится к мнению самого опытного или самого уверенного участника. В результате важные детали остаются за кадром и всплывают уже во время работы.
Что такое Planning Poker простыми словами
Planning Poker — это командная оценка задач: у участников есть набор карт. Чаще всего используют колоду с числами Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55 и 89. В некоторых командах встречаются и другие наборы значений, построенные по похожему принципу. Шкала построена таким образом, что по мере роста чисел увеличивается и неопределенность оценки. Например, если задача кажется сложнее, чем на пять баллов, но проще, чем на восемь, участнику приходится выбрать одно из этих значений, тем самым отражая свое представление о рисках и объеме работ.
По мере роста сложности шаг между значениями увеличивается, потому что не возникает иллюзия точности там, где ее на самом деле нет. Ноль ставят, когда делать практически нечего: либо задача уже реализована, либо речь идет о совсем небольшой доработке, которую нет смысла оценивать отдельно.
В колоде встречаются не только числа. Например, карточка «?» позволяет показать, что для оценки пока недостаточно информации. Карту бесконечности «∞» обычно используют для слишком больших или плохо определенных задач, которые сначала стоит декомпозировать. А карточка «☕» служит сигналом, что пора сделать небольшой перерыв.
Кстати, это не новый инструмент — в зарубежной разработке он давно активно используется и даже пережил свой модный бум. Методика Planning Poker появилась в начале 2000-х, о ней писал Джеймс Греннинг, один из авторов Agile-манифеста. После публикации книги Майка Кона в 2005 году подход быстро набрал популярность в Scrum-сообществе. Именно поэтому сегодня можно встретить и другое название — Scrum Poker; инструмент не потерял актуальности до сих пор.
Как проходит оценка
- Инициатор задачи (Product Owner или аналитик) рассказывает задачу.
- Команда задает вопросы.
- Каждый участник независимо выбирает карточку с оценкой.
- Важный момент: карточки открываются одновременно. Это позволяет получить независимые первые оценки: участники не успевают подстроиться под уже озвученное мнение.
- Если оценки существенно различаются, команда обсуждает причины и проводит повторный раунд оценки, пока участники не придут к общему пониманию.Тот, кто дал самую низкую оценку, объясняет, за счет чего задача может быть выполнена быстрее. В свою очередь участник с самой высокой оценкой рассказывает о рисках, ограничениях и сложностях, которые, по его мнению, могут повлиять на сроки.
Если после нескольких обсуждений оценки по-прежнему сильно расходятся, это хороший сигнал к тому, что задачу стоит декомпозировать или нужно уточнить требования.
Основное преимущество Planning Poker — коллективная оценка. Благодаря обсуждению разных взглядов на задачу команда получает более взвешенное решение и раньше выявляет потенциальные риски и неопределенности.
В Planning Poker задачи обычно оценивают не в часах, а в story points. Это не совсем оценка, сколько времени займет работа, а скорее способ сравнить задачи между собой по сложности:
- насколько хорошо понятны требования,
- есть ли сложные сценарии,
- затрагиваются ли интеграции и данные,
- потребуются ли миграции,
- сколько времени уйдет на тестирование,
- могут ли возникнуть риски,
- есть ли зависимости от других команд.
По сути, команда отвечает на вопрос «Насколько сложно довести эту задачу до состояния, когда ее можно спокойно отправлять в продакшен, не опасаясь неприятных сюрпризов?».
Польза Planning Poker заключается в том, что обсуждение помогает декомпозировать крупные или не до конца понятные задачи. В процессе оценки команда декомпозирует их, выявляет скрытые требования, зависимости и пограничные сценарии. В итоге все лучше понимают задачу, ее проще оценивать и планировать.
Кому подойдет
Planning Poker лучше всего работает в небольших командах (4–7 человек), где участники могут активно участвовать в обсуждении и слышать друг друга.
Метод особенно хорошо подходит для проектов, которые развиваются по гибким методологиям и допускают регулярный пересмотр планов и оценок.
Наибольшую пользу он приносит там, где команда готова обсуждать задачи, обмениваться мнениями и совместно искать решения. При этом важно, чтобы у участников была возможность выделить время на обсуждение и достижение общего взгляда на объем и сложность предстоящей работы.
Кому не подойдет
Planning Poker — это не универсальное решение: если команда живет в режиме постоянных дедлайнов и цейтнота, а приоритеты меняются каждый день, времени на подробные обсуждения может просто не быть. В таких случаях чаще используют более быстрые способы оценки: ориентируются на опыт команды, оценивают задачи в часах или принимают решение на уровне технического лидера.
Практические рекомендации
- Устанавливать таймер для говорящего (например, 2 минуты), чтобы мотивировать членов команды выражаться лаконично.
- Не тратить время на незначительные расхождения. Если оценки отличаются на соседние значения шкалы и команда понимает причины, достаточно выбрать более консервативную оценку и двигаться дальше.
- Приходить на оценку с понятными и подготовленными задачами. Если в них больше вопросов, чем ответов, обсуждение быстро превращается в попытку разобраться, что вообще требуется сделать, а это точно не цель любого планирования, каким бы ни был инструмент. Чем четче описана задача, тем проще команде сосредоточиться на оценке, а не на выяснении требований.
- Не прорабатывать задачи до мельчайших деталей. Важно, лишь чтобы основные сценарии, ограничения и известные риски были понятны команде. Если остаются открытые вопросы, лучше обозначить их сразу. Тогда все участники понимают, где находится неопределенность и почему оценки могут отличаться.
Последние два пункта немного противоречат друг другу, но они как раз показывают, как необходим баланс: задачи нужно оценить, а не решить прямо сейчас.
Инструменты для Planning Poker
Вариантов инструментов два. Первый — живые карточки (можно нарезать кастомные и использовать таймер на телефоне или купить готовые наборы на маркетплейсах).
Если команда работает удаленно, вместо физических карточек можно использовать второй вариант: онлайн-сервисы для Planning Poker. Они сохраняют тот же принцип: участники одновременно подключаются к сессии, независимо выбирают оценку, а результаты скрыты до момента общего вскрытия карточек. После этого команда обсуждает расхождения и при необходимости проводит повторный раунд голосования.
Большинство сервисов также позволяют импортировать задачи с доски, настраивать шкалу оценок, использовать таймер и сохранять историю оценок. Например:
- PlanITPoker — можно создать комнату, пригласить членов команды, добавить задачи, провести несколько раундов голосования и посмотреть историю оценок.
- Planning Poker — с помощью сервиса можно импортировать задачи из Jira, настраивать шкалу оценок, таймеры.
- Kollabe — бесплатный интерактивный сервис с приятным интерфейсом; можно посмотреть демообзор, как это проходит.
Что происходит после
На самой оценке работа не заканчивается: как часто бывает, во время обсуждения почти всегда всплывают новые детали — дополнительные требования, ограничения, риски, зависимости или вопросы, которые нужно уточнить у бизнес-заказчика. Всё это важно зафиксировать сразу, пока информация свежа, иначе через несколько дней команда снова будет обсуждать те же самые вопросы и пытаться вспомнить, к каким выводам уже пришла.
По этой причине после Planning Poker полезно обновить задачу: уточнить описание, дополнить критерии приемки, зафиксировать ограничения, риски, зависимости, открытые вопросы и решения по декомпозиции. Именно на этом этапе результаты обсуждения превращаются в понятные и полезные требования для команды.
Что в итоге дает Planning Poker
Planning Poker помогает вовремя обнаружить пробелы в требованиях, скрытые риски и разное понимание задачи внутри команды. Это хороший способ проверить, насколько задача действительно готова к разработке: если во время обсуждения возникает много вопросов или оценки регулярно расходятся из-за неопределенности, это повод вернуться к требованиям и доработать их до начала реализации.
Но, на мой взгляд, при этом не стоит воспринимать Planning Poker как универсальное решение всех проблем с оценкой задач: он не заменит качественно проработанные требования, не избавит от неопределенности и не гарантирует точные оценки. Это всего лишь один из инструментов, который помогает команде лучше понять задачу, обсудить риски и синхронизировать ожидания перед началом работы.
