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

Каждый выбирает свою карту анонимно, перед тем как они все будут одновременно открыты. Это помогает командам честно обсудить, сколько работы требуется для выполнения выбранных задач или пользовательских историй. Затем следует обсуждение оценок каждого члена команды, чтобы команды смогли согласовать усилия, необходимые для завершения работы. В результате такой оценки команда покер планирование это участников приходит к общему видению способа реализации задачи и оценке ее сложности или объема работ. После второго тура команда выбирает среднее значение из полученного диапазона или останавливается на варианте, близком к пессимистичной оценке. Другими словами, это эффективный метод коллективного принятия решений в процессе разработки программного продукта.
В первую очередь при planning poker лучше оценивать общие усилия на задачу, а не только время. Как при использовании любой техники планирования, успех в покер планировании зависит от точности использования. В онлайн-сервисах итоги оценок подводятся автоматически. После голосования карты переворачивают лицевой стороной вверх. Команда видит оценки, и снова начинается обсуждение. Карты должны появляться именно рубашкой вверх — чтобы не повлиять на оценки других.
Карточки
Такой подход позволяет снизить влияние эмоций и авторитета отдельных исполнителей (участников команды) и повысить объективность планирования. Также каждую задачу надо оценить в числах по этим критериям по шкале от 1 до 10. Исходя из результатов, принимается решение о дальнейшей работе. Исходя из результатов игры можно делать выводы и решать, как работать над задачами дальше. В некоторых командах в покерном планировании участвуют все сотрудники, даже если у некоторых недостаточно экспертности в оцениваемой задаче. Независимо от того, сколько участников команды присутствует на встрече и какой продукт разрабатывается, совещания по покерному планированию обычно состоят из следующих шагов.
Но этап обсуждения в покер-планировании заканчивается голосованием с помощью карт. Собственно, с реальной карточной игрой покер-планирование никак не связано. Единственная общая черта – необходимость открытия карт и немного элементов «торговли». Правда «торговаться» нужно больше с собой, чем с другими участниками. Ну и «играть» при планировании часто приходится с неполной информацией о картах противников. Иными словами, получается некая модель «в тёмную», когда сначала делаются ставки на время реализации задачи, и только потом заслушиваются мотивированные части решений.

