Менеджер проектов Selectel Наташа заявила, что ее команды уже дважды отказывались от спринтов и не теряли в скорости, в том числе когда речь шла о закрытии уязвимостей в SELECTOS. Для рынка, где спринты в IT давно стали почти обязательным ритуалом, это звучит как неприятный, но полезный вопрос: действительно ли командам нужен Scrum, или они просто привыкли жить по календарю встреч.
Об этом она пишет в колонке для Habr / Карьера, где разбирает типичный сценарий: компания берет отдельные элементы Scrum, но не живет по его логике целиком. В результате спринт остается, а вместе с ним дейлики, ретро и грумминги, хотя сам продукт, состав команды и характер задач давно не укладываются в учебниковую модель. Главный тезис автора простой: если убрать спринты, уязвимости все равно будут закрываться так же быстро, а местами и быстрее, потому что команда перестанет обслуживать процесс ради процесса.
В исходной логике Scrum спринт работает не сам по себе, а внутри набора жестких условий. Есть владелец продукта, который качественно приоритизирует бэклог. Есть кроссфункциональная команда, способная брать задачи в работу без постоянных зависимостей между узкими специалистами. Есть понятная цель итерации и готовый инкремент в конце. И есть предсказуемость хотя бы на горизонте нескольких циклов. Наташа прямо пишет: в реальной IT-разработке такой конструкции почти не встретить. Команды стали слишком специализированными, продукты слишком сложными, а людей нельзя безболезненно переставлять с одной задачи на другую только потому, что так удобнее ритуалу.
Отсюда и главная претензия к спринтам в IT по-российски. Компании продолжают сохранять внешние атрибуты Scrum, но теряют его смысл. Планирование превращается в попытку угадать объем работ на две недели вперед, хотя параллельно меняются приоритеты, прилетают инциденты, люди уходят в отпуск, заболевают или подключаются к другим задачам. Ретро проходят по расписанию, даже если обсуждать особо нечего. Дейлики номинально занимают 15 минут, а по факту часто становятся рутинной перекличкой. В такой конфигурации спринт уже не помогает управлять неопределенностью, а лишь добавляет ей красивую доску и набор встреч.
Отдельно автор бьет по самой болезненной зоне: карго-культу вокруг Agile. По ее наблюдению, многие команды настолько привыкают к процессу, что начинают защищать не результат, а форму. Целью становится не ускорить доставку фич, не снизить риски и не навести порядок в зависимостях, а “правильно настроить Scrum”. Это удобная ловушка для менеджмента: кажется, что работа над процессом ведется, потому что в календаре много регулярных событий, есть оценки, демо и ретроспективы. Но если к концу каждого спринта команда снова “не успела”, а проблемы из ретро повторяются из раза в раз, то перед нами не зрелый Agile, а дорогая имитация управляемости.
Любопытно, что Selectel не предлагает примитивную замену в духе “уберите все встречи и пишите код”. Наоборот, в тексте есть более прагматичная альтернатива. С одной из команд Наташа какое-то время сохраняла спринты как инструмент личного планирования: сотрудники просто вытаскивали на доску крупные блоки задач, которые собирались сделать в ближайшие две недели. Это давало локальную определенность без насилия над реальностью. При этом ретро, стендапы и обсуждение задач в команде происходили иначе, в основном асинхронно. И именно этот момент выглядит самым важным для практиков: проблема не в самом слове “спринт”, а в том, что его слишком часто продают как универсальную оболочку для любых процессов.
Не менее показателен разбор ежедневных созвонов. Автор честно перечисляет типовые оправдания дейликов: расшарить контекст, быстро снять блокеры, синхронизировать людей. И тут же говорит, что значительную часть этих задач можно решать письменно. Канал со стендапами в мессенджере работает как автоматический фоллоуап: человек формулирует планы, рефлексирует по итогам прошлого дня, а коллеги читают сообщения в удобное время, а не в момент, когда половина команды еще не вошла в рабочий ритм. Для распределенных инженерных команд это уже не теоретическая дискуссия, а вполне прикладной выбор между синхронной дисциплиной и экономией внимания.
То же касается ретроспектив и груммингов. Если продукт ведут больше пяти человек и внутри идут параллельные потоки разработки, общий грумминг быстро становится дорогим занятием для тех, кто не участвует в конкретной фиче. Люди переключаются между встречей, чатами и своей работой, а полезный выхлоп получают двое-трое. Ретро без общей цели превращается в обязательный сбор жалоб по кругу. Наташа предлагает смотреть на это трезво: обсуждать не “как прошел очередной спринт”, а какие риски были заранее видны, какие сработали по факту, что команда сделала для снижения ущерба и чему научилась. Для инцидентов и уязвимостей логика еще жестче: разбирать их нужно по горячим следам, а не ждать ближайшего регулярного окна в календаре.
Для разработчиков и тимлидов эта позиция важна по одной причине: она легализует отказ от ритуалов, которые не работают именно в их контексте. Для продактов и IT-директоров сигнал другой: предсказуемость не появляется автоматически от того, что задачи нарезали на двухнедельные отрезки. Ее дают прозрачные приоритеты, понятные зависимости, нормальная работа с рисками и честная оценка того, насколько команда вообще способна планировать в таком темпе. А для HR и основателей стартапов здесь есть совсем прикладной вывод: зрелость процесса не измеряется количеством церемоний. Иногда самый взрослый управленческий шаг — признать, что спринты в IT-команде давно стали декоративным слоем и их пора убирать без траурной музыки.
На фоне охлаждения интереса к “чистому” Scrum колонка Selectel попадает точно в нерв отрасли. Чем сложнее инфраструктурные и платформенные продукты, тем слабее работает идея, что универсальный набор ритуалов можно натянуть на любую команду. Вопрос уже не в том, нужен ли бизнесу Agile как философия адаптации, а в том, готов ли он отказаться от его самых узнаваемых церемоний, если они перестали приносить результат.