Agile vs Waterfall

Требования в Agile и Waterfall

📚 15 вопросовПройти тест →
Лекция

Требования в Agile и Waterfall

Agile vs Waterfall

Требования в Agile и Waterfall

Введение: ремонт кухни 🛠️

Если вы точно знаете, что хотите — можно сделать подробный план и идти по нему.
Но если планы меняются каждую неделю, нужен гибкий подход.
Так же и с требованиями: Waterfall любит стабильность и заранее согласованный план,
а Agile — гибкость и регулярные уточнения.
💡 Совет: метод не выбирают «по вкусу» — его выбирают по уровню неопределённости и рисков.
✅ Вывод: подход к требованиям зависит от контекста проекта.

Проблема: один подход на все проекты ❌

Если применять Waterfall там, где всё меняется:
  • требования быстро устаревают;
  • команда тратит время на согласования;
  • продукт отстаёт от рынка.
Если применять Agile там, где всё фиксировано:
  • нет чёткого плана;
  • сложно проходить регуляторные проверки;
  • растёт риск срыва сроков.
✅ Вывод: требования должны жить в том подходе, который подходит проекту.

Чем помогает и как работает

  • Помогает выбрать подход к требованиям по уровню неопределённости, а не по привычке команды.
  • Помогает снизить риск срыва сроков: стабильные требования фиксируются, изменчивые управляются итерациями.
  • Помогает синхронизировать бизнес, аналитику, разработку и QA через понятные правила изменений.
Как это работает:
  • Шаг 1: определяем, какие требования стабильны, а какие будут часто меняться.
  • Шаг 2: выбираем формат артефактов для каждого потока (SRS или backlog/user stories).
  • Шаг 3: фиксируем процесс изменений: CR для фиксированного контура и refinement для гибкого.
  • Шаг 4: регулярно сверяем риски и актуальность требований на уровне команды.
✅ Вывод: правильный выбор процесса делает требования одновременно управляемыми и живыми.

Ключевые термины (простыми словами)

  • Agile (гибкая методология) — итеративная разработка с частыми уточнениями.
  • Waterfall (каскадная модель) — последовательные этапы с фиксированными требованиями.
  • Backlog (бэклог) — список требований и задач для развития продукта.
  • User Story (пользовательская история) — краткое требование «как [роль] хочу [действие]…».
  • SRS (Software Requirements Specification) — подробная спецификация требований.
  • Baseline (базовая версия требований) — согласованный и зафиксированный набор требований.
  • Change Request (запрос на изменение) — формальная заявка на корректировку требований.
  • Acceptance Criteria (критерии приёмки) — условия проверки выполнения требования.
✅ Вывод: эти термины определяют, как выглядит работа с требованиями.

Самое важное (must-know)

  • Waterfall эффективен там, где требования должны быть стабильны и формально согласованы.
  • Agile эффективен там, где требования регулярно уточняются по обратной связи и рынку.
  • Формат требования должен соответствовать подходу: SRS для фиксации, user stories/backlog для адаптации.
  • Процесс изменений обязателен в любом подходе: без него команда теряет управляемость.
  • На практике часто работает гибрид: разные типы требований ведутся разными контурами.
✅ Вывод: в этой теме главное не «что лучше», а «что лучше для конкретного типа требований».

1. Waterfall: требования заранее и подробно

Назначение: зафиксировать всё до начала разработки.
Простыми словами: это режим, где требования сначала подробно фиксируют и согласуют, а изменения потом проходят формальный контроль.
Аналогия: подробный архитектурный проект перед стройкой.
Пример:
SRS: 120 страниц, требования согласованы и утверждены.Изменения только через Change Request.
🔎 Как это происходит на практике:
  1. Бизнес и аналитик формируют полный перечень требований до старта разработки.
  2. Требования утверждаются как baseline и становятся опорой для плана проекта.
  3. Команда реализует работу по утверждённой спецификации без свободных правок.
  4. Любое отклонение оформляется через Change Request с оценкой влияния.
Характеристики:
  • ✅ подробная спецификация (SRS);
  • ✅ требования фиксируются (baseline);
  • ✅ изменения контролируются.
Когда использовать: регуляторные, контрактные, инфраструктурные проекты.
✅ Вывод: Waterfall даёт предсказуемость при стабильных требованиях.

2. Agile: требования как живой бэклог

Назначение: быстро реагировать на изменения.
Простыми словами: это режим, где требования живут в backlog и уточняются по мере получения обратной связи.
Аналогия: готовка по рецепту, который корректируется по вкусу.
Пример:
Backlog:- User Story: как студент хочу фильтр курсов, чтобы быстрее найти нужный.- Acceptance Criteria: фильтр по теме, уровню, длительности.
🔎 Как это происходит на практике:
  1. Требования оформляются как user stories с критериями приёмки.
  2. На refinement команда уточняет формулировки, риски и зависимости.
  3. Приоритеты требований пересматриваются на planning по целям спринта.
  4. После итерации требования обновляются по результатам проверки и фидбэка.
Характеристики:
  • ✅ требования формулируются как user stories;
  • ✅ уточняются на refinement;
  • ✅ приоритеты пересматриваются постоянно.
