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

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce, преподаю на курсах разработки и архитектуры в OTUS. За годы работы я собрал и разогнал не одну команду, прошёл несколько «agile-трансформаций». И вот что я понял: чаще всего команда не «делает Agile плохо». Она делает не Agile вообще. Снаружи всё на месте — доска, спринты, стендапы, — а внутри обычный водопад, просто переодетый.

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

Одно типичное утро в «agile»-команде

Представьте утро. Стендап. Двенадцать человек по очереди отчитываются: «вчера делал задачу, сегодня продолжу, блокеров нет». Никто никого не слушает, все смотрят на тимлида, а не друг на друга. Через две недели — ретро: всплывают те же три проблемы, что и месяц назад, и квартал назад. Их записывают в Confluence, где они и умирают. А роадмап на квартал уже утверждён сверху, и ни один спринт его не меняет.

Если вам это знакомо — у вас, скорее всего, не Agile. У вас его декорация. И теперь к этой декорации подошёл ИИ, который умеет за вас писать саммари стендапа, генерить user story и рисовать burndown. И если выясняется, что вся ценность процесса была именно в этом, — то, скорее всего, вы автоматизировали ритуал, а не работу.

Сразу оговорюсь, чтобы дальше читать без споров: ИИ не ломает Agile. Он ломает организации, которые подменили Agile набором ритуалов. Это разные вещи, и вся статья — про вторую.

Логика тут простая. Когда нейросеть начинает выполнять ритуал без заметной потери результата, организация вынуждена задать неудобный вопрос: а какую проблему этот ритуал вообще решал? Если честный ответ — «собирал статусы», «оформлял артефакты», «рисовал отчёт наверх», — то процесс проще автоматизировать, чем оправдать. Вот этим ИИ и работает как детектор: он не трогает живые практики, он обнажает мёртвые.

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

Сначала — общая картинка проблемы, чтобы было от чего отталкиваться (рис. 1).

Эта картинка задаёт всю мысль статьи: снаружи процесс может выглядеть образцово, а под «рентгеном» оказывается, что половина ритуалов ничего не двигает. Дальше — конкретика.

Признак 1. Дейли превратился в устный отчёт начальнику

Симптом. Каждый по кругу рассказывает, что делал вчера и будет делать сегодня, глядя на менеджера. Вопросов друг к другу нет. Решений на встрече не принимается — только сбор статусов.

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

Последствия. 12 человек × 15 минут × каждый день — это полтора человеко-часа в день, выброшенных на пересказ Jira вслух. А главное — пропадает то, ради чего дейли существует: быстрая координация и вскрытие блокеров до того, как они станут авариями.

Исправление. Стендап нужен для решений, а не для отчёта. Простой тест: если дейли сводится к обмену статусами и не даёт ничего сверх того, что и так уехало бы в тред Slack, — формат пора пересматривать. Речь не о том, что синхрон не нужен: распределённой команде или горящему проекту живой разговор важнее любого треда. Речь о дейли, которое стало пересказом тикетов вслух. Помню, как однажды я просто молча перестал приходить на дейли своей команды на неделю. Ничего не сломалось. Это и был диагноз. Мы переделали формат: разговариваем только про то, что мешает двигаться, и только если есть что решать.

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

Признак 2. Ретро есть, изменений нет

Симптом. Раз в спринт команда садится, выписывает «что хорошо / что плохо», все кивают — и расходятся. Через спринт всплывают ровно те же боли.

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

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

Исправление. Любая идея с ретро превращается в конкретное действие: с владельцем, сроком и измеримым результатом, и кладётся прямо в бэклог спринта, что хорошо согласуется с рекомендациями Scrum Guide. Не «надо улучшить тесты», а «Петя до конца спринта настраивает прогон unit-тестов в CI на каждый PR». Я в своих командах держу простой шаблон:

# Плохо — умрёт в Confluence
retro_action: "Надо что-то сделать с флакающими тестами"

# Хорошо — попадёт в спринт и закроется
retro_action:
  problem: "Тесты падают в CI рандомно, ре-ран спасает в 80% случаев"
  owner: "Пётр"
  metric: "Доля флакающих прогонов < 2%"
  due: "Спринт 47"
  backlog_id: PLT-1184

Разница в одном: у действия есть хозяин и дата. Всё остальное — благие намерения.

Признак 3. Спринты есть, но роадмап заморожен на квартал

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

