Agile и ИИ: почему Agile нужен сильнее

Интересный вопрос не в том, заменит ли ИИ разработчиков. Он в том, что происходит с Agile, когда писать код становится дешевле.

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

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

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

О чём на самом деле был Agile

После лет Daily, story points и графиков velocity легко забыть, на что отвечал Agile Manifesto. Он не пытался сделать разработку быстрее. Он пытался сделать её честной.

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

Главная мысль Agile: разработка это исследование, а не исполнение плана. Задачу вы понимаете, пока её решаете. Чего хотят пользователи, видно, когда у них есть на что реагировать. Подходящая архитектура проявляется в итерациях, а не в предварительном проекте. Короткие циклы были не программой продуктивности. Это был способ оставаться честными с собой и со стейкхолдерами.

От линейной схемы Plan, Build, Ship к циклу сборки, Review и обучения

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

Что ИИ действительно меняет

Первый эффект очевиден: то, что занимало время, занимает меньше. Писать код, набрасывать тесты, читать чужую кодовую базу, собирать варианты решения. Всё это заметно ускорилось.

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

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

Закономерность, которую стоит держать в голове: тяжелее всего не тем, кто внедряет медленно. Тяжелее тем, кто берёт ИИ с энтузиазмом и без дисциплины. Сборка сжимается, а вопрос, что собирать, остаётся прежним. Velocity растёт. Переделки растут быстрее.

Именно здесь логика Agile становится нужнее, а не слабее.

Две картины Agile и ИИ

Связь может пойти двумя путями. Какой выберет команда, многое говорит о том, как она понимает Agile.

В первой картине ИИ это турбонаддув. Спринты дают больше. Функции выходят быстрее. Доска двигается. Velocity выглядит лучше, чем когда-либо. Практики остаются в календаре, но становятся церемонией: каркас вокруг процесса, который ведут промпты и сгенерированный код. Здесь Agile считают рамкой поставки. ИИ делает поставку быстрее. Вопрос закрыт.

Во второй картине ИИ освобождает внимание для того, что Agile всегда защищал: настоящее исследование, живые петли обратной связи, честный разговор о том, что работает. Команда уже не так поглощена реализацией, чтобы забыть спросить, верна ли сама реализация. Sprint Review меньше про демо и больше про обучение. Ретроспектива задаёт более крупные вопросы.

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

Какие практики ещё решают свою задачу

Если команда широко использует ИИ и быстро поставляет: нужны ли ещё ритуалы? Daily, Review, ретроспектива?

Честный ответ зависит от того, зачем вы их завели.

Если Daily было в основном отчётом о статусе, чтобы руководитель видел картину, его часто заменяют инструменты и асинхронная переписка. Если Sprint Review было показом готовой работы, оно лишнее, как только репозиторий открыт всем.

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

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

Чего ИИ не берёт на себя

Есть мышление, которое защищает Agile и которого ИИ не касается. Оно случается, когда разработчик и Product Owner посреди разговора понимают: требование, с которым все согласились, не решает задачу, ради которой его написали. Или когда команда на ретроспективе видит повтор: одна и та же переделка, и сводит её к тому, как устроена коммуникация.

Это организационное обучение. Оно медленное, неаккуратное и требует доверия, психологической безопасности и готовности сказать неудобное в одной комнате. ИИ этого не облегчает. Ускорение всего остального делает труднее найти на это время.

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

Где теперь трудность

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

В середине трение сильно упало. Сборка и тесты идут быстрее. Перебирать технические варианты дешевле. Остаётся почти то самое трение, под которое собран Agile: понять настоящую задачу, решить, что важнее, собрать общую картину со стейкхолдерами, научиться на том, что ушло в прод.

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

Что это значит в работе

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

Скорость уходит в большую пользу или просто в больший объём? Разговоры о плане становятся точнее, потому что есть время думать, или короче, потому что всем не терпится начать собирать? Обратной связи от реальных пользователей больше, или мы меряем в основном выпуск?

В сильной форме Agile был набором практик, которые держат команду честной перед лицом неопределённости. ИИ эту неопределённость не уменьшает. Он её сгущает. Когда механическая работа уходит, остаются вопросы, которые всегда были самыми трудными. Что нужно людям, которые пользуются продуктом? Мы решаем верную задачу? Чему мы учимся?

Ближайшие годы лучше пройдут не те команды, которые быстрее всех внедрят ИИ. Их пройдут те, кто продолжает задавать эти вопросы и создаёт условия, в которых на них можно ответить. Для этого Agile и собран. Эпохе ИИ он нужен сильнее.

Дальше по теме: что такое Agile, установка в совместной работе и сертификации AI-Native. Кто хочет отработать шаг в своей организации, начинает с AI-Native Value Architect.

Частые вопросы про Agile и ИИ

ИИ заменяет разработку?

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

Нужны ли Daily, Review и ретроспектива, если в команде есть ИИ?

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

Как понять, что ИИ даёт только больше выпуска, а не больше пользы?

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

← Блог