Как совместить гибкость Agile и жесткие сроки: рабочие стратегии для команд

Вольный перевод статьи Agile and deadlines: How to align Agile delivery with long-term planning, опубликованной на сайте agilealliance.org

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

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

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

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

Стабильная скорость (velocity): ключ к предсказуемости

Первый шаг — добиться стабильной скорости работы команды. Velocity — это объём задач, который команда завершает за один спринт. Обычно его считают в story points или просто по количеству задач. Важно: задачи, над которыми ещё ведётся работа, не засчитываются.

Чтобы контролировать отклонения, фиксируйте разницу между запланированными и выполненными story points в каждом спринте.

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

Возможно, ещё важнее — удерживать отклонения под контролем.  

Отклонения (variance) — это разница между запланированными задачами и фактическим результатом в баллах. Иногда производительность команды (velocity) падает по объективным причинам: наступают праздники или кто-то уходит из команды. В таких случаях скорость работы может снизиться. Но если команда умеет грамотно планировать, отклонения останутся стабильными, даже при снижении темпа.

Например, если спринт выпадает на новогодние праздники, команда уже заранее знает, что часть участников возьмёт выходные. Это не мешает провести планирование спринта с учётом того, что ресурсов станет меньше. Скорость, скорее всего, снизится, но уровень отклонения может не измениться.

PI planning: как команде собраться и двигаться вперёд

Термин PI planning (Program Increment — программный инкремент) не встречается в Scrum Guide, но стал популярным благодаря SAFe (Scaled Agile Framework). Многие гибкие команды успешно внедрили этот подход. Суть проста: раз в квартал команды и заинтересованные участники собираются вместе, чтобы согласовать общие цели и видение. На встрече они выбирают задачи, которые планируют завершить за несколько ближайших спринтов.

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

Обычно PI planning охватывает квартал, но ничто не мешает заглянуть дальше — на несколько инкрементов вперёд или даже составить дорожную карту (roadmap). Главное здесь — не переусердствовать. Если строить дорожные карты неправильно, легко попасть в ловушку типичных ошибок и нежелательных сценариев. Чтобы их избежать, разберём, как обычно создают классические дорожные карты.

Только начинаете знакомиться с Agile-подходом? Приглашаем на курс Базовый Agile: основы Scrum, Kanban и командной работы

Дорожные карты на практике: почему эмпиризм работает

Мы все знаем: эмпиризм — это основа гибких методологий, таких как Scrum. Но давайте ненадолго остановимся и уточним: что именно мы подразумеваем под эмпиризмом?

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

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

1. Планирование от финальной даты

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

2. Оценка трудозатрат по алгоритму

Здесь продукт разбивают на отдельные функции. Для каждой функции считают показатели: сколько потребуется экранов, строк кода, насколько сложна бизнес-логика, сколько раз система обратится к базе данных и так далее. Эти данные подставляют в специальную формулу, чтобы посчитать, сколько человеко-дней уйдёт на каждую задачу.

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

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

Вместо этого стоит использовать уже упомянутые метрики скорости (velocity) и отклонения (variance). С их помощью можно создать куда более точный прогноз и построить реалистичную дорожную карту.

Как выстроить иерархию рабочих задач, чтобы всё было прозрачно

Работая с инструментами вроде Jira, мы обычно связываем задачи с пользовательскими историями (stories), а истории — с эпиками (epics). Можно пойти дальше и добавить более крупные элементы, такие как инициативы (initiatives), темы (themes) или возможности (capabilities). Эпики привязываются к ним. Например, тема (theme) может объединять сразу несколько эпиков.

Часто в отрасли такие темы формулируют слишком размыто и абстрактно. Например:

• Сделать мобильное приложение удобнее и красивее
• Добавить новые отчеты в систему

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

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

Хотя само понятие жёстких сроков (дедлайнов) в какой-то мере чуждо гибким методологиям, продуктовые цели — их неотъемлемая часть. Почему бы не превратить наши темы в чёткие продуктовые цели и не формулировать их по принципу SMART: конкретно, измеримо, достижимо, актуально и с ограниченным сроком? Вот несколько примеров:

1. Привести внешний вид мобильного приложения в полное соответствие корпоративным стандартам UI/UX к релизу 4.2.

2. Внедрить модуль отчетности к ноябрьскому релизу. (Можно дополнить критериями приемки, чтобы сразу было понятно, какие отчеты нужны)

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

Жёсткие сроки или осознанные цели: что выбрать?

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

Дедлайны

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

Такой подход явно противоречит духу гибких методологий.

Зачем нужны продуктовые цели?

Scrum Guide (Руководство по Scrum) описывает цели продукта как «ориентир для команды Scrum при планировании». Это значит, что цель должна быть конкретной и иметь чёткие сроки — иначе команде будет сложно понять, как к ней прийти.

Как совместить гибкость Agile и жёсткие сроки

Возможно, строгие дедлайны и гибкая методология (Agile) никогда полностью не совпадут — и это нормально. Но мы уже видим, что Agile-фреймворки могут стать более конкретными и учитывать время. Они помогают строить не только долгосрочные, но и среднесрочные планы. Что для этого важно? Нужно стабилизировать темп работы, проводить взвешенное PI planning (планирование инкремента программы), связывать задачи с целями продукта и опираться на опыт при создании дорожной карты. При этом важно не потерять главные ценности Agile.

В любом случае, как напоминает Agile Manifesto (Манифест гибкой разработки), мы всегда должны быть готовы меняться, а не просто следовать плану. Даже если требования меняются на поздних этапах — это не повод останавливаться.

Где больше узнать об Agile и командной работе?

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

💡 Проверьте, насколько хорошо вы разбираетесь в Agile-подходах — пройдите один из наших тестов. Вы не только узнаете свой уровень, но и получите разбор ошибок и персонализированные рекомендации.

💡 А тем, кто хочет систематизировать основы Agile, подойдет курс «Базовый Agile: Scrum, Kanban и командная работа». Вы получите четкое понимание Scrum и Kanban, научитесь применять Agile-практики и сможете уверенно участвовать в процессах.