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 был отличным решением для своего времени. Но его время прошло.
Пора это признать.
Комментарии (21)
K0styan
07.02.2026 09:57Посмотрите на типичную Scrum-команду.
Вот это всё описанное ниже - это уже не Scrum. Это карго-культ под маской скрама, или скрамно́, или ещё как угодно. Да, продавцы скрама постоянно твердят, что-де все ритуалы обязательны, действительно допродают дополнительные фреймворки. Но это их история.
А так нигде гвоздями не прибито, что спринт обязательно должен быть 2 недели, а планирование - 2 часа. Умеете быстрее - делайте быстрее. Более того, уже лет 5 назад 2 недели считалось в иных местах слабым показателем.
Вместо спринтов я предлагаю поток.
А это практически в чистом виде Канбан.
yuloskov Автор
07.02.2026 09:57А что тогда такое Scrum по вашему?
K0styan
07.02.2026 09:57Система работы короткими итерациями фиксированой длины (это основное отличие от прочих agile методологий), с получением готового к проду продукта в конце каждой. Исходно задуманная как средство выживания в условиях быстро изменяющихся требований, это вы верно заметили.
Разумеется, привязка к календарю несёт некий оверхэд в плане реагирований на эти самые изменения требований. Но а) эти требования надо ещё сформировать, между инсайтом от рынка и требованием в любом случае лаг будет; и б) можно спринт и однодневным сделать: это всё ещё будет скрам.
voroninp
07.02.2026 09:57Встречал мнение, что использование скрама без WIP-лимитов крайне часто превращает его в мини водопад, когда задачи массово доезжают до последних стадий под конец спринта и перегружают систему: типа на QA или продактов сразу вываливается большой объем работы по приёмке.
durnoy
07.02.2026 09:57Так ведь Scrum (и Agile вообще) как раз и задумывался как мини водопад!
В Kanban WIP-лимит явно прописан. В Scrum, во-первых, количество задач ограничено емкостью спринта (velocity), а во-вторых, предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Если же "на QA или продактов сразу вываливается большой объем работы по приёмке", то дело скорей всего в другом. Важный и неотъемлемый принцип Agile -- это автоматическое непрерывное тестирование всего вообще, и это тестирование есть ответственность команды. В идеале, продакт может посмотреть на состояние приемочных тестов (acceptance test) и убедиться, что система работает так, как задумывалась. Много времени это не должно же занимать. QA же должен заниматься тестированием того, что команда не может автоматизировать сама, а не просто проверять работу за программистами.
Понятно, что на практике идеал никогда не достижим, но нельзя недостижимостью идеала оправдывать сваливание в другую крайность, когда команда не делает свою работу.
voroninp
07.02.2026 09:57предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Тут тогда вопрос, почему в спринте есть задачи, не подчинённые цели спринта. А если таковых нет, то какая разница, если команда закомитилась на весь скоуп, определенный при планировании. Все задачи важны.
Явные WIP-лимиты канбана мне милы тем, что подсвечивают узкие места и заставляют команду их разгребать. Сворминг в скраме я не встречал, пожалуй, ни разу.
yuloskov Автор
07.02.2026 09:57Аргумент про карго-культ я слышу каждый раз, когда кто-то критикует Scrum. Мол, проблема не в Scrum, а в том что его неправильно готовят. Но если подавляющее большинство команд «готовят неправильно», может, проблема всё-таки в рецепте?
Однодневный спринт формально возможен, спору нет. Но вы видели хоть одну команду, которая реально так работает со всеми церемониями? Планирование, ревью, ретро каждый день? Это же абсурд. А если церемонии убрать, чем это отличается от потока?
По поводу канбана, пересечение есть, не спорю. Но я говорю не только про организацию потока. Я говорю про то что сами роли в команде и скорость работы изменились настолько, что фиксированные итерации любой длины становятся лишними. Канбан про то, как двигать карточки. Я про то, что карточки стали другими, и люди которые их двигают тоже.
durnoy
07.02.2026 09:57Предположим, есть рецепт пирога. В нем указаны ингредиенты и последовательность действий.
В некоторых пределах можно менять и соотношения в составе, и порядок действий.
Но если выкинуть важный ингредиент или не поставить в печку, то получится фигня.
Смысл церемоний не в том, чтобы их обязательно проводить и обязательно какой-то определенной длины, а в том, что они задают моменты времени, когда команда останавливается на мгновение и соображает, в правильную сторону ли она двигается, нужные ли задачи решает, приносит ли пользу бизнесу, и так далее.
outlingo
07.02.2026 09:57с AI-инструментами заменяет трёх узких специалистов ... этому инженеру не нужен Scrum, чтобы быть продуктивным. Ему нужно понимание продукта, доступ к проду и свобода действовать.
К такому комбо надо бы добавить материальную ответственность за функционирование продукта. Катнул на прод ИИ-слоп который сложил сервис - минус 50% премии и замечание/выговор. Три замечания - и нам с таким ИИ-инженером не по дороге. И вот что интересно - когда людям приходится отвечать своей зарплатой за ИИ-выхлоп, то "внезапно" производительность такого уникально ценного передового ИИ-ассистед инженера резко падает до исходных значений, или даже ниже. Потому, что когда человек что-то делает сам, он машинально адаптирует и делает множество проверок "в голове" прямо в процессе работы. Как правило, это "задел на будущее" или "что-то тут не очень хорошо получается, наверное я что-то пропустил в исходной постановке - а не уточнить ли мне этот вопрос".
Пока что все диалоги с адептами ИИ выглядят так:
Я написал офигенный продукт с помощью ИИ!
Им кто-то кроме тебя пользуется? Он тиражируем? Насколько он масштабируем?
Пока только я, вот докер контейнер, я не думал
Через пару дней продукт становится неинтересен и отправляется на кладбище петпроектов на гитхаб. В общем, СДВ в чистом виде. Сделать 30% от PoC спомощью ИИ, понять что дальше надо пахать, забить болт и уйти срочно писать еще более интересный проект - и конечно "с чистого листа"!!! Ибо ИИ-ассистент хорошо генерирует бойлерплейт, а вот с пониманием кодовой базу у него так себе, как у стажера
yuloskov Автор
07.02.2026 09:57ИИ - это холиварная тема и эта статья как раз написана ради холивара!
Что вам могу сказать, мой опыт отличается от вашего. Я вижу много людей, которые написали продукты с помощью ИИ, этими продуктами пользуются и они приносят прибыль. Я в числе этих людей.
Shortki
07.02.2026 09:57Спорное мнение, одно из тех, когда со всеми словами согласен, но не можешь согласиться с общим выводом.
Пока Scrum, он как демократия — наихудшая форма правления, если не считать всех остальных.
Да, ритуалы раздражают, особенно когда проводятся формально. Да, две недели — искусственный срок. Упрёки можно продолжать, но что взамен?
Команда из четырёх-шести человек. Все фуллстеки разной глубины, но каждый способен довести фичу до прода. У каждого есть понимание продукта, его пользователей, его бизнес-модели.
Это верный путь вытащить очередную галлюцинацию ИИ в прод. Может для развлекательных и сервисных приложений это может сработать, но для приложений критической инфраструктуры это катастрофа, путь в бездну.
Когда листаешь ленту шортсов (каюсь), то время от времени попадаются ролики полностью созданные ИИ, в которых сразу ощущается некая вторичность, как многократно переработанный продукт (чем по сути является выход ИИ). Вам это неочевидно, но ваш путь ведёт к такому же, но в приложениях — к череде вторичных клонов. Ваш метод не сможет их сдержать, даже Scrum, не сможет, но он хотя бы создаёт трение этому процессу.
Постирония в том, что у вас создалось ощущение, что ритуалы Scrum лишь "создают ощущение контроля". Вы просто на втором уровне абстрагирования, но ещё не осознали этого.
Metotron0
07.02.2026 09:57когда вы в последний раз выходили со стендапа с мыслью «вот это было полезно», а не «ещё пятнадцать минут жизни, которые я не верну»
Ни разу. Ни разу не был на стендапе. В тех двух компаниях, где я поработал за 13 лет, такого не было. Сейчас есть летучки по утрам, там раздают задачи на день. Менеджеры договариваются между собой, у кого есть что срочное или не срочное, а мы говорим, что всё сделали, хотя это и так видно по закрытым задачам. Обычно, вместе с проверкой, что все на работе, и болтовнёй о том, кто как зубы полечил, это занимает не больше 20 минут. Иногда 10.
Задачи я не обсуждаю. Мне командуют — я делаю. Надо это кому-то или нет, не моё дело. Я сделал — мне заплатили.
два фронтендера, три бекендера, девопс, QA, дизайнер
Кучеряво. У меня обычно было, что один фронтендер, один бэкендер, а дизайн уже нарисован, но можно считать, что дизайнер всё же есть. На прошлой работе были два тестировщика на всю компанию, сейчас иногда появляется фрилансер, но обычно заказчик сам тестирует на проде. Как оно попадает на прод, знают бэкендеры, у них там где vpn, где просто по ssh, я без понятия.
Судя по тому, что везде знают аджайл, я даже не уверен, смогу ли я сменить работу, я слишком дед.
zikkuratvk
07.02.2026 09:57Как и любая методология, это не прямое указание действия, а набор рекомендации. Все адаптируется под конкретный процесс.
То что у автора нет планирования разработки на пару месяцев вперед хотя бы - это понятно. Но не у всех же так.yuloskov Автор
07.02.2026 09:57Я считаю, что планирование разработки на 2 месяца вперед в современном мире - это не только не полезно, но и вредно. Такое длинное планирование нужно только в очень специфичных продуктах, где важен комплаенс или очень высокая безопасность. В большинстве приложение такие сроки планирования - это абсурд
zikkuratvk
07.02.2026 09:57С созданием экскаватора планирование стройки обрело ещё больший смысл и потребность только возрасла. Я поясню мысль, если у вас произошло разрушение процесса и вы стали это выдавать за нормальность, это не значит, что это нормально.
killyself
07.02.2026 09:57Там где я работал по спринтам в 2 недели, эти спринты наоборот помогали команде разработки, потому что человеку вот накидали задач, и он защищен от ежедневной МарьПетровны, которой надо перекрасить кнопки в жопно-розовый с наивысшим приоритетом. Для действительно горящих задач в спринте выделялся буфер в 1 день, но их надо было согласовать, обосновав срочность.
Что же касается итераций разработки - в разных местах бывает разное. Если задачи позволяют выдать за день мвп и накладывать заплатки на каждый чих - возможно есть смысл просто в канбане жить, с другой стороны серьезные фичи в ответственных местах можно делать и полгода, и пока на них знак качества 15 человек не проставит, к проду их не подпустят. И тут фикс. итерации это меньшее зло, т.к позволяют хоть как-то увидеть траекторию проекта
Forigen
07.02.2026 09:57Статья написана человеком который по скраму никогда не работал и уж точно не когда не отвечал рублем за свои эстимейты)
iliks84
У меня всегда было чувство, что скрам придумали в первую очередь, чтобы мочь продавать такой Продукт как Официальные Тренинги и Сертификации. Certified Scrum Master (TM).
Вы классно сказали, посмотрите не на кол-во жир, а на изменение метрик в проде.
voroninp
Я спросил ИИшки, почему стыд и скрам сильно более популярен, нежели канбан. В ответах одним из факторов была "продаваемость" скрама менеджменту.