Каскадная модель в крупных проектах подводит предсказуемо: к моменту приёмки требования устарели, а заказчик впервые видит работающую систему через год после старта. Scrum обещает другое – рабочий инкремент каждые две-три недели и возможность менять приоритеты по ходу. Вопрос не в том, работает ли метод на пятёрке энтузиастов. Вопрос в том, выживает ли он на команде из пятидесяти человек, в проекте с фиксированной сметой и государственным заказчиком. По нашему опыту – выживает, но только если перестроить процесс вокруг итераций, а не приклеить спринты к старому регламенту.

Что ломается при масштабировании

Один Scrum-мастер и один владелец продукта не тянут полсотни разработчиков. Команду режут на ячейки по семь-девять человек, каждая со своим бэклогом и спринтом единой длины. Дальше появляется слой синхронизации: общий митинг лидов вместо общего стендапа, единый Product Backlog, который владелец продукта разбирает на потоки. Технически связку держит непрерывная интеграция – без ежедневной сборки всего продукта итерации в разных ячейках расходятся, и на демо вы получаете не инкремент, а конфликт версий.

Второе, что ломается, – оценка. Заказчик из госсектора требует план и бюджет на год вперёд, а Scrum даёт горизонт в один спринт. Мы решаем это двухуровневым планированием: грубая оценка эпиков в стори-поинтах для контракта и техзадания, детальная разбивка задач – только на ближайшие один-два спринта. Скорость команды (velocity) за три-четыре итерации даёт честный прогноз срока, и это аргумент в разговоре с заказчиком, а не обещание наугад.

Контракт и приёмка по итерациям

Главный барьер в России – не методология, а форма договора. ГОСТ 34 и привычка к фиксированному ТЗ плохо стыкуются с гибким объёмом. Выход – фиксировать не функции, а время и состав команды, либо разбивать контракт на этапы, равные двум-трём спринтам, с приёмкой работающего инкремента в конце каждого. Демонстрация живой системы заменяет приёмку по бумаге: заказчик видит результат раньше и корректирует курс, пока это дёшево. Поэтапная приёмка живого инкремента особенно оправдана в разработке корпоративных и государственных систем, где цена поздней правки требований измеряется месяцами.

Особенно это важно в проектах с понятным конечным пользователем. Когда мы делали личный кабинет на портале госуслуг, ранние демо вскрыли расхождения в сценариях, которые ни одно ТЗ не описывало заранее. То же касается мобильных интерфейсов: полевые сценарии работы с iPad проверяются только на устройстве у реального сотрудника, а не на бумаге.

С чего начинать переход

Не переводите весь департамент разом. Возьмите один проект средней критичности, поставьте опытного Scrum-мастера и владельца продукта с реальными полномочиями приоритизации. Зафиксируйте длину спринта и не меняйте её полгода – ритм важнее идеального плана. Параллельно поднимите CI-сервер и автотесты: без них демо превращается в ручную сборку и итерации буксуют. Когда первая команда выдаст три-четыре стабильных спринта, переносите практики на соседние.

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