Покер скрам: Карты, деньги, два ствола. Как выглядит покер в скрам?

Покер Планирования 🃏 (Poker Planning) — Гибкая Оценка

Правила игры в покер планирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Покер планирования — совместная оценка задач командой 💎 — OnAgile Consulting

Planning poker (перевод с англ. — Покер планирования) — техника командной оценки задач в относительных единицах. Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning». 

Достоинства техники:

• Вовлекает всех участников в процесс оценки.
• Позволяет сформировать у команды одинаковое понимание сути оцениваемой задачи. В результате оценки задачи с помощью Покера планирования команда понимает объем изменений и их сложность — за счет передачи знаний и опыта между участниками.
• Позволяет команде за ограниченное время прийти к консенсусу в определении сложности задачи. Согласно исследованиям, такие оценки получаются более точными и менее оптимистичными.
• Помогает минимизировать эффект якорения. Эффект якорения возникает, когда при оценке задач один из участников вслух произносит свою версию оценки сложности задачи, например: «Я думаю, что эта задача на 5 дней». В этот момент у других участников неосознанно возникает привязка к числу 5. Это число становится отправной точкой в их личном мыслительном процессе, задавая рамки. Например, если кто-то думал про оценку в 1-2 дня, после услышанного мнения в 5 дней он неосознанно захочет увеличить свою оценку. Особенно сильно этот эффект проявляется, когда первым говорит человек, являющийся формальным или неформальным лидером для команды.

Описание процесса планирования с использованием карт

Подготовка

Чтобы встреча командной оценки с использованием техники Покер планирования прошла продуктивно, мы советуем подготовить:

• список задач на оценку, по которым владелец продукта может дать обзор, что и зачем необходимо сделать, и ответить на уточняющие вопросы команды;
• колоды карт для участников команды. Мы рекомендуем колоды, содержащие для оценки адаптированный ряд Фибонначи: 1, 2, 3, 5, 8, 13, 20, 40… Такой ряд хорошо отражает неопределенность, которая возрастает с ростом сложности оцениваемой задачи. Чем меньше задача, тем мы точнее можем понять ее трудоемкость. Мы отчетливо можем отличить сложность в 1 от 2 или от 3. С ростом сложности и неопределенности обеспечить такую точность становится трудно. И разница, скажем, между 13 и 20 не столь велика, риск ошибиться большой — как в большую, так и в меньшую сторону. Мы советуем командам декомпозировать задачи с оценкой 13 и более;
• эталонную задачу, а лучше набор эталонных задач разного объема, например: 1, 3, 5. Эталонная задача — это задача, которая уже была выполнена командой, или по которой команда одинаково понимает, какие доработки были сделаны, и все согласны с указанной оценкой сложности. Эталонные задачи значительно упрощают и ускоряют процесс относительной оценки в команде.

Механика проведения Покер планирования

У каждого участника команды есть своя колода карт для оценки. Колоды содержат одинаковый ряд значений. Для того чтобы процесс относительной оценки проходил проще, желательно на встрече поместить в поле зрения команды набор эталонных задач (флипчарт, whiteboard и др.).

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

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

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

Как только все участники команды выложили свои карты, вскрываются значения. Участники с минимальной и максимальной оценкой рассказывают свои доводы, объясняя, почему данная задача сложнее или легче эталонной. В процесс обсуждения может вовлекаться вся команда. Фасилитатор следит, чтобы обсуждение не ушло в торги и нескончаемый спор. Цель обсуждения — обменяться опытом, понять, почему есть такой разброс оценок, и прояснить детали решения, которые помогут снизить разброс и прийти к консенсусу. Если в результате обсуждения выясняется, что команде не хватает информации, и участники не могут принять решение, оценка задачи откладывается и в бэклог добавляется задача (Spike) на проработку.

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

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

как сделать процесс постановки задач максимально прозрачным и четким / Блог компании Retail Rocket / Хабр

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

Как и зачем мы проводим планирования

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

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

Заказчик (постановщик задачи – менеджер продукта, маркетолог или даже генеральный директор) обязательно должен присутствовать на планировании, чтобы объяснить суть задачи, рассказать, как он ее понимает, донести до команды почему задача важна и мотивировать исполнителей на ее выполнение. Цель инженерной команды — за счет дополнительных вопросов выяснить максимальное количество подробностей, вытянуть из заказчика скрытые требования, предложить свои идеи по реализации и выработать наилучший способ решения. Либо объяснить, почему выполнение задачи стоит отложить на некоторое время или не брать в работу вообще.

Постановка задачи

Заказчик зачитывает свою задачу (это всегда делает строго заказчик, чтобы избежать “сломанного телефона” при передаче данных и ускорения процесса выработки решения), объясняет, что именно нужно сделать и почему это важно.

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

Оценка сложности

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

Исполнители с пограничными оценками (т.е. участники, которые дали самую низкую и самую высокую оценку по времени) должны объяснить свой выбор. С одной стороны, давление команды не позволит участникам дать неадекватно завышенную оценку сроков, с другой — команда получает возможность обсудить возможные проблемы по задаче. Тот, кто поставил наименьшую оценку по времени, делится с командой, как именно он планирует выполнить задачу так быстро. Участник, который дал самую большую оценку, должен рассказать о том, какие риски и сложности он предвидит при выполнении этой задачи. После повторного обсуждения с учетом всех подводных камней, команда принимает решение о том, какая оценка является более подходящей для задачи. Этот срок заносится в карточку с описанием задачи в таск-менеджере.

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

