Agile — это ценности, а не методология

Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

   Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.

Waterfall: миф о жестком подходе

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

Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:

1. Техническое задание

2. Эскизный проект

3. Технический проект

4. Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)

5. Внедрение (Подготовка и передача программы)

Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:

1. Устранение ошибок.

2. Развитие и усовершенствование продукта.

Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.

Почему возникает миф о несовместимости?

Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».

Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут:
- Давайте заново начнем.

Однако в реальности:

Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками.
Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum.
Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.

Синтез вместо конфронтации: гибридные подходы

На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например:
Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.

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

Как же выбирать методологию? Нужно опираться на критерии, а не догмы
Выбор между Waterfall и итерационными методами зависит от четырёх факторов:

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

2. Стоимость изменений.
   В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.

3. Регуляторные ограничения.
   В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.

4. Культура команды и заказчика.
   Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.

Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum

Заключение: за пределами маркетинговых мифов

Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:

1. Какова степень неопределённости требований?

2. Какие ограничения накладывают регуляторы или бюджет?

3. Насколько команда и заказчик готовы к гибкости?

Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:

1. Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».

2. Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).

3. Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.

Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.

Простыми словами – заказчику не нужно напрягать голову в момент согласования заказа – приходи хоть через месяц, хоть через год, и говори: «Ой, я забыл совсем – вот тут нужно еще добавить вот это, а вот это должно быть не зеленым, а коричневым». И команда-исполнитель это должна принимать.

Выгодно это заказчику? Конечно, заказчику это выгодно. Выгодно это исполнителю? Очевидно, что нет. Лишняя работа за бесплатно.

Но проблема, на самом деле, еще глубже, чем дополнительные нагрузки на исполнителей. Дело в том, что гибкие методологии можно использовать только на простых проектах. И категорически противопоказано их использовать на сложных.

Два простых примера

Первый пример

Приходит заказчик (мэрия города) в артель, занимающуюся изготовлением уличного инвентаря, и говорит: «Мы открываем новый парк в N-ском районе, нам нужно для парка 20 лавок, каждая лавка должна быть рассчитана на 3-х человек».

Артельщики говорят: «Не вопрос – у лавки будет одна секция и две опорные металлические стойки. Вот дизайн, вот стоимость, срок – 3 недели».

Мэрия говорит: «По рукам».

Второй пример

Приходит какой-нибудь умник с мешком денег в аэрокосмическое агентство условной страны Y и говорит: «Хочу организовать туристический маршрут на орбиту – нужна ракета, способная брать на борт 3-х человек».

В агентстве умнику говорят: «Хорошо, вот вам смета, вот сроки – 5 лет».

А теперь применим правило гибких методологий – прием изменений в проект на любых стадиях проекта.

В первом примере.

Приходит заказчик (мэрия города) в артель через две недели после начала работы и говорит: «Вы знаете, мы просчитались, в N-ском районе живет в два раза больше людей, поэтому нам нужно для парка 20 лавок не по 3 человека на лавку, а по 6».

Артельщики говорят: «Не вопрос – нам нужно будет для лавки 2 секции, вместо одной, и 3 стойки вместо двух. Мы уже купили короткие доски, а нам теперь нужны длинные. Оплачивайте дополнительные стойки, уже купленные короткие доски и новые длинные и все сделаем».

Т.е. стоимость проекта вырастет более чем на 50% от первоначальной сметы, но, во всяком случае, проект может быть выполнен и будет выполнен в заявленные сроки – никаких существенных препятствий для этого нет.

А теперь посмотрим, что произойдет во втором примере.

Приходит умник в аэрокосмическое агентство через 2 года после начала проекта и говорит: «Вы знаете, я пересчитал бизнес-план, мне мало 3-х человек, мне нужно выводить на орбиту минимум шесть, чтобы проект был рентабельным».

Ракетчики смотрят на умника как на идиота и говорят: «Вы понимаете, что это совсем другая задача? Если будет не 3 человека, а 6 – это не только увеличение выводимой на орбиту массы в два раза, это еще и дополнительный запас кислорода, это увеличение жилого пространства в ракете в 2 раза, это увеличение топливных баков, это другая обшивка – это совершенно новый проект! Более того, сейчас не только таких двигателей может не быть, может еще просто не существовать технологий, чтобы их строить.

Итого, что в итоге – простые проекты по гибкой методологии делать можно. Сложные – только по каскадным методологиям (Waterfall) – c четким ТЗ изначально.

У всех методов есть рамки применения. Они не универсальны. Нужно об этом всегда помнить.

(с) Бухаров К.А.

3. Следующий этап и доработка. Во втором этапе добавили дверь и собрали второй этаж. Чтобы не перепутать цвета, кубики заранее отсортировали. На работу заложили 4 дня. Далее собрали третий этаж и получили бело‑сине‑красную башню со входом — точно в срок.

Итог: башня строилась шагами, роли были понятны, ошибки исправлялись сразу. Scrum подходит для проектов, где нужно постоянно улучшать продукт, но при этом держать ритм.

Терминология Scrum
Спринт — короткий отрезок времени, за который команда должна сделать готовый кусочек продукта. У нас это были этапы по 3 и 4 дня. В реальных проектах спринт длится 2–4 недели.
Бэклог продукта — список всех идей и задач (например, добавить вход). Бэклог пополняется в процессе работы.
Бэклог спринта — задачи, выбранные на конкретный спринт.
Дейли (Stand‑up) — ежедневные короткие собрания.
Демонстрация (Демо) — показ результата и сбор идей (пришла идея добавить дверь)
Ретроспектива — работа над ошибками и улучшениями (почему перепутали цвет кубика и как этого не допустить в будущем).

Kanban — собираем LEGO с доской и стикерами
На этот раз мы строим башню без жёстких сроков и визуально отображаем процесс.
1. Планируем. Берём доску и стикеры, рисуем три колонки:
- Что нужно собрать?
- Что собираем?
- Что собрано?
В первую колонку клеим задачи: «Собрать первый этаж», «Собрать второй этаж», «Собрать третий этаж».

2. Собираем башню. Берём стикер из первой колонки и переносим во вторую. Закончили — перемещаем в «Собрано». Проверяем по инструкции — и снова ошибка: вместо красного кубика поставлен коричневый. Тогда добавляем новый стикер «Исправить цвет кубика», переносим его в колонку «Что собираем?» и сразу же исправляем ошибку.

Так мы собрали всю башню, параллельно внося изменения: на ходу придумали сделать вход в башню — и просто добавили новый стикер. В Kanban это нормально: менять и улучшать можно хоть в процессе.

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

Вывод: Scrum и Kanban — лишь разные способы организовать процесс, но их можно использовать вместе. Например, команда может работать спринтами, как в Scrum, но при этом вести задачи на Kanban‑доске, чтобы видеть процесс и быстро реагировать на изменения.
Agile не требует строго следовать одной методологии, а позволяет комбинировать инструменты под задачи команды, чтобы строить продукты быстрее, качественнее и без путаницы.)

Буду благодарна, если поддержите подпиской в тг
https://t.me/jer_it
🎉