Тренд Water Scrum Fall (scrumfall) меняет правила игры: теперь можно жить в мире госрегламента и контрактов «по 44‑ФЗ/223‑ФЗ», но работать внутри проекта итеративно — это снижает цену ошибки на внедрении и тестировании, однако требует дисциплины в документах, управлении изменениями и понятной инструкции scrumfall для всех участников.

Если вы когда-нибудь видели госпроекты, то знаете их главный парадокс: заказчик хочет «как в Agile», но подписывать готов всё равно «как в Waterfall». Точнее… он и не может иначе: ТЗ, смета, этапы, акты, закрывающие, контрольные точки, протоколы — это не чья-то вредность, а способ не получить по голове на проверке.

И вот тут появляется water-scrum-fall: гибрид, который не делает вид, что регламентов не существует. Он честно говорит: «наружу — предсказуемый план и документы, внутрь — короткие циклы и обратная связь». Для новичков и джунов это вообще терапия: меньше эзотерики про «самоорганизацию», больше понятных артефактов и ответственности.

Что такое Water Scrum Fall (Scrumerfall) на человеческом

Определение без маркетинга

Water Scrum Fall / scrumfall / scrumerfall — это модель, где проект стартует и завершается «водопадом» (фиксируем рамки, формализуем результаты, сдаём по этапам), а разработка и уточнение требований внутри — по Scrum (спринты, бэклог, демо, ретро).

Тезис: в госпроектах гибрид обычно честнее «чистого Agile».

Обоснование: в госконтракте почти всегда есть: этапность, фиксированная цена, жёсткие сроки, требования по безопасности/инфобезу, госИС, интеграции, отчётность. «Чистый Scrum» без фиксации объёма и критериев приёмки конфликтует с контрактной логикой.

Практический вывод: не пытайтесь «протащить Scrum целиком». Лучше соберите scrumerfall так, чтобы регламент было чем кормить — а команду не душить.

Подводный камень: самая частая ошибка — назвать проект Agile, а жить как в водопаде, просто с митингами. Это не scrumfall, это «водопад с созвонами».

Почему это часто называется не Water Scrum Fall, а «так у нас и было»

Потому что многие команды интуитивно делали именно так: сначала «большое ТЗ», потом «пилим кусками», в конце «героически сдаём». Разница в том, что зрелый water-scrum-fall добавляет управление изменениями, прозрачность и нормальную приёмку по итерациям, а не финальную разборку на последней неделе.

Где scrumerfall уместен в госпроектах: реальные сценарии

Сценарий 1: 44‑ФЗ/223‑ФЗ, фиксированная цена, этапы и акты

Тезис: scrumfall помогает не провалить сроки, когда «всё уже подписано».

Обоснование: контракт фиксирует вехи: обследование, проектирование, разработка, испытания, ввод. Внутри этапа «разработка» можно вести спринты и принимать результаты частями: прототипы, интеграции, отчёты о тестировании, инкременты функциональности.

Практический вывод: встраивайте Scrum внутрь этапов, а не вместо них. Тогда акты закрываются документами, а продукт растёт итеративно.

Подводный камень: если не описать в контракте (или в ПМИ/Плане) механизм изменений, любые уточнения требований будут считаться «вне ТЗ» и превращаться в конфликт.

Сценарий 2: Регламент, инструкции, ГОСТ‑подобная отчётность

Тезис: water-scrum-fall работает, когда документация — часть «Definition of Done» (критериев готовности).

Обоснование: госпроекты любят артефакты: регламенты, руководства пользователя, программы и методики испытаний (ПМИ), эксплуатационные документы. Если писать их «когда-нибудь потом», потом наступает внезапно — в день сдачи.

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

Подводный камень: отдельная «документальная команда» без связи с разработкой — гарантированный рассинхрон и боль на приёмке.

Сценарий 3: Интеграции с госИС и зависимость от внешних контуров

Тезис: scrumerfall спасает, когда половина рисков не в коде, а «по ту сторону API».

Обоснование: интеграции с СМЭВ, ЕСИА, ведомственными шинами, внутренними реестрами — это очереди, доступы, тестовые стенды, окна изменений. Вода-часть нужна, чтобы заранее согласовать протоколы, регламенты, доступы. Scrum-часть — чтобы быстро адаптироваться, когда реальность снова не совпала с документом.

Практический вывод: выделяйте «интеграционные спринты» с обязательным демо на тестовом контуре и фиксацией результатов актами/протоколами.

Подводный камень: обещать интеграцию «в конце проекта». В госпроектах «конец» обычно означает «штрафы и письма».

Мини‑инструкция scrumfall: как собрать гибрид, чтобы он не развалился

Слой 1. Waterfall снаружи: что фиксируем

