Если спросить у обычного человека о покере, то первым ответом будет карточная игра, при которой ценится умение просчитывать ситуацию наперед, концентрироваться и убедительно блефовать. Но на самом деле, покер можно использовать и в офисе, например, в компании по разработке и тестированию программного обеспечения.
Понятие покера планирования
Покер планирования (англ. planning poker, scrum poker) – это специальная техника, при которой проводится коллегиальный анализ с последующим решением задачи, возникающей в процессе разработки и проверки ПО.
В данном процессе могут быть задействованы любые специалисты: программисты, отдел тестирования, технические инженеры, менеджеры по проектам, системные администраторы, дизайнеры и другие, кто так или иначе задействован на проекте.
Так как в этом процессе участвуют разные члены проектной команды, подобный подход позволяет достичь действительно разносторонней независимой оценки при решении сложных технических и практических задач.
К слову, впервые подобный подход был детально описан в известном Agile-манифесте Джеймса Греннинга. Собственно, название «покер планирования» получил от Майка Кона, который в 2005 году на бесплатной основе разрешил использовать наименование своей торговой марки.
Идеи покера планирования
Цель покера планирования не просто установить конечный срок завершения задачи, но и убедится в том, что каждый участник процесса создания ПО понимает используемые при этом алгоритмы и решения.
На сегодняшний день множество глобальных компаний и концернов уже приняли на вооружение подобный метод. Среди множества можно выделить наиболее узнаваемых:
- Coca-Cola;
- General Electric;
- KIA.
Базовые правила покера планирования
Итак, весь этот покер происходит во время собрания перед началом работы над проектом или при внедрении нового функционала в ранее разработанный продукт.
Каждый участник получает специальную колоду карт. Есть 2 наиболее популярные колоды карт.
Первый вид
Карты на основе специализированной оценочной шкалы, автором которой является Майкл Кон. К слову, за основу такой колоды берется видоизмененный ряд чисел Фибоначчи (числа — 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 + карта с вопросительным знаком + карта с картинкой кофе + карта со знаком бесконечности).
Kарты для игры в покер планирования
Значение (расшифровка карт)
| 0 | Обозначает задачу, которая уже выполнена или очень легкая, а значит ей нет места в общем плане работ |
| 1-3 | Маленькие задачи |
| 5-13 | Средние по важности задачи |
| 21-55 | Большие и сложные задачи |
| 89 | Глобальные задачи |
| Знак бесконечности | Обозначает настолько крупную задачу, что ей нет смысла даже присваивать определенное число |
| ? | Позволяет получить дополнительные расшифровки у владельца продукта. Некоторые участники могут использовать эту карту для отказа от оценки текущего спринта (но не от участия в оценивании или же обсуждении). |
| Карта с картинкой кофе | Обозначает необходимость, по мнению члена проектной команды, выполнить перерыв на чашечку кофе или чая |
Второй вид
Карты, основаны на ряде чисел в степени 2: 0, ½, 1, 2, 4, 8, 16, 32, 64, 128, «?», «чашка кофе», знак бесконечности.
Роли
Итак, скрам-мастер (англ. scrum master) выступает в должности ведущего, постоянно следит за соблюдением правил, разрешает противоречия и защищает игроков от потенциально отвлекающих факторов. Сам он не берет участие в игре, а всего лишь документирует итоги состоявшихся дискуссий.
Владелец продукта (англ. product owner) представляет требования и желания клиента, а также прочие пользовательские сценарии. Во время собрания он читает участникам проекта все требования к будущему продукту. Помимо этого, владелец берёт на себя миссию представления интересов конечных потребителей создаваемого продукта.
Если владельца продукта нет, то требования может читать скрам-мастер либо же менеджер данного проекта.
Процесс игры
Перед началом игры проектная команда должна определить числовые обозначения своих карт. Это могут быть как часы, дни, или относительные величины сложности выполнения поставленных задач.
Если есть необходимость, ведущий может использовать таймер. Подобная практика позволяет команде не затягивать время на обсуждение и обеспечивает качественный мозговой штурм.
В начале игры ведущий объявляет рассматриваемую задачу (или несколько сразу). Участники игры обсуждают ее содержание и при необходимости уточняют вопросы у владельца продукта, который отвечает за ПО.
После этого каждый участник тайно выбирает себе карту, которая соответствует его оценке и кладет карту рубашкой наверх.
Как только все участники игры определятся со своими оценками – игроки показывают карты, которые демонстрируют их текущие оценки.
Процесс игры в покер планирования
Основные обозначения итогов игры
- Если вдруг оценки задачи одинаковые, значит, компромисс достигнут и согласованное число интерпретируется как оценка обсуждаемой задачи.
- Если есть очень большая разница между выставленными оценками, то ведущий должен выбрать тех участников, которые поставили самые минимальные и максимальные оценки.
Эти участники выступают перед остальными, детализировано аргументировав свой выбор. - Члены группы приступают к обсуждению, чтобы развеять все сомнения и высказать определенные предложения и наработки.
- После завершения обсуждения проводится еще 1 раунд оценки. Процедура длится до тех пор, пока команда не достигнет общего (положительного) знаменателя.
Пример проведения покера планирования
Допустим, руководитель кладет перед участниками процесса разработки и тестирования ПО колоду карт с цифрами. На обсуждение выносится вопрос касательно временных затрат на создание мобильного дизайна веб-сайта.
Все участники митинга начинают думать, затем по очереди достают карты с цифрами и кладут рубашкой наверх. Таким образом, никто не может сбить с толку того, кто еще не определился с выбором.
Итак, первые из всех участников дали оценку 5 и 8. Они должны обсудить насущный вопрос с тем, кто достал и выбрал себе карту с цифрой 20.
Последний участник вообще не вникал в суть проблемы и выбрал себе карту со знаком вопроса.
После короткого обсуждения, третий участник группы вспомнил, что не до конца учел некоторые моменты и хочет кардинальным образом пересмотреть принятое ранее решение.
Четвертый член команды полностью разобрался в вопросе и готов активно участвовать в общем обсуждении. Карты выкладываются заново.
Каждый участник группы показывает свои карты. На них значения: две по 8, одна карта с цифрой 10 и одна с цифрой 12.
Как итог, решение принято и можно переходить к обсуждению следующего вопроса. И так пока все актуальные вопросы не будут полноценно и достаточно рассмотрены.
Распространенные проблемы использования данного подхода
- Наиболее актуальной проблемой можно считать так называемый эффект привязки. Базовой ошибкой, которая вызывает данную ситуацию, является открытое обсуждение оценок, выставленных участниками.
К примеру, человек, который начинает собрание, высказывается примерно так: «По моему мнению, создание и тестирование данного функционала займет до 20 часов». Это вызовет диссонанс мнений.
Тот, кто думал, что задача решится за 3 дня будет верить, что и 20 часов хватит. А тот, кто рассчитывал потратить 5 часов, подумает, что он просто недооценил будущий функционал. - Вторая проблема заключается в том, что могут возникать ситуации, при которых оценки выставляются не одновременно. В данном случае кто-то сможет высказать свое мнение, а кто-то просто бросит карту с цифрой ближе к тем, что лежат в общей сумме.
Например, снова кто-то думает о том, что задача решается за 20 часов, но трое до него кинули карты по 6 часов каждый. Логично предположить, что такой человек, скорее всего, подумает, что оценил время разработки неверно. Он не захочет выделяться на общем фоне и банально сменит свое изначальное мнение и решение.
Когда стоит использовать метод покера планирования?
Подобные сценарии решения задач технического и практического характера стоит использовать в следующих случаях:
- При работе на малых и средних проектах (когда в процесс разработки и тестирования программного обеспечения вовлечено не более чем 10 человек);
- На проектах, которые отличаются гибкой методологией разработки;
- Для проектных групп, внутри которых постоянно поддерживается очень высокий уровень коммуникации и вовлеченности участников процесса разработки/тестирования ПО;
- Для компаний, которые могут тратить достаточно времени на полное разрешение возникающих задач.
В завершение
Итак, базовое преимущество применения покера планирования – абсолютная интерактивность данной методики, а также ее очевидная способность сплотить всех участников процесса разработки над разрешением поставленной задачи. Таким образом, внутри определенной компании по тестирования ПО решение принимается не единолично, а коллегиально.
Обязательным атрибутом качественной организации покер планирования считается применение оценочных суждений. Это позволяет команде тестировщиков и разработчиков учитывать достижения и ошибки, совершаемые в прошлом.
В конечном итоге, клиенты получают корректные оценки по времени и бюджету на выполнение проекта. Это обеспечивается тем, что выводы формируются всеми профильными специалистами, участвующими в процессе создания и тестирования веб-продукта.
Оставить комментарий