Изучите метод покер планирования для оценки задач в Agile. Эффективный и интерактивный способ определения временных и ресурсных затрат на различные задачи.

Это метод быстрой и относительной оценки трудоемкости выполнения задачи в Story Points, используемый, например, в Scrum фреймворке.

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

Позвольте всей команде голосовать. Используйте Story Points. Не обсуждайте способы реализации задачи, а скорее голосуйте за саму задачу (независимо от того, кто и как ее будет решать).

В этом тексте вы узнаете про основные преимущества, правила и этапы проведения покера планирования.

Покер планирования (Planning Poker) — это очень эффективный метод гибкого планирования и оценки, который стал чрезвычайно известным в последние годы. Он основан на процедуре, известной как Wideband Delphi, которая была сделана корпорацией RAND между 1940 и 1968 годами (точный год неизвестен).

Этот метод был отточен Джеймсом Греннингом (James Grenning) в 2002 году, и он приобрел большую популярность, когда был включен в книгу Майка Кона «Agile Estimating and Planning» («Agile оценка и планирование»).

Основные стратегии планирования существовали в течение долгого времени, но Agile–команды, которые в полной мере воспользовались этим, приветствовали усовершенствования, сделанные Греннингом.

• Каждый участник получает набор карточек, представляющих последовательность чисел. Обычно последовательности включают удваивающиеся числа, (0, ½, 1, 2, 4, 8, 16 и т. Д.), Ряд Фибоначчи (1, 2, 3, 5, 8, 13, 21), размеры футболки (S, M, L, XL, XXL) и т. д. Последовательность Фибоначчи более распространена и с ней легче работать. — Scrum Master представляет одну пользовательскую историю за раз.

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

• Каждый участник тайно выбирает карту, которая представляет его оценку «размера» для их истории. Как правило, размер истории (также известный как сюжетные точки) оценивается на основе промежутка времени, рисков, сложности и других важных элементов, связанных с пользовательской историей.

• Когда все подготовили свою карту, все карты раскрываются.

• Когда есть соглашение по конкретному номеру, Scrum Master записывает размер истории, и команда переходит к следующей истории.

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

• Вероятно, будут дебаты между членами, чтобы придумать новый набор оценок, который, по сути, потребует повторения предыдущих шагов.

• Продолжайте до тех пор, пока не будет достигнуто соглашение.

• Повторите это для остальных историй.

• Люди, которые продвинулись в использовании Planning Poker, могут увидеть ряд фундаментальных причин его успеха. Такие люди, как Майк Кон, очень помогли привлечь внимание к этому виду покера. Он также создал веб–сайт planningpoker.com, чтобы люди могли играть в игры с разбросанными группами.

1. Голосуют люди с ответственностью за обсуждаемые задачи.

Довольно часто гибкие команды позволяют всем голосовать, даже если они не знают, о чём идет речь.

2. Менеджеры не должны голосовать.

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

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

3. Выбор большего размера при прочих равных

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

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

4. Не вступайте в глубокое обсуждение внедрения

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

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

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

5. Используйте карту «Мне нужен перерыв»

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

Они могут использовать карту «Мне нужен перерыв», которая позволяет им привлечь внимание каждого к необходимому перерыву.

6. Используйте таймеры, чтобы уменьшить обсуждение

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

7. Выбор самого большого размера в третьем раунде

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

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

8. Пусть Владелец Продукта встретится с руководителями отдела обеспечения качества и разработчиками раньше времени

Чтобы убедиться, что на все вопросы, связанные с пользовательской историей, даны ответы, Владелец Продукта встречается с лидерами Dev и QA до начала покера планирования. Это позволяет команде сосредоточиться на оценке размера, а не вкладывать.

9. Помните про основные единицы измерения

Все, что команда выбирает в качестве шаблона, должно быть согласованным на всех итерациях.

Если в качестве размера выбран день, то он также должен использоваться в качестве ориентира для остальных итераций. Если конкретная пользовательская история имеет размер 1 или 3, она должна оставаться постоянной в течение итераций.

• Для успешного покера планирования нужна вся команда. Он устанавливает консенсус–оценку, а не заставляет одного человека вести ее целиком.

• Он выявляет проблемы раньше времени и в ходе истории пользователя, а не в конце.

• Ключом к успеху является забавная сторона игры, которая обычно нравится гибким Scrum командам. Приятного покера планирования вашей команде!

Poker Planning