Какова цель планирования покера в спринте?

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

Они попросили всех нас рассмотреть «Сложность», а не «Усилие». Мы действительно растеряны и тратим время на наши встречи. Один разработчик задал вопрос: «Что нам действительно нужно рассмотреть? Речь идет об изменении кода / DDL, которое мы должны выполнить в этом требовании (оценка времени), или о том, поняли ли мы это требование или нет?

Но что они (бизнес-аналитики и руководители проектов) на самом деле подразумевают под «пониманием требований» и «поднять карту»?

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

Кто-нибудь может объяснить это на примере? Попытайтесь разграничить то, о чем они действительно говорят, когда говорят «Сложность» и «Усилие».

Рассмотрим точку зрения руководителя проекта

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

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

Обсуждение важнее, чем число

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

Сложность против усилий

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

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

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

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

Причины, по которым вы не можете дать оценку

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

1. История слишком большая. Разбейте его на более мелкие, более конкретные пользовательские истории. Помните, что каждая пользовательская история должна предоставлять пользователю одну ценность; вход - процесс - выход = значение.
2. Они недостаточно хорошо разбираются в проблемной области, чтобы сказать, сколько времени им потребуется, или даже правильно задать все вопросы. Поговорите с людьми, которые знают больше о предметной области / программировании заинтересованных сторон, такого рода приложения, чего бы вы не видели раньше. Если это невозможно или не поможет вам, вы можете использовать всплеск дизайна. Пойдите и прототипируйте решение, но только в течение ограниченного и определенного промежутка времени. Определите, как долго будет продолжаться фаза прототипирования, не слишком долго, а затем снова встретитесь, чтобы поделиться своим новым пониманием.
3. Ваши заинтересованные стороны недостаточно конкретны. «Построй мне облако» - неприемлемая пользовательская история. «Создайте мне систему, в которой я могу раскручивать виртуальные машины по требованию» лучше, поскольку она разбита дальше, но все еще не на том уровне, на котором вы можете дать точную оценку того, сколько времени вам понадобится, поскольку будет сотня скрытых Предположения в этом заявлении, которые есть у вашей заинтересованной стороны, вы не узнаете, пока не покажете им что-нибудь.
4. Наконец, даже если вы можете дать оценку, это может быть неправильно с первого раза. Оценка - сложная проблема, и лучший способ решить сложные проблемы - это использовать научный метод. Соберите данные о том, какие числа оценивает каждый член команды, затем соберите данные о том, сколько времени они действительно потребовали, или насколько «сложными» они были на самом деле, хотя это сложнее, и затем сравните их с течением времени. В конце концов вы почувствуете, кто переоценивает, а кто недооценивает, и тогда вы должны поделиться этим с командой. Люди могут помочь друг другу стать лучше в оценке. Эти цифры также могут быть возвращены в ваш инструмент отслеживания, чтобы помочь лучше предсказать, сколько времени займет история.

Вывод

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

Предупреждение

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

В сторону

Набор чисел в покере для планирования обычно распределяется таким образом, что промежутки между числами продолжают увеличиваться. Я считаю, что это должно отговорить людей от споров о том, является ли пользовательская история 16 или 17, если она больше 13, тогда просто сделайте ее 20.

пример

Я знаю по крайней мере одну команду, которая использует только цифры 1, 2, 3 и 4 для планирования покера. Они, вопреки соглашению и вопреки обсуждению выше, определяют их как дни программирования (фактически пара дней программирования, то есть, сколько дней потребуется двум программистам, работающим вместе на одной машине, чтобы завершить пользовательскую историю). Если команда считает, что для создания пользовательской истории потребуется более 4 дней, то она не указывается, а владельца продукта просят работать с командой, чтобы подробнее рассказать историю или указать ее более точно, чтобы она могла быть приведенным в этот диапазон для будущего совещания по планированию. Но это продвинутая гибкость и, вероятно, должны использоваться только людьми, которые уже имеют опыт использования других методов.

Я думаю, что ответы Фрэнка и Энсайты в значительной степени покрывают это, но есть некоторые дополнительные вещи, чтобы рассмотреть:

Зачем использовать сюжетные очки

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

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

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

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

Затем вы, как команда, соглашаетесь, что для этого спринта вы будете стремиться выполнить историю из 13 пунктов, одну историю из 8 пунктов плюс изменение URL-адреса из 1 пункта, которое вы уже определили. Итак, всего 22 балла. На следующий спринт вы получите 27 очков, на следующий спринт вы получите 18 очков. После 3 спринтов вы можете начать чувствовать себя увереннее в скорости (скорость - это объем работы, которую ваша команда может выполнить за один спринт). Чтобы получить скорость, возьмите среднее значение предыдущих спринтов. Таким образом, в этом примере среднее значение (22 + 27 + 18) / 3 = 22,3, поэтому округлите его до ближайшего по шкале Фибо, равной 21.

Теперь для следующего спринта просто стремитесь получить 21 очко.

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

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

Оценка всей команды

