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

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

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

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

Спринты чаще всего используют при работе по чистой методологии Scrum или ScrumBan. Метод придумали программисты, но сейчас его используют во всех проектах — от личных дел до крупного производства.

Например, в нашей компании Аспро по спринтам работают два отдела:

• разработчики облачных продуктов;
• маркетинг.

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

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

Как команды приходят к работе по спринтам

Обратимся к опыту нашей команды. Отдел разработки всегда работал по спринтам. Однако поначалу это было совершенно неэффективно.

Внутри направления облачных продуктов есть отдельные продуктовые команды, которые разрабатывают свой модуль Аспро.Cloud. Мы начинали с того, что у каждой из них был свой «спринт». Но такой подход был скорее формальным. Да. мы планировали какие-то задачи, но каждый выполнял их по своему желанию, потому что спринт не был фиксирован по времени. Кто-то укладывался в 2 недели, кто-то в месяц. Поэтому задачи тянулись, тянулись и тянулись.

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

Василий Ферапонтов, директор по Saas Аспро

А вот в отделе маркетинга ситуация иная. Работать по спринтам сотрудники начали не сразу, но из-за большой нагрузки и отсутствия прозрачности в процессах это стало необходимостью.

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

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

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

Алина Абдулвалеева, руководитель отдела маркетинга Аспро

Длительность спринта

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

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

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

На все это нужно время. И всегда есть шанс, что тестирование найдет ошибки, и задача вернется на доработку.

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

Василий Ферапонтов, директор по Saas Аспро

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

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

Недельный спринт решает эту проблему. Это как короткий забег на километр: есть старт в понедельник и финиш в пятницу. Такой ритм помогает быстро расставлять приоритеты и не откладывать важное, держать команду в темпе и «перезагружаться» каждую неделю.

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

Алина Абдулвалеева, руководитель отдела маркетинга Аспро

Также можно ставить разную продолжительность спринта в зависимости от этапа работы над продуктом.

Несколько советов, как определить оптимальную длительность спринта:

1. Если команда только начинает работать по Scrum, делайте короткие итерации в 1–2 недели. Иначе коллегам будет трудно сфокусироваться на приоритетах.
2. Спросите у заказчика, как часто он может давать обратную связь, потому что он должен участвовать в каждом спринте. В Scrum важно тесное сотрудничество команды с клиентом, и если он готов выходить на связь только раз в месяц, то придется сделать такую длину цикла.
3. Чем больше неопределенности в задачах, тем короче спринты в проектной деятельности. Будет много уточнений и новых данных, поэтому лучше не затягивать с инкрементом.

Как строится работа по спринтам

Над каждым спринтом команда работает в несколько этапов:

Разберем каждый их подробнее.

Планирование

Команда вместе с заказчиком решает, какие задачи можно выполнить за 2–3 недели. Коллеги оценивают ресурсы и объем задач, а также их приоритетность. У задач нужно определить трудоемкость, в Scrum обычно используют Story Points — условные единицы трудозатрат, которые помогают сравнить сложность одной задачи с остальными.

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

В результате планирования несколько задач переносится из бэклога проекта в бэклог спринта. То есть формируется список приоритетных дел на ближайшие 2–3 недели, в который уже нельзя вносить изменения. Но так работает только в чистом Scrum. Однако в Аспро оба отдела совмещают Scrum и Kanban, это вынужденный подход.

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

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

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

Алина Абдулвалеева, руководитель отдела маркетинга Аспро

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

Аспро.Cloud — это «‎живой продукт»‎, клиенты каждый день используют его в работе. Сложная бизнес-логика, много взаимозависимости, неидеальная архитектура могут провоцировать критичные ошибки. И их нужно очень быстро исправлять. Буквально немедленно. Мы не можем ждать следующие две недели. Поэтому мы просто закладываем некоторый объем спринта на решение инцидентов, которые могут возникать.

Василий Ферапонтов, директор по Saas Аспро

Выполнение

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

Стендапы в Аспро проводят и отдел маркетинга, и отдел разработки. В первом случае это одна ежедневная встреча руководителя с командой, которая занимают не больше 10-15 минут.

В разработке же каждый день проходит по 2 встречи:

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

2. После этого встречаются продакт-менеджеры каждой команды и директор по Saas.

Такое дробление позволяет мне быть в курсе того, что вообще происходит. Да, зоны ответственности у нас разделены по командам, но продукт глобально один — all in one. И кто бы там что-нибудь свое не разрабатывал, оно должно тесно взаимодействовать со всей системой. Я считаю, что общее инфополе — очень важная вещь.

Василий Ферапонтов, директор по Saas Аспро

Обзор

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

Мы проводим обзор по окончании каждого спринта, так как его завершение — это всегда какое-то улучшение в продукте. У нас это называется демонстрацией, она длится примерно 30-40 минут. Каждый продакт-менеджер готовит презентацию и показывает, какие доработки или апдейты были реализованы за прошлый спринт.

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

Василий Ферапонтов, директор по Saas Аспро

Ретроспектива

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

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

По сути, у нас встроенные «малые ретроспективы»: планерки, one-on-one встречи, ежедневные стендапы. Это позволяет решать вопросы быстро и не дожидаться отдельного большого собрания.

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

Алина Абдулвалеева, руководитель отдела маркетинга Аспро

Несколько советов Алины, как проводить ретроспективу:

1. Высказаться должны все. Даже если кажется, что добавить нечего, это создает ощущение, что мнение каждого важно.
2. Иногда ретро — это не про действия, а про эмоции. Команде бывает достаточно «выпустить пар» в безопасной среде. Постоянное негативный фон разрушает командный дух, но раз в квартал или год — это полезная разгрузка.
3. Ретро должно заканчиваться конкретикой: кто что меняет и за что отвечает. Иначе это превращается в разговор ради разговора.

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

Как эффективно работать по спринтам в Аспро.Cloud

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

Заполняйте и корректируйте бэклог проекта

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

В Аспро.Cloud есть отдельный инструмент «‎Бэклог», в котором можно создать все планируемые задачи. Это позволяет хранить все в одном месте и быстро планировать спринты.

Пример бэклога в системе Аспро.Cloud

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

Кроме фиксированных полей, есть пользовательские — их можно настроить под особенности проекта и требования команды.

Узнайте больше про инструменты системы

Пример карточки задачи в системе Аспро.Cloud

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

Пример объединения задач по категориям

Планируйте итерации

Во время встречи с командой нужно оценить объем работы и выделить приоритетные задачи — это бэклог спринта. Создайте в Аспро.Cloud спринт, укажите его название, добавьте описание, дату начала и окончания.

Создание спринта в Аспро.Cloud

Создание спринта в Аспро.Cloud

Потом наполните его задачами, сделать это можно тремя способами:

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

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

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

Пример канбан-доски спринта в проекте

Контролируйте показатели и проводите ретроспективы

Проводите ежедневные стендапы, чтобы делиться результатами и планами развития продукта или проекта. Если команда удаленная, то общаться можно во встроенном чате Аспро.Cloud.

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

Пример отчета сгорания задач. В Аспро.Cloud он формируется автоматически.

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

Автоматизация работы в Аспро.Cloud

Аналитика в Аспро.Cloud помогает оценивать эффективность команды. В отчетах можно фильтровать показатели по каждому сотруднику или типу задач. А конструктор ретроспектив позволяет руководителю за несколько минут спланировать сценарий встречи и провести ее онлайн.

Встроенный конструктор респектив в Аспро.Cloud позволяет быстрее и эффективнее готовится к командным встречам.

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

Спринт–задачи — это особенность не только Scrum-подхода, но и таких гибких методологий как LeSS или SAFe. По данным отчета ScrumTrek в России только 30% компаний, которые практикуют Agile, используют чистый Скрам, остальные смешивают его с Kanban или разрабатывают свои уникальные бизнес-процессы. И вне зависимости от того, насколько «чистую» гибкую методологию используют компании, в процессах находится место спринтам. И вот почему с ними работать удобнее:

1. Адаптивность. Любые новые требования или правки легче учесть, когда есть промежуточный вариант. Задачи стоят не на год вперед, а только на 2–3 недели, поэтому их список можно легко пересмотреть — и планы при этом не рухнут. В отличие от того, как задачи планируют на год вперед в Waterfall, в Scrum команда смотрит на вещи более гибко. Появилась новая идея — отлично, учтем ее в следующем спринте Заказчик захотел изменений — скорректируем план.
2. Обратная связь. Во время планирования и обзора команда встречается с клиентом. Это может быть и онлайн-встреча, но главное — получить фидбэк. Тесное сотрудничество повышает удовлетворенность заказчика. Он всегда знает, что происходит с проектом: на какой он стадии, какой промежуточный результат. А команде не нужно тратить ресурсы на выполнение задач, которые уже могут быть неактуальны для продукта.
3. Фокусировка на конкретных задачах. Бэклог каждого спринта имеет ограниченное число задач. Исполнители не распыляются на несколько дел, а сосредоточены на текущих целях.
4. Точная оценка трудозатрат. Легче определить ресурсы на месяц вперед, чем на весь проект. Когда пытаешься заранее распланировать время, человеческие ресурсы и деньги на большой проект, часто бывают перерасходы — что-то не учтено, где-то появились новые задачи, изменились условия, и уже нужно потратить больше, чем в плане.
5. Прозрачность процессов и результатов. В ходе итерации коллеги проводят ежедневные стендапы. Каждый шаг виден руководству, клиентам и сотрудникам, а значит, можно вовремя заметить отклонения от плана и скорректировать работу команды.
6. Визуализация. Задачи всего спринта находятся на Scrum-доске — сперва в левой колонке, как нерешенные, а потом постепенно они переходят в правую часть, с пометкой «выполнено». В любой момент можно быстро оценить, как идет работа и где задачи стопорятся.
7. Снижение рисков. Регулярные обзоры и ретроспективы помогают быстро выявить проблемы и устранить их уже на следующем цикле. А постоянное общение и прозрачность — залог быстрого принятия решений.

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

1. Нехватка времени. Если исполнитель не успевает закончить задачу за итерацию, он может сделать ее некачественно или просто отметить как выполненную, а доработать потом. Эти недоделки или костыли в разработке накапливаются, со временем могут стать большой проблемой. Решается это контролем руководителя и обратной связью от исполнителей.
2. Много микроменеджмента. Гибкие методологии должны бороться со злом бюрократии, а не возглавлять его. Но ежедневные митинги, ретроспективы, планирование и статистики могут стать бюрократической рутиной — формальностью, на которую команда тратит время вместо работы. Так случается, если в Scrum добавляют слишком много менеджеров, а в отчеты — показателей.
3. Отказ клиента сотрудничать. Нередкая ситуация: команда ждет фидбэк от заказчика, а его нет. Пора начинать новый цикл, но планы не согласованы. Решается проблема общением с клиентом: нужно донести до него ценность тесного сотрудничества.

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