Agile планирование: как построить график проекта при неопределённости — практики

Agile‑планирование — это способ собрать рабочий график проекта без иллюзий точности: выйти на предсказуемые поставки каждые 1–2 недели и вменяемый прогноз на 1–3 месяца можно за 2–4 спринта, но ключевой риск — вы начнёте «рисовать сроки», не имея потока данных (скорости команды) и нормальной декомпозиции.

Почему “график” в Agile вообще возможен (и почему у многих он фейковый)

Классическая боль: бизнес хочет дату, команда хочет не умереть, продакт хочет «чуть-чуть ещё фичу», а менеджер — Gantt, чтобы всем было спокойно. Проблема в том, что при неопределённости график уровня «всё до 15 июня» — это не планирование, это успокоительное.

Agile не запрещает график. Он запрещает делать вид, что вы знаете детали на горизонте полугода. Рабочая модель такая: точно планируем близко (1–2 итерации), примерно планируем средне (1–3 месяца), и держим намерение по дальнему горизонту (квартал/полгода) через темы и гипотезы, а не через список из 247 задач.

Что значит “построить график” в Agile: три горизонта

1) Горизонт 0–2 недели: план поставки (Sprint/Iteration plan)

Тезис: на коротком горизонте нужен не «график», а конкретный список инкрементов и критериев готовности.

Практика: берёте верх бэклога, дробите до задач 0.5–2 дня, фиксируете Sprint Goal и Definition of Done. Это и есть ваш график — в терминах ценности, а не человеко-часов.

Подводный камень: планировать «занятость людей» вместо «готовых результатов». Команда занята всегда. Пользователю от этого ни тепло ни холодно.

2) Горизонт 1–3 месяца: прогноз релиза (Release forecast)

Тезис: прогноз строится из наблюдаемой скорости, а не из пожеланий.

Практика: после 2–4 спринтов у вас появляется velocity (в сторипоинтах или throughput в штуках). Тогда можно оценить: “Вот этот объём обычно делаем за X спринтов”. И у вас рождается дата “с вероятностью”.

Подводный камень: менять команду или правила посреди расчёта и удивляться, что прогноз поплыл. Скорость — характеристика системы, а не героизма.

3) Горизонт квартал+: дорожная карта (Roadmap) без самообмана

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

Практика: roadmap в формате Now/Next/Later или квартальные цели (OKR/инициативы). Для каждой темы — гипотеза, метрика успеха, “что будем считать поставкой”.

Подводный камень: “roadmap = обещание”. Нет. Это меню, которое меняется по данным.

Минимальный набор артефактов, чтобы график не развалился

Практики, которые реально помогают при неопределённости

Практика 1. Планирование от “ценности” и MVP (чтобы график был коротким)

Тезис: неопределённость падает, когда вы быстрее получаете обратную связь.

• Сформулируйте MVP как минимальную проверку гипотезы, а не “минимальный набор фич”.
• Срежьте объём до того, что можно поставить за 2–6 недель.
• Зафиксируйте “что не делаем” — это половина плана.

Ошибка: делать MVP “урезанной версией финального продукта”. На практике это часто «финальный продукт, только без половины качества», то есть репутационный суицид.

Практика 2. Story Mapping для графика по частям (релизы слоями)

Тезис: map помогает строить график релизов без микроменеджмента задач.

• Соберите пользовательский сценарий “сквозняком”.
• По вертикали — “глубина” (детализация и улучшения), по горизонтали — шаги пользователя.
• Нарежьте релизы: Release 1 (скелет), Release 2 (мясо), Release 3 (косметика и оптимизация).

Ошибка: строить карту по внутренним компонентам (“сделаем сервис A, потом B”), игнорируя путь пользователя.

Практика 3. Прогноз через диапазоны: P50 / P85 вместо “точной даты”

Тезис: руководству нужен не “день X”, а понимание риска.

Делайте два сценария:

• P50: “с вероятностью ~50% успеем к …” — оптимистично, но честно.
• P85: “с вероятностью ~85% успеем к …” — почти комфортный вариант.

Ошибка: обещать P50 как гарантированный срок. Потом начинаются ночные релизы и поиск виноватых.

Практика 4. Управление WIP и очередь вместо “всех загрузить”

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

• Ограничьте Work In Progress в Kanban/внутри спринта.
• Сделайте явные политики: что считается “готово к разработке”, “готово к тесту”.
• Мерьте flow: cycle time, lead time, возраст задач.

Ошибка: “начать всё сразу, чтобы быстрее”. Это почти всегда делает медленнее.

Практика 5. “Бюджет неопределённости”: capacity на баги, долги и сюрпризы

Тезис: если вы планируете 100% мощности на фичи — вы планируете провал.

• Закладывайте 15–30% capacity на техдолг/инциденты/переработку требований.
• Если продукт сырой или интеграций много — ближе к 30%.

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

Как собрать “график проекта” пошагово (чтобы это можно было показать руководству)

1. Определите цель релиза: не “выпустить фичи”, а какой outcome ждёте (например, активация, конверсия, снижение ручного труда).
2. Соберите Story Map и выберите MVP‑поток.
3. Оцените крупно (T‑shirt sizing или грубые поинты) и отрежьте лишнее до объёма на 2–6 недель.
4. Прогоните 2–4 итерации, чтобы получить базовую скорость/пропускную способность.
5. Сделайте прогноз P50/P85 на 1–3 месяца и оформите в виде релизных окон (например, “окно релиза: 20–31 марта”).
6. Добавьте риски и триггеры: 5–10 пунктов, что может снести график и как вы это заметите ранo (точнее, рано).
7. Обновляйте прогноз регулярно (каждый спринт/раз в 2 недели). Не “перепланировать”, а уточнять по данным.

Экспертный вердикт и инструмент: чек‑лист “план реалистичный или маркетинговый”

• Есть ли у нас выходы (deliverables) каждые 1–2 недели? Если нет — это не Agile‑график, это ожидание чуда.
• Прогноз основан на данных (velocity/throughput) или на оценке “как бы хотелось”?
• Срок представлен диапазоном (P50/P85) или одной датой? Одна дата = скрытый риск.
• Есть ли резерв мощности 15–30%? Если “всё на фичи” — готовьте объяснительную.
• Roadmap описывает outcomes и темы, а не детальный бэклог на полгода? Детальный бэклог на полгода — это архив будущих разочарований.

Частые вопросы