Причина. Организация купила механику Scrum, но не приняла его суть. Это то, что в англоязычных разборах метко называют «Waterfall со Scrum-логотипом сверху».

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

Исправление. Зафиксированной должна быть проблема и видение, а не решение. И сразу уточню: квартальный план сам по себе — это нормально. Годовые цели, OKR, инвестиционные темы прекрасно уживаются с Agile. Проблема не в том, что план есть, а в том, что его нельзя поменять, когда пришли новые данные. Я бы предпочёл планировать вперёд гипотезами, а не задачами: «проверяем, что фича X поднимает конверсию», а не «делаем фичу X к 1 июня любой ценой». Если за квартал ни одна строчка роадмапа не изменилась под влиянием данных — это уже не дисциплина, а неспособность услышать новую информацию.

Признак 4. Меряете output, а не outcome

Симптом. Главная метрика команды — velocity и количество закрытых стори-поинтов. На демо радуются, что «сделали 60 поинтов вместо 50».

Причина. Стори-поинты легко считать, а ценность — трудно. Поэтому меряют то, что под фонарём. Тут важная оговорка: сам по себе velocity — нормальный инструмент прогнозирования внутри команды, и Scrum Guide, кстати, нигде не предлагает использовать его как KPI. Беда начинается ровно тогда, когда им меряют эффективность и сравнивают команды между собой.

Последствия. Velocity отлично растёт, а толку всё меньше. Я для себя сформулировал так: output может расти, пока поток деградирует. Команда производит больше тикетов, а время от идеи до пользы (lead time) не сокращается. В 2026-м это особенно больно: согласно исследованию DORA «State of AI-assisted Software Development» 2025, ИИ-инструментами регулярно пользуется подавляющее большинство опрошенных разработчиков — но сам по себе ИИ команду не чинит, он усиливает то, что уже есть. Слабый процесс с ИИ просто быстрее выпускает некачественную работу: как формулируют авторы отчёта, скорость без стабильности — это ускоренный хаос. Если вы меряете количество, цифры будут красивыми ровно до первого инцидента.

Исправление. Смотреть на поток и результат, а не на активность. Базовый набор — метрики DORA (частота деплоев, lead time, change failure rate, MTTR), поверх — flow-метрики и связка с бизнес-результатом. Сравните два дашборда:

# Имитация (output)
Velocity: 58 SP — растёт
Closed tickets: 41 — растёт
Hours logged: 312 — растёт

# Реальность (outcome + flow)
Lead time (идея -> прод): 21 день (цель 7)
Flow efficiency: 18% (82% времени задача ждёт)
Change failure rate: 19%
Влияние на метрику продукта: 0

Метрику flow efficiency ввели Никлас Модиг и Пер Алстрём в книге «This is Lean», и Lean/Kanban-сообщество с тех пор не раз отмечало неприятное: у многих команд она держится около 15%, а то и ниже. То есть большую часть времени задача просто лежит и ждёт — ревью, тестов, релиза, чьего-то решения. Никакой velocity этого не покажет. Меня эта цифра в своё время хорошо отрезвила.

Чтобы сдвиг был наглядным, я свёл его в одну схему. В разборе ниже (Рис. 2) видно, где проходит граница: что из «agile-работы» ИИ уже забирает на себя, а что остаётся исключительно за человеком.

Подсвечу главное из этой диаграммы: ИИ работает как детектор экспертизы. Всё, что слева, он скоро будет делать дешевле и быстрее человека — и если менеджер занят только этим, его роль сводится к обслуживанию инструментов. Ценность живёт справа: в работе с людьми, конфликтами и приоритетами, которая всё ещё требует человеческой ответственности. Хороший менеджер Agile-проектов в 2026-м — это тот, кто движется из левой колонки в правую.

Признак 5. Бэклог без цели, приоритет — у того, кто громче кричит

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

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

Последствия. Цена этого — не только медленная поставка. Это размытый фокус и неспособность сказать руководству, что нужно остановить, чтобы ускорить главное. Команда вечно занята и вечно ничего важного не доводит. Помню один бэклог, где мы были загружены на 110%, а на вопрос «что важного вы выпустили за квартал» повисала неловкая тишина.

Исправление. Сильный навык менеджера сегодня — не «успеть всё», а внятно объяснить, что мы сознательно не делаем. Я обычно держу жёсткий WIP-лимит и список «нет» на видном месте. Могу себе представить, как это звучит для бизнеса непривычно — но фраза «мы это не возьмём в этом квартале, потому что…» экономит больше, чем десять закрытых тикетов.