Если один участник оценивает задачу в ½ дня, а другой в 3 дня, они явно задумали выполнять задачу по-разному, и поэтому должны согласовать свои действия и объяснить, почему надо делать именно так, как они думают. Иногда расхождение в оценке может быть обусловлено разным опытом в решении схожих задач, в этом случае берется максимальная оценка, но если срок отличается более чем на 1 день, то задача выполняется в парном программировании, когда тот, кто оценил в меньшую сторону, руководит тем, кто оценил в большую.

Советы:

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

Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше. Так все участники будут хорошо помнить все детали обсуждения каждой конкретной задачи. Если задача провисела в очереди на исполнение более 4-х дней, ее нужно снова вынести на обсуждение, чтобы команда вспомнила, что и как нужно сделать по задаче.

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

Формат «Planning Poker» хорошо прижился в работу наших команд: разработчиков, аналитиков, админов, и позволяет лучше понимать задачи и пути их решения на этапе постановки.

А как вы обсуждаете задачи и оцениваете сложность и время их выполнения? Делитесь своим опытом в комментариях!

‎App Store: Scrum Planning Poker

Scrum Planning Poker: гибкая оценка историй — это просто!
Поделитесь своими голосами и наслаждайтесь своим следующим спринтом!

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

— Спасите мир, не рубите деревья для некоторых карт.
-Не нужно носить с собой колоду карт, каждый член вашей команды может бесплатно установить приложение на iPad, iPhone, iPod.

-Это приложение выросло из-за необходимости иметь самое простое и читаемое приложение для планирования покера.

— С картами Scrum Planning Poker в вашем телефоне вам никогда не придется нести свои карты на собрания по планированию Scrum. И вы будете чувствовать себя хорошо, экономя бумагу!

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

ФУНКЦИИ:
• Легко использовать
• Плоский дизайн
• Доступен iPad, iPhone, iPod БЕСПЛАТНО
• Полная HD графика
• Красивый и простой интерфейс
• Стандартные, футболка и колоды карт Фибоначчи
• Красивые анимации
• Быстрый выбор карты

Несколько карт имеют определенные значения:
• Бесконечный: пользовательская история очень большая и должна быть разделена
• Вопросительный знак: мне нужно больше информации от владельца продукта, чтобы я мог оценить историю пользователя
• Чашка кофе: мне нужен перерыв!

Примечание: не рекомендуется использовать во время вождения!

Ваши оценки, предложения по улучшению или сообщения об ошибках очень ценятся.

Узнайте больше на нашем сайте: https://scrum-app.itcarst.com

Спасибо за использование Scrum Planning Poker,
Команда iTCarst

Что такое сложность работы в очках и как проводить оценку по этой методике?

Оценить свои возможности и сложность предстоящей работы нелегко. Для разработчиков ПО это одна из самых сложных частей работы (если не самая сложная). Нужно учесть уйму факторов, на основе которых владельцы продукта принимают решения, влияющие на всю команду и даже компанию. Когда на карту поставлено так много, неудивительно, что нервничать начинают все: и разработчики, и руководители высшего звена. Но делать этого не стоит. Agile-оценка — это всего лишь оценка, прогноз, а не клятва на крови.

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

Взаимодействие с владельцем продукта

В рамках agile-разработки задача владельца продукта — расставить приоритеты в бэклоге. Это перечень работы, содержащий краткие описания всех возможностей и исправлений, которые требуется реализовать в продукте. Владельцы продуктов формулируют требования от лица компании, но не всегда понимают тонкости их реализации. Понять, сколько усилий нужно затратить для выполнения каждой рабочей задачи, владельцу продукта поможет правильная оценка, и уже на ее основании он сможет определить приоритет каждой задачи.

Когда техническая команда приступает к оценке сложности, обычно возникают вопросы относительно требований и пользовательских историй. И это хорошо: благодаря таким вопросам вся команда получает более полное представление о работе. Владельцам продуктов, в частности, разбиение рабочих задач на мелкие составляющие и их оценка в очках помогают расставить акценты между всеми (в том числе неочевидными!) направлениями работы. Как правило, когда владелец продукта получает результаты оценки сложности от команды разработчиков, он снова меняет приоритеты в бэклоге.

Agile-оценка — это командная работа

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

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

Не позволяйте своей команде стать жертвой оценок сложности, сделанных в отрыве от большей части коллектива. Это верный способ провалиться!

Хотите попробовать оценивать сложность в очках? Для начала зарегистрируйте аккаунт Jira Software или войдите в него >>

Оценка сложности в очках и часах

При традиционном подходе команды разработчиков ПО дают оценку в единицах измерения времени: днях, неделях и месяцах. Однако многие команды agile предпочитают оценку сложности в очках. Очки сложности отражают общие трудозатраты, необходимые, чтобы полностью реализовать элемент бэклога продукта или выполнить любую другую рабочую задачу. Команды начисляют очки в зависимости от сложности и объема работы, а также сопутствующих рисков или неопределенности. Эти числовые значения нужны для того, чтобы более эффективно разбить работу на небольшие части и избавиться от неопределенности. Благодаря такому подходу со временем команды понимают, сколько они могут сделать за отведенное время, вырабатывают общее представление и придерживаются его. Может показаться, что это далеко не самый понятный способ, однако его польза в том, что он подталкивает команды к принятию более точных решений о сложности работы. У этой системы оценки есть и другие преимущества.

