Разделяй и властвуй, или что такое спринт в Scrum

Если вам нужно регулярно обновлять продукт и оперативно вносить в него изменения, можете попробовать разделить работу на части — итерации. А для управления ими использовать Scrum-спринты. Подготовили для вас гайд, в котором расскажем: что такое спринт, какой должна быть продолжительность спринта и как управлять спринтами, используя Кайтен.

Начнем с теории

Чтобы не запутаться, предлагаем разобраться с базовыми терминами: Agile, спринт и Scrum.

Agile — методология, набор практик и методов для улучшения производимого продукта. Подробнее о подходе рассказали здесь, а подробнее про 10 моделей управления проектами здесь.

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

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

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

Scrum sprint (спринты) — это период времени, в который команда выполняет определенный объем работы шаг за шагом. Подробнее о спринтах расскажем в блоке ниже.

С теорией разобрались, теперь подробнее поговорим о спринтах в методологии Scrum.

Спринт в методологии Scrum

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

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

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

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

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

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

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

Кто участвует в Scrum-спринтах

Существует три типа участников Scrum-проекта:

1. владелец продукта,
2. скрам-мастер,
3. команда разработчиков.

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

• подсчет ресурсов (ПО, времени, кадров) для успешного выполнения каждого спринта;
• отслеживание изменений в требовании клиента к продукту;
• предоставление четких ТЗ команде.

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

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

Как проводится спринт

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

Этап 1. Планирование

Продолжительность встречи —  от 2 до 8 часов (в зависимости от продукта и размера команды). На ней присутствуют все члены команды: разработчики, владелец продукта и скрам-мастер. Но что же нужно обсуждать?

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

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

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

После чего вся скрам-команда формирует Цель спринта и Бэклог для достижения поставленной цели.

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

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

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

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

Чтобы упростить планирование, можно использовать ICE-метод — нужно оценить каждую задачу по 3 параметрам:

1. I — Impact, показывает, насколько идея положительно повлияет на ключевые показатели, которые нужно улучшить (продажи, узнаваемость и др.).
2. E — Effort, помогает оценить сколько усилий и ресурсов потребуется для реализации этой идеи.
3. C — Confidence, демонстрирует, насколько команда уверена в легкости реализации каждой задачи. Если разработчики понимают, что не смогут выполнить одну из задач, не стоит включать ее в спринт.

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

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

Этап 2. Исполнение и отслеживание прогресса

После организации, команды приступают к работе. Главное в этом этапе — отслеживать промежуточные результаты. Для этого нужно проводить ежедневные мероприятия — Daily-встречи (или Daily Scrum).

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

Что следует обсудить на таком синхроне:

1. Что сотрудник сделал с момента прошлой встречи для достижения цели?
2. Что разработчик планирует сделать сегодня?
3. Есть ли какие-то препятствия для его работы (или работы команды)?
4. Если да, то как их решить?

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

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

Этап 3. Обзор и тестирование (Sprint Review)

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

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

Этап 4. Ретроспектива спринта

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

Важно! Ретроспектива — это не публичная порка и не обсуждение проекта под бокал шампанского. Цель встречи в том, чтобы Scrum-команда:

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

Продолжительность ретроспективы: 1,5-3 часа. Чтобы встреча прошла успешно, скрам-мастер может распределить тайминг на такие шаги:

Шаг 1. Приветствие и создание приятной атмосферы, чтобы «включить» всех участников в обсуждение. К примеру, можно узнать, как коллеги оценивают прошедший спринт от 1 до 10, или спросить с каким словом ассоциируется спринт. Открытие занимает 10% от общего времени.

Шаг 2. Сбор данных — возможность высказаться каждому члену команды. Например, рассказать о плюсах и минусах прошедшего спринта или поделиться мыслями о том, что можно улучшить. Время на этап — примерно 40% от общего.

Шаг 3. Генерация идей. Время — 20% от встречи. За это время важно обозначить проблемы, возникшие в ходе работы, и найти способы их решения. Для этого можно использовать разные техники, например, мозговой штурм или составить матрицу идей.

Шаг 4. Выбор оптимальных решений. Тайминг — 20% времени. Сотрудники выбирают те идеи, которые могут пригодится в следующем спринте и формулируют из них четкие задачи. К примеру, если новый сотрудник Маша выложила непроверенный код, можно попросить отдавать его на тестирование опытному коллеге Васе.

Шаг 5. Завершение встречи занимает примерно 10% времени. Нужно подвести итоги и собрать обратную связь о ретроспективе.

Советы для проведения успешного спринта

Чтобы спринт прошел успешно, нужно:

• Убедиться, что команда правильно понимает цель спринта. Если участники спринта не поймут, зачем они это делают, разработчики не смогут выдать крутой результат.
• Визуализировать процесс работы, используя Scrum-доску. На ней размещаются задачи и отслеживается их статус в рамках текущего спринта. Доска может быть виртуальной или реальной.
• Сделать четкий и понятный бэклог. В идеале для каждой задачи проставить дедлайн, приоритет и обозначить зависимость задач друг от друга. Если не сможете организовать прозрачный рабочий процесс, спринт будет похож не на бег по дорожке стадиона, а пробежку по болоту с завязанными глазами.
• Отбрасывать задачи, которые блокируют карточки вашей команды. В идеале не брать на спринт задачи связанные с работой смежных команд (дизайнеры, бухгалтерия и т.д.).
• Фиксировать на доске все идеи, решения или планы, которые обсуждаете на встречах. Так вы точно не потеряете важную информацию.
• Трезво оценивать силы команды, учитывая количество сотрудников в штате, отпуска и время на общие собрания с коллегами. Если понимаете, что не успеете выполнить задачу за спринт — не берите ее в работу.
• Не зацикливаться на скорости. Главное, чтобы все участники проекта работали в одном направлении. Прислушивайтесь к сотрудникам — если коллеги не успевают, всегда можно внести коррективы по необходимости.
• Анализировать проделанную работу, чтобы в дальнейшем оптимизировать и рабочие процессы, и итоговый продукт.

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

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

Если вам удобнее работать с онлайн-сервисами, можете сделать виртуальную доску в Кайтен. Например, у нас есть готовый шаблон для работы по Скраму. Он состоит из доски Backlog и Sprint с тремя колонками: «Бэклог», «В работе» и «Готово».

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

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

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

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

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

Вместо итога

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

Спринты в проекте помогут эффективнее справляться с большими и сложными задачами. Благодаря чему можно:

• Улучшить качество. Из-за регулярных встреч в конце спринтов, члены команды смогут проанализировать проделанную работу и понять, с чем команда справляется лучше всего, а где буксует.
• Повысить производительность. Все сосредоточены на одной задаче: не нужно «прыгать» между разными проектами.
• Адаптироваться к изменениям. Команда сможет менять продукт по требованию заказчика или адаптировать его под изменяющийся рынок на ходу.
• Улучшать коммуникацию сотрудников. В цикле спринта (Scrum sprint cycle), команды обязаны работать над продуктом вместе, из-за чего могут оперативно решать вопросы и учиться чему-то друг у друга.
• Минимизировать риски. Регулярно встречаясь на митингах и ретроспективах, сотрудники выявляют и оперативно решают проблемы.
• Сделать работу прозрачнее. В планировании спринта и его проведении команда фиксирует задачи на досках. Благодаря таск-трекеру можно оценивать количество задач и загруженность сотрудников. Также вся коммуникация специалистов сводится в одно место — участникам проекта проще распределять обязанности и общаться с заказчиками внутри сервиса.