Если я правильно понимаю Scrum, вот как я определяю работу, которую моя команда может выполнить в следующем спринте:
Я усредняю количество набранных очков за последние несколько спринтов.
Эта величина является нашей средней скоростью. Следующий спринт, мы берем столько историй.
Это среднее значение , поэтому, если история повторяется, в этом спринте вероятность того, что мы набираем слишком мало историй, составляет 50%, а вероятность того, что мы набираем слишком много историй, составляет 50%.
В 50% случаев мы взяли на себя слишком много историй, которые мы могли бы:
Не в состоянии завершить спринт. Это означает, что мы не сможем выполнить наше обязательство в спринте половину времени.
Работать дополнительно, чтобы наверстать упущенное. Проблема в том, что это только один способ. Мы выполним спринт, и количество пройденных сюжетных пунктов будет отражать это. Поскольку мы всегда заканчиваем, со временем наше среднее значение будет расти вверх до точки, где мы всегда выполняем большое количество сюжетных моментов и остаемся с опозданием.
Верно ли мое понимание обязательств по средней скорости и спринту?
Если так, что мы должны сделать для 50% спринтов, где мы отстаем от среднего?
Если нет, то что я ошибся?
источник
Ответы:
Да, у вас есть суть этого.
То, что вы упустили из виду, это то, что сюжетные моменты - это то, что вы делаете . Почти невозможно, чтобы все работали над историями вплоть до конца спринта. Если вы все делаете правильно, большинство ваших разработчиков будут «бездействовать» в течение нескольких дней, пока тестируются истории (и ваши тестеры находятся в середине спринта, так как разработка идет полным ходом).
Я бездействую в кавычках, потому что ваши разработчики не сидят без дела, наблюдая за кошачьими видео, они исправляют ошибки, исправляют некоторые кодовые / модульные тесты, добавляют некоторую документацию вокруг процессов, думают о дизайне для историй в отставании или одном из другие десятки полезных вещей, от которых команда разработчиков может извлечь пользу, но не вписывается в историю.
Таким образом, хотя вы будете переоценивать 50% времени и недооценивать 50% времени, это не значит, что вы потерпите неудачу в спринте или будете работать сверхурочно . Это означает, что у вас не будет достаточно времени для выполнения этой разной работы (если вы действительно не пропустите свои оценки). Но это не имеет большого значения, так как разные работы не чувствительны ко времени, и в конечном итоге все выровняется.
источник
К сожалению, вы были дезинформированы о нескольких вещах, касающихся планирования спринтов в Scrum. Во-первых, команда разработчиков (DT)
Слово для этого самоорганизуется. Это включает в себя работу по прогнозированию работы, которая будет выполнена в данном спринте. DT не говорят, что он будет работать на каждом спринте, он скорее уполномочен выбирать свою собственную работу. DT может потребоваться такая информация, как историческая скорость, хорошо продуманное отставание по продукту и способность DT следующего Sprint для создания прогноза. В конечном счете, именно определение DT о том, что может и не может быть достигнуто в спринте, должно преобладать в их прогнозе; им не следует говорить, сколько работы они будут делать.
Обратите внимание, прогноз, а не обязательства. C-слово было удалено из Scrum Guide, потому что оно использовалось для злоупотребления командой разработчиков. Прогноз является предпочтительным термином.
Что касается вероятности пропуска прогноза Спринта на низком или высоком уровне, я не считаю это важным. В какой-то момент, больше анализа не дает большей точности, и я думаю, что мы сейчас зашли.
Кроме того, Спринт может быть только «Отменен»; это никогда не может потерпеть неудачу. Спринт отменяется только тогда, когда цель спринта становится полностью устаревшей и неактуальной. Это очень редко бывает. Если прогноз неверен, вы просто сохраняйте спокойствие и продолжайте Scrum. У тебя есть ретроспектива? В следующем спринте ваши прогнозы будут лучше :).
источник
Во-первых, ваша скорость зависит от вашего предыдущего спринта или иногда от среднего значения нескольких последних спринтов (вчерашняя погода), а не от всех предыдущих спринтов. Конечно, если у вас нет исторических данных от вашей команды или компании, вам нужно найти разумное значение для вашего первого спринта. На втором спринте вы набираете набранные очки истории в спринте. Если вы нарисуете график, вы можете увидеть изменения по первым нескольким спринтам (например, 17 в первом спринте, 22 во втором, 26 в третьем, 24 в четвертом). Этого следует ожидать, когда вы нормализуете свою командную работу и процесс оценки, а также получите лучшее понимание проекта (технологии, предметной области).
Это не значит, что вы не приспосабливаетесь. Например, если у вас есть неделя, которая является выходной, обязательно учитывайте выходной, когда работа закрыта. Если вы знаете, что члены команды берут отпуск, планируйте, чтобы меньше людей работало. Конечно, незапланированные события тоже случаются, но вы можете объяснить их в ретроспективе спринта и решить, как это повлияет на количество сюжетных очков, которые вы принесете в следующий спринт.
Что касается того, что делать, «не завершить спринт» отличается от «мы не завершили все истории». Для меня провал спринта означает, что в конце вы не произвели потенциально отгружаемый продукт - ни одна из ваших историй не завершена, у вас нет сборки, вы не можете продемонстрировать какую-либо дополнительную ценность для клиента или пользователи.
Что бы вы ни делали, вы не должны работать поздно или чрезмерно со временем. Это называется устойчивым темпом ( Agile Alliance , Scrum Alliance ).
Индикаторы, которые могут быть проблемы, если:
источник
Гибкая методология варьируется от компании к компании, в одной реализации она может значительно отличаться от другой. Я работал в Agile с двумя компаниями. В первой компании, в которой я был, они относились к своим показателям довольно серьезно, а во второй - совсем нет. Так что из всего, что вы знаете, никто не обращает внимания на ваши показатели.
Все это говорит о том, что вы обеспокоены тем, что не достигли своих целей в спринте или что происходит, когда у вас неточная оценка. Я думаю, что этот тип беспокойства и перспективы распространен, но это не особенно важно. Agile, прежде всего, система разработки программного обеспечения, которая делает несколько вещей:
В конце концов, если вы неправильно оценили спринт или провалили спринт, это не так уж важно. Люди, которые выше вашей команды в вашей компании, вероятно, больше обеспокоены тем, что ваша команда постоянно движется, и проекты доводятся до логического завершения.
Как человек, работающий в Agile, вы должны больше всего беспокоиться о том, сколько работы вы эффективно выполняете по отношению к остальной части вашей команды. Если вы новичок, от вас не ожидают, что вы будете слишком продуктивными, но в какой-то момент вашего срока работы вы должны быть на одном уровне с хотя бы частью вашей команды. Если вы не выводите работу, вы не выполняете свою работу.
источник
Ваша средняя скорость на месте. По моему опыту это очень полезно для долгосрочных оценок завершения - при условии, что у вас большое отставание; но не так полезно для обязательств по планированию спринта.
Процесс планирования спринта, который я видел, состоит в том, чтобы вытащить истории из верхней части списка невыполненных работ и позволить команде решить, смогут ли они их достичь. Команды решили это на основе интуиции, разбивки задач на 1/2 дня, давления со стороны Владельца продукта, согласованности с целью спринта, наилучшего предположения (основанного на скорости) или некоторой их комбинации.
Иногда владелец продукта может пропустить пару пунктов, чтобы можно было добавить еще.
Иногда команда и владелец продукта заранее договариваются о растяжках, на которые можно перейти.
источник
Это отличный вопрос, и он очень важен для команд. Эта тема обманчива и широко неправильно понята. Первоначальная цель указания истории состояла в том, чтобы найти быстрый и приемлемо точный метод оценки уровня усилий (LOE), необходимый для завершения функциональности, определенной в историях. Общая цель: дать командам метод ПРОГНОЗИРОВАНИЯ или прогнозирования того, сколько времени потребуется для завершения работы (например, проекта). Ваше понимание Velocity верно: это СРЕДНИЕ баллы за спринт (действительно СДЕЛАНО). Таким образом, если у вас есть проект, который нужно выполнить, и он набирает 250 баллов, а ваша команда набирает в среднем 25 баллов за спринт, проект займет примерно 10 спринтов, плюс или минус некоторое время буфера.
Некоторые светила, такие как Кен Швабер, предполагают, что скорость и точки используются только для среднесрочного и долгосрочного прогнозирования. Они предлагают использовать рабочие часы в качестве второй «проверки работоспособности» того, что на самом деле можно сделать в спринте. Таким образом, количество очков в каждом спринте может варьироваться в зависимости от производительности. Другие (включая меня) полагают, что зрелая команда установит очень последовательную схему определения размеров, которая может точно предсказать емкость, и в конечном итоге рабочие часы станут бесполезным дополнительным бременем. (Критически важно выступать в новых командах как минимум от 6 до 12 спринтов до тех пор, пока команда не поймет правильные моменты и размер сюжета.)
Ваша первая маленькая ошибка в том, что вы сказали, что команда должна знать скорость и вносить столько историй. На самом деле, тренеры побуждают команды удерживать от 10% до 20% и вместо этого совершать * обязательства на этом уровне. Поэтому, если ваша команда стремится набрать 25 очков за спринт, не доводите спринт до 25 очков, а остановитесь на 20-22 очках. Помните: когда вы выполняете другую работу, совершенно прекрасно вносить истории. Таким образом, вы можете «зафиксировать» 22 очка и набрать 28. Это здорово. Только будьте осторожны, чтобы не поощрять команду к "мешку с песком" и постоянно находиться под коммитом. Нет ничего плохого в растяжке, чтобы увидеть, сможем ли мы сделать больше.
Теперь к вашей точке зрения по поводу дисперсии между спринтами. Это очень распространенный (но НЕ ОПТИМАЛЬНЫЙ) паттерн, когда команда, набравшая 20 очков за один спринт, затем 50, затем 22, затем 45, затем 15, 60. Если вы рассчитаете отклонение, это может показать колебания в 50%. до 100% спринта после спринта. Почему команды набирают всего 15 очков в одном спринте, а затем 60 в следующем?
Это может означать, что команда действительно не знает, что они могут сделать. (Эй, мы выполнили 50 очков в последнем спринте, мы можем сделать это снова в этом спринте).
ИЛИ, это может указывать на то, что владельцы продукта вынуждают команду к чрезмерной фиксации или добавляют работу после запуска спринта и т. Д. Это лишь некоторые из АНТИ-ШАБЛОНОВ, которые могут вызывать это дикое колебание в завершенных точках.
Эта мера предсказуемости является важной для мастеров схваток, чтобы наблюдать и привлекать внимание команды.
Часто причиной того, что они набрали несколько очков в одном спринте, а затем много очков в следующем спринте, является то, что я называю «ВОЛНОВАЯ ВОЛНА НЕПОЛНОЙ РАБОТЫ». Вот очень распространенный шаблон:
Владелец продукта находится под давлением, чтобы встретить дату. Поэтому команда чувствует необходимость сделать много работы. Они начинаются как новая команда, и не уверены, что они действительно могут сделать.
Таким образом, спринт 1, они планируют спринт и, поскольку они находятся в фазе формирования, не могут завершить всю работу. На самом деле, у них больше незавершенной работы, чем выполненной работы. Незавершенная работа НАЧАЛАСЬ, но НЕПОЛНАЯ. Он перенесен на следующий спринт, и на этот раз они проделали больше работы, чем незавершены. К следующему спринту этот большой объем незавершенных работ падает на ГОТОВО, и доверие команды возрастает.
Владелец продукта взволнован, и поэтому они снова увеличивают свою нагрузку. В конце этого спринта у них ОГРОМНОЕ количество незавершенных работ и разочаровывающее количество выполненных работ.
Здесь вы начинаете видеть Волны Готово против Неполного чередующегося спринта после спринта. Если команды не понимают, что происходит, эта схема может продолжаться месяцами. Но в среднем они заканчивают около 24 очков за спринт. Так что же происходит, когда они перестают совершать коммиты?
Вы заметите, что они ДОЛЖНЫ завершить от 24 до 26 баллов, но перенесенная работа уменьшается. Теперь вместо того, чтобы пытаться выполнить невозможный объем работы, что также разрушает командный дух, команда может начать улучшать свои процессы.
Со временем скорость начнет увеличиваться без огромных колебаний в работе «Готово против незавершенности».
Если вы не позволите команде «расслабиться», они НИКОГДА не успеют выполнить работу, которая сделает их стройнее, быстрее, лучше. Например, Dev-Ops не может быть. Автоматизация тестирования - у кого есть на это время? Но это именно то, над чем нужно работать командам, чтобы они могли увеличить скорость.
источник