Признак 6. Скопировали чужую модель как ритуал

Симптом. Команда внедрила сквады, трайбы, чаптеры и гильдии, потому что «так делает Spotify». Слова новые, проблемы старые.

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

Последствия. Тут уместно вспомнить реальную историю. В 2012 году Spotify описал свою модель организации, и полмира бросилось её копировать. А в 2020-м бывший продакт-менеджер компании Джеремайя Ли опубликовал разбор «Failed #SquadGoals»: по его словам, это была скорее декларация о намерениях: копировали модель по миру куда активнее, чем применяли внутри самого Spotify, да и там она толком не прижилась. Соавтор модели и agile-коучи годами просили её не копировать. Причина простая: автономия без выравнивания. Когда каждый сквад сам выбирает фреймворки, практики деплоя и инструменты, кодовая база расползается, а сопровождение дорожает.

Исправление. Никаких «давайте как у больших». Берём не структуру, а проблему, которую структура решала, и думаем, как решить её в своих условиях. Я для себя вывел правило: если не можешь объяснить, какую конкретную боль практика закрывает именно у тебя, — не внедряй её.

Признак 7. Менеджер = администратор церемоний

Симптом. Вся работа руководителя — провести встречи по расписанию, обновить Jira, собрать burndown и отчитаться наверх, что «спринт идёт по плану».

Причина. Роль свелась к администрированию процесса. Долгое время это сходило с рук, потому что администрирование выглядело как управление.

Последствия. И вот кульминация. Если ценность менеджера сводится к ведению бэклога, проведению церемоний и рисованию графиков, то ИИ резко обесценивает именно эту, чисто административную часть работы — её и десять лет назад можно было автоматизировать, просто не было повода. Алгоритм просвечивает разницу между теми, кто делает настоящую работу, и теми, кто исполняет «agile-театр». Быть «сертифицированным по Agile» в 2026-м ценится куда меньше, чем уметь показать, как ты улучшил поток, прояснил приоритеты, сократил время принятия решений и связал поставку с ценностью.

Исправление. Перестать быть диспетчером и стать тем, кто снимает неопределённость. Отдать ИИ рутину (саммари, черновики, отчёты) и освободить голову для того, что он не умеет: переговоры, доверие, фокус, тяжёлые решения о приоритетах. Как и предполагал, сильнее всех за свою роль тревожатся те, кто держится за церемонии. А спокойнее всех — те, кто давно занимается людьми и ценностью.

Что делают команды, которые не имитируют

Теперь — про тех, у кого работает. Соберу актуальные на 2026 год практики в один маршрут оздоровления (Рис. 3), от имитации к рабочему процессу.

Что запомнить из этой схемы для себя: оздоровление — это не «внедрить ещё один фреймворк», а пять последовательных шагов, каждый из которых убирает один из разобранных анти-паттернов. Сильные команды 2026 года начинают с метрик: меряют поток и результат, а не активность. Мой вариант, который я обычно использую на старте, — не тащить сразу весь зоопарк метрик, а взять одну, lead time от идеи до прода: она вскрывает почти все узкие места разом, а дальше уже разматываешь остальное. Потом — дисциплина фокуса и честная передача рутины машине. Сертификат тут ни при чём.

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

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

Сводная таблица: как себя проверить

Какой навык всё это на самом деле проверяет

Если присмотреться, все семь признаков — про одно. Они проверяют не знание Scrum Guide и не количество сертификатов. Они проверяют способность отличать форму от содержания: видеть, где процесс реально двигает поставку ценности, а где просто красиво крутится на месте.

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

Хороший менеджер Agile-проектов — это не тот, кто безупречно проводит церемонии. Это тот, кто в нужный момент готов сказать: «то, что мы делаем, — театр, давайте перестанем». И знает, чем его заменить.

Больше про управление читайте в материалах:

• Есть ли шанс правильно оценить трудозатраты?

• User Story: полный гайд по написанию без ошибок

• Риски в IT-продукте: как бизнес-аналитик спасает проект

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

• 11 июня в 20:00. «Внутри Scrum: как работают мастер, владелец и команда». Записаться

• 17 июня в 20:00. «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться

• 24 июня в 20:00. «Ретроспектива в Agile: что это, нужна ли она и как сделать её полезной». Записаться