Scrum стал священной коровой индустрии. Его преподают на курсах, под него заточены целые карьеры, а сертификация Scrum Master стала отдельным бизнесом на миллиарды долларов. Но давайте честно: когда вы в последний раз выходили со стендапа с мыслью «вот это было полезно», а не «ещё пятнадцать минут жизни, которые я не верну»?
Я предлагаю признать очевидное: мир разработки изменился настолько, что процессы, придуманные в начале двухтысячных, стали тормозом. И если профессия программиста еще поживет какое-то время, то Scrum должен умереть сейчас.
Когда Scrum имел смысл
Давайте отдадим должное. Scrum появился как ответ на Waterfall, монструозный подход, в котором продукт планировали годами, а потом обнаруживали, что он никому не нужен. Scrum сказал: «Давайте резать на кусочки, итерироваться, получать обратную связь». И это было революцией.
Двухнедельный спринт был разумным компромиссом. Чтобы написать фичу, нужно было понять задачу, продумать архитектуру, написать код, протестировать, задеплоить. Каждый этап занимал дни. Разработчик физически не мог выдавать результат быстрее, потому что писал каждую строку руками, дебажил часами и вручную настраивал инфраструктуру.
Но мы больше не живём в том мире.
Что изменилось
Современные AI-инструменты сжали цикл разработки в разы. То, что раньше занимало неделю работы одного разработчика, сейчас делается за день, а иногда за часы. Речь не о том, что ИИ пишет идеальный код. Речь о том, что он убирает рутину, ускоряет прототипирование, помогает разобраться в незнакомых технологиях и генерирует бойлерплейт, который раньше съедал часы.
Добавьте к этому зрелость инфраструктуры: контейнеризация, CI/CD, IaC, serverless. Всё это превратило деплой из события в рутину. Раньше релиз был стрессом. Сейчас это коммит в main.
И вот в этой реальности мы продолжаем собираться раз в две недели, чтобы «запланировать спринт». Серьёзно?
Проблема не в Agile. Проблема в ритуалах
Уточню: я не воюю с идеями Agile-манифеста. «Люди важнее процессов», «работающий продукт важнее документации», «реакция на изменения важнее следования плану». Всё это по-прежнему верно. Я полностью поддерживаю эти идеи. Сейчас они актуальны как никогда. Ирония в том, что Scrum, рождённый из Agile, превратился в его противоположность.
Посмотрите на типичную Scrum-команду. Спринт-планирование: два часа, чтобы натянуть задачи на две недели. Ежедневные стендапы: пятнадцать минут отчётов, которые никто не слушает. Ретроспективы: «Что было хорошо? Что было плохо?», одни и те же ответы каждые две недели. Груминг: ещё пара часов на обсуждение задач, которые могут стать неактуальными к завтрашнему дню.
Всё это ритуалы. Они создают ощущение контроля, но не создают ценность. И хуже того, они создают задержку. Клиент прислал запрос в понедельник, а команда «возьмёт его в следующий спринт». Через две недели. Потому что текущий спринт уже запланирован, а менять план это «нарушение процесса».
В мире, где фичу можно собрать за два дня, двухнедельный цикл планирования выглядит абсурдно.
Нов��я реальность: от конвейера к потоку
Вместо спринтов я предлагаю поток. Пришёл запрос, взяли в работу. Сделали, задеплоили, получили обратную связь. Не через две недели, а через два дня. Или завтра.
Это не хаос. Это требует другой дисциплины, инженерной. Качественный CI/CD, feature flags, автотесты, мониторинг. Всё это позволяет деплоить быстро и безопасно, без ритуального «закрытия спринта».
Приоритизация никуда не девается. Но вместо «набиваем спринт раз в две недели» работает постоянный бэклог с понятными приоритетами, который пересматривается по мере поступления информации. Product Owner не ждёт спринт-планирования, чтобы объяснить, что важно. Он делает это тогда, когда появляется новая информация.
Канбан? Ближе к истине. Но речь о чём-то ещё более гибком, где единица работы это не «задача из Jira», а бизнес-результат: фича, которую кастомер может пощупать.
Смерть специализации
Изменение процесса это только половина истории. Изменились и роли.
Ещё пару лет назад команда выглядела так: два фронтендера, три бекендера, девопс, QA, дизайнер. Каждый сидел в своей нише и делал свою часть. Фронтендер не трогал бекенд, «не моя зона ответственности». Бекендер не понимал, почему кнопка выглядит криво, «пусть дизайнер разбирается». Девопс жил в своём мире Terraform-конфигов.
Это работало, когда каждая область была настолько глубокой и сложной, что одному человеку было невозможно охватить несколько. Но AI кардинально снизил порог входа. Фронтендер, который никогда не писал API, теперь может собрать работающий эндпоинт за полчаса с помощью AI-ассистента. Бекендер, далёкий от CSS, может собрать приличный интерфейс. Дизайнер может генерировать компоненты в коде.
Разработчик нового типа это не тот, кто знает наизусть документацию React или может написать Kubernetes-оператор с закрытыми глазами. Это тот, кто понимает продукт целиком: от пользовательской проблемы до деплоя решения. Тот, кто может взять фичу и довести её до продакшена, весь путь, а не свой кусочек конвейера.
Фронтендер теперь это фуллстек, который ещё и дизайнит. Бекендер это фуллстек, который ещё и девопсит. И все они понимают, как развивается продукт, потому что без этого понимания невозможно принимать быстрые решения.
«Но ведь нужна экспертиза!»
Слышу возражение. И оно валидно, но наполовину.
Да, есть области, где глубокая экспертиза незаменима. Высоконагруженные системы, криптография, ML-инфраструктура, специфичные домены. Никакой AI не заменит понимания CAP-теоремы, когда вы проектируете распределённую систему.
Но давайте посмотрим правде в глаза: большинство продуктовых команд не пишут распределённые базы данных. Они делают CRUD-приложения, дашборды, интеграции с API, мобильные приложения. И для этих задач T-shaped специалист с AI-инструментами в руках эффективнее, чем команда узких профессионалов, которые неделю передают друг другу задачи через Jira.
Экспертиза смещается. От «я знаю синтаксис и API» к «я понимаю систему, пользователя и бизнес». От ширины знания фреймворка к глубине понимания проблемы.
«Ваш подход не масштабируется»
Второе популярное возражение. Тоже частично справедливое.
Команда из пяти человек легко работает в потоковом режиме. А компания из двухсот разработчиков? Там же нужна координация, зависимости, роадмапы.
Да. Но посмотрите на то, как Scrum «решает» эту проблему: SAFe, LeSS, Nexus. Фреймворки-матрёшки, которые добавляют ещё больше ритуалов и ролей. PI Planning на два дня, Release Train Engineer... это не решение проблемы масштабирования. Это её бюрократизация.
Масштабирование решается иначе: чёткими контрактами между командами (API-first), автономностью команд (каждая владеет своим доменом от начала до конца) и культурой, в которой коммуникация происходит по необходимости, а не по расписанию.
Как это выглядит на практике
Команда из четырёх-шести человек. Все фуллстеки разной глубины, но каждый способен довести фичу до прода. У каждого есть понимание продукта, его пользователей, его бизнес-модели.
Бэклог живой, приори��изированный, без жёстких границ спринтов. Задача берётся в работу сразу, как только она становится приоритетной. Нет двухнедельного ожидания.
Ежедневные синки короткие, по необходимости. Если за день нечего синхронизировать, не синхронизируемся. Асинхронные апдейты в чате работают не хуже стендапа.
Ретроспективы когда есть что обсудить, а не каждые две недели по будильнику. Иногда раз в неделю, иногда раз в месяц. Рефлексия ценна, когда она своевременна.
Это не анархия
Я чувствую нервные тики менеджеров, читающих это. «Как мы будем предсказывать сроки? Как отслеживать прогресс? Как отчитываться перед стейкхолдерами?»
Velocity в Scrum это иллюзия предсказуемости. Все знают, что «двадцать стори-поинтов» ничего не значат за пределами одной конкретной команды. Прогресс измеряется работающими фичами в руках пользователей, а не закрытыми тикетами.
Хотите отчёт? Посмотрите на прод. Что залито за последнюю неделю? Какие метрики выросли? Это единственный честный ответ.
Это уже происходит
Можно спорить о терминах и деталях, но тренд очевиден. Лучшие продуктовые команды мира уже работают не по Scrum. Быстрые итерации, автономные команды, универсальные разработчики, минимум ритуалов, максимум результата.
AI изменил экономику команды. Один толковый инженер с AI-инструментами заменяет трёх узких специалистов, передающих задачи друг другу через Jira-тикеты. И этому инженеру не нужен Scrum, чтобы быть продуктивным. Ему нужно понимание продукта, доступ к проду и свобода действовать.
Scrum был отличным решением для своего времени. Но его время прошло.
Пора это признать.
