Agile vs Waterfall: какую методологию выбрать для разработки ПО

Для заказчика разработки выбор «Agile vs Waterfall» — это прежде всего вопрос договора, а не теории управления. От методологии зависит, что вы получите на старте (подробное техническое задание или бэклог), за что будете платить (за этап или за время команды), когда увидите первую работающую версию и кто оплатит изменения, которые почти неизбежно появятся по ходу проекта. Если вы заказываете разработку программного продукта под ключ, модель работы влияет на бюджет, сроки и распределение рисков между вами и подрядчиком сильнее, чем выбор языка программирования или фреймворка.

Это не ликбез. Если нужны основы, начните с материалов о том, что такое Agile, и с обзора методологий разработки ПО. Здесь два подхода сравниваются глазами заказчика: таблица различий, сценарии выбора, связь с типом договора, ТЗ и приёмкой, гибридные модели, данные исследований, влияние на бюджет и чек-лист для самостоятельного решения.

Что такое Waterfall и как он работает

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

Модель принято связывать со статьёй Уинстона Ройса «Managing the Development of Large Software Systems» (1970). В ней есть парадокс, о котором вспоминают редко: Ройс описал строго последовательную схему как рискованную. Он обращал внимание, что ошибки требований и проектирования проявляются только на тестировании, когда исправлять их дороже всего, и предлагал обратные связи между фазами, раннее прототипирование и вовлечение заказчика (подробнее об истории модели — в обзоре происхождения каскадной модели). Слово «водопад» появилось позже, а в отрасли закрепилась именно упрощённая линейная версия. Она хорошо легла на логику крупных контрактов и регламентов: одобрили документ — перешли к следующему этапу — подписали акт.

Этапы каскадной модели

1. Сбор и анализ требований. Аналитики фиксируют, что должна делать система. Результат — техническое задание или спецификация требований (SRS), которую утверждает заказчик.
2. Проектирование. Архитектура, модель данных, интеграции, макеты интерфейсов. Результат — проектная документация.
3. Разработка. Программисты реализуют систему по утверждённому проекту.
4. Тестирование. Проверка соответствия ТЗ: функциональные, интеграционные, нагрузочные тесты, приёмочные испытания.
5. Внедрение. Развёртывание, перенос данных, обучение пользователей, подписание акта.
6. Поддержка. Исправление ошибок и доработки, чаще всего уже по отдельному договору.

Центральный артефакт Waterfall — ТЗ. На нём держится всё остальное: оценка, план, цена договора и критерии приёмки. Изменения после утверждения проходят через процедуру change request: подрядчик оценивает влияние на сроки и стоимость, стороны подписывают допсоглашение. Поэтому каскадную модель до сих пор используют там, где объём известен заранее, а отступление от согласованного документа само по себе риск: госсектор, регулируемые системы в финансах и медицине, промышленная автоматизация, встроенное ПО, интеграции и миграции данных.

Что такое Agile и как он работает

Agile — не конкретная методология, а набор ценностей и принципов гибкой разработки. Их сформулировали в феврале 2001 года семнадцать практиков в Манифесте гибкой разработки программного обеспечения. Манифест содержит четыре ценности:

• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.

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

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

Фреймворки Agile: Scrum, Kanban и другие

Ценности Agile реализуются через конкретные фреймворки:

• Scrum — спринты фиксированной длины, роли (владелец продукта, Scrum-мастер, команда разработки) и обязательные события: планирование, ежедневная встреча, демо, ретроспектива;
• Kanban — непрерывный поток задач с ограничением незавершённой работы, без фиксированных спринтов; удобен для поддержки и развития продукта;
• Extreme Programming (XP) — инженерные практики: парное программирование, разработка через тестирование, непрерывная интеграция;
• Lean — устранение потерь и сокращение времени от идеи до релиза;
• SAFe и LeSS — подходы к масштабированию Agile на десятки команд.

В заказной разработке чаще всего встречаются Scrum и Kanban. Чем они отличаются и как выбрать между ними, мы разобрали в статье «Scrum и Kanban — в чём разница и какую методику выбрать?».

В чём разница между Agile и Waterfall — сравнительная таблица

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