«Мы использовали Planning Poker на этой неделе и нашли метод очень полезным. Кстати, гораздо легче оценивать задачи, когда те сгруппированы по относительной сложности. Обсуждение продолжается до тех пор, пока команда не достигнет соглашения по оценке.
Это не так удобно, как работать со специальными картами, но допустимо, если заранее договориться о значениях. Соберите всю команду https://deveducation.com/ за одним столом и раздайте каждому по колоде карт. Неважно, реальная она или виртуальная, это всегда будут карточки с числами.
Planning Poker И Другие Методы Оценки
Главное, чтобы все участники договорились о значениях всех карт и правильно понимали их суть перед началом оценки. Команда договаривается, в каких единицах измерения будут делать оценки задач. При оценке элементов журнала продукта рекомендуется разбивать каждый элемент на задачи, каждая из которых может быть завершена за 1 день. Важно ограничить встречу по времени и строго следить за таймингом. Обычно на одну сессию выделяется 2—4 часа в зависимости от объема обсуждаемых задач, количества участников и уровня их вовлеченности. Подробнее о том, как грамотно планировать встречи с командой и делать их продуктивнее, можно узнать здесь.
- С помощью серий последовательных опросов, интервью, мозговых штурмов участники добиваются консенсуса для решения.
- Цифры обычно соответствуют дням или иным единицам, используемым для оценки сложности работы.
- Собственно, с реальной карточной игрой покер-планирование никак не связано.
- В оценке по методу Planning Poker участвует вся команда во главе с менеджером проектов — это одно из условий.
А Junior недооценил сложность задачи по неопытности. Вот как проходит оценка задачи по методу Planning Poker. Мы расскажем, что делать, когда команда находится в офисе и её можно привлечь к обсуждению. Командная оценка помогает получить объективный результат. Например, разработчик лучше знает, сколько времени реально занимает его работа, но может преувеличить её сложность, чтобы перестраховаться и получить больше времени. Поэтому процесс оценки всегда контролирует менеджер, он же ведущий.
Оценка Задач По Методу Planning Poker
Этот эффект подробно описан в книге психологов Амоса Тверского и Даниэля Канемана “Думай медленно, решай быстро”. В покере планирования обычно используются специальные карточки — карты для покера планирования. На них изображены числа Фибоначчи — 0, 1, 2, 3, 5, 8, 13, а также альтернативные оценки — 20, forty, 100. Когда известны все значения, озвучьте задачу для оценки, но не обсуждайте её, пока все не выберут подходящую, по их мнению, карту. Если, например, разработчик выскажет своё мнение о задаче до начала голосования, остальные уже не смогут быть объективны, потому что станут ориентироваться на его оценку. Каждая задача должна быть оценена одной картой от одного участника.
Если есть — то человеку, который поставил оценку, сильно отличающуюся от других, дают слово. Он объясняет, в чём для него сложность (или простота) задачи. Систематизировать знания и освоить методы Agile, Scrum и Kanban для управления рабочими процессами можно в Product Lab на курсе Agile Certified Professional. Метод покерного планирования можно легко реализовать в Kaiten.
Как И Зачем Мы Проводим Планирования
Открыть карты можно, только когда решения приняли все, то есть карты всей команды лежат на столе. Фасилитатор встречи ведет процесс, следит за ходом обсуждения, помогает командам найти консенсус в спорных ситуациях, следит за временем. У каждого участника команды есть своя колода карт для оценки. Для того чтобы процесс относительной оценки проходил проще, желательно на встрече поместить в поле зрения команды набор эталонных задач (флипчарт, whiteboard и др.). Planning poker (перевод с англ. — Покер планирования) — техника командной оценки задач в относительных единицах.
Онлайн-курсы
Когда команда состоит из трех человек, достичь единого мнения может быть легко, но когда в ней участвуют 10, 20 или даже больше сотрудников, мнения часто расходятся. Именно для таких случаев было создано покер планирование. Planning Poker (покер планирования) — техника оценки задач для гибких команд. Проводится с помощью карт и напоминает игру в покер. Однако подход будет более эффективным, если в оценке каждой задачи будут принимать участие только те участники команды, кто потенциально может выполнить задачу.
Scrum, Материалы Для Изучения, Фотографии Флипчартов, Презентации И Методы Развития Команд
Метод обсуждения задач по модели Planning Poker впервые предложил Джеймс Греннинг, который является одним из создателей манифеста Agile. Чуть позже подход популяризировал Майк Кон в своей книге Agile Estimating and Planning (год выхода – 2005). Ни одна командная техника не работает без грамотного руководителя. Поэтому менеджер проекта должен уметь взаимодействовать с командой так, чтобы добиваться нужного результата. Это значит, что QA ошибся или у него есть сведения, которых нет у остальных.
Как Провести Встречу По Покер Планированию С Удаленной Командой
Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning». Голосовать должны только те люди, которые имеют представление и понимают контекст задачи. В то же время, люди с практически нулевым знанием задачи или проекта не могут дать полезную оценку, или могут затянуть фазу обсуждения своими вопросами. Предполагая, что вы заранее выбрали, какие задачи будете оценивать, вы готовы начать играть в покер планирование со своей командой!
Это может быть опасным и приводить к оценкам, на которые повлияли планы или личные мнения людей, не сфокусированных на качественном выполнении задачи. После чего каждый участник команды молча сравнивает сложность представленной задачи со сложностью эталонных задач. Выбирает из колоды карт значение, которое максимально близко, с его точки зрения, соотносится со сложностью задачи, и выкидывает соответствующую карту рубашкой вверх.
Так, если разработчик желает выбрать 6, но он не до конца уверен, он выберет 5, либо может предусмотрительно выбрать eight. Аргумент в пользу использования последовательности Фибоначчи — отражение возрастающей неопределённости с ростом сложности оцениваемых функций или задач. Она обычно используется в гибкой методологии разработки, в частности, в методологии экстремального программирования.
Бесплатная базовая версия подходит для команд до пяти человек. Платные тарифы позволяют интегрироваться с Jira и добавлять неограниченное количество пользователей. Если вы не любите оценивать задачи на глаз, а хотите точных результатов — поиграйте в Planning Poker.
Карта с цифрой 2 — это 2 идеальных часа или 2 Story Point’а и т. Для офлайн-встречи необходимо заранее подготовить колоду карт — это могут быть специальные карты для покерного планирования или обычная колода карт. Покер планирования (Planning Poker) — это техника оценки задач, основанная на методе Wideband Delphi, который начали использовать в 1970-х годах. В 2002 году этот метод был адаптирован для Agile-команд Джеймсом Гренингом, одним из участников разработки Agile-манифеста.