Спринт в Scrum: как сделать так, чтобы итерации не срывались

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

Что такое спринт в методологии Scrum

Спринт — это одно из ключевых понятий в гибкой методологии проектного управления Scrum. Подход подразумевает поэтапное достижение целей: декомпозицию крупных работ на более мелкие и выполнение выбранных задач в заданный промежуток времени — итерацию.

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

Итак, постараемся максимально подробно рассмотреть, что такое спринты и почему как они работают.

Спринт характеризуется:

1. Фиксированной продолжительностью в рамках проекта. Разные команды в зависимости от своей специфики определяют для себя длительность спринта. Обычно это не менее недели и не более месяца. Более мелкие отрезки не имеют смысла, иначе не успеть получить результаты. Более длинные связаны с рисками потери фокуса и динамики работы.
2. Конкретной целью и обязательствами команды по достижению. Обычно это некая функциональность или характеристика продукта, которая по итогам спринта потенциально пригодна к применению.
3. Инкрементом, что выступает результатом спринта. Например, рабочая версия продукта, соответствующая поставленным целям, которую можно продемонстрировать заказчику и стейкхолдерам.

Обязательные этапы спринта, включая детализацию временных периодов

Что дает работа спринтами

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

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

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

Роли в спринте: кто за что отвечает

Команда спринта — это группа коллег, способных тесно взаимодействовать друг с другом и заказчиками. Как и спринт в программировании, проектная группа в любой сфере обычно включают 5–10 человек.

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

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

Роли в команде определяются по методологии Scrum. Например, среди них есть разработчики. Но это не значит, что лишь спринт в it имеет место, потому что речь не о разработчиках ПО, а об исполнителях задач в широком смысле в любой сфере.

Так выглядит классический состав команды в спринте

Product owner, или владелец продукта

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

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

Скрам-мастер

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

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

Разработчики

Разработчики — это исполнители, которые непосредственно выполняют задачи и создают продукт. При разработке ПО это могут быть программисты, UX/UI-дизайнеры, тестировщики, аналитики. В других сферах разработчиками в спринте могут быть исполнители любой специализации. Например, в фармацевтике — химики и медики, а в рекламном агентстве — дизайнеры, маркетологи и копирайтеры. Важно, чтобы в команда включала участников со всеми компетенциями, необходимыми для достижения цели.

Сколько длится спринт в Scrum: выбираем оптимальный интервал

Спринты в проекте — это своего рода метроном, которые задает ритм работе. Но каким будет этот ритм, определяет команда. По официальному руководству по Scrum (Scrum Guide) длительность спринта не может превышать месяц.

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

1 неделя — когда стоит выбрать

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

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

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

Недельные спринты подходят:

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

2 недели — золотая середина

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

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

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

Двухнедельные спринты подходят:

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

3-4 недели — длинные дистанции

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

К минусам «длинных дистанций» относится наименьшая гибкость из всех возможных вариантов спринта. Есть риск, что к концу «забега» стейкхолдеры могут изменить вводные данные, и часть работы окажется проделанной напрасно. Или по итогу спринта выяснится, что команда не совсем верно поняла задачу и ушла в реализации не в ту сторону. Такие ошибки будут дорого стоить. Наконец, такие сроки сложнее корректно планировать.

Длинные спринты подходят:

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

Этапы спринта: что происходит и где чаще всего ломается

Любой спринт включает несколько обязательных событий: планирование, ежедневные встречи — Daily Scrum, обзор спринта — Sprint Review, ретроспектива. Остановимся подробнее на каждом из них и посмотрим, как работу упрощает решение для управления проектами Naumen Project Ruler (NPR).

Как планировать спринт

Планирование спринта происходит на общей встрече команды. По методике скрам она должна занимать не более двух часов в неделю. Таким образом с планированием двухнедельного спринта нужно укладывать максимум в четыре часа.

Формулировка цели. За этот этап отвечает владелец продукта. Чтобы цель была выполнимой, нужно учесть итоги предыдущего спринта и мнения стейкхолдеров. Цель — это ответ на вопрос: «Какую именно ценность обеспечит пользователям и бизнесу данный спринт». Фиксировать все решения по спринту, начиная с цели, можно прямо по ходу планирования в системе автоматизации.

Формирование бэклога. Здесь владелец продукта, уже совместно с командой, формирует бэклог спринта — задачи, которые нужно выполнить, чтобы достичь поставленной цели.

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

Задачи должны быть максимально детализированными и понятными команде. Также здесь необходимо прописать критерии приемки. Данные по задачам фиксируются в системе управления проектами и в любой момент доступны исполнителю.

В проекте можно удобно работать со списком задач или с карточками на Kanban-доске

Определение объема работы. Опыт участников помогает оценить необходимые трудозатраты по каждой задаче. Чем точнее это сделано, тем меньше риска, что цель спринта не будет достигнута. Одни команды измеряют трудозатраты в человеко-часах, другие в стори-поинтах. Стори-поинты — более относительная единица. И это часто на пользу: исполнители больше сосредоточены на работе, а не на оценке, укладываются ли в четко заданное число часов. Допустимо при планировании закладывать резерв до 20% от оценки работ на случай форс-мажоров.