• При выборе дат не учитывается работа, не относящаяся к проекту напрямую, а ведь она неизбежно появляется. Отправка электронных сообщений, проведение встреч и собеседований — все это может отнимать время участника команды.
• На выбор дат значительное влияние оказывают эмоции человека. Относительная оценка работы позволяет максимально исключить эмоциональную привязанность.
• Каждая команда подходит к оценке сложности работы немного по-своему, а значит, скорость каждой команды (измеренная в очках) тоже будет немного иная, чем у других. Это, в свою очередь, означает, что никто не сможет оказывать давление на команду, апеллируя к какому-то эталону скорости.
• Договорившись о соответствии между трудозатратами и сложностью в очках, вы сможете быстро и без дальнейших споров распределить очки.
• Количество очков, которое получат участники команды за решение проблем, зависит от сложности задачи, а не от затраченного времени. Следовательно, участники команды будут заинтересованы в повышении эффективности, а не в расходе времени.

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

Оценка сложности и покер планирования

Команды, которые только пробуют оценивать сложность в очках, пользуются техникой, которая называется «покер планирования». Покер планирования часто используется в разных подразделениях компании Atlassian. В ходе процедуры команда кратко разбирает каждую задачу из бэклога, после чего каждый участник мысленно выставляет ей оценку. Затем каждый поднимает карточку с номером, который соответствует оценке. Если все приходят к одному мнению, отлично! Если нет, уделите время (не слишком много, пару минут), чтобы понять, чем обоснованы разные оценки. Не стоит забывать, что оценка не должна быть скрупулезной. Если команда зашла в дебри, сделайте перерыв и верните обсуждение на более общий уровень.

Готовы попробовать?

Будьте умнее — не мудрите

Отдельное задание не должно занимать более 16 часов работы (если вы оцениваете сложность в очках, можете договориться о верхнем пределе, скажем, в 20 очков). Оценить более сложные рабочие задачи с должной долей уверенности практически невозможно. А уверенность очень важна, особенно когда речь идет о задачах с наиболее высоким приоритетом в бэклоге. Если сложность какой-либо задачи выходит за верхний предел команды (16 часов или 20 очков), это сигнал, что ее нужно разбить на более мелкие составляющие и провести оценку повторно.

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

Извлекайте уроки из прошлых оценок

Ретроспективы существуют для того, чтобы команда могла взять на вооружение ценную информацию из прошлых итераций, включая факторы, повлиявшие на точность оценок. Многие agile-инструменты (например, Jira Software) отслеживают очки за истории, значительно упрощая анализ и оптимизацию оценок. Возьмите, например, последние 5 пользовательских историй, которым команда присвоила по 8 очков. Обсудите, какие из этих задач потребовали одинаковое количество усилий. Если разные случаи потребовали разных усилий, обсудите причины этого. Используйте полученные выводы в процессе оценки сложности в будущем.

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

Поделитесь этой статьей

Dan Radigan

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

Эстимация задач (Оценка). Виды эстимации задач

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

Стори поинты (Story Points)

Сколько усилий нужно потратить на задачу? В условиях неопределенности и сложности ответ лучше дать не в часах. Куда удобнее относительные единицы, из которых самые известные — стори поинты (Story Points).

— Числовой размер (от 1 до 10)
— Размеры футболки (XS, S, M, L, XL XXL, XXXL)
— Последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34 и т. Д.)
— Породы собак (чихуахуа, ………, дог)

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

Измеряя работу стори поинтами, обязательно оцените каждый из этих факторов:
— Объем работы для выполнения.
— Сложность работы.
— Риски или неопределенность при выполнении работы.

Покер планирования (Planning Poker или Scrum poker)

Покер планирования (Planning Poker, а также Scrum poker) — метод оценки проектов по разработке программного обеспечения. Эта техника минимизирует эффект привязки путём опроса каждого из участников команды таким образом, что никто не знает чужого решения до одновременного оглашения выбора каждого из участников.

Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Список функций либо пользовательские истории описывают разрабатываемое программное обеспечение. Карты в колодах должны быть пронумерованы. Обычно колода содержит карты, содержащие числа Фибоначчи, включая ноль: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. (Ноль означает, что функция или уже реализована, или настолько мала, что нет смысла присваивать ей число.)
В колоде могут быть также специальные карты:
— знак вопроса (?), означающий неуверенность;
— бесконечность (∞), означающая, что обсуждаемая функция или принципиально не может быть реализована, или слишком велика, чтобы присваивать ей число;
— чашка кофе (☕), означающая требование перерыва.
Аргумент в пользу использования последовательности Фибоначчи — отражение возрастающей неопределённости с ростом сложности оцениваемых функций или задач.

Процедура проведения покера планирования (Scrum poker):

Каждому участнику обсуждения выдаётся по одной колоде карт. Все колоды идентичны друг другу.