Критерий	Agile	Waterfall
Подход	Итеративный: короткие циклы, каждый даёт работающий инкремент	Последовательный: фазы идут одна за другой
Требования и ТЗ	Бэклог и user stories, уточняются по ходу	Детальное ТЗ или SRS, утверждается до разработки
Реакция на изменения	Нормальная часть процесса, через перестановку приоритетов	Через change request, допсоглашение и пересчёт цены
Роль заказчика	Постоянное участие: приоритеты, демо, решения каждую итерацию	Активен на старте и при приёмке этапов
Первый рабочий результат	Через 1–2 итерации	Ближе к концу проекта, после тестирования
Планирование	Укрупнённая дорожная карта и детальный план на ближайшую итерацию	Детальный план на весь проект в начале
Бюджет	Фиксирована стоимость периода работы команды, объём гибкий	Фиксирован объём и цена, изменения оплачиваются отдельно
Тип договора	Time & material, выделенная команда, бюджет на период	Fixed price с поэтапной приёмкой
Документация	Минимально достаточная, живёт рядом с кодом и в трекере	Полная, формальная, часть результата работ
Тестирование	Внутри каждой итерации, автотесты и регресс постоянно	Отдельная фаза после разработки
Риски и когда они проявляются	Видны рано, но итоговые сроки и сумма менее предсказуемы	Предсказуемый план, но ошибки требований всплывают поздно
Типичные проекты	Стартапы, MVP, мобильные и веб-продукты, развитие продукта	Госзаказ, регулируемые системы, интеграции, встроенное ПО

Если свести таблицу к одной мысли: Waterfall покупает предсказуемость ценой гибкости, Agile — гибкость ценой предсказуемости. В каскадной модели вы заранее знаете, что и за сколько получите, но расплачиваетесь за каждое изменение и поздно узнаёте, правильно ли были поставлены требования. В Agile вы рано видите работающий продукт и можете менять курс, но итоговая сумма зависит от того, сколько итераций понадобится.

Важно и то, что методология не существует отдельно от людей. Agile требует от заказчика времени и готовности принимать решения каждую неделю или две. Если такого человека на стороне заказчика нет, гибкая методология разработки быстро превращается в хаотичную, а Waterfall с хорошим ТЗ может оказаться честнее.

Плюсы и минусы каждого подхода

Сильные и слабые стороны Waterfall

Сильные стороны:

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

Слабые стороны:

• изменения дорогие и медленные: каждое проходит через change request;
• первый работающий результат появляется поздно;
• ошибки в требованиях обнаруживаются на тестировании или при внедрении, когда исправлять их дороже всего;
• риск получить систему, которая соответствует ТЗ, но не решает задачу бизнеса;
• длинная фаза анализа: за время подготовки ТЗ рынок или процессы могут измениться;
• оценка «на весь проект» создаёт иллюзию точности, хотя подрядчик закладывает в неё риск-буфер.

Сильные и слабые стороны Agile

Сильные стороны:

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

Слабые стороны:

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

Когда выбрать Waterfall?

Каскадная модель уместна там, где неопределённость низкая, а цена отклонения от согласованного плана высокая. Типичные сценарии:

1. Госзаказ и тендеры с жёстким ТЗ. Объект закупки описывается до объявления процедуры, цена контракта фиксируется, приёмка идёт по этапам и актам. Гибкий объём в такую конструкцию вписывается с трудом.
2. Регулируемые отрасли и сертификация. Медицинское ПО, банковские системы в части требований регулятора, промышленная автоматизация. Здесь нужна трассируемость: каждое требование связано с проектным решением, тестом и записью о проверке. Формальные фазы и полная документация упрощают аудит.
3. Интеграция или миграция с известным объёмом. Перенос данных из одной системы в другую, подключение к API с описанным контрактом, замена модуля с сохранением функциональности. Требования известны, сюрпризов мало.
4. Небольшой проект с понятными требованиями. Корпоративный сайт, лендинг, внутренний инструмент на несколько экранов. Затраты на итерации, демо и ретроспективы здесь могут превысить пользу.
5. Встроенное ПО и связка с «железом». Когда параллельно разрабатывается оборудование со своим длинным циклом, программная часть подстраивается под его график и спецификации.