Распределение задач. На работы из созданного бэклога спринта назначаются исполнители. При этом учитываются компетенции, опыт и ресурсы. Суммируя данные по объему работ, последовательности и распределению рабочего времени специалистов, для задач назначаются дедлайны.

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

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

Как проводить Scrum Daily

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

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

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

Как проводить обзор спринта

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

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

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

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

Ведение отдельной карточки для спринт-ревью позволяет обозначить повестку, зафиксировать протокол и сразу добавлять новые задачи

Как проводить ретроспективу спринта

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

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

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

Этап	Как должно быть	Что может пойти не так
Планирование	Команда договаривается о цели и выбирает задачи	Цель не поставлена Директивное назначение задач Берутся задачи «про запас»
Scrum Daily (стендап)	«Сверка курса» за 15 минут: как идет работа, какие сложности, кто и как их решает	Отчет кто что делал Перечисление статусов задач без учета контекста спринта
Спринт-ревью	Демонстрация инкремента Сбор обратной связи	Отсутствие стейкхолдеров Презентация вместо работающего продукта Формальная обратная связь
Ретроспектива	Анализ взаимодействия и процессов	«Вечер жалоб» без конкретных предложений Замалчивание проблем

Метрики спринта: что отслеживать и как интерпретировать

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

Velocity (скорость команды) — отражает сколько сторипоинтов команда закрыла за спринт. Показывает реальную мощность команды. В идеале от итерации к итерации это должен быть примерно один и тот же показатель. И он помогает при планировании. Если же эта цифра все время меняется, то это поводу проанализировать ситуацию. Причина может быть в том, что в команде не выстроены четкие процессы работы, задачи некорректно декомпозируются или постоянно добавляются в спринт. В результате команда не справляется в установленные сроки и доделывает задачи одного спринта в следующем.

Say/Do Ratio (коэффициент выполнения обязательств) — соотношение реально выполненных задач к запланированным. Измеряется в процентах, учитываются только полностью выполненные работы. По сути показатель отражает надежность и предсказуемость команды. Если 90-100%, значит, команда зрелая и адекватно оценивает свои силы и возможности. 80-90% — нормальный рабочий диапазон продуктивной команды. Меньше 80% — это невыполнение взятых на себя обязательств. Нужно разбираться в причинах: неверная декомпозиция задач, некорректное планирование, нестабильная команда.

Оба показателя в системе Naumen Project Ruler можно отслеживать на дашбордах — интерактивных панелях, на которых отображаются заранее настроенные нужные параметры в виде виджетов.

Burndown Chart (диаграмма сгорания задач) — показывает текущее соотношение запланированных работ к фактически выполненным. Горизонтальная ось Х — это дни спринта. Вертикальная ось Y — это оставшийся объем работы в стопоинтах или часах. На этот график нужно смотреть не по итогам спринта, а в процессе. Это помогает понять, двигается ли команда к финалу спринта в нужном темпе, или есть отклонения.

Burndown Chart формируется по актуальным трудозатратам. В текущем варианте справа видно, что работа в спринте шла неравномерно

Cumulative Flow Diagram (накопительная диаграмма потока) — показывает распределение задач по статусам на протяжении всего спринта. Если Burndown Chart сигнализирует об отклонениях, то CFD помогает найти причину — где именно замедляется работа. Горизонтальная ось Х здесь — это время, например, дни. Вертикальная ось Y — число задач или сторипоинтов. Цветные полосы — статусы задач.

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

Типичные ошибки при работе со спринтами

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

Проблема	Решение
Недостаточное участие владельца продукта. Он не понимает своей роли в планировании, а потом раз за разом недоволен результатами	Задача скрам-мастера сполна вовлечь product owner в процесс, объяснить важность его участия и в чем оно состоит
Отсутствие четкости при постановке задач, либо они слишком крупные. Исполнители могут плохо понимать, что им делать, но не говорить об этом. Кроме того, объем таких задач может быть оценен некорректно. В итоге команда не укладывается в спринт	Чек-лист критериев для задач, которые берутся в спринт. Каждая сопоставляется с ним Грамотная декомпозиция Озвучка сложностей на стендапах, а также разбор неудач на рестроспективе
Перебор задач с высокой степенью неопределенности в одном спринте. Такие есть всегда, но лучше не допускать, чтобы в одной итерации их было несколько. Это ставит под угрозу весь спринт	Оценка задач по уровню неопределенности Договоренность в команде, сколько таких задач допускается в спринте
Несоблюдение таймингов регулярных встреч. Как следствие — непродуктивный расход рабочего ресурса	Соблюдение таймингов — задача скрам-мастера. Именно он должен следить за временем и корректировать при необходимости ход встречи
Частые или значительные изменения приоритетов в разгар спринта по инициативе стейкхолдеров	Зафиксированный план спринта в рассчитанными ресурсами Замена запланированных задач на новые Временной лаг при планировании на подобные случаи

К выводам

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

Что еще интересного