Мифы об Agile

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

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

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

Миф 1: Agile — это без документации

Источник мифа — ценность «работающий продукт важнее исчерпывающей документации», прочитанная до середины. Слово там ключевое — исчерпывающая. Манифест бьёт по документации, которая пишется ради процесса: стостраничное ТЗ, которое устареет через месяц и которое никто не откроет.

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

Заметьте: в правой колонке слово «обязателен» встречается чаще, чем «заменяется». Хорошая agile-команда пишет не меньше документации, а меньше мёртвой документации. Например, ADR — короткая запись формата «контекст → решение → последствия»:

ADR-014. Храним историю заказов в отдельной таблице, а не в JSON-поле
Статус: принято, 2026-03-04
Контекст: нужен поиск по позициям заказа и отчёты по товарам.
Решение: нормализованная таблица order_items с FK на orders.
Последствия: + быстрые агрегаты и индексы;
              - при изменении схемы позиции нужна миграция;
              - отклонён вариант с JSONB (усложняет отчёты аналитикам).

Это шесть строк, которые через год сэкономят команде день спора. Ровно такую документацию Agile и имеет в виду.

Миф 2: Agile — это без сроков

Этот миф обычно рождается в момент, когда разработчик не хочет называть дату, и слово «Agile» оказывается удобным щитом. На деле спринт — это сам по себе срок, причём жёсткий: двухнедельная итерация не продлевается, если команда не успела. Не успели — переносим объём, а не дату.

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

Как в Agile отвечают на вопрос «когда будет готово»? Не отказом, а прогнозом с диапазоном, основанным на фактических данных. Если команда за последние шесть спринтов закрывала 18–26 story points, а в оставшемся объёме их около 100, честный ответ звучит так:

Оставшийся объём:      ~100 SP (оценка, точность ±30%)
Факт за 6 спринтов:    22, 19, 26, 18, 24, 21 → 18–26 SP за спринт
Прогноз:               4–6 спринтов = 8–12 недель
Обещаем:               к 15 мая — блок «оплата» и «личный кабинет» целиком,
                       «отчёты» — под вопросом, решим после 3-го спринта.

Это гораздо более полезный ответ бизнесу, чем «будет 15 мая» с вероятностью попадания 20%. Agile не отменяет сроки — он отменяет ложную точность.

Миф 3: Agile — это без планирования

Здесь всё ровно наоборот: планирования становится больше, просто оно размазано тонким слоем по всему проекту вместо одного толстого куска в начале. Посчитаем время команды из семи человек за месяц (два двухнедельных спринта):

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

Миф 4 (бонус): Agile — это быстрее и дешевле

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

Agile-карго-культ

Самая честная проверка: если убрать ритуал, что сломается? Если ничего — ритуал уже мёртв.

Общий корень у всех строк один: цикл обратной связи разомкнут. Ритуал был контейнером для обратной связи, контейнер оставили, содержимое вылили. Отсюда народное «мы работаем по Agile» как синоним «у нас бардак, но с досками».

Когда Agile не подходит

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

• Жёсткий контракт fixed price / fixed scope. Если подписано «вот эти 240 функций за эту сумму к этой дате», то переприоритизация бэклога юридически бессмысленна: любое изменение проходит через допсоглашение. Работать внутри такого контракта итерациями можно (и полезно), но продавать заказчику «мы гибкие» — обман.
• Регуляторика и безопасность жизни. Медицинский софт (IEC 62304), авионика (DO-178C), атомная и железнодорожная автоматика требуют трассируемости: каждое требование связано с проектным решением, кодом и тестом, и всё это проходит аудит. Итеративно работать можно, но объём обязательной документации не сокращается ни на страницу, а «выкатим и посмотрим» просто незаконно.
• Железо и всё, что печатается тиражом. Пресс-форма стоит миллионы, партия плат едет с завода два месяца. Цена итерации огромна — экономика разворачивается, и предварительное проектирование окупается. Именно поэтому в железе живут гибриды: прошивку пишут итеративно, корпус — нет.
• Проекты с полностью известным скоупом. Миграция почты на новый сервер, перенос базы в другой ДЦ, обновление версии фреймворка. Требования не изменятся, обратная связь от пользователя не нужна. Планируйте линейно, никто не осудит.
• Один исполнитель на маленькой задаче. Scrum на одного человека — это оверхед ради оверхеда. Возьмите доску и лимит на незавершённое, остальное не нужно.

И встречное предупреждение: список выше часто используют как отговорку. «У нас регуляторика» иногда означает «мы не хотим показывать промежуточный результат». Проверяйте: какой конкретно пункт какого конкретно стандарта запрещает вам сделать демо через две недели?

Как это работает

Все четыре мифа устроены одинаково: у ценности манифеста отбрасывают правую часть («…важнее исчерпывающей документации», «…важнее следования первоначальному плану») и получают лозунг. Лозунг удобен, потому что снимает ответственность. Противоядие простое — при любом «в Agile так не делают» задайте два вопроса: какой цикл обратной связи мы этим улучшаем? и что сломается, если мы это уберём? На карго-культ оба вопроса ответа не имеют.

Частые ошибки

• Использовать Agile как щит от вопроса о сроках. Бизнесу нужны сроки — и он имеет на них право. Давайте диапазон и данные, а не отказ.
• Выбросить документацию целиком. Через год команда сменится, и «код документирует себя» превратится в археологию.
• Ставить velocity в KPI. Метрика, ставшая целью, перестаёт быть метрикой: оценки надуваются за неделю, и вы теряете инструмент прогноза.
• Внедрять ритуалы сверху, не меняя ничего в решениях. Стендапы без права команды влиять на план — это просто ещё одна встреча.
• Считать, что Agile подходит везде. Евангелизм — тот же карго-культ, только с трибуны.

Итоги

• «Без документации» — миф: убирают мёртвую документацию, оставляют ту, у которой есть читатель (README, ADR, схемы, runbook, API).
• «Без сроков» — миф: спринт сам по себе жёсткий срок; фиксируют время и команду, а переменной делают объём, и отвечают прогнозом с диапазоном.
• «Без планирования» — миф наоборот: планирования 10–12% времени, просто оно короткими циклами и без культа плана.
• «Быстрее и дешевле» — тоже миф: Agile улучшает попадание в цель, а не скорость набора кода.
• Карго-культ узнаётся по одному вопросу: если убрать ритуал, что сломается? Если ничего — обратная связь уже не работает.
• Agile честно не подходит там, где итерация физически дорога (железо, тиражи) или изменения ограничены внешне (fixed price, регуляторика, аудит).