Какой продолжительности должен быть Agile Sprint?

Если бы вы были новичком в Scrum и спринтах, я бы сказал, что вы должны начать с определенной продолжительности (3 недели или 30 дней) и проверить, работает ли это для вас, и внести изменения, если это необходимо. Вместо этого похоже, что вы уже знакомы со спринтами, поэтому вопрос: каков ваш опыт работы с продолжительностью спринта? Есть ли у вас какие-либо сомнения, которые заставляют вас задать вопрос?

Я вижу пару влияющих факторов:

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

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

Чем короче спринт - тем лучше. Это эмпирическое правило. Однако есть много препятствий, которые не позволяют нам делать поставки каждую, скажем, неделю. Вот некоторые из этих препятствий:

• у спонсора/заказчика проекта есть определенная бюрократия
• ресурсы (люди) медленные в доставке
• некоторые задачи занимают больше времени и не могут быть разбиты на подзадачи

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

В общем, чем короче спринт, тем лучше, даже если вы только начинаете. Чем короче спринт, тем раньше можно будет проверить и адаптироваться. Более короткие спринты также будут способствовать внедрению более гибких практик: сокращению незавершенного производства, уменьшению размера партии и повышению пропускной способности. Более длинные спринты могут стимулировать старые привычки водопада. На недавнем вебинаре, который мы провели для 2800 человек, мы опросили участников на предмет наиболее распространенной продолжительности спринта, и чуть более 50% ответили, что это 2 недели. Обычно мы рекомендуем именно такую ​​продолжительность спринта, хотя есть более зрелые команды, у которых спринта вообще нет.

Исходя из своего опыта, я обнаружил, что хорошо иметь 7-10-дневные спринты в начале и увеличивать их до 15-20 дней позже , когда команда переходит к этапам нормирования/выполнения.

амельвин,

Я работал над проектом из трех команд, где за 15 месяцев работы мы использовали двухнедельные спринты — это (для нас) было оптимальной продолжительностью.

Я говорю «в итоге», потому что мы совершенно сознательно в первые несколько месяцев возились с рядом основ, и длина спринта была одной из них. Более длинные спринты (IIRC, 4 недели были самыми длинными, которые мы пробовали) не были эффективными. Мы чувствовали, что получение обратной связи занимает слишком много времени (ретроспективы), истории были менее точными, а проблемы, казалось, затягивались, а не закрывались быстро. Я не думаю, что это простая данность — команды других проектов могли бы справиться с этим лучше — но наш опыт показал, что чем короче, тем лучше.

Здесь нет правила. Самая распространенная продолжительность спринта — 2 недели. Подавляющее большинство команд, я бы сказал, более 90% тех, кто использует тайм-боксинг, будут иметь от 1 до 4 недель.

Но тогда я не верю, что есть универсальное решение, которое подходит всем.

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

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

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

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

Согласно ScrumMethodology.com , спринт длится 30 дней. Тем не менее, я вижу преимущества и недостатки как в более длинных, так и в более коротких спринтах. Фактически, руководство по Scrum на веб-сайте Scrum.org описывает спринт как не более 30 дней по следующим причинам:

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

Чем длиннее становятся спринты, тем менее гибкими вы на самом деле становитесь, особенно если вы следуете правилам методологии схватки, которые не позволяют вам прерывать или менять спринт в середине.

Чем меньше спринтов, тем проворнее вы становитесь; однако команде разработчиков может быть сложнее выполнить больше работы, поскольку продукт должен быть в рабочей версии в конце каждого спринта.

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

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

Вы можете увидеть хорошее освещение вашего конкретного вопроса, но как вы работаете в течение 4/5 недель для своей команды, клиента, системы?

Вы пробовали другие длины? Давали ли они лучшие результаты, было ли легче планировать, приносить пользу, была ли команда счастливее?

Как продвигается ваше общее внедрение Agile? Помогает ли вам 4/5 недельный интервал принять другую часть agile/scrum рецепта для разработки программного обеспечения?

Вы перестали улучшаться? С чего вы начали с длины спринта? Вы и ваша команда активно управляете длительностью, как говорил Кен Клайн ?

Основываясь на этих ответах, я бы сказал, что вам нужно активно управлять этим самостоятельно и игнорировать эмпирические правила.

В одном из моих проектов, который длился 60 недель ( аналогично вашему ), моя команда работала в 4-недельном спринте, и все шло хорошо.

Однако, чтобы ответить на ваш вопрос: НЕТ эмпирического правила разумного количества спринтов. Я руководил многими проектами, в настоящее время 5 проектов одновременно. Некоторые из них длятся менее 10 спринтов, некоторые длятся 10-30 спринтов, а некоторые особенно длинные проекты занимают > 50 спринтов. И каждый проект может иметь разную продолжительность спринта (1, 2 и 3 недели) .

В группе Agile, в которой я участвую , многие команды выбирают 30-дневный период, в то время как многие команды выбирают 2 недели и 3 недели.

Итак, как мне определить длину спринта? Решение принимается после рассмотрения: предполагаемой продолжительности проекта, характера продукта, характера вашей команды.

1) Расчетная продолжительность проекта.

Оценка не должна быть точной на 100%, чтобы дать вам представление о том, как долго продлится проект. Если он длится более 6 месяцев, имеет смысл рассмотреть 3-недельную или 30-дневную продолжительность.

2) Природа продукта.