Обсуждение проводится следующим образом:

 
— Ведущий (Модератор), не участвующий в обсуждении, ведёт собрание.
— Менеджер продукта (Product Manager) представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков. Итог обсуждения записывается менеджером продукта.
— Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Числовые достоинства карт могут использоваться по-разному: они могут означать количество дней, наиболее подходящие дни или относительные единицы сложности (story points). Во время обсуждения достоинствам не должны приписываться новые значения в зависимости от размера функций с целью избегания эффекта привязки.
— Каждый участник называет свою карту и переворачивает её.
— Участникам с высокими и низкими оценками даётся возможность высказаться и обосновать свою оценку.
— Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус. Голос участника, который, скорее всего, будет владеть разработкой, имеет больший вес в «голосовании на основе консенсуса».
— Таймер используется для обеспечения структурированного обсуждения; ведущий или менеджер продукта может в любое время перезапустить таймер, по истечении времени все обсуждения должны быть прекращены, затем начинается новый круг покера.

Метод функциональных точек 

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

Последовательность шагов:
— Определение типа оценки.
— Определение области оценки и границ продукта.
— Подсчет функциональных точек, связанных с данными.
— Подсчет функциональных точек, связанных с транзакциями.
— Определение суммарного количества не выровненных функциональных точек (UFP).
— Определение значения фактора выравнивания (FAV).
— Расчет количества выровненных функциональных точек (AFP).

Диаграмма Ганта

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

Покер планирования . Scrum [Революционный метод управления проектами]

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

К счастью, есть довольно быстрый и точный способ сбора оценок. Он называется «покер планирования».

Идея проста. Каждому участнику дается колода карт с числами Фибоначчи – 1, 3, 5, 8, 13 и так далее. Каждая единица работы, которая должна быть оценена, выкладывается на стол. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта.

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

Например, вы красите стены в доме, и вам нужно оценить, сколько времени уйдет на покраску гостиной, кухни и двух спален. Вы работаете с мастерами, с которыми уже красили стены раньше. Итак, сначала две спальни: все оценивают их на три. Никаких особых разногласий, вы делали такое раньше, и вам не кажется, что со спальнями могут возникнуть сложности. Затем команда оценивает гостиную. Это довольно большое помещение, но там все просто. Оценки расходятся от пяти до тринадцати, затем сходятся на средней оценке – шесть. И снова нет смысла спорить. Затем дело доходит до кухни, и тут на столе оказываются и три, и восемь, и тринадцать, и еще пять. Тот, кто положил тройку, уверяет, что комната небольшая, площадь даже меньше, чем у двух спален. Человек, положивший цифру тринадцать, напоминает, что стоит учесть все то время, которое понадобится, чтобы заклеить шкафчики и столы, а красить отдельные маленькие участки придется кистью, а не валиком. Команда быстро выкладывает новые карты. Цифра три превратилась в восемь, все остальные оценки остались старыми. Теперь оценки довольно близки друг к другу, можно их сложить, вычислить среднее арифметическое и переходить к следующей задаче.

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

Я научился всему этому на собственном горьком опыте, когда работал в Пенсильвании в GSI Commerce, занимавшейся интернет-продажами. С тех пор их купила компания eBay. GSI специализируется на создании онлайн-магазинов для таких компаний, как Levi’s, Toys “R” Us, Major League Baseball и Zales Diamond. Это не мелкие проекты. И GSI с ними очень неплохо справляется.

Однако у компании GSI появилась идея, которая какое-то время казалась хорошей. Вместо того чтобы каждая группа занималась оценкой проекта самостоятельно, руководство решило отдавать эту часть работы лучшим оценщикам компании – довольно умным и профессиональным ребятам, отлично разбиравшимся как в проектах, так и технологических процессах и знавшим, что нужно делать. Они взяли несколько проектов и оценили их. Вот этот потребует столько-то времени, другой столько-то и так далее. Всего требовалось оценить восемьдесят мультимиллионных проектов, оформить бумаги по экспертизе и представить результаты в первую очередь всем заказчикам, во вторую – группам разработчиков, которые будут непосредственно выполнять задания. На первый взгляд все разумно, не так ли?

Как выяснилось, этот путь до такой степени плох, что эксперты остановились на полпути, успев оценить ровно сорок проектов. Сразу приходят на ум срочно прерванные клинические исследования лекарств, в процессе которых выяснялось, что препараты скорее убивают, чем лечат. Экспертные оценки в GSI были настолько далеки от реальности, что оказались совершенно бесполезными.

Ничто не выполнялось вовремя. Клиенты оставались недовольными. Рабочие группы были деморализованы. В общем, полная катастрофа. Руководители вернулись к старому варианту: теперь группы разработчиков снова самостоятельно проводили оценку проектов. Вот чудеса! Оценки вновь стали сходиться с реальностью.

Из этой истории я вынес простую мысль: только тот, кто непосредственно выполняет проект, знает, сколько он требует времени и сил. Скорее всего, группы, работавшие в GSI, очень разные. Какая-нибудь группа хороша в разработке одного вида продукта, но совершенно несостоятельна в работе над другим. Наверняка в каждой группе можно найти специалистов, способных совершать чудеса в какой-то конкретной сфере. Наверное, есть группы, где кто-то с чем-то не справляется. Как мы уже не раз говорили, все команды уникальны и неповторимы. У каждой свои темп и ритм работы. Подгонять их под общий шаблон – верный путь в пропасть.

