Как появился Planning Poker

Мы собираем практику и смыслы продакт-менеджмента: от CustDev и JTBD до бэклога, онбординга и роста метрик. Даем простые чек-листы, рабочие примеры и разборы, чтобы вы быстрее принимали продуктовые решения. Без воды и хайпа — только то, что помогает делать продукт и карьеру сегодня.

planning pokerпланированиеwideband delphi

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

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

История "покера" началась в 2002 году, в American Fork, штат Юта. Джеймс Греннинг (один из авторов и подписантов Agile Manifesto) вел встречу по планированию для одного из клиентов по методологии Extreme Programming. Два самых опытных архитектора минут сорок препирались по поводу оценки одной задачи и в итоге написали ту же цифру, которую называли в первые пять минут. Остальные шестеро за столом просто скучали.

Греннинг решил проблему на ходу: попросил всех молча записать оценку на карточке и открыть одновременно. Так родился Planning Poker.

Agile Alliance определяет технику коротко: "игровой подход к оценке, который используют многие agile-команды" (Agile Alliance, Glossary)

Позже метод подхватил и упаковал Майк Кон. Добавил числа Фибоначчи, написал книгу "Agile Estimating and Planning" и в итоге зарегистрировал торговую марку на название.

Но у покера есть и более старые предки.

В основе лежит Wideband Delphi из 1970-х: эксперты оценивают независимо, расхождения обсуждают вслух, потом переоценивают, и так по кругу, пока не сойдутся. А он вырос из классического Delphi - метода, который еще в 1950-х придумала RAND Corporation для стратегических военных прогнозов, где эксперты вообще не видят друг друга и общаются только через фасилитатора.

Забавно, как часто привычные рабочие ритуалы оказываются верхушкой айсберга с полувековой историей.

А вы знали, откуда пошел покер планирования? Или тоже, как я, просто играли, не задумываясь?

Автор:
Андрей Миронов 😌 - Run. Build. Chill. Repeat

Дискуссия

Холопцев | Немного продакт
А как ты историю узнал? GPT?
Andrey
Холопцев | Немного продакт
А как ты историю узнал? GPT?
гуглил, потом клодил, а потом еще вспомнил, что реально раньше пару раз пользовался делфи планирование лет 10 назад и оно плюс минус похоже
Andrey
я вообще чем дальше в продуктовое управление захожу, тем больше мне встречаются базовые инструменты из проектного управления которые мне 10 лет назад на разных курсах давали. А в продуктовом управлении такое ощущение что люди их переизобретают и новые названия придумывают) скоро и ганта перепридумают наверное, про него уже тоже пособирал материала. Гант это уже конец цепочки, а в процессе его создания как минимум еще 2 инструмента участвуют. И опять же в проектном управлении это все как 2х2 расписано в стандартах
Кать, а ты правда agile коуч?
Andrey
я вообще чем дальше в продуктовое управление захожу, тем больше мне встречаются базовые инструменты из проектного управления которые мне 10 лет назад на разных курсах давали. А в продуктовом управлении такое ощущение что люди их переизобретают и новые названия…
я думаю, все дело в том, что проще сказать "у нас продуктовый подход, а не проектный", чем во что-то там вникать... даром что создание продукта это проект, ровно исходя из определения проекта 😂😂😂
Andrey
Кать, а ты правда agile коуч?
я думаю, все дело в том, что проще сказать "у нас продуктовый подход, а не проектный", чем во что-то там вникать... даром что создание продукта это проект, ровно исходя из определения проекта 😂😂😂
Тут прям холиварный холивар может случиться) с одной стороны да - результат деятельности проекта = продукт. Когда я сдавал PMP, то в PMBoK был жестко процессно-водопадный подход (5я редакция) и зона ответственности руководителя проекта ограничивалась рамками самого проекта. Сейчас в 8й редакции стандарта фокус сильно сместился в сторону бизнес-ценности и value. Тут уже нечто среднее, но все равно в моем понимании зона ответственности у проджектов и продактов отличаются. Отсюда и переизобретение (адаптация) инструментов, практик и каких-то принципиальных моментов чтобы было удобнее достигать результатов
Алексей Ф
Кать, а ты правда agile коуч?
создание продукта это проект, ровно исходя из определения проекта
что такое создание продукта? идея? реализация? в какой версии?
Andrey
Алексей Ф
что такое создание продукта? идея? реализация? в какой версии?
Это все тоже может быть проектами. Даже разработка технического задания с нуля тоже можно считать проектом если вы его в таком виде еще не делали. А если кто-то другой делал и достает уже готовое тз в котором нужно поправить несколько косметических моментов, то не обязательно считать и делать это с применением проектных инструментов. Грань есть, но часто она размазывается. Для себя иногда определяю проектное управление как набор инструментов и практик, которые помогают справляться с неопределенностью при реализации чего-то нового для меня/компании. Я их также применяю и точечно в обычной работе или в работе над продуктов, а комплексный подход включается на крупный изменениях или при запуске продукта с большой неопределенностью и высокими рисками
Кать, а ты правда agile коуч?
Andrey
Тут прям холиварный холивар может случиться) с одной стороны да - результат деятельности проекта = продукт. Когда я сдавал PMP, то в PMBoK был жестко процессно-водопадный подход (5я редакция) и зона ответственности руководителя проекта ограничивалась рамками…
не, я не ради холивара. на многие вещи нет однозначных ответов - если всерьез начать описывать разницу продукта и проекта, это с ума можно сойти...)))
Andrey
Кать, а ты правда agile коуч?
не, я не ради холивара. на многие вещи нет однозначных ответов - если всерьез начать описывать разницу продукта и проекта, это с ума можно сойти...)))
Интересно кто-нибудь когда-нибудь придумал что то очень простое вроде - продукт это результат, проект это понятный способ как эти результаты получать
Присоединиться к обсуждению →

Читайте так же