Вся команда должна согласовать единую оценку для каждой истории. Функция не выполнена, пока она не готова к производству. Просто получить написанный код ни в коем случае не сделано. По моему опыту, команды Scrum были намного эффективнее, когда работали в команде. Возьмите пример команды, с которой я сейчас работаю. Когда я присоединился, они делали все встречи по спринту и планировали покер, но во время спринта процесс был 1. БА / Владельцы продукта определяют требования как истории с критериями приемки и приемочными тестами 2. Они передают эти требования разработчику, который затем пишет код 3. Разработчик объединил код в ветку разработки для тестирования 4. Для тестирования QA затем начинают задавать вопросы, и тесты не проходят, и он возвращается в разработку.

Чего здесь не хватает? Там не достаточно обсуждения заранее, и каждый член команды видел только свою задачу. Теперь BA / PO, разработчики и QA собираются вместе перед написанием любого кода, чтобы подробно обсудить требования и задать вопросы, а затем продолжить обсуждение на протяжении всего спринта. Это намного более эффективно и приводит к лучшим качественным решениям.

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

По времени оценка задач

Мой взгляд на то, что я работал с командами, которые оценивают время на заданиях, и командами, которые оценивают только сюжетные моменты, - это НЕ ОЦЕНКА ВРЕМЕНИ! Они на самом деле просто пустая трата времени. Они не так точны, как сюжетные пункты, потому что они специфичны для людей, а не для команды, и у каждого человека будет свое представление об оценке времени (вызвать пламя).

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

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

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

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

Оценка не самая большая проблема

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

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

Зачем планировать покер?

Прежде всего, вы все должны знать, почему вы занимаетесь планированием покера, а не «нормальной» оценкой. Причина на самом деле довольно проста: мы все тратим время, когда дело доходит до оценки времени для выполнения задачи. Практически каждое исследование показало, что человеческий мозг просто неспособен оценить задачу, которая занимает достаточно много времени. (Также причина того, почему билеты, стоимость которых превышает 2-3 дня в оценке, практически бесполезны с точки зрения оценки.)

Почему сложность, а не усилие?

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

Зачем прятать карты?

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

Почему числа Фибоначчи?

Числа на ваших картах - это, как правило, числа Фибоначчи или какой-то другой вид последовательности с большим количеством пробелов в числах. Это для того, чтобы заставить вас полностью доверять своим внутренним чувствам. Если вам нужно выбрать между 8 и 13, это гораздо больше, чем утверждение для 9 или 10. Кроме того, как уже упоминалось выше, большие различия заключаются в том, где скрытые проблемы, поэтому, увеличивая пробелы, вы увеличиваете вероятность обнаружить эти проблемы лучше.

Почему это работает вообще?

Интересно, что первые несколько раз, когда вы играете в покер для планирования, это не сработает. Это так просто. Что означает «3» или «5»? Не существует определения того, что означает каждое число (специально!), И вся ваша команда должна выяснить фактическое значение каждого из этих чисел. Только после того, как вы согласились оценивать свои истории в этих числах - и после того, как вы поняли некоторые из них - вы получите лучшее представление о том, когда вы должны поднять 5, а когда это скорее 8.

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

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

пример

Простой пример того, что обычно происходит, - это представление истории, а затем человек А выдвигает возражение. Это что-то вроде «пожалуйста, не забывайте, что эта функция влияет на X, и это может означать, что это дороже, чем мы думали до сих пор». Основная проблема в том, что за столом всегда присутствует этот человек. Всегда есть что-то, о ком кто-то беспокоится. Если у вас есть открытое предварительное обсуждение, вы на самом деле понятия не имеете, насколько серьезным является беспокойство об этой вещи X.

Если вы делаете скрытые оценки, основанные на времени, то это становится немного лучше. Но все же, человек А с действительным возражением, возможно, еще не является явным выбросом в ее оценке. С другой стороны, при планировании покера человек А должен больше думать о том, насколько серьезна проблема Х. Для двух разных проблем вы не можете должным образом различить их важность с помощью приведенного выше «устного текста возражения». Даже с оценками времени довольно трудно понять, что является более серьезной проблемой. Надежда с помощью планирования покер является то , что вы в конечном итоге с одним возражением является всего лишь 2-3 балла отличаются от оценок чужих, но другие возражения , которые в конечном итоге 5 или 8 очков от медианы может быть просто наиболее важная неопределенность вашего планирования спринта.

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

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

Это совпадает с точкой зрения, высказанной Майком Коном здесь .

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

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

В результате это «не основано на времени», то есть «основано на времени». Неудивительно, что все запутались.

Есть способы сделать эту работу для вас. Во-первых, забудьте об усилиях и сосредоточьтесь на сложности. Забудьте все о том, сколько времени может потребоваться для развития и сосредоточиться вместо этого на областях, на которые влияет каждая история. Если у вас есть история, которая обновляет БД, код сервера, код клиента и документацию клиента, то вы можете сказать, что это история из 4 пунктов. Если это только изменение базы данных sql, то это история из 1 пункта. Это дает вам более понятный способ выяснить относительную сложность между историями. (Вам придется придумать некоторые показатели, которые имеют смысл для ваших обстоятельств, например, проверить требования к покрытию или сложность пользовательского интерфейса)

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

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