Когда использовать: продуктовые проекты, стартапы, проекты с высокой неопределённостью.
✅ Вывод: Agile помогает держать требования актуальными.

3. Работа с изменениями

Назначение: договориться, как оформлять и принимать изменения.
Простыми словами: разница в том, что Waterfall старается ограничить изменения, а Agile встраивает их в регулярный процесс.
Аналогия: ремонт квартиры — либо через официальное согласование, либо через быстрые правки на месте.
Waterfall:
  • изменения через формальный Change Request;
  • анализ влияния и пересогласование;
  • часто дорого и долго.
Agile:
  • изменения — нормальная часть процесса;
  • корректировки через приоритизацию бэклога;
  • быстрый цикл обратной связи.
🔎 Как это происходит на практике:
  1. Команда заранее определяет, какие изменения критичны и требуют формального согласования.
  2. Для Waterfall-потока изменение оформляется как CR с анализом сроков и бюджета.
  3. Для Agile-потока изменение попадает в backlog и переоценивается по приоритету.
  4. Решение и статус изменения фиксируются, чтобы сохранить прозрачность для всех ролей.
✅ Вывод: Waterfall контролирует изменения, Agile их ожидает.

4. Документация и артефакты

Назначение: определить, какие документы нужны и в каком объёме.
Простыми словами: документация отличается объёмом и форматом, но в обоих подходах должна обеспечивать проверяемость требований.
Аналогия: подробный техпаспорт vs короткая памятка для команды.
Waterfall:
  • полная SRS;
  • диаграммы, спецификации интерфейсов;
  • фиксированный baseline.
Agile:
  • user stories + acceptance criteria;
  • definition of done;
  • минимально достаточная документация.
🔎 Как это происходит на практике:
  1. Для фиксированного контура готовится формальная спецификация с полнотой требований.
  2. Для гибкого контура ведутся короткие, но проверяемые user stories и acceptance criteria.
  3. Команда согласует минимально достаточный набор артефактов для разработки и QA.
  4. Документация обновляется вместе с изменениями, чтобы не терять актуальность.
✅ Вывод: объём документации зависит от метода и рисков.

5. Роль стейкхолдеров

Назначение: задать уровень вовлечения бизнеса в требования.
Простыми словами: чем выше неопределённость, тем важнее постоянное участие стейкхолдеров в уточнении требований.
Аналогия: совладелец, который регулярно приходит на приёмку, vs заказчик, который утверждает план один раз.
Waterfall:
  • вовлечены в начале;
  • согласуют и утверждают.
Agile:
  • вовлечены постоянно;
  • дают обратную связь каждую итерацию.
🔎 Как это происходит на практике:
  1. На старте проекта определяют роли и уровень вовлечения каждого стейкхолдера.
  2. В Waterfall ключевые согласования проходят в контрольных точках и этапах.
  3. В Agile обратная связь от стейкхолдеров собирается на регулярных итерациях.
  4. Решения по приоритетам и изменениям фиксируются, чтобы убрать разночтения.
✅ Вывод: в Agile стейкхолдеры участвуют чаще, но короткими циклами.

Сравнение: Agile vs Waterfall

КритерийAgileWaterfall
Формат требованийUser Stories, BacklogSRS, спецификации
ИзмененияОжидаемы и управляемыФормальные Change Requests
ДокументацияМинимально достаточнаяПодробная и фиксированная
РискиСнижаются через итерацииСнижаются через планирование
Подход к поставкеЧастые релизыОдин большой релиз

Часто спрашивают на собеседованиях

  • Когда лучше Waterfall, а когда Agile? стабильные требования vs высокая неопределённость.
  • Что такое baseline требований? зафиксированный набор, от которого идут изменения.
  • Чем user story отличается от SRS? короткая цель vs подробная спецификация.
  • Как оформлять изменения в Waterfall? через Change Request.
  • Почему Agile не отменяет документацию? потому что нужна проверяемость и контекст.
✅ Вывод: это базовые вопросы о выборе подхода.

Типичные ошибки

Ошибка 1: Waterfall без стабильных требований

❌ требования меняются каждую неделю
✅ выбрать Agile или гибрид

Ошибка 2: Agile без бэклога

❌ хаос, нет приоритетов
✅ поддерживать и обновлять backlog

Ошибка 3: Нет acceptance criteria

❌ невозможно проверить
✅ критерии приёмки обязательны

Ошибка 4: Игнорирование change management

❌ изменения ломают сроки
✅ процесс изменений обязателен

Ошибка 5: Смешали форматы

❌ user stories в SRS без структуры
✅ выбрать формат под подход

Best Practices

  • Выбирайте подход по рискам и неопределённости.
  • Фиксируйте baseline для Waterfall‑проектов.
  • В Agile держите бэклог живым и приоритизированным.
  • Всегда пишите acceptance criteria.
  • Документируйте изменения (Agile — через backlog, Waterfall — через CR).

Заключение

Ключевые мысли

🎯 Waterfall требует стабильности и фиксированных требований.
🎯 Agile требует гибкости и регулярной обратной связи.
🎯 Выбор подхода = выбор того, как будут жить требования.
Теперь вы можете осознанно выбирать метод и правильно оформлять требования под него.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Требования в Agile и Waterfall»

Пройти тест →