5 советов и хитростей при планировании покера, о которых вы, вероятно, никогда не слышали

Рейтинг: 4.6 из 5
Автор
Вадим Соколов
Рейтинг автора
4.6

Planning Poker, который обычно считается стандартным инструментом для проведения оценки Agile-проектов, - это инструмент, который часто неправильно понимают и неправильно используют. За годы коучинга Agile-команд я видел, как команды справлялись с этим процессом по-разному, некоторые из которых не могли правильно применить инструмент, не зная об этом. Я лично наблюдал за многими вариациями процесса Planning Poker, как эффективными, так и неэффективными. Я поделюсь с вами некоторыми из них, чтобы помочь вам повысить эффективность процесса оценки для ваших Agile-команд.

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

Задача № 1 - установить приблизительный объем работ, который позволит измерить скорость работы команды, что позволит делать прогнозы (например, планирование выпуска).

Задача № 2 - Содействовать обсуждению объема работ, необходимых для соответствия критериям приемки для элементов невыполненных работ по продукту.

Совет №1 - Не конвертируйте рабочие часы в очки истории.

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

Совет № 2 - Избегайте группового мышления, будучи дисциплинированным в процессе оценки.

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

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

Совет № 3 - Избегайте чрезмерной настройки карт планирования покера.

Некоторые команды, с которыми я работал, имеют тенденцию настраивать покерные карты, используемые для Planning Poker, то есть выбирать определенные карты, которые, по их мнению, имеют смысл использовать в конкретном спринте. Я рекомендую вам выбрать ряд Фибоначчи (1, 2, 3, 5, 8, 13, 21) или модифицированный Фибоначчи (1, 2, 3, 5, 8, 13, 20) и придерживаться его. НЕ меняйте серию, если нет веской причины, чтобы проконсультироваться с Agile Coach. Некоторые команды добавляют "?" карточка, чтобы позволить членам команды повысить потребность в получении дополнительной информации. Я предлагаю использовать эту карту с осторожностью из-за возможного неправильного использования.

Неправильное использование карт может стать большой проблемой для команды, если будет продолжаться. Некоторые команды имеют тенденцию неправильно использовать "?" карта при чрезмерном использовании этой карты; это может привести к длительному и ненужному обсуждению деталей пользовательской истории, что может снизить эффективность команды и замедлить процесс. Некоторые команды используют только от 1 до 13, причем 13 - это максимальный размер истории, которая может уместиться в одном спринте. Хотя это может показаться эффективным способом обеспечить целесообразное голосование, это может привести к неточным оценкам из-за отсутствия способа указать, что история слишком велика, чтобы ее можно было выполнить за один спринт! Команда может выбрать 13, даже если Сюжет слишком велик, просто потому, что другого варианта нет. На первый взгляд это может показаться тривиальным, но со временемэто часто приводит к неполным историям и потраченным впустую усилиям, в результате чего незавершенная работа переносится на следующий спринт.

Совет №4 - Убедитесь, что в процессе планирования покера участвуют нужные люди.

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

Совет № 5 - Избегайте сползания значения точки из-за калибровки

Когда Agile-команда проработала вместе несколько спринтов и достигла видимого успеха, некоторым командам рекомендуется «производить больше работы», что является антипаттерном, выходящим за рамки данной статьи. Здесь важно отметить, что даже самые лучшие и опытные Agile-команды могут столкнуться с явлением, известным как «сползание балльной ценности», при котором оценки пользовательских историй со временем постепенно увеличиваются. Например, пользовательская история, которая раньше состояла из пяти пунктов, по какой-то причине постепенно превратилась в восьмерку. Это может происходить естественным образом и загадочно и, как правило, приводит к восприятию, что команда делает больше работы и / или со временем приносит больше пользы; Хотя это может показаться положительным моментом, существует риск завышенных ожиданий, что приведет к усилению давления со стороны руководства, что является порочным кругом.

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

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

Новости спорта

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

Больше новостей