Когда выбрать Agile?

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

1. Стартап и MVP. Продукт ищет рынок, гипотезы проверяются на пользователях, и половина исходных требований может оказаться ненужной. Как определить минимальный объём первой версии, мы рассказывали в статье «MVP: от концепции до создания минимально жизнеспособного продукта».
2. Продукт с живыми пользователями и метриками. Решения о следующей функции принимаются по данным аналитики, обращениям в поддержку и A/B-тестам, а не по документу годичной давности.
3. Мобильное или веб-приложение с частыми релизами. Магазины приложений, конкуренты и пользователи ждут регулярных обновлений, и короткие итерации естественно ложатся на такой ритм.
4. Высокая неопределённость требований. Новая предметная область, новый для компании процесс, сложный пользовательский опыт, который нужно проверять на прототипах.
5. Долгосрочное развитие продукта. Когда разработка не заканчивается релизом, а продолжается годами, работа выделенной команды по бэклогу удобнее серии отдельных «проектов по ТЗ».

Как методология связана с договором: fixed price или time & material?

Именно здесь выбор методологии становится юридическим и финансовым решением. Большинство сравнений обходят этот вопрос, хотя заказчика он касается в первую очередь. Связь прямая: Waterfall естественно сочетается с договором fixed price, Agile — с time & material или фиксированной командой. Подробно о плюсах и рисках каждой модели оплаты — в статье «Fixed price или Time and Material: как выбрать модель».

Waterfall и fixed price. Цена и сроки фиксируются на основании детального ТЗ. Заказчик получает предсказуемый бюджет, но платит за это двумя способами. Во-первых, подрядчик закладывает в цену риск-буфер, ведь он отвечает за перерасход. Во-вторых, всё, что не описано в ТЗ, становится предметом спора и change request. Чем менее проработано ТЗ, тем дороже обходится фиксированная цена.

Agile и time & material. Заказчик оплачивает фактически отработанное время команды по согласованным ставкам. Объём гибкий, приоритеты можно менять каждую итерацию, буфер на неопределённость в цену не закладывается. Риск перерасхода при этом переходит к заказчику, поэтому ему нужны прозрачность и инструменты контроля.

Между этими полюсами есть рабочие компромиссы, которые подходят для гибкой разработки:

• Выделенная команда — фиксированный состав и ежемесячная оплата, объём определяется бэклогом;
• Фиксированный бюджет на период — сумма на квартал или релиз известна, а состав функций внутри неё гибкий;
• Fixed price на спринт или этап — каждая итерация оплачивается по согласованной стоимости, после неё можно скорректировать план или остановиться;
• T&M с потолком — оплата по факту, но не выше согласованного лимита без отдельного одобрения.

Модель договора	С какой методологией сочетается	Основной риск заказчика	Что прописать
Fixed price	Waterfall	Буфер в цене, споры о границах объёма, дорогие изменения	Детальное ТЗ, этапы и критерии приёмки, порядок и стоимость change request
Time & material	Agile	Перерасход при слабом контроле	Ставки, отчётность по часам, доступ к трекеру, право остановить работу
Выделенная команда	Agile, Kanban	Оплата простоя при нечётком бэклоге	Состав команды, порядок замены специалистов, регулярность демо
Fixed price на этап	Гибрид	Неточная оценка следующих этапов	Цель каждого этапа, условия перехода к следующему и выхода из договора

Что важно прописать в договоре независимо от модели:

• порядок приёмки — по этапам и актам (Waterfall) или по инкрементам после демо (Agile), с критериями «готово»;
• порядок изменений — кто инициирует, кто оценивает, в какой срок, как меняются цена и сроки;
• права на результат — передача исключительных прав на код по каждому этапу или инкременту, а не только в конце проекта;
• условия выхода — как завершить работу досрочно, что заказчик получает на этот момент (код, документация, доступы);
• отчётность — формат и частота отчётов о прогрессе и затратах.

ТЗ или бэклог: что заказчик получает на старте и как принимает работу

