Каковы преимущества спринтов фиксированной длины для agile?

Идея спринта фиксированной длины состоит в том, чтобы обеспечить взаимопонимание между разработчиками и заказчиком (или PO), когда будет доступно что-то новое (и работающее), и определить длину цикла обратной связи, которая равна длине цикла обратной связи. спринт.

Другими словами, заказчик будет знать, что через 2 недели он получит что-то, что работает, а команда разработчиков будет знать, что они получат отзывы о своей работе и узнают больше о предстоящей работе через две недели. Это предсказуемость .

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

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

Почему бы просто не поставить цели для итерации и не закончить их за то время, которое требуется, вместо того, чтобы иметь фиксированную итерацию, которую вы пропустите, закончив слишком рано или слишком поздно?

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

Прежде чем выбрать модель, проверьте всю систему (от клиента к клиенту) и выберите модель, которая обеспечивает следующие преимущества: качество, скорость, надежность и предсказуемость .

Последнее: придерживайтесь модели . Если вы делаете (или должны следовать) scrum, то динамическое изменение длины спринта не может быть и речи, потому что без спринта фиксированного размера он просто не будет работать, потому что вы потеряете скорость, надежность и предсказуемость.

Когда я проходил скрам-класс, инструктор показал график, похожий на этот.

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

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

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

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

Полностью согласен с Zsolt в этом. Вот хорошая цитата из книги Хенрика Книберга « Scrum and XP from the Trenches» [бесплатная версия] , в которой подчеркивается важность предсказуемости длины спринта:

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

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

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

См. scrum.org для получения дополнительной информации.