Коротко о главном
Спринт нужен для того, чтобы работа по проекту шла быстрее и можно было в любой момент поправить ошибку в коде или внести изменения в технические требования. Итеративный подход — это основа в методологии Scrum, а спринт — инструмент, который используют для достижения гибкости в проектах, где много неопределённости. Во время спринта важно соблюдать события, следовать назначенным ролям, отслеживать метрики и постоянно взаимодействовать во время работы.
Что такое спринт в методологии Scrum
— это короткий цикл работы над продуктом, за который нужно успеть выполнить определённый набор задач и проанализировать промежуточный результат. В Scrum вся работа делится на спринты по 1–4 недели каждый
Scrum — это фреймворк гибкого подхода в управлении проектами Agile. Он помогает контролировать ход работ, следить за результатами и эффективностью команды.
Спринты помогают работать над продуктом в условиях неопределённости. Если меняются обстоятельства, рынок или пожелания заказчика, команда может скорректировать планы. Главное, чтобы изменения не противоречили цели спринта и не снижали качество продукта.
Результат спринта — это готовый и протестированный продукт или его часть, которой уже можно пользоваться. В дальнейшем версию конкретного продукта будут обновлять и дорабатывать.
Кто участвует в спринте
В методологии Scrum участники спринта разделены на зоны ответственности — это называют ролями. Их всего три.
Владелец продукта (Product Owner, PO)
Член команды Scrum, который доносит до всех участников процесса ценность продукта. Владелец продукта общается напрямую с клиентами и партнёрами, собирает обратную связь по работе и передаёт информацию и пожелания команде. Также в его задачи входит вести бэклог и ставить понятные задачи разработчикам.
Скрам-мастер (Scrum Master, SM)
Следит, чтобы команда соблюдала принципы и ценности методологии Scrum. Выступает в роли наставника, собирает обратную связь у команды по рабочим процессам и решает конфликты, если они возникают. Скрам-мастер помогает корректировать бэклог и ищет оптимальные решения для планирования работы в разных условиях.
Команда (Developers)
Это техническая часть Scrum-команды, в которую входят специалисты разных направлений: разработчики, тестировщики, UX-дизайнеры и другие эксперты. Они отвечают за создание качественного продукта, самостоятельно организуют свою работу и выполняют все технические задачи, которые нужны для достижения целей продукта.
Как выбрать продолжительность спринта
Каждый рабочий цикл нужно планировать так, чтобы не выбиться из сроков проекта в целом, но и не загнать команду. Итогом спринта должен стать инкремент — завершённая часть продукта, которая соответствует определению готовности (Definition of Done) и потенциально готова к релизу. Ниже объясним термины и зачем они нужны. Пока посчитаем, какие сроки обычно закладывают для спринтов.
| ⏱️ Сроки | 🧠 Когда подходит |
|---|---|
| Одна неделя | На случай, если нужно почаще проверять гипотезы или получать обратную связь. Так работают команды, которым важна высокая динамика, — например в стартапе, при запуске эксперимента или для регулярных продуктовых улучшений |
| Две недели | Классика работы спринтами: хватит и на детальное выполнение, и на вдумчивый анализ |
| Три недели | Расширенная версия для более сложных разработок и длительных согласований. Такой спринт можно проводить, например, для дизайна сайта с нуля: готовить разные версии страниц и отдавать на утверждение сразу всю работу |
| Четыре недели | Максимальная длительность спринта в Scrum, удачная при предсказуемом развитии продукта или в длинных фазах производства |
✏️ Длина спринта должна оставаться постоянной для всей работы над продуктом, чтобы команда могла прогнозировать скорость работы и постепенно улучшать процесс
Что подготовить перед спринтом
Нельзя просто так взять и запланировать спринт, не сделав предварительную подготовку. Ниже будет небольшой чек-лист, который поможет ничего не упустить и приступить к работе с полной уверенностью, что команда на правильном пути. Но сначала — базовые понятия, с которыми тебе нужно познакомиться на этапе подготовки к спринту.
Цель продукта (Product Goal)
Это долгосрочная цель, к которой стремится Scrum-команда. Она задаёт общее направление развития продукта и помогает понимать, зачем выполняются задачи из бэклога. Product Goal делает работу команды более прозрачной и помогает расставлять приоритеты. Это ориентир для планирования каждого спринта.
Бэклог продукта (Product Backlog)
Список улучшений и задач для развития продукта. Перед планированием владелец продукта актуализирует приоритеты, а команда добавляет описание, критерии приёмки, оценку и при необходимости делит крупные задачи на более мелкие. Из бэклога продукта команда забирает задачи на спринт.
Определение готовности (Definition of Done, DoD)
Единый набор требований к качеству инкремента. Каждое требование — пункт в чек-листе, который отвечает на вопрос «Когда можно считать, что работа выполнена?» Например, код прошёл ревью, тесты выполнены, документация обновлена, а результат можно использовать.
Данные о доступности команды
До планирования собери данные о доступности команды: отпусках, больничных, праздниках, частичной занятости, обязательных встречах и другой работе вне спринта. На их основе команда оценивает capacity — доступный объём усилий команды на предстоящий спринт.
🤔 Чек-лист: что проверить перед спринтом
Посмотреть бесплатно и без смс →Как проводится спринт
Для того чтобы спринт завершился без нервотрёпки, нужно следовать шагам ниже, быть внимательным и не пренебрегать ценностями Scrum. Понимаем, что написать проще, чем сделать. Но до практики мы ещё доберёмся.
Шаг 1. Планирование спринта (Sprint Planning)
Рабочая сессия планирования перед началом спринта. На ней формируют цель и бэклог, после чего назначают ответственных. Чем длиннее планируется спринт, тем дольше эта встреча — но обычно не более 8 часов.
Официальное руководство по Scrum советует обсудить во время планирования спринта эти три вопроса:
- Почему этот спринт ценен? Владелец продукта объясняет, каким образом спринт может повысить ценность продукта, а затем вся команда совместно формулирует цель спринта
- Что можно сделать за этот спринт? Разработчики выбирают элементы бэклога продукта, которые, по их прогнозу, получится завершить в течение спринта
- Как будет выполнена работа? Команда разбивает выбранные элементы на задачи или части работы, достаточно небольшие, чтобы ежедневно отслеживать прогресс
Планирование спринта — длительный и ресурсозатратный процесс. Короткий план действий ниже поможет провести церемонию так, чтобы у команды не взорвался мозг.
Выходим из абстракции и попробуем объяснить, как планировать спринт на конкретном примере конкретного улучшения, которое нужно продукту. Пользовательский запрос — получить быстрый код для восстановления пароля на сайте компании Х на почту, чтобы не ломать голову лишний час.
Итак, вот что нужно сделать владельцу продукта, чтобы команда справилась с этой задачей.
| Шаг | Что делать |
|---|---|
| Пройдись по бэклогу | До встречи сверь приоритеты и проверь, готовы ли важные задачи к работе. У них должны быть понятное описание, оценка и критерии приёмки |
| Расскажи команде, что происходит | Коротко напомни, где сейчас находится продукт, что уже сделали и что важно дальше. Например, пользователи часто забывают пароль, поэтому команда хочет дать им возможность восстановить его без помощи поддержки |
| Сформулируй цель спринта | Одним предложением скажи, к какому результату команда должна прийти и зачем он нужен пользователю. Например: дать пользователям возможность самим восстановить пароль по электронной почте |
| Выбери задачи | Возьми из бэклога только те задачи, которые помогут достичь цели спринта. Учитывай сложность, связи между задачами и свободное время команды |
| Подумай, что может пойти не так | Обсуди с командой возможные проблемы и сразу реши, что делать, если они возникнут. Например, письмо для сброса пароля может попасть в спам или прийти с задержкой |
| Разбей крупные задачи | Подели большую работу на небольшие понятные шаги. Так будет проще распределить задачи и каждый день видеть прогресс |
| Сверься с загрузкой команды | Посмотри, кто будет в отпуске, у кого есть другие проекты и сколько времени команда реально сможет уделить спринту. Если времени мало, лучше сразу взять меньше задач |
| Убедись, что всё понятно | В конце ещё раз сверься с командой: все ли понимают цель спринта, свои задачи и ожидаемый результат |
Шаг 2. Начать выполнять задачи и отслеживать процесс на дейликах
Приступив к работе, разработчики обновляют бэклог спринта по мере появления новых данных. На доске можно отмечать статусы, препятствия и оставшийся объём работы. Прогресс регулярно сверяют с целью спринта, а готовый результат — с Definition of Done. Если план больше не ведёт к цели, его корректируют, не дожидаясь конца спринта.
Каждый рабочий день проводят дейлики — встречи продолжительностью не больше 15 минут. На них оценивают прогресс на пути к цели спринта и планируют работу до следующего дейли.
Шаг 3. Управлять изменениями во время спринта
Препятствий и прочих неприятных ситуаций в работе не стоит бояться — почти всегда можно предотвратить кошмар или решить проблему быстрее и с минимальными потерями.
- Ориентироваться на цель спринта. Если появляется новая задача, первый вопрос, который стоит задать: помогает ли она достичь цели спринта? Если да, её можно добавить, если нет — отправить в продуктовый бэклог или рассмотреть на следующем планировании
- Не паниковать. При критическом баге можно добавить задачу в спринт, перенести на следующий спринт или отменить спринт вообще. Последнее — редкий вариант, когда цель спринта потеряла смысл. Но он допускается, и да, такое бывает
- Фиксировать все ошибки и расхождения с изначальными ожиданиями. Их нужно будет обсудить на ретроспективе, чтобы улучшить процессы работы команды
Планирование загрузки на 80–90% и выполнение важных задач в начале спринта поможет пережить форс-мажоры. Но не гарантирует, что их не будет.
Шаг 4. Провести обзор спринта (Sprint review)
Обзор спринта — предпоследняя встреча в конце спринта, на которой Scrum-команда вместе с заинтересованными сторонами оценивает готовый инкремент, обсуждает полученную ценность и определяет дальнейшие приоритеты.
На этом этапе все участники рабочего процесса понимают, как выполненная работа связана с развитием продукта, и могут скорректировать планы с учётом новых данных.
Шаг 5. Провести ретроспективу (Sprint Retrospective)
Ретроспектива спринта — встреча, в которой участвует только команда, чтобы обсудить успехи и провалы в рабочих процессах. Вместе фиксируют удачные решения и разбираются в ошибках, которые могли возникнуть во время работы и повлиять на результат.
На ретроспективе Scrum-команда разбирает не получившийся результат, а способ работы: взаимодействие людей, процессы, инструменты и соблюдение определения готовности.
💙 Лови подарок! Отрываем от сердца шаблон с примерным сценарием для ретроспективы, которым ты можешь пользоваться без зазрения совести.
Как оценивать результат спринта в Scrum
Фух, спринт запланирован и завершён! Время оглянуться назад — провести ревью и ретроспективу. Сейчас назовём показатели, на которые удобно опираться при оценке.
Достигла ли команда цели
Цель спринта показывает, получила ли команда тот результат, ради которого начала спринт. При этом ей не обязательно закрывать все элементы бэклога.
Незавершённая работа не переходит в следующий спринт автоматически. Она возвращается в продуктовый бэклог. Там её можно уточнить, переоценить или поставить ниже в списке приоритетов. На ретроспективе команда обсуждает, что помогло достичь цели, что помешало и какие идеи стоит применить дальше.
Создала ли команда готовый инкремент
Помним, что это готовый к работе результат, который приближает продукт к цели. За один спринт команда может создать несколько инкрементов.
Результат в 99% не считается 🙂↔️ Результат становится частью инкремента, только когда отвечает определению готовности.
Принёс ли результат пользу
На ревью команда и заинтересованные стороны обсуждают не только объём работы, но и её пользу. Как пользователи отреагировали на результат? Что изменилось на рынке? Как новые данные повлияют на продукт и дальнейшие приоритеты? Ответы помогут выбрать следующие шаги.
Какие метрики использовать для отслеживания результатов?
Показатели выше помогают достичь цели текущего спринта, но следом будут новые. Сохрани себе следующие метрики, чтобы команда росла и крепла с каждым спринтом:
- Время выполнения (Lead time). Период от момента, когда команда берёт обязательство выполнить задачу, до её полного завершения
- Время цикла (Cycle time). Время, которое сотрудники тратят на выполнение задачи
- Скорость (Velocity). Показывает, как много сторипоинтов закрыто за спринт
- Потенциал команды (Capacity). Измеряется в часах, которые доступны у сотрудников для выполнения задач
- Диаграмма сгорания (Burndown Chart). Показывает оставшийся объём работы и прогресс спринта в целом
- Пропускная способность (Throughput). Количество задач, завершённых за определённый период времени
Как запустить спринт в Weeek и повторить Scrum-процесс шаг за шагом
Теперь предлагаем отработать навыки на практике. Для примера посмотрим, как Scrum-процесс настраивает под свою команду Ирина — руководитель направления казуальных головоломок в инди-студии мобильных игр. Задача — выпустить на рынок новую игру на основе упражнений N-back для развития когнитивных способностей. Вот что она делает ⬇️
Шаг 1
Открой своё рабочее пространство, выбери слева кнопку «Создать проект» и впиши название, которое будет понятно всем коллегам. Ирина называет проект «Кампании Март», поскольку на месяц запланировано несколько релизов новинок. Для каждого будет отдельный спринт.
Шаг 2
Когда проект создан, Ирина сделала первую доску и сразу выбрала формат отображения задач «Спринт». Также указала его название и сроки — они будут отображаться в рабочем пространстве слева перед общим полем с задачами.
Шаг 3
Теперь настрой базовые колонки рабочего процесса. Например, у Ирины это Бэклог ➡️ К работе ➡️ Ревью ➡️ Готово. На каждый спринт можно создавать новую доску.
Шаг 4
Перед тем как стартует спринт, стоит подумать над продуктовым бэклогом. Собрать его можно в колонке на Канбан-доске или в отдельном документе списком задач.
Если выберешь первый вариант, в карточке задачи добавь описание, назначь приоритет, поставь исполнителя и оцени время на выполнение. Ещё в Weeek можно заводить подзадачи — они выглядят как чек-лист.
Ирине по душе собирать списком. Для этого она перешла в Базу знаний, создала новый документ и расписала там основные моменты — цель, сроки, инкремент и бэклог.
Ещё добавила обложку и сделала форматирование, чтобы с документом всем было приятно работать 😉
Шаг 5
Теперь переходим к планированию спринта, где команды обычно определяют его цель и выбирают задачи из бэклога — чтобы перенести их в колонку К работе. На протяжении всего спринта карточки задач будут двигаться по колонкам до тех пор, пока не будут сделаны.
Ирина использует в проекте WIP-лимиты — они помогают ограничивать количество задач в колонках, чтобы команда не перерабатывала.
Также Ирина настроила автоматизацию колонок. Когда задача попадает в колонку Ревью, у карточки автоматически появляется исполнитель. А когда задача оказывается в Готово — выполняется и зачёркивается.
Шаг 6
Создай в «Документах» одну заметку для записи идей и замечаний в бэклог, а другую — для фиксации проблем на «дейликах» и способов их решения. Всё это не только поможет коллективу в моменте, но и пригодится на ретроспективе, чтобы проанализировать все-все недочёты и стать ещё круче 💪
