Что такое спринт в Agile? Длительность, события и примеры

Что такое спринт в Agile?

A спринта — это период фиксированной длительности не более месяца, в течение которого Agile-команда работает над единой Целью спринта и создаёт как минимум один пригодный к использованию инкремент продукта. Спринты идут один за другим без перерывов, и вся работа по планированию, координации, обзору и улучшению продукта происходит внутри них.

Термин пришёл из Scrum — самого распространённого Agile-фреймворка. Руководство по Scrum (редакция 2020 года, по-прежнему актуальная официальная версия) описывает спринты как сердцебиение Scrum, где идеи превращаются в ценность. Другие Agile-методы используют для той же идеи слово итерация , а многие команды, не следующие Scrum строго, всё равно говорят «спринт».

Как бы он ни назывался, у спринта пять определяющих признаков:

• Фиксированная длительность. Длительность задаётся заранее и не меняется от спринта к спринту, поэтому команда узнаёт свой темп.
• Одна цель. У каждого спринта есть Цель спринта: единая цель, объясняющая, почему спринт стоит проводить.
• Пригодный к использованию результат. К концу спринта у команды есть инкремент, соответствующий критериям готовности (Definition of Done), даже если он ещё не выпущен.
• Один за другим. Новый спринт начинается сразу после окончания предыдущего.
• Всё внутри. Планирование, ежедневная координация, уточнение, обзор и ретроспектива происходят внутри спринта, а не до или после него.

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

Спринт, итерация и Scrum

Эти термины часто путают. В таблице показано, как они соотносятся.

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

Сколько длится спринт?

Руководство по Scrum устанавливает лишь одно правило: спринт длится не более месяца. В этих пределах выбор за командой. На практике большинство команд проводят спринты продолжительностью от одной до четырёх недель, и две недели — безусловно, самый популярный вариант, поскольку он уравновешивает быструю обратную связь и накладные расходы на планирование и обзоры.

Как выбрать длину спринта

Выберите минимальную длительность, за которую команда может поставить что-то значимое и готовое. Затем учтите:

• Как быстро всё меняется. Чем изменчивее рынок или требования, тем короче спринт.
• Как долго может ждать обратная связь. Если заинтересованным сторонам нужно видеть прогресс каждую неделю, четырёхнедельный спринт слишком длинный.
• Размер элементов. Если большинство элементов бэклога занимает больше нескольких дней, разбейте их, прежде чем удлинять спринт.
• Ограничения релизов и тестирования. Интеграция, проверки на соответствие или сроки поставки оборудования могут сделать очень короткие спринты непрактичными.
• Синхронизация. Команды, работающие над одним продуктом, обычно используют одинаковую длину спринта и дату начала.

Изменение длины спринта

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

Составные части спринта

Форму спринту придают три вещи: цель, план и результат.

цель спринта

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

• Слабо: «Выполнить тикеты 412, 415, 419 и 420».
• Лучше: «Дать постоянным клиентам возможность оформить заказ в один шаг, чтобы проверить, снижает ли это число брошенных корзин».
• Пример не из ПО: «Запустить лендинг весенней кампании и первые два письма, чтобы отдел продаж мог начать обзвон в понедельник».

Бэклог спринта

Именно Бэклог спринта состоит из Цели спринта, выбранных на спринт элементов бэклога продукта и плана разработчиков по их поставке. Он принадлежит разработчикам, которые обновляют его на протяжении всего спринта, чтобы все видели оставшуюся работу.

Инкремент и критерии готовности

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

События внутри спринта

Спринт — это контейнер для четырёх других событий. Ниже приведены максимальные таймбоксы из Руководства по Scrum для месячного спринта; в более коротких спринтах события обычно короче.

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

Ежедневный Scrum — это 15-минутная сверка для разработчиков. Это не отчёт о статусе руководителю. Важен один вопрос: идём ли мы к Цели спринта, и если нет, что мы меняем сегодня?

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

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

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

Повестки и советы по фасилитации каждой встречи — в нашем руководстве по церемонии Scrum.

Кто что делает в спринте

В Scrum-команде три зоны ответственности. Для работы спринта нужны все три.

Обратите внимание: никто не раздаёт задачи разработчикам — они организуют работу сами.

Как спланировать и провести спринт: пошагово

Это рекомендуемая нами последовательность для команды, проводящей свои первые спринты. Она следует Руководству по Scrum с добавлением практических привычек.

1. Подготовьте бэклог продукта. Перед планированием убедитесь, что верхние элементы упорядочены, понятны и достаточно малы, чтобы завершить их в рамках спринта. Для этого служит уточнение в предыдущем спринте.
2. Проверьте доступную загрузку. Перечислите отпуска, обучение и другие обязательства, чтобы знать, сколько времени у команды есть на самом деле. Наше руководство по планированию загрузки в Agile объясняет, как это сделать.
3. Согласуйте Цель спринта. На планировании спринта владелец продукта предлагает цель, а команда формулирует её одним ясным предложением.
4. Выберите работу. Разработчики берут элементы с верха бэклога, пока не наберут реалистичный объём, ориентируясь на недавнюю скорость или пропускную способность.
5. Спланируйте, как это сделать. Разбейте работу первых нескольких дней на задачи и договоритесь, кто что начинает. Планировать все задачи заранее не нужно.
6. Работайте небольшими партиями. Завершайте элементы, прежде чем браться за новые. Если кто-то заблокирован, остальные помогают; это называется роением (swarming).
7. Проводите ежедневную инспекцию. Используйте Ежедневный Scrum и наглядную Scrum-доску, чтобы заранее замечать риски для Цели спринта.
8. Уточняйте предстоящую работу. Уделяйте в каждом спринте время подготовке следующего набора элементов; в ранних редакциях Руководства по Scrum говорилось, что на это обычно уходит не более 10% загрузки команды, и многие команды до сих пор используют это как эмпирическое правило.
9. Проведите обзор с заинтересованными сторонами. Покажите, что готово, соберите обратную связь и обновите бэклог продукта.
10. Улучшайтесь. Проведите ретроспективу, выберите одно-два действия и перенесите их в следующий спринт, который начинается сразу же.