В Waterfall стартовый результат — техническое задание или спецификация требований к ПО. Это формальный документ: функции, нефункциональные требования, интеграции, ограничения, критерии приёмки. Его утверждают до разработки, и он становится приложением к договору. Как устроена такая спецификация и что в неё входит, описано в статье «SRS: что такое и зачем это нужно разработчикам».

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

Отсюда разница в приёмке. В каскадной модели вы подписываете акт по завершении этапа после приёмочных испытаний по ТЗ. В Agile вы смотрите результат на демо в конце каждой итерации, а приёмка привязана к Definition of Done — общему для команды и заказчика определению «задача готова». Юридически это часто оформляют ежемесячным актом на фактически выполненные работы с приложением списка закрытых задач.

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

• демо каждой итерации — вы видите работающий результат, а не процент выполнения в отчёте;
• доступ к трекеру задач — бэклог, статусы и списанное время видны в любой момент;
• диаграммы сгорания (burn-down, burn-up) — показывают, сколько работы осталось и с какой скоростью она закрывается;
• скорость команды (velocity) — средний объём работы за итерацию, по которому можно прогнозировать сроки оставшегося бэклога;
• регулярный отчёт о затратах — часы и сумма по итерации в сравнении с планом.

Можно ли совместить Agile и Waterfall? Гибридные модели

Да, и в заказной разработке гибрид встречается чаще «чистых» подходов. Выбор Agile или Waterfall не обязан быть взаимоисключающим: разные части проекта могут жить по разным правилам. Три устойчивые схемы:

Water-Scrum-Fall. Планирование и бюджетирование идут по каскадной логике (требования, оценка, утверждение), разработка — итерациями по Scrum, а выпуск и внедрение — снова формальной фазой с приёмочными испытаниями. Такую схему часто выбирают крупные компании: бюджетный процесс и релизный регламент остаются прежними, а команды работают гибко.

Фиксированный Discovery, затем итерации. Первый этап — исследование и проектирование: цели, пользователи, сценарии, архитектура, прототип, оценка. Его делают по фиксированной цене и с понятным результатом. Дальше разработка идёт итерациями по бэклогу, который сформирован на Discovery. Заказчик получает предсказуемость там, где она возможна, и гибкость там, где она нужна. Что входит в этот этап и сколько он длится, мы разобрали в статье «Как вместе с клиентом из идеи спроектировать приложение».

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

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

• ТЗ на двести страниц утверждено заранее, и любое отклонение от него — change request, но команда «работает спринтами»;
• демо проводятся, но решения по их итогам не принимаются, потому что всё уже зафиксировано;
• заказчик не выделяет владельца продукта, и приоритеты определяет подрядчик;
• оплата по факту часов, а объём жёстко зафиксирован — заказчик несёт риски обеих моделей сразу.

Что говорят исследования об успешности проектов?

Самый цитируемый источник в споре Agile vs Waterfall — отчёты CHAOS компании Standish Group. По сводке отчёта 2015 года, которую приводит Scrum.org, по проектам всех размеров успешными признаны 39% Agile-проектов против 11% каскадных, а провалились 9% Agile-проектов против 29% Waterfall. Остальные попали в категорию «с проблемами» — с превышением сроков, бюджета или урезанным объёмом.

Похожий вывод делал и более ранний отчёт: по данным CHAOS 2011, которые разбирает Mountain Goat Software, Agile-проекты успешны примерно в три раза чаще каскадных. Тот же порядок разницы называли и в более поздних выпусках отчёта.

Эти цифры важно читать с оговорками:

• методологию отчётов критикуют — Standish Group не раскрывает полностью выборку и критерии, а определение «успеха» (в срок, в бюджет, с ожидаемым объёмом) само по себе спорно;
• выборка в основном американская — переносить результаты на российский рынок и госзаказ напрямую нельзя;
• корреляция не означает причинности — Agile чаще выбирают для проектов, где он уместен, а Waterfall — для крупных и регламентированных проектов, которые проваливаются чаще независимо от методологии.

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

Почему Agile в России приживается медленнее

Agile в России давно используют продуктовые IT-компании, банки и крупный e-commerce. В заказной разработке, особенно с государственными и крупными корпоративными заказчиками, гибкие модели встречаются реже. Это не вопрос «отсталости», а следствие нескольких устойчивых факторов:

