Planning Poker

Обновлено: 7 октября 2024

Planning Poker

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

Что такое Planning Poker

Идея покера планирования родилась из стремления сделать процесс оценки более точным — метод разработал Джеймс Гренинг в 2002 году, адаптировав технику Wideband Delphi для нужд Agile-команд. Позже, в 2005 году, Майк Кон популяризировал этот подход в своей книге Agile Estimating and Planning.

В Planning Poker участвует вся команда разработки: программисты, тестировщики, аналитики и другие специалисты. Каждый участник получает набор карт с числами из последовательности Фибоначчи, эти карты используют для оценки сложности задачи.

Процесс оценки выглядит так:

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

Покер планирования помогает избежать влияния авторитетов на оценку, так как все участники показывают свои карты одновременно. Кроме того, метод стимулирует обмен мнениями и опытом между членами команды, благодаря чему оценка становится точнее, и участники лучше понимают задачи.

Преимущества и недостатки техники

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

Когда оценки расходятся, команда обсуждает причины. Такие дискуссии помогают обнаружить скрытые риски и сложности, которые могли бы остаться незамеченными при других подходах.

Также игровой формат покера планирования делает оценку более увлекательной, что позволяет вовлечь команду в обсуждение задач. Если в процессе команда наткнулась на неясные требования к задаче, она может своевременно уточнить детали у заказчика — так метод помогает повысить качество планирования.

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

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

Как работает метод Planning Poker

Planning Poker напоминает карточную игру, но вместо обычных карт участники используют специальную колоду с числами. Эти числа обычно представляют собой последовательность Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Такой набор чисел не случаен — он помогает избежать ложной точности в оценках и стимулирует обсуждение при больших расхождениях.

Процесс оценки обычно начинается с того, что владелец продукта представляет задачу команде. Он описывает требования, отвечает на вопросы и уточняет детали, чтобы у команды было полное понимание задачи. После этого каждый участник выбирает карту с числом, которое, по его мнению, отражает сложность или трудоемкость задачи. Участники держат свой выбор в секрете, пока все не определятся с оценкой.

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

После обсуждения все снова выбирают карту, этот процесс повторяют, пока команда не придет к общему мнению. Такой подход позволяет учесть различные точки зрения и прийти к более объективной оценке задачи.

Метод Planning Poker хорошо работает в небольших командах до 10 человек. Для крупных проектов можно разделить команду на подгруппы, каждая из которых будет оценивать свою часть задач.

Пошаговый процесс покер планирования

Каждый этап процесса Poker Planning играет важную роль в формировании точной и согласованной оценки. Ниже — подробнее о каждом шаге и рекомендации для успеха команды.

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

Успех Planning Poker во многом зависит от тщательной подготовки:

Выберите удобное для всех время и место. Для офлайн-встреч подойдет просторная комната с большим столом, а для удаленных команд — платформа для видеоконференций.
Определите состав участников. В идеале на сессии должны присутствовать все члены команды разработки, включая программистов, тестировщиков и аналитиков. Не забудьте пригласить владельца продукта — его участие критически важно для прояснения требований.
Подготовьте колоды карт для каждого участника. Стандартный набор включает карты со значениями последовательности Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Добавьте также карту с символом «?» для обозначения неопределенности и «∞» для чрезмерно сложных задач.
Заранее составьте список задач для оценки. Убедитесь, что каждая задача четко сформулирована и понятна всем участникам. Расположите задачи в порядке приоритета, начиная с наиболее важных.
Назначьте модератора сессии. Обычно эту роль выполняет Scrum-мастер или менеджер проекта. Модератор должен следить за временем, направлять дискуссию и обеспечивать конструктивное обсуждение.
Установите правила проведения сессии. Например, ограничьте время обсуждения каждой задачи 10-15 минутами. Договоритесь, что после двух раундов голосования, если консенсус не достигнут, команда принимает среднее значение оценок.
Подготовьте инструменты для фиксации результатов. Это может быть простая таблица в Excel или специализированное ПО для управления проектами.

Презентация задачи

Качественная презентация задачи — фундамент точной оценки. Она помогает команде сосредоточиться на сути проблемы и принять обоснованное решение. Обычно задачу представляет владелец продукта или менеджер проекта, его задача — дать участникам полное понимание того, что нужно сделать:

Начните с краткого описания задачи. Например: «Нам нужно разработать функцию автоматического сохранения для текстового редактора». Затем раскройте детали: частота сохранений, поведение при потере соединения, взаимодействие с другими функциями.
Используйте визуальные материалы. Покажите макеты, диаграммы или прототипы, если они есть. Визуализация помогает команде лучше понять задачу и сократить время на обсуждение.
Объясните бизнес-ценность задачи. Почему она важна для пользователей или клиентов? Как она соотносится с общими целями проекта? Понимание контекста помогает команде принимать более взвешенные решения при оценке.
Будьте готовы ответить на вопросы. Команда может спросить о технических ограничениях, интеграции с существующими системами или ожиданиях пользователей.
Проводите презентацию за 5-10 минут. Если задача сложная, разбейте ее на подзадачи и презентуйте каждую отдельно.
Убедитесь, что все поняли задачу одинаково. Это поможет избежать недопонимания на этапе оценки.