Готовый шаблон планирования спринта даёт место для Цели спринта, загрузки, выбранных элементов и задач.

Пример: двухнедельный спринт день за днём

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

Примеры Целей спринта

• Программный продукт: «Новые пользователи могут зарегистрироваться с рабочей почтой и пригласить одного коллегу, чтобы мы могли запустить бета-версию онбординга».
• Маркетинговая команда: «Опубликовать лендинг вебинара и форму регистрации, чтобы открыть запись на июньское мероприятие».
• HR-команда: «Опробовать новый чек-лист адаптации на двух сотрудниках, выходящих в этом месяце».
• Внутренний ИТ-отдел: «Перевести финансовый отдел на новую сборку ноутбуков без потери доступа к общим дискам».

Можно ли изменить, продлить или отменить спринт?

Руководство по Scrum даёт чёткие правила для идущего спринта:

• Никаких изменений, ставящих Цель спринта под угрозу. Новую срочную работу можно обсуждать, но команда защищает цель.
• Качество не снижается. Критерии готовности не ослабляются ради соблюдения даты.
• Объём работ можно уточнять и пересогласовывать с владельцем продукта по мере того, как команда узнаёт больше. Элементы можно заменять или исключать, пока цель остаётся достижимой.
• Бэклог продукта уточняется по мере необходимости.

Продлевать спринт нельзя. Таймбокс фиксирован. Неготовая работа возвращается в бэклог продукта, где владелец продукта заново её упорядочивает; она не переносится автоматически в следующий спринт, а частично выполненная работа не учитывается в скорости команды.

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

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

Как отслеживать прогресс во время спринта

Для управления спринтом не нужна сложная отчётность, но нужно видеть, достигается ли цель.

• Scrum- или Kanban-доска. Столбцы вроде «К выполнению», «В работе», «На проверке» и «Готово» позволяют сразу увидеть работу и выявить узкие места.
• Диаграмма сгорания спринта. Показывает оставшуюся работу по дням относительно идеальной линии. Горизонтальная линия в течение нескольких дней — ранний сигнал тревоги.
• Проверка Цели спринта. На каждом Ежедневном Scrum спрашивайте, достижима ли ещё цель; это важнее любой диаграммы.
• Скорость или пропускная способность (после спринта). Объём работы, завершённый за спринт, используемый для планирования будущих спринтов. См. диаграммы скорости в Agile.
• Доля достигнутых Целей спринта. Как часто команда достигала цели на протяжении нескольких спринтов — полезный показатель предсказуемости.

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

Преимущества работы спринтами

• Быстрая обратная связь. Заинтересованные стороны видят работающие результаты каждые несколько недель, а не в конце проекта.
• Фокус. Единая цель и короткий горизонт снижают многозадачность и переключение контекста.
• Меньший риск. Проблемы проявляются в пределах одного спринта, когда их дешевле исправить.
• Предсказуемость. Устойчивый ритм облегчает прогнозирование и планирование релизов.
• Встроенное улучшение. Ретроспектива даёт команде регулярное защищённое время для улучшения своей работы.
• Прозрачность. Цели, бэклоги и доски делают прогресс видимым для всех.

Типичные ошибки в спринтах и как их исправить

Все ли Agile-команды используют спринты?

Нет. Спринты относятся к Scrum и к методам на основе итераций, таким как XP и SAFe. Другие подходы работают иначе:

• Kanban использует непрерывный поток с лимитами незавершённой работы вместо фиксированных спринтов; планирование и релизы проводятся по мере необходимости. Сравнение — в материале Kanban и Scrum.
• Scrumban сочетает оба подхода, часто сохраняя ритм планирования и при этом управляя работой как потоком.
• Дизайн-спринты — это другая идея: структурированный воркшоп примерно на пять дней (популяризированный Google Ventures) для исследования и проверки продуктовой концепции. Название совпадает, но правила Scrum к нему не относятся.

Чтобы сравнить эти подходы, прочитайте виды Agile-методологий.

Шаблоны и инструменты для спринтов

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

• Шаблон планирования спринта: Цель спринта, загрузка, выбранные элементы, оценки и задачи.
• Шаблон ретроспективы спринта: что прошло хорошо, что улучшить и действия.
• Шаблон бэклога продукта: упорядоченный список элементов, готовых к будущим спринтам.
• Шаблон пользовательской истории: единообразные истории с критериями приёмки и оценками.
• Шаблон Agile-плана проекта: релизы, спринты и вехи в одном представлении.

Большинство инструментов управления проектами сейчас поддерживают спринты. Jira построен вокруг Scrum- и Kanban-досок для команд разработки, а Wrike, лучший инструмент в нашем общем рейтинге, подходит командам, которые ведут спринты наряду с другими видами работы в разных отделах.

Бесплатные шаблоны по этой теме

Все шаблоны

Частые вопросы