• культура ТЗ и госзакупок. Законы 44-ФЗ и 223-ФЗ требуют описать объект закупки до проведения процедуры, а цену контракта зафиксировать. Гибкий объём плохо совместим с такой логикой, и привычка «сначала ТЗ, потом работа» переходит из госсектора в коммерческие компании;
• бухгалтерия и приёмка по актам. Финансовой службе нужен понятный результат работ для акта и учёта. Формулировка «команда работала месяц над приоритетными задачами» требует дополнительного оформления;
• недоверие к T&M. Оплата по факту воспринимается как «подписать чек без суммы», особенно если с подрядчиком нет истории отношений;
• нехватка роли владельца продукта. У заказчика часто нет сотрудника, который может каждую неделю принимать продуктовые решения, а без него Agile не работает.

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

Стоимость и сроки разработки: как методология влияет на бюджет

Методология сама по себе не делает проект дешевле или дороже. Она меняет структуру затрат и то, в какой момент заказчик узнаёт итоговую сумму. Универсальных цифр нет: бюджет определяют объём, сложность, интеграции и состав команды. Различия в структуре устойчивые:

Статья затрат	Waterfall	Agile
Анализ и требования	Длинный и дорогой этап до старта разработки	Короче на старте, уточнение распределено по итерациям
Риск-буфер в цене	Закладывается подрядчиком в фиксированную цену	Не закладывается, риск перерасхода на заказчике
Изменения требований	Оплачиваются отдельно через change request	Входят в бюджет за счёт перестановки приоритетов
Время заказчика	Сосредоточено на старте и приёмке	Распределено по всему проекту: демо, приоритеты
Первый релиз	В конце проекта	Раньше, часто через несколько итераций
Предсказуемость итоговой суммы	Высокая, если ТЗ не меняется	Ниже, управляется лимитами и приоритетами
Документация	Входит в результат работ	Минимальная, полная — по отдельной договорённости

Условный пример (иллюстрация, а не расчёт). Представим проект, в котором по ходу работы меняется примерно треть исходных требований — для нового продукта это обычная ситуация. В Waterfall каждое изменение проходит оценку и оплачивается сверх фиксированной цены, а часть уже сделанной работы уходит в корзину; итоговый бюджет оказывается выше стартового. В Agile те же изменения поглощаются перестановкой приоритетов: итоговая сумма остаётся в рамках бюджета на период, но часть функций из первоначального плана в релиз не попадает. Обратная ситуация — требования стабильны, и меняется меньше десятой части. Тогда Waterfall даёт точную цену заранее, а итерационные накладные расходы Agile (демо, планирования, ретроспективы) не окупаются.

Из чего складывается оценка проекта и почему вилки у подрядчиков так различаются, читайте в статье «Из чего состоит оценка проекта для заказной разработки».

Чек-лист: как выбрать методологию для своего проекта

Ответьте на вопросы ниже. Если большинство ответов указывает в одну сторону, выбор очевиден. Если ответы разделились, присмотритесь к гибриду.

• Насколько хорошо известны требования? Описаны полностью и вряд ли изменятся → Waterfall. Есть видение, детали будут уточняться → Agile. Нужен этап, чтобы их выяснить → гибрид с Discovery.
• Готовы ли вы выделить представителя для регулярной работы с командой? Нет → Waterfall. Да, с правом принимать решения → Agile.
• Насколько жёсткие бюджет и дата? Сумма и срок не могут сдвинуться → Waterfall или фиксированный бюджет с гибким объёмом. Есть пространство для манёвра → Agile.
• Есть ли регуляторные требования и сертификация? Да, с полной трассируемостью → Waterfall или гибрид с формальными вехами. Нет → любой вариант.
• Нужен ли ранний релиз? Да, чтобы проверить гипотезу или показать инвесторам → Agile. Нет, важна полная функциональность к дате → Waterfall.
• Какой договор допускает ваша бухгалтерия или закупки? Только фиксированная цена с актом по этапу → Waterfall или гибрид с оплатой по этапам. T&M допустим → Agile.
• Проект — разовая разработка или развитие продукта на годы? Разовая с понятным концом → Waterfall. Долгое развитие → Agile.
• Насколько дороги ошибки требований? Ошибку легко исправить следующим релизом → Agile. Ошибка в выпущенной системе дорога или опасна → Waterfall или гибрид.
• Зависит ли ПО от оборудования или внешних подрядчиков с жёстким графиком? Да → Waterfall или вехи с итерациями внутри. Нет → Agile.
• Есть ли опыт гибкой работы у вас и у подрядчика? Нет ни у кого → начните с гибрида и коротких этапов. Есть → Agile.