• Рамки: цель, пользователи, контуры, ограничения, критерии приёмки (в идеале — измеримые).
• Этапность: вехи, состав поставки по этапам, формат закрывающих документов.
• Управление изменениями: как оформляем CR (change request), кто утверждает, как влияет на сроки/стоимость.
• Риски и зависимости: доступы, сторонние интеграции, поставки железа/лицензий.

Типичная ошибка: фиксировать технические детали раньше времени (архитектуру «в граните»), а критерии приёмки — размыто. В итоге архитектуру нельзя менять, а «сдали/не сдали» решается настроением комиссии.

Слой 2. Scrum внутри: как живёт команда

• Бэклог = декомпозиция ТЗ/требований в user story/задачи (да, в госпроектах это часто «user story без пользователя», но пусть).
• Спринты 2–3 недели с демо заказчику/представителю эксплуатации.
• Definition of Done: код + тесты + обновлённая документация + результаты испытаний на стенде.
• Ретро не как «поговорить о чувствах», а как список улучшений процесса и устранение причин дефектов.

Типичная ошибка: спринты есть, а инкремента нет (на демо показывают презентацию). Это убивает смысл Scrum‑части.

Слой 3. Fall на выходе: как сдаём и закрываемся

Финал — это формальная приёмка, опытная эксплуатация, обучение, комплект документов, устранение замечаний. В scrumerfall финал проще, потому что часть замечаний уже всплыла на демо и «прожарке» инкрементов раньше.

Типичная ошибка: оставлять нагрузочное тестирование, безопасность и эксплуатационную готовность «на потом». В госпроекте «потом» дороже, чем кажется.

Таблица: Waterfall vs Scrum vs Water Scrum Fall в госпроектах

Два кейса из практики: один спасли, другой — «ну вы поняли»

Кейс удачный: «Этапы по контракту, спринты по жизни»

Проект внедрения внутренней системы документооборота для учреждения (интеграции, роли, маршруты). Контракт — этапный, с жёсткими актами. Команда сделала так: этап 1 — обследование и прототип, этап 2 — разработка, этап 3 — испытания и ввод. Но внутри этапа 2 работали спринтами по 2 недели, на каждом демо показывали живые маршруты и отчёты, параллельно обновляли регламенты и инструкцию пользователя.

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

Кейс провальный: «Scrum на словах, waterfall в душе»

Разработка подсистемы отчётности для госИС. Формально — Scrum, по факту — ТЗ на 200 страниц, полгода разработки без демо, в конце «вот вам релиз». Комиссия нашла расхождения с методикой расчёта показателей и формами выгрузки. Закончилось переработками, конфликтами и перепиской «это не в ТЗ».

Где сломалось: отсутствовали регулярная приёмка инкрементов и нормальная процедура изменения требований. То есть scrumfall не собрали — просто повесили бирку Agile.

Коммерческие факторы: где реально «съедается» бюджет и сроки

В госпроектах стоимость ошибки обычно растёт не линейно: ошибка в требованиях → переписывается код → переделываются документы → сдвигаются испытания → переносится приёмка. Поэтому scrumerfall ценен не «скоростью разработки», а управлением риском.

• Скрытая цена документации: если не заложить её в план, она съедает последние 20–30% времени этапа (и это ещё оптимистично).
• Интеграции и доступы: ожидание доступов/окон изменений легко превращает 2 недели в 2 месяца.
• Испытания: ПМИ, протоколы, стенды, «а давайте ещё нагрузку» — это отдельный проект внутри проекта.

Кстати, на itokno.ru удобно собирать такие разборы в одну картину: кто за что отвечает, где ломается процесс, и почему «мы же почти успели» — не стратегия.

Экспертный вердикт и инструмент

Вердикт: Water Scrum Fall (scrumfall, scrumerfall) в госпроектах — не компромисс «для слабаков», а способ совместить контрактную реальность и нормальную разработку. Он уместен, когда есть регламент, фиксированная приёмка и много внешних зависимостей.

Чек‑лист: 7 вопросов, чтобы понять, нужен ли вам scrumfall

1. Есть ли фиксированные этапы, акты и состав документации? Если да — «вода» снаружи неизбежна.
2. Можно ли показывать инкремент каждые 2–3 недели и получать обратную связь от реальных пользователей/эксплуатации?
3. Определены ли критерии приёмки не в стиле «должно работать», а измеримо?
4. Есть ли процедура изменения требований (CR) с влиянием на сроки/стоимость?
5. Документация включена в Definition of Done или живёт «где-то рядом»?
6. Интеграции вынесены в план как риск с отдельными задачами/спринтами?
7. Есть ли у заказчика представитель, который реально принимает результаты, а не появляется на финальной комиссии?

Частые вопросы