Planning Poker®: лучший инструмент для гибкого планирования

Planning Poker® — это цифровая карточная игра, предназначенная для того, чтобы помочь командам agile и scrum-разработчиков эффективно устанавливать свои спринтерские цели посредством совместного планирования и оценок на основе консенсуса. Planning Poker® оказался одним из самых эффективных инструментов планирования спринта для гибких команд.

Три способа играть в Planning Poker®

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

Ознакомьтесь с планами Premium и ценами

Функции, необходимые для планирования спринта

Многие команды считают планирование спринта рутиной. Новые функции Planning Poker® позволяют вашей команде легко и эффективно устанавливать ваши оценки спринта:

• Играйте на мобильном или настольном компьютере для поддержки распределенных команд
• Выберите одну из нескольких шкал, чтобы построить спринт, подходящий для вашей команды
• Зарегистрируйтесь и играйте безопасно, чтобы защитить свой спринт
• Измените оценки, чтобы добиться консенсуса команды вокруг оценок
• Расширьте игровую комнату для более крупных гибких команд (только Standard и Pro)
• Экспорт историй для простого управления спринтом (только Standard и Pro)
• Отслеживайте скорость работы команды, чтобы убедиться, что члены команды достигают своих целей (только Standard и Pro)
• Добавьте подробности истории и критерии приемки для точных оценок (только Standard и Pro)
• Создание пользовательской шкалы наведения (только Standard и Pro)
• Импорт и экспорт в JIRA, TFS, VersionOne и другое гибкое программное обеспечение (только Standard и Pro)

Команда Planning Poker®

Planning Poker® популяризировал Майк Кон, основатель Mountain Goat Software. В 2014 году Кон в партнерстве с агентством по разработке цифровых продуктов Three Five Two создал новую версию PlanningPoker.com, добавив улучшенные функции и современный дизайн. Как проворные евангелисты, команда разработчиков Three Five Two продолжает создавать новые функции и улучшать Planning Poker® посредством отзывов пользователей и постоянного тестирования. Хотите предложить новую функцию или попросить о помощи? Напишите нам.

Часто задаваемые вопросы | Planning Poker®

• Кто создал PlanningPoker.ком?
• Как вы играете в Planning Poker®?
• Почему существует колода карт с размерами футболок?
• Почему вы допускаете средний балл по истории?
• Что такое Planning Poker®?

• Что означает кофейная карта?
• Можно ли просто оценить, не вводя истории?
• Можете ли вы подтвердить безопасность сайта?
• Почему вы допускаете средний балл по истории?
• Какие функции доступны в платных аккаунтах?
• Как работает усреднение баллов?
• Как переключиться в режим зрителя?
• Интеграция с JIRA
• Использование интеграции JIRA для добавления историй
• Использование Deck Builder

• Какие значения присвоены размерам футболок?
• Можно ли просто оценить, не вводя истории?
• Почему вы допускаете средний балл по истории?
• Как работает импорт / экспорт с Jira
• Как мне пригласить игроков в мою игру?
• Как удалить игрока из игры?
• Как изменить порядок историй в игре?
• Импорт историй в CSV
• Использование Deck Builder

• Какие значения присвоены размерам футболок?
• Что означает кофейная карта?
• Можно ли просто оценить, не вводя истории?
• Как вы играете в Planning Poker®?
• Почему существует колода карт с размерами футболок?
• Как работает усреднение баллов?
• Как переключиться в режим зрителя?
• Как изменить порядок историй в игре?

• Можете ли вы подтвердить безопасность сайта?
• Какие браузеры поддерживаются?
• Как я могу сбросить пароль?

• Какие функции доступны в платных аккаунтах?

Что такое планирование покера в Agile?

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

Точность групповых и индивидуальных оценок

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

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

Что такое Planning Poker?

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

Scrum Planning Poker

Этапы планирования в покере

1. Чтобы начать сеанс планирования игры в покер, владелец продукта или покупатель читает гибкую пользовательскую историю или описывает функцию оценщикам.
   Например:
   «Клиент входит в систему бронирования»
   «Клиент вводит критерии поиска для бронирования гостиницы»
2. Члены группы делают оценки, раскладывая пронумерованные карты лицом вниз перед столом, не раскрывая свою оценку (значения Фибоначчи: 1,2,3,5,8,13,20,40)
3. Карты одновременно отображаются
4. Затем обсуждаются оценки и объясняются высокие и низкие оценки
5. Повторяйте по мере необходимости, пока оценки не сойдутся.

Scrum Planning Poker шаги

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

Agile Estimation — относительное против абсолютного

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

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

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

Последовательность Фибоначчи и покер планирования

Planning Poker использует последовательность Фибоначчи для присвоения значения в очках функции или пользовательской истории. Последовательность Фибоначчи — это математический ряд чисел, который был введен в 13 веке и использовался для объяснения определенных формирующих аспектов природы, таких как ветвление деревьев.Серия создается путем сложения двух предыдущих чисел вместе, чтобы получить следующее значение в последовательности: 0, 1, 1, 2, 3, 5, 8, 13, 21 и так далее.

Для целей гибкой оценки некоторые числа были изменены, в результате чего получился следующий ряд: 1, 2, 3, 5, 8, 13, 20, 40, 100, как показано на рисунке ниже:

Последовательность Фибоначчи и планирование покера

Интерпретация точки, присвоенной покерной карте, приведена в таблице ниже:

Карточка (и)	Интерпретация
0	Задача уже выполнена.
1/2	Задача крошечная.
1, 2, 3	Они используются для небольших задач.
5, 8, 13	Они используются для задач среднего размера.
20, 40	Они используются для больших задач.
100	Они используются для очень больших задач.
<бесконечность>	Задача огромная.
?	Не знаю, сколько времени уйдет на выполнение этой задачи.
<чашка кофе>	Я голоден 🙂

Соотношение баллов и часов в оценке

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

Например, мы не часто учитываем «затраты на ведение бизнеса». Встречи, электронная почта, обзоры кода и т. Д. Со значениями времени. Но на самом деле все это необходимые практики в нашей повседневной жизни, но на самом деле они не считаются «работой». Сюжетные точки изолируют работу по разработке программного обеспечения от связанных элементов логистической работы, поэтому оценки с использованием точечных оценок должны быть более последовательными, чем часовой базовый подход.

О Visual Paradigm

Visual Paradigm помогает организациям оставаться конкурентоспособными и быстро реагировать на изменения в быстро меняющейся среде.Нашим отмеченным наградами продуктам доверяют более 320 000 пользователей в самых разных компаниях: от малых предприятий и консультантов до самых крупных организаций, университетов и государственных структур по всему миру. Он позволяет организациям повышать гибкость бизнеса и ИТ и стимулировать инновации с помощью популярных открытых стандартов и структур процессов. Visual Paradigm, потрясающая функция Agile в 2018 году, представила Scrum Process Canvas для автоматизации процесса создания, управления и развертывания программного обеспечения командой Scrum. приложение, которое позволяет команде постоянно улучшать свою работу с беспрецедентной скоростью и масштабом. Управляйте всем процессом Scrum из одной страницы Автоматизируйте Scrum Framework в веселой и приятной приборной панели с привлекательным обновленным статусом. Управляйте бэклогом, несколькими спринтами различных ролей Scrum с помощью одностраничного визуально исполняемого холста Разрешить мгновенный доступ, просмотр и создание артефактов схватки и связанных документов для архивации в общем кабинете Автоматизируйте события Scrum и связанные с ними действия с помощью понятных инструкций, образцов и необходимых шаблонов документов.

Что такое Planning Poker? | Agile Alliance

Определение

Игривый подход к оценке, используемый многими Agile-командами.

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

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

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

Общие ловушки

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

Ожидаемые выгоды

• Использование структурированного, похожего на игру формата поддерживает ход событий и позволяет избежать увязания оценочной встречи в бесконечных обсуждениях (именно этот результат был первоначальной целью практики)
• Формат встречи дает возможность использовать знания всех членов команды, тогда как в менее структурированном формате встречи более общительные члены команды иногда не обращают внимания на тихих
• беседа после раскрытия первоначальных оценок — отличный способ объединить идеи об обсуждаемой пользовательской истории и выявить риски реализации

Академические публикации

Исследовательские исследования Нильса Кристиана Хаугена, похоже, подтверждают ценность этой практики, которая дает несколько лучшие оценки, чем оценка одного «эксперта».

Истоки

• 1970-е: Барри Бем предлагает «Wideband Delphi», предшественника Planning Poker
• 2002: текущая форма Planning Poker изложена в статье Джеймса Греннинга
• 2005: техника Planning Poker популяризируется в сообществе Scrum, как и ряд других методов планирования, благодаря книге Майка Кона «Agile Assessment and Planning»

Планирование покера и скрам-покер Все, что вам нужно знать

ПЛАНИРОВАНИЕ ПОКЕРА ИЛИ SCRUM-ПОКЕР ВСЕ, ЧТО ВАМ НЕОБХОДИМО ЗНАТЬ

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

Planning Poker in Scrum объединяет мнения нескольких экспертов для быстрой оценки проекта. Этот тип гибкого планирования включает всех: программистов, тестировщиков, инженеров баз данных, аналитиков, дизайнеров взаимодействия с пользователем и весь другой персонал, участвующий в проекте. Поскольку эти члены команды представляют все дисциплины в программном проекте, они лучше всего подходят для задачи оценки.

Как работает планирование в покере

Планирование игры в покер, или сессия схватки в покере, вовлекает владельцев продуктов или клиентов и редакторов. Сессия начинается с того, что каждый оценщик держит в руках колоду карт, основанных на ценностях, расположенных в порядке очереди. Мы рекомендуем следующее: 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Эти значения представляют количество очков истории, идеальных дней или других единиц, в которых команда будет оценивать.

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

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

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

Оценщики продолжают процесс планирования покера до тех пор, пока не будет достигнуто консенсус в отношении стоимости. Если они не могут прийти к согласию, оценщики могут отложить гибкую оценку и планирование конкретного элемента до получения дополнительной информации.

Когда мы должны участвовать в Planning Poker (или Scrum Poker)

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

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

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

Советы по планированию покера в Scrum

Следующие советы помогут командам справиться с типичными проблемами при планировании покера в Scrum:

• Поддерживайте продуктивность дискуссий: Двухминутный песочный таймер — полезный инструмент, используемый для обучения групп более быстрым оценкам.Чтобы использовать таймер, таймер устанавливается, когда кто-то в группе начинает раунд. Когда песок заканчивается, начинается следующий раунд планирования покерных карт.

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

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