Как YuSMP Group выбирает методологию для проекта

Мы не навязываем одну методологию всем проектам: модель работы выбирается под задачу, ограничения заказчика и требования его финансовой службы. Когда клиент приходит за разработкой под ключ или разработкой MVP, порядок обычно такой:

1. Discovery и оценка. Разбираем цели, пользователей, сценарии, интеграции и ограничения, оцениваем неопределённость требований.
2. Предложение модели работы. По итогам предлагаем Waterfall, Agile или гибрид с обоснованием: где нужна фиксация, где — гибкость, как будет устроена приёмка.
3. Договор под модель. Тип оплаты, порядок изменений, критерии приёмки и формат отчётности прописываем так, чтобы они соответствовали выбранной методологии, а не противоречили ей.

Часто задаваемые вопросы

Что лучше для стартапа — Agile или Waterfall?

В большинстве случаев Agile. Стартап проверяет гипотезы, и часть исходных требований почти наверняка изменится после первых пользователей. Итерации позволяют быстро выпустить MVP, получить обратную связь и скорректировать план без переподписания договора. Waterfall оправдан, только если продукт — точная копия понятного процесса с известными требованиями.

Можно ли перейти с Waterfall на Agile посреди проекта?

Можно, но это нужно оформить, а не просто начать работать спринтами. Обычно уже утверждённое ТЗ превращают в бэклог, расставляют приоритеты, договариваются о новом порядке приёмки и, при необходимости, меняют модель оплаты допсоглашением. Безопаснее переходить на границе этапа, а не посреди него.

Нужно ли ТЗ при работе по Agile?

Детальное ТЗ на весь проект не нужно, но документ с целями, рамками и ключевыми требованиями нужен. В Agile его роль выполняют видение продукта, дорожная карта и бэклог с пользовательскими историями и критериями приёмки. Нефункциональные требования — безопасность, производительность, интеграции — лучше зафиксировать письменно с самого начала.

Подходит ли Agile для госзаказа?

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

Agile дороже Waterfall?

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

Чем Scrum отличается от Agile?

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

Как контролировать бюджет при Agile?

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

Что такое гибридная методология?

Это сочетание элементов Waterfall и Agile в одном проекте. Самые распространённые варианты — фиксированный этап Discovery с последующей итеративной разработкой, Water-Scrum-Fall с каскадным планированием и выпуском и итеративной разработкой посередине, а также крупные вехи с фиксированными целями и спринтами внутри них.

Какую методологию выбрать для мобильного приложения?

Чаще всего Agile или гибрид. Мобильное приложение выпускается в магазины и обновляется регулярно, а пользователи быстро дают обратную связь через отзывы и аналитику. Короткие итерации позволяют выпускать обновления в таком же ритме. Waterfall подходит для небольшого приложения с фиксированным набором экранов, например корпоративного инструмента.

Вывод: Agile или Waterfall — как принять решение

Agile vs Waterfall — не спор старого и нового, а выбор того, за что вы платите: за предсказуемость или за гибкость. Оба подхода зрелые, и правильный ответ определяют условия проекта, а не мода.

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

Выбирайте Agile, если продукт новый и будет меняться по обратной связи пользователей, важен ранний релиз, у вас есть владелец продукта с правом принимать решения, а финансовая служба допускает оплату по времени или бюджет на период.

Выбирайте гибрид, если вам нужна предсказуемость для бюджета и гибкость для продукта одновременно. Самая практичная схема — фиксированный Discovery с понятным результатом, затем итеративная разработка с ежемесячной приёмкой и прозрачным контролем затрат.