Хотя название напоминает популярную карточную игру, планировочный покер — это метод оценки в Agile. Agile-команды используют планировочный покер, чтобы оценить объём работы, необходимый для завершения пользовательской истории. Узнайте больше о процессе планировочного покера и о том, как эта техника может помочь вашей Agile-команде создавать более точные оценки.
Представьте, что вы купили дом и планируете переделать кухню. Вы просите подрядчика оценить, сколько времени займёт ремонт и сколько он будет стоить. Он даёт вам оценку, но два месяца спустя вы сожалеете о своём решении, потому что проект вышел далеко за рамки первоначального графика и бюджета.
Когда вы полагаетесь на мнение только одного человека, вы учитываете только его вклад и опыт. Однако, когда вы привлекаете больше людей с разным опытом, вы получаете более полную и точную оценку того, какую работу необходимо выполнить.
Такая оценка на основе консенсуса лежит в основе Agile-метода планирования покера.
Планировочный покер — метод оценки, который помогает вашей Agile-команде спрогнозировать объем усилий, необходимых для завершения одной пользовательской истории в продуктовом бэклоге. Этот метод часто используется в Agile-методологиях управления проектами и иногда называется «Scrum-покером» или «покером с указанием». Слово «покер» в названии относится к картам, которые каждый участник команды использует в процессе.
Бесплатный шаблон для планирования спринтовПланировочный покер основан на методике, известной как широкополосный Дельфийский метод. Широкополосный Дельфи — это основанный на консенсусе процесс оценки, разработанный в середине XX века некоммерческим аналитическим центром RAND Corporation.
Джеймс Греннинг, автор книги «Манифест гибкой разработки программного обеспечения», усовершенствовал метод широкополосного Дельфи в 2002 году и переименовал его в Planning Poker. Затем он был доработан и популяризирован Майком Коном в его книге 2005 года «Agile Estimating and Planning».
Процесс планировочного покера происходит на ранней стадии планирования спринта, поэтому Scrum-мастера и менеджеры по продукту могут получить точное представление о том, сколько работы может быть завершенный в каждом спринте. Вот как это работает:
У каждого участника Scrum- или Agile-команды есть презентация с карточками с разными значениями. Каждая карта имеет одно из следующих значений: 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Эти числа могут показаться случайными, но на самом деле они представляют собой округлённые значения последовательности Фибоначчи. Эти значения чаще всего представляют собой стори поинты. Однако некоторые команды могут использовать их для оценки времени, необходимого для завершения пользовательской истории. Чаще всего оценка по времени измеряется в часах.
Владелец продукта или мастер Scrum выступает в роли модератора и зачитывает конкретную пользовательскую историю из бэклога продукта или спринта. Затем участники команды могут задавать вопросы и уточнять детали, чтобы все получили точное представление о том, какую работу нужно выполнить для этого конкретного элемента бэклога.
Вот несколько вопросов, которые команда может задать, чтобы лучше понять пользовательскую историю:
Какие методы мы можем использовать, чтобы завершить эту историю?
Сколько человек должны работать над этой историей?
Как отреагируют заинтересованные стороны, если возникнут задержки с этой историей?
После того как команда завершит обсуждение одной пользовательской истории, каждый оценщик выбирает карточку, соответствующую объёму трудозатрат или баллов, которые, по его мнению, соответствуют этому элементу бэклога. Затем все одновременно открывают свои карточки. Если все выберут одинаковую оценку, она становится официальной оценкой для этого элемента бэклога. Цель состоит в том, чтобы все пришли к единому мнению.
Если у участников команды разные мнения о первоначальных оценках, участник команды с самой высокой оценкой и участник команды с самой низкой оценкой обсуждают, почему они выбрали именно это число. После завершения обсуждения все участники снова выбирают карточки. Этот процесс повторяется до тех пор, пока команда не придет к консенсусу.
Теперь, когда все элементы в бэклоге оценены, гораздо проще точно спланировать спринт. Поскольку вся команда пришла к единому мнению о том, сколько времени займёт каждая задача, гораздо более вероятно, что вы сможете правильно спланировать объём работы в спринтах.
Бесплатный шаблон для планирования спринтовПланирование покера обычно происходит непосредственно перед процессом планирования спринта, поэтому менеджер по продукту или мастер Scrum может получить точное представление о работе перед планированием спринта. Вы можете использовать этот метод оценки один раз за спринт. Поскольку элементы постоянно добавляются в бэклог продукта или спринта, у вас должен быть постоянный запас элементов бэклога, которые можно использовать в каждом спринте.
Если в вашем продуктовом бэклоге есть только небольшое количество пользовательских историй, которые нужно обсудить, вы можете объединить эту сессию с ежедневным стэндапом, поскольку все участники команды уже присутствуют.
Главное преимущество планировочного покера заключается в том, что ваша команда получает более точные оценки. Точная оценка — важная часть процесса планирования спринта, поскольку она дает как команде, так и заинтересованным сторонам реалистичный график выполнения задачи.
Вот ещё несколько способов, которыми планировочный покер в интересах вашей команды Agile:
Каждый участник команды имеет право голоса. Каждый участник команды разработчиков важен, и этот процесс дает им возможность заявить о своем вкладе. Это помогает сотрудникам оставаться вовлечёнными в работу.
У команды есть возможность обсуждать пользовательские истории. В процессе планировочного покера команда разработчиков может совместно обсудить пользовательские истории до начала фактической работы. Это помогает всем участникам согласовать подход к определённым пользовательским историям, независимо от того, кто из разработчиков назначен на эту историю.
Оценки задач привязаны к другим задачам. Когда ваша команда использует баллы историй для представления числа на своей карте планирования, то легче понять, сколько усилий потребуется для конкретного задания на основе других задач в конвейере. Например, пользовательская история с оценкой 2 будет намного проще завершенной, чем пользовательская история с оценкой 40.
Держите свою Agile-команду в курсе событий с помощью инструмента для управления работой. Asana помогает планировать и организовывать проекты по Agile в инструменте, который является гибким и действенным. Независимо от того, работает ли ваша команда с канбан-досочкой или с более линейной хронологией, в Asana есть функции, которые помогут вашей Agile-команде быстро выполнять задачи.
Бесплатный шаблон для планирования спринтов