Посмотрите, я собираюсь сказать то, что все думают на утренних стендапах в 9 утра, но стесняются озвучить: внедрение Scrum часто превращается в бюрократический кошмар, функционально неотличимый от Waterfall, только с обязательным участием аудитории и большим количеством уведомлений Jira.

Я знаю, это спорно. Но выслушайте меня, прежде чем закрыть эту вкладку в расстроенном молчании.

Неудобная правда за Agile революцией

Дело в том, что Scrum родился из искреннего желания вырваться из жёстких, последовательных оков методологии Waterfall. Первоначальная структура Scrum подчёркивает гибкость, итеративную разработку и непрерывную обратную связь. В теории это прекрасно. Agile-манифест — это, по сути, поэзия разработки программного обеспечения.

Но потом что-то произошло. Организации взяли Scrum — итеративную структуру, предназначенную для реагирования на изменения, — и превратили её в свою разновидность последовательной жёсткости. И я наблюдал, как это происходило в достаточном количестве кодовых баз и ретроспектив команд, чтобы распознать закономерность: большинство «Scrum-команд» просто запускают спринты по Waterfall, где вместо завершения всех требований → проектирования → реализации → тестирования за шесть месяцев, они завершают все требования → проектирование → реализацию → тестирование за две недели.

Математика выглядит лучше, но протокол встреч — нет.

Когда Scrum становится Waterfall (но со стендапами)

Позвольте мне описать ситуацию, с которой вы, вероятно, сталкивались:

Классический антипаттерн: Ваша «Scrum-команда» действует следующим образом:

  • Планирование спринта: владелец продукта вываливает двухнедельные требования в виде фаз Waterfall.
  • Ежедневные стендапы: ритуальное посещение, минимальное сотрудничество, много «заблокирован X».
  • Фаза разработки: разработчики работают изолированно над своими «историями» (которые на самом деле просто требования).
  • Фаза тестирования: тестировщики получают сборку на девятый день, находят трёхмесячные баги.
  • Обзор спринта: демонстрация «законченной» работы, заинтересованные стороны говорят: «На самом деле, мы имели в виду нечто другое».
  • Ретроспектива: те же жалобы, что и в прошлом спринте; ничего не меняется.

Знакомо? Это не Scrum. Это продолжение Waterfall: Waterfall: Sprint Edition.

Основная разница между реальным Scrum и реальным Waterfall должна быть глубокой. Waterfall следует линейному, последовательному процессу, где каждый этап завершается до начала следующего, с минимальной гибкостью и небольшой обратной связью до конца. Scrum должен быть итеративным, предоставляя приращения ценности с постоянным сотрудничеством и обратной связью на протяжении всего процесса.

Но вот что убивает реальный Scrum на практике: когда внедрение становится догматичным, а не адаптивным.

Список симптомов: является ли ваш Scrum на самом деле Waterfall?

Прежде чем язву звучать совершенно невменяемо, позвольте мне привести вам конкретные симптомы того, что ваш «Scrum» тайно эволюционировал в Waterfall:

1. Ваши спринты имеют чёткие фазы Серьёзно: если ваш спринт имеет чёткую «фазу требований», «фазу разработки» и «фазу тестирования» с минимальным перекрытием, поздравляю — вы случайно заново открыли Waterfall. Каждая фаза перетекает в следующую, как вода, каскадирующая с обрыва, только теперь это происходит быстрее и требует больше встреч.

Исправление? Работа должна происходить одновременно. QA должен тестировать незаконченные функции. Дизайнеры должны делать итерации, основываясь на отзывах разработчиков. Если ваш спринт выглядит как последовательные слои, вы реализовали Waterfall с двухнедельным дедлайном.

2. Бэклог не меняется в середине спринта Scrum должен быть гибким. В этом весь смысл. Если ваш бэклог спринта блокируется в момент окончания планирования спринта, и изменение требований требует формального процесса с накладными расходами, вы занимаетесь не Scrum — вы занимаетесь более эффективной версией процесса управления изменениями Waterfall.

Настоящий Scrum допускает корректировку курса. Настоящий Waterfall — нет. Большинство реализаций «Scrum» находятся где-то посередине, притворяясь гибкими, сохраняя при этом осторожность Waterfall перед изменениями в середине спринта.