Вам нужно спросить себя:

• Нужно ли часто адаптировать этот продукт к потребностям рынка/реальных пользователей, чтобы приносить пользу заинтересованным сторонам? Если это так, вы должны сократить длину спринта и чаще выпускать рабочую версию, чтобы получить отзывы общественности.
• Технически возможно ли доставить продукт в короткие сроки? Как вы знаете, короткая итерация приветствуется, но вы не можете делать это в 100% случаев из-за технических сложностей. Например, в каком-то проекте нам нужно реализовать сложный алгоритм, прежде чем показывать его заинтересованным сторонам.

3) Характер вашей команды

Ваша команда работает наиболее эффективно в недельных спринтах или в 30-дневных спринтах? Если вы работали с командой на нескольких двухнедельных спринтах и ​​чувствуете, что они работают хорошо, почему бы не подумать об этом?

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

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

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

Более короткие спринты обычно превосходят более длинные спринты.

Из гораздо более длинного поста в блоге Shorter Trumps Longer

Плюсы

• Поскольку у команды больше ретроспектив, но они короче, у них больше возможностей попробовать небольшие изменения. Это также дает больше возможностей для обучения.
• Более частые Обзоры Спринта дают Владельцу Продукта больше отзывов и больше возможностей для изменений. Это должно в значительной степени устранить необходимость для Владельца Продукта когда-либо запрашивать изменение (т.е. новую Историю) в текущем Спринте.
• Препятствия и замедления выделяются быстрее, так как ожидается, что команда завершит выполнение функций к концу каждого спринта. Это заставляет команду смириться с вещами, которые их замедляют.
• Более короткие циклы облегчают планирование, что повышает концентрацию внимания и уменьшает объем «черной работы». Заставляет команды лучше выполнять работу по разделению историй или функций на более мелкие фрагменты. Это увеличивает видимость и дает владельцу продукта лучший контроль над расстановкой и снижением приоритетов.

Минусы

• Труднее добраться до готового продукта в конце одно-двухнедельного цикла. Предупреждение: поначалу это так, однако большинство команд могут освоить это после трех-четырех спринтов.
• Работа в течение одной недели Спринты поначалу могут быть более напряженными.
• Накладные расходы — люди говорят, что встречи спринта — это слишком много накладных расходов для однонедельного спринта. Однако встречи спринта масштабируются линейно в зависимости от продолжительности спринта. Таким образом, в однонедельном спринте будет 2 часа планирования спринта, в двухнедельном спринте — 4 часа и так далее.

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

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

Разработчики в команде должны решить, что лучше всего подходит для них. Может случиться так, что короткие спринты лучше всего работают в начале, затем более длинные спринты в середине, а затем более короткие спринты в конце. Или наоборот. Или все одного размера, в 4 недели. Или, может быть, 4 недели окажутся слишком большими для эмпирического подхода, которым является Scrum, поэтому команда разработчиков может решить сократить его до 3 недель.

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

Амельвин,

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

Почему 5-я неделя паузы? Одна из целей схватки — поддерживать устойчивый темп. Если вам нужен перерыв каждые 4 недели, это говорит мне о том, что вы, возможно, перегружаете команду в остальные 4. Сможете ли вы выдержать это в течение 14 месяцев?

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

Необходимость исправления ошибок ставит вопрос о контроле качества. Как вы обеспечиваете качество своих спринтов? Как изменилось ваше определение готовности? Наличие недели исправления ошибок заставляет команду разработчиков срезать углы и снижать качество. Это подкрепляет мысль о том, что проблемы «можно решить в течение недели исправления ошибок». И прежде чем вы это узнаете, вещи, которые, как вы думали, были сделаны, продолжают возвращаться для исправления за исправлением. Здоровый DoD имеет решающее значение для прозрачности, а прозрачность является ключом к успеху проекта. Мой совет — будьте строги с определением «готово» и подталкивайте команду к тому, чтобы оно росло с каждой ретроспективой. Нефункциональные требования — отличные кандидаты для контрольных точек «Определение готовности».

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

Прочтите руководство по Scrum на сайте scrum.org, и я бы посоветовал всей команде пройти формальное обучение по Scrum на сайте .org или в Alliance. Большинство решений должна принимать команда. Продолжительность EG Sprint должна определяться командой Scrum. Всегда лучше, когда все понимают основное руководство и аргументацию, стоящую за ним.

Удачи вашему проекту

Я больше на стороне разработки, и я просто хотел вмешаться.

Я наблюдаю одну распространенную ошибку, которую допускают продакт-менеджеры: они пытаются зафиксировать блоки работы в обычном расписании, а не планировать блок работы.

Например, рассмотрим ситуацию с 6 строганными блоками:

• Особенность А (1 нед. 3 д.)
• Улучшение Б (4д)
• Функция C (1 нед. 1 д.)
• Утвержденные исправления ошибок (3d)
• Рефакторинг 5 (2 нед 4 д)
• Улучшения обработки ошибок (2d)

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

Вместо этого подумайте о планировании блоков, которые необходимо выполнить, сколько времени займет каждый из них и в логическом порядке, в котором они должны быть доставлены. Затем сделайте каждый блок отдельным спринтом и запланируйте их. Пусть будет двухдневный спринт на обработку ошибок. Пусть будет 3-недельный спринт для рефакторинга. Управление проектом и планирование должны управлять проектом, а не управлять им.

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