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

Почему так происходит, что такое спринты и как они помогают команде двигаться быстрее, а не сгорать по пути? Разбираемся вместе с редакцией Kaiten.

Зачем так много разговоров о скорости и управляемости разработки? Объясняем на примере LEGO

Представим, что команде нужно собрать машинку из конструктора лего. 

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

Какие еще трудности могут возникнуть при таком подходе:

• У каждого компонента свой срок сборки — сложно «подстроить» все параллельные процессы под один дедлайн.

• Затрата времени на излишнюю коммуникацию между частями команды.

• «перетягивание» сотрудников между компонентами для ускорения сборки одного из них.

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

• Отсутствие прозрачности и предсказуемости: никто не может сказать, когда точно будет результат из-за хаоса в процессах.

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

Как избежать такой участи проекта? Можно пойти другой дорогой — разбить процесс на несколько этапов:

• распределение деталей по частям. Одна «кучка» для колес, другая — для кузова, третья — для кабины;

• сборка поддона;

• присоединение колес;

• компоновка деталей кузова;

• сборка кабины.

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

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

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

Что такое спринты в IT и как они помогают организовать процессы разработки

Спринт в программировании – это короткий, заранее ограниченный по времени отрезок работы, обычно от одной до четырех недель. За это время команда берет конкретный набор задач из бэклога (списка всех идей и требований) и фокусируется только на них. 

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

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

Преимущества использования спринтов в проекте:

• Понятные заранее оговоренные сроки каждого спринта. Заказчик понимает, когда ожидать результата.

• Фокус на конкретных задачах. Команда работает над ограниченным набором задач не распыляясь.

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

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

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

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

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

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

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

Какие критерии завершенности могут быть у команды разработки:

• все задачи, запланированные на спринт, переведены в статус Done в системе управления проектам;

• код покрыт юнит-тестами, интеграционные тесты пройдены;

• функциональность протестирована на staging-сервере;

• документация обновлена, баги критического уровня исправлены.

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

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

Пример в разработке:

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

Жизненный цикл спринта в разработке

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

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

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

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

4. Ретроспектива. Сотрудники оценивают, что можно улучшить в следующем спринте – выявляются стопперы в коммуникациях, пересматривают оценку задач. Вносят комментарии к планированию следующего спринта. Как правильно проводить ретроспективы, разобрали в статье вместе с сертифицированным проджект-менеджером. 

5. Подготовка к следующему спринту. Тимлид обновляет бэклог задач, просматривает, какие можно переложить на следующий отрезок работы, фиксирует итоги прошедшего, собирает метрики: Velocity, Burn-down chart и другие показатели эффективности. Ниже рассмотрим, какие из них можно автоматически собрать в системе управления проектами Kaiten.

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

Ошибки при организации спринтов 

Какие ошибки могут тормозить процесс работы по спринтам?

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

Нереалистичный объем задач. Команда планирует 20 задач на спринт, но за две недели успевает сделать только 12. Остальные переносятся в следующий спринт, что демотивирует команду и разрушает доверие заказчиков.

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

Контролировать нагрузку сотрудников помогают WIP-лимиты на досках системы управления проектами. 

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

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

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

Игнорирование критерия завершенности. Задачи переносят в колонку «Готово» без согласования, обсуждения и тестов. При сборке конструктора это может привести к тому, что машина в момент релиза просто не поедет из-за отсутствия какой-то важной детали. 

Некорректная оценка задач. Все задачи оценивают «на глаз», без обсуждения сложности. В итоге спринт перегружен, часть задач срывается, а команда выгорает. В других статьях редакции Kaiten разобрали, как оценивать задачи с помощью Story points и приоритизировать их по методам RICE и ICE. 

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

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

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

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

Как Kaiten помогает организовывать спринты в разработке

Kaiten — система управления проектами, где сотрудники в режиме единого информационного окна могут просматривать прогресс по всем бизнес-процессам. 

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

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

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

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

Простая настройка спринта

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

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

Еще в Kaiten есть подробные отчеты о работе команды по Scrum-методологии. Какие отчеты будут полезны для оценки эффективности спринтов:

Velocity chart. График скорости позволяет оценивать производительность всей команды и отдельных ее участников.

Чтобы график показывал корректные данные о выполненном объеме, нужно заполнить в каждой задачи поле «Размер» и поместить все планируемые задачи до старта спринта в колонку «Бэклог». Также график может отобразить число выполненных карточек. В этом случае поле «Размер» можно не заполнять.

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

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

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

Как запустить спринт с помощью системы управления проектами

Краткий алгоритм запуска спринта в проекте с помощью любого сервиса управления задачами и командой.

1. Создать спринт в системе с помощью шаблона. Отобразить основные этапы спринта и отдельно вынести бэклог. Обозначить цель, критерий завершенности и временные рамки.

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

3. Оценить вместе с командой объем каждой задачи. Сделать это можно с помощью Story points внутри карточек задач.

4. Распределить задачи между участниками. Система покажет загрузку каждого участника, чтобы избежать перегрузки при заполненном поле со Story points. 

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

6. Фиксировать критерий завершенности. Все ли задачи прошли тесты и проверку кода. Нужно ли доделать документацию, есть ли баги. Система не даст отправить карточку задачи в колонку «Готово», пока все критерии не выполнены.

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

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

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

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

Заключение 

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

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

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