3. Тестирование происходит после завершения разработки Это звон смерти Waterfall. Если ваша команда QA получает тикеты после того, как разработчики заявляют о чём-то «готовом», вы проводите последовательные фазы, мой друг. Это Waterfall.

Разработка, ориентированная на тестирование, непрерывная интеграция, парное программирование с перспективой QA — это антипаттерны Waterfall. Если ваше тестирование происходит в фазе тестирования, а не непрерывно, у вас Waterfall со спринтами.

4. Документация загружается заранее Waterfall делает упор на тщательную документацию на начальном этапе. Если ваш спринт начинается с спринта по документации, спринта по окончательной доработке требований или любого спринта, который в основном связан с планированием работы, а не с выполнением работы, вы работаете по Waterfall.

Scrum документирует постепенно. Waterfall документирует всесторонне до начала кодирования. Большинство «Scrum»-команд делают гибрид: они хотят скорости Scrum с уверенностью Waterfall в документации. Спойлер: вы не можете иметь и то, и другое без ущерба для обоих.

Почему это происходит: институциональная иммунная система Waterfall

Организации обычно не намерены саботировать Scrum. Это более коварно.

Waterfall существует, потому что люди боятся неопределённости. Когда вы точно знаете, что строите — объём работ фиксирован, сроки фиксированы, бюджет фиксирован — вы можете составить удобные графики проектов, сообщения для заинтересованных сторон и показатели производительности.

Scrum говорит: «На самом деле, мы не будем знать все эти вещи, и это нормально — мы узнаем их итеративно».

Это нервирует руководителей, менеджеров проектов и сотрудников отдела соответствия. Поэтому организации перенимают форму Scrum (спринты, стендапы, ретроспективы), сохраняя при этом философию Waterfall (предварительное планирование, фазовые ворота, фиксированный объём работ).

Результат: Scrum с дополнительными встречами™.

Результаты поиска признают и это — Waterfall хорошо работает для проектов с чётко определёнными требованиями и минимальными ожиданиями изменений, и многие команды возвращаются к этой структуре, потому что она кажется более безопасной, даже в рамках фреймворка Scrum.

Реальные проблемы со встречами в Scrum (и они реальны)

Позвольте мне быть справедливым: у Scrum есть проблема со встречами, особенно в плохо выполненных реализациях.

Сравните типичный день:

  • Ежедневный стендап: 15 минут (обязательно).
  • Уточнение бэклога: 1–2 часа (еженедельно).
  • Планирование спринта: 2–4 часа (еженедельно).
  • Обзор спринта: 1–2 часа (еженедельно).
  • Ретроспектива: 1–2 часа (еженедельно).
  • Спонтанные синхронизирующие встречи: 1–3 часа (по мере необходимости).

Это 6–15 часов встреч в неделю для команды из 6 человек. Это примерно 20–50% вашей фактической пропускной способности разработки, затраченной на обсуждение разработки.

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

Вот конкретный пример того, как выглядит эффективный Scrum по сравнению с версией с большим количеством встреч:

АНТИПАТТЕРН (Waterfall со спринтами):
- Понедельник 9:00: Ежедневный стендап (15 мин).
- Понедельник 10:00: Неплановая синхронизация по блокировке (30 мин).
- Вторник 9:00: Ежедневный стендап (15 мин).
- Вторник 14:00: Уточнение бэклога (90 мин).
- Среда 9:00: Ежедневный стендап (15 мин).
- Четверг 9:00: Ежедневный стендап (15 мин).
- Четверг 13:00: Планирование спринта (180 мин). 
- Пятница 9:00: Ежедневный стендап (15 мин).
- Пятница 15:00: Специальная дискуссия по дизайну (45 мин).
= 7,5 часов встреч за ~40 часовую неделю = 19% накладных расходов
ЛУЧШИЙ ПАТТЕРН (Настоящий Scrum):
- Пн-Пт 9:00: Ежедневный стендап (15 мин каждый = 75 мин).
- Понедельник 14:00: Непрерывное уточнение бэклога владельцем продукта во время спринта (асинхронно).
- Четверг 13:00: Планирование спринта как планирование, а не перепланирование (90 мин).
- Пятница 16:00: Обзор спринта + ретроспектива (60 мин).
= 3,75 часа встреч за ~40 часовую неделю = 9% накладных расходов

Заметьте разницу?