Что такое управление спринтами и зачем это командам

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

Спринт в управлении проектами — это итерация. Так называют интервал времени, на протяжении которого команда решает определенную задачу или несколько задач. Sprint как инструмент управления используют agile-команды. В Scrum Guide 2020 Reordered сказано, что такой интервал может длиться до 4 недель. По его результатам команда обязательно выдает жизнеспособный продукт или отдельно работающую часть продукта.

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

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

По результатам команда выдает инкремент. Это промежуточный жизнеспособный результат. Например, если команда работает над сайтом, промежуточным результатом может быть работоспособный один из разделов. А, допустим, если наш проект — внедрение CRM-система, то одним из инкрементов может быть подключение к системе отдела техподдержки.

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

Спринт основан на теории эмпирического управления. В ее основе прозрачность, инспекция и адаптивность. Это три залога успеха итерации.

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

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

Любая итерация начинается с планирования. Команда проводит собрание, на повестке дня которого всего два вопроса:

1. Какую работу в состоянии осилить команда за предстоящую итерацию?
2. Как команда будет выполнять эту работу?

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

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

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

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

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

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

Схема спринта. Каждая итерация циклична и проходит по одинаковому сценарию. За одной итерацией всегда идет другая.

Управление спринтами означает четкое следование правилам и принципам скрама. Более-менее подробно мы описали их в статье про скрам. Если нужно подробнее, Scrum Guide 2020 Reordered в помощь. Так вот, частичное игнорирование этих правил и принципов убивает проект. Мы тоже используем методологию скрам в своей работе. За последние 2 года мы накопили достаточный опыт и готовы им поделиться. Мы смогли выделить 3 главных заблуждения, которые мешают нам (и, вероятно, другим гибким командам) добиваться успеха в проектах. Вот они.

Обратную связь иногда можно игнорировать

В Scrum Guide 2020 Reordered сказано: метод используется в первую очередь для разработки креативных продуктов. Продуктов, которые будут окупаться и приносить пользу потребителям, пользоваться спросом.

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

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

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

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

Итерация провалена, если не удалось достичь цели

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

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

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

Итерация не всегда завершается выпуском инкремента

Есть мнение, что итерация не всегда должна завершаться выпуском готового продукта. Те, кто так думает, видимо не читали руководство по скраму. Сочувствую им. Если не выпускать совсем ничего, то какие выводы мы можем сделать, какую обратную связь получим? Что покажем заказчику? А как же принципы эмпирической теории управления? Короче, это глупости: итерация должна завершаться выпуском инкремента. Точка.

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

Для примера привожу три разновидности таких итераций.

ZERO Sprint. Это итерация, после которой команда получает набросок бэклога продукта. Оценивают время, объем работы, собирают команду, прикидывают дату первого релиза. Если представить проект как приготовление блюда, то ZERO-sprint — это подбор рецепта, ингредиентов, подготовка необходимого кухонного оборудования. В таких действиях нет ничего плохого, часто это обязательная часть процесса.

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

Разработчик Скрама Кен Швабер писал так. «Именно… sprint 0 стал фразой, неправильно используемой для описания планирования, которое происходит до первого спринта. И поскольку планирование создает артефакты, которые часто меняются, его следует свести к минимуму. А планировать каждую новую итерацию нужно на обзоре и по результатам прошлой итерации».

С точки зрения событий SCRUM, ZERO Sprint не существует. Но на практике многие так называют этап планирования, которое выполняют еще до запуска скрама.

Design Sprint. Это пятидневный процесс для проверки идей и решения больших задач с помощью прототипирования и тестирования идей с клиентами. Его цель — создание набросков технической архитектуры и функционала, чтобы показать клиентам.

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

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

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

Hardening Sprint. Это итерация, посвященная стабилизации кодовой базы, чтобы она была достаточно надежной для релиза. Часто это необходимо, потому что команда по результатам одного из прошлых спринтов не смогла получить готовый инкремент. Осталась недоработка, и «укрепляющая» итерация призвана устранить недоработки, выдать результат, которого не удавалось добиться ранее.

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

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

Но стоит ли оно того? Нисколько! Команда тратит целый спринт на проблемы, которых не было бы, если бы она больше обсуждала особенности продукта и находила время на исправление косяков вовремя. Порядок в проекте — это хорошо, но все должно быть вовремя.

Чтобы работать над итерациями было проще, грамотные аджайл-команды используют программные решения. Конечно, можно вести kanban-доску и на бумаге, но так ведь неудобно. Нам повезло — у нас есть OkoCRM, в которой мы реализовали модуль «Проекты». Он помогает управлять командой, ставить задачи, наладить коммуникацию и отслеживать прогресс.

Задачи по итерации мы размещаем на канбан-доске. Тут же бэклог, рабочие процессы, карточки задач, назначение ответственных, и все для грамотного Sprint-управления.

Вот так выглядит модуль «Проекты» в OkoCRM. Он помогает нам управлять задачами и держать все процессы под рукой.

Вот три обязательных правила автоматизации, которые мы ввели для нашей команды:

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

1. Спринт — это короткая итерация. Промежуток времени, в течение которого команда решает одну или несколько задач. В результате итерации команд выдает какой-то жизнеспособный продукт или его часть. Итерации, которые завершаются без жизнеспособного продукта или правильных выводов, можно считать неудачными
   
2. Итерации всегда цикличны: они проходят по одному сценарию, включают одни и те же этапы и идут одна за другой. Значительная часть работы в рамках итерации — собрания команды. На них обсуждаются планы, результаты, перспективы. Есть даже собрания, которые проводят ежедневно
3. Чтобы грамотно управлять итерациями, нужно делать все по правилам согласно руководству скрам. Если нарушать кое-какие принципы, нарушается вся структура скрама. Четкое следование правилам — залог успеха итераций
4. Чтобы было проще управлять спринтами, команды используют инструменты автоматизации. Например, у нас есть OkoCRM, в котором реализован модуль «Проекты». Удобнее инструмента я не видел