Индивидуальная оценка

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

Не торопите участников. Каждому члену команды нужно проанализировать задачу и сопоставить ее со своим опытом. Участники должны учитывать все аспекты работы: кодирование, тестирование, документацию. Например, разработчик оценивает не только время на написание кода, но и на проведение code review и исправление возможных ошибок.
Следите за независимостью оценок. Участники не должны показывать свой выбор или обсуждать его с коллегами до момента раскрытия карт. Это помогает избежать влияния авторитетов и получить честную картину.
Для сложных или непонятных задач используйте карту «?». Она послужит сигналом о необходимости дополнительного обсуждения.
Не зацикливайтесь на точных цифрах. Выбирайте ближайшее значение из доступных на картах. Цель оценки — получить общее представление о сложности задачи, а не точное количество часов или дней.

Обсуждение результатов

Этап обсуждения — самая интересная часть покера планирования. Именно на этом этапе команда находит расхождения в понимании задачи и работает над формированием общего мнения.

Если все участники выбрали близкие значения, например, 5 и 8, обсуждение может быть коротким. Однако при существенном разбросе, например, от 3 до 21, потребуется прояснить ситуацию. Первыми высказываются участники с крайними оценками. Например, разработчик, выбравший 3, объясняет: «Я думаю, мы можем использовать готовую библиотеку, что значительно упростит задачу». А тот, кто выбрал 21, может возразить: «Но нам придется адаптировать эту библиотеку под наши нужды, что потребует дополнительного времени».

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

Не затягивайте обсуждение, оптимальное время — 5-10 минут на задачу. Если дискуссия затягивается, возможно, задачу стоит разбить на более мелкие подзадачи. После обсуждения проводят повторное голосование, обычно второй раунд дает более близкие друг к другу результаты.

Достижение консенсуса

После обсуждения и повторного голосования команда обычно приходит к согласованной оценке. Если оценки стали ближе друг к другу, например, большинство выбрало 8, а пара человек — 13, можно принять среднее значение или округлить в большую сторону.

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

Как повысить вовлеченность команды в Planning Poker

Чтобы сделать Planning Poker не просто формальностью, а увлекательным и продуктивным процессом, попробуйте следующие приемы:

Создайте игровую атмосферу. Используйте необычные карты или добавьте элемент соревнования. Например, награждайте символическим призом участника, чья оценка оказалась ближе всего к итоговой.
Ротируйте роль модератора. Дайте возможность каждому члену команды побыть в роли ведущего сессии. Это повышает ответственность и вовлеченность всех участников.
Визуализируйте процесс. Используйте доску или онлайн-инструменты для наглядного отображения оценок и прогресса. Визуальная составляющая стимулирует интерес и упрощает восприятие информации.
Проводите мини-ретроспективы. После каждой сессии выделите 5-10 минут на обсуждение того, что прошло хорошо, а что можно улучшить. Это поможет постоянно совершенствовать процесс.
Связывайте оценки с реальными результатами. Периодически сравнивайте оценки с фактическими затратами времени. Это помогает команде калибровать свои оценки и видеть пользу от процесса.
Поощряйте обмен знаниями. Создайте условия, в которых опытные члены команды могут делиться инсайтами, а новички — задавать вопросы без стеснения.
Экспериментируйте с форматом. Попробуйте проводить Planning Poker стоя или в неформальной обстановке, например, в парке или кафе. Смена обстановки может освежить восприятие и стимулировать творческое мышление.

Ошибки в Planning Poker и как их избежать

Проведение покера планирования может сопровождаться ошибками, которые могут влиять на эффективность метода в команде. Тем не менее, эти распространенные ошибки можно решить:

Ошибка: слишком долгие обсуждения.
Как избежать: установите таймер на 5-10 минут для обсуждения каждой задачи; если прийти к согласию не получилось, отложите задачу и вернитесь к ней позже.

Ошибка: влияние авторитетов на оценки других участников.
Как избежать: предложите высказываться сначала младшим членам команды.

Ошибка: оценка времени вместо сложности.
Как избежать: используйте абстрактные единицы измерения, например, story points.

Ошибка: недостаточная подготовка и плохо сформулированные задачи.
Как избежать: требуйте от владельца продукта четкого описания задач перед сессией; откладывайте оценку, если задача непонятна.

Ошибка: игнорирование «незаметной» работы, например, тестирование, документация и коммуникация.
Как избежать: составьте чек-лист всех этапов работы над задачей и обращайтесь к нему при оценке.

Резюме

Planning Poker — это эффективный метод оценки задач в Agile-разработке, который позволяет командам более точно прогнозировать сложность и время выполнения проектов. Правильно организованный покер планирования не только улучшает точность оценок, но и помогает команде лучше понять проект и выявить потенциальные риски.