3 главные причины, почему планирование в покере — это хорошо

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

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

Небольшие шаги, которые пропускает большинство людей, можно сделать, чтобы улучшить процесс. Знание этих советов позволит успешному тренеру или надежному члену команды улучшить свою команду. Так что же это за крупицы мудрости?

Те, кто выполняет работу, должны голосовать.

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

Руководители не голосуют.

Менеджеры обычно хотят, чтобы работа занимала меньше времени, поэтому часто голосуют очень низко.Однако у них больше опыта, чем у среднего члена команды. Предоставляя менеджеру право вето в отношении консенсуса команды в одном конкретном случае, он может попросить команду рассмотреть что-то, что может УВЕЛИЧИТЬ размер.

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

Если в голосовании два последовательных размера равны, просто выберите больший размер и двигайтесь дальше.

Последовательные размеры могут быть 5 и восемь8, если вы используете последовательность Фибоначчи для определения размеров (1, 2, 3, 5, 8, 13). Равное разделение обычно занимает много времени, поэтому используйте большее число. По моему опыту, никто никогда не соглашается на среднее число и обычно выбирает максимальный размер в конце обсуждения. Использование этих фактов выгодно и ускорит процесс.

Прекратите обсуждение реализации, пока оно не зашло слишком далеко.

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

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

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

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

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

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

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

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

Попросите человека, создающего пользовательские истории, встретиться с руководителями отдела тестирования и разработки перед игрой в Planning Poker

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

Запомните базовый уровень.

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

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

Удачи!

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

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

УДОВАЛИВАЕТЕСЬ ЛИ ВЫ, ВЫПОЛНЯЕТЕ ХОРОШУЮ РАБОТУ В КАЧЕСТВЕ SCRUM MASTER? ЗАГРУЗИТЕ МОЕ ОЦЕНКУ, КОТОРОЕ ПРЕДОСТАВЛЯЕТ ВАМ БОЛЬШУЮ ИНФОРМАЦИЮ О ВАШЕЙ ЕЖЕДНЕВНОЙ ДЕЯТЕЛЬНОСТИ В КАЧЕСТВЕ SCRUM MASTER

Получите мою оценку сейчас!

Планирование Poker (или Scrum Poker) для распределенных команд

«Как можно играть в Planning Poker с географически распределенными командами» ? Вероятно, есть много способов добиться этого.Вот несколько распространенных вариантов:

Вариант-1: Окно чата (Пробовал, но оставляет лазейки для предвзятого выбора точек)

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

Вариант-2: Веб-камера (я использую эту в текущем проекте — не очень весело, но работает!)
При использовании видеоконференцсвязи для встреч с несколькими людьми (видео в Google+ является бесплатным и популярным), один человек проводит собрание.Этот человек говорит «1-2-3-го»; после того, как сказано «Вперед», каждый член команды показывает свою карточку на веб-камеру.

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

Вариант-3: Планирование Poker.com (Хорошо. Но вы не можете менять карты)
Этот веб-сайт разработан Mountain Goat Software, той же организацией, которая первой изобрела карты планирования в покере. Это бесплатный сайт, который позволяет модератору создавать проект, добавлять истории и приглашать людей по электронной почте для участия в процессе.

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

Вариант-4: Google Docs
Идея проста: создать электронную таблицу в Google Docs и позволить людям вводить свои номера.

Option-5: OneNote
Идея аналогична Google Docs, но документы MS Office также предлагают синхронизацию в реальном времени и платформы. Хотя использование ограничено настольным браузером, люди также могут публиковать свои мнения со своих смартфонов. Пользователи, впервые знакомые с OneNote, смогут изучить это видео с помощью этого видео.

Option-6: плагин JIRA
JIRA для управления Scrum имеет плагин для интеграции планирования покера в пользовательский интерфейс JIRA.Более подробная информация доступна здесь.

Option-7: Scrummy
Scrummy — это игра для оценки сюжетных точек для команд схватки, разработанная веб-поварами Four Kitchens, чтобы упростить участие удаленных членов команды и поэкспериментировать с некоторыми новыми технологиями.

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

Пройти тест

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

Мы обеспечиваем командное обучение, гибкое обучение и гибкое консультирование, обучение OKR, консультирование по OKR, обучение инновациям и консультирование по инновациям.

Со своей командой я создал 5 основных продуктов: высокопроизводительные команды, тренер по Scrum Team, наставничество Scrum Master, организационное мастерство и внешний ускоритель бизнеса.

Что планирует покер | Scrum Poker

Что такое планирование покера в Agile?

Планирование в покер — это игра, используемая для оценки усилий и, следовательно, поиска незавершенных продуктов.Он основан на консенсусе и используется для оценки размера пользовательской истории в схватке. За десять лет до этого, в 2002 году, Джеймс Греннинг назвал эту игру оценочным покером, спустя некоторое время официально Майк Кон сделал эту технику популярной в своей книге по Agile. Он также создал Planningpoker.com, позволяющий людям играть бесплатно и максимально эффективно использовать этот инструмент.

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

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

Лучшее время для использования Planning Poker?

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

Должны ли мы использовать эту технику после написания первого бэклога продукта? По нашему мнению, ответ — нет. Вы можете догадаться почему? Это потому, что мы хорошо понимаем, что планирование покера — это метод оценки размера, и если оно будет выполнено сразу после написания первого бэклога продукта, то будут добавлены пользовательские истории, которые снова приведут к оценкам. Поэтому мы предлагаем использовать покер планирования в конце каждой итерации.Это также сэкономит время и усилия по переоценке. Лучше сделать это за несколько дней до завершения итерации, а затем проводить ежедневные стендапы. Это позволит участвовать всей команде.

Команда планирования и распределения покера

Планирование онлайн-покера Инструмент был предложен миру Майком Коном. Это может использоваться распределенными командами, и поэтому коуч по гибкой методике и инструкторы активно ее продвигают всем людям в гибком сообществе.

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

Agile Assessment — Relative Vs Absolute

Само слово «оценка» на простом английском языке — это угадывание.Имея опыт и знания, руководители команды оценивают время, необходимое для выполнения той или иной работы. Если вы новичок в работе, то какой у вас будет опыт? Как угадать время или спланировать работу? Тогда вам понадобятся некоторые ссылки, и их можно получить из предыдущих работ. Для этого не нужен опыт. Мы всегда можем быстро связаться и прийти к выводу.

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

Я называю относительное произвольным, а абсолютное — реальным. На самом деле не все возможно, и поэтому может произойти, а может и не произойти. С другой стороны, родственников всегда можно настроить и приблизить к точности.

Баллы по сравнению со стоимостью часа в оценке

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

Из приведенной выше таблицы понятно, что при оценке человеко-часов не все задачи легко решить. оценивать.Если разработчик, который оценивает, и разработчик, который завершает, — это два разных человека, тогда оценка может быть неверной. С другой стороны, независимо от того, кто оценивает задачу, сохраняйте пользовательскую историю, поскольку измерение даст точные результаты. Это потому, что ключом является завершение пользовательской истории, а не личность. Таким образом, уровень квалификации и опыт человека не имеют значения.

Что такое планирование покерной оценки — Советы по эффективному использованию плановой оценки?

Это метод оценки и метод дискретного масштабирования.Он разыгрывается с использованием карт, которые представлены в виде модифицированного ряда Фибоначчи.

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

Мы предлагаем вам разбить пользовательские истории для более эффективной оценки. Использовать «?» card и соберите информацию, прежде чем выбрать нужную карту.

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

Когда использовать?

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

Кто должен участвовать в планировании покера в схватке?

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

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

Планирование покера — это работает? Да, следуйте этим советам

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

1. Сделайте подробный обзор литературы по программному обеспечению перед оценкой.
2. Работает эффективно, оценивает грамотный коллектив.
3. Проведите живое обсуждение с командой, и оценщик должен привлечь своих коллег и подтвердить свои оценки. Это повысит точность элементов с неопределенностью.
4. Вся недостающая информация собирается для обоснования оценок.
5. Усредняйте каждую оценку, а затем планируйте оценку для достижения наилучших результатов.

Заказать Планирование Покерные карты?

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

Рисунок 1: Планирование покерных карт

• Это колода карт, и каждая колода содержит 4 набора карт, а именно: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100…. Как вы угадали, это ряд Фибоначчи с небольшими изменениями.

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

• Карта, которая является? подтвердит, что оценщик ничего не знает о задаче.

• Имеется чашка кофе, указывающая на необходимость сделать перерыв.

Теперь знайте, что эти карты для скрам-покера доступны онлайн на Amazon для продажи. Бренды включают карты Bee, Bicycle или World Poker Tour.

Как работает планирование покера — подробные инструкции

Это гибкое планирование покерной схватки.У каждого оценщика будет колода карт, и он начнет с упражнения.

Рис. 2. Этапы планирования игры в покер

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

1. Сначала модератор ознакомится с подробностями.Обычно это владелец продукта, и он делает это для каждой пользовательской истории / темы, требующей оценки.
2. Затем начинается обсуждение, и ЗП ответит на вопросы оценщика. Следует иметь в виду, что цель состоит не в том, чтобы сделать оценку, а в том, чтобы сделать оценку стоимости рентабельным способом.
3. Теперь оценщики будут индивидуально выбирать карточку на основе обсуждения, чтобы представить свою оценку. После того, как все участники сделают выбор, каждый одновременно перевернет карточку, чтобы показать свою оценку всем участникам. Не ожидайте, что они будут одинаковыми, они будут отличаться.
4. Очень разные оценки требуют объяснения со стороны оценщиков. При необходимости проводится переоценка. Этот процесс повторяется до тех пор, пока команда не придет к согласию с одной оценкой, которая будет реализована для конкретной пользовательской истории.

Заключение

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

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

Чтобы узнать больше о планировании и оценке, посетите тренинг StarAgile Certified Scrum Master, чтобы узнать о предстоящих расписаниях, пожалуйста, позвоните нам по телефону +91-80502 05233

Scrum Planning Poker Cards — приложение для iPhone и iPad

Scrum Planning Покерные карты Описание

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

Используя адаптированную последовательность Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 100) с дополнительными символами (?, Перерыв на кофе, без подсказки, слишком большой), члены команды могут взвесить сложность и усилия, затрачиваемые на разработку функциональности на сессиях планирования Scrum.