Битва титанов: Waterfall VS Agile — какую методологию управления проектами выбрать

Waterfall как Билл Гейтс — строгий и бескомпромиссный, а Agile — амбициозный стартапер, готовый к экспериментам. Разбираемся, в чëм сходства и различия двух методологий.

Что такое Waterfall
Как работает Waterfall
Преимущества и недостатки водопадной модели
Отличие методологии Agile от Waterfall
Когда стоит применять каскадную модель
Совет эксперта

Что такое Waterfall

Методология Waterfall — её ещё называют каскадной или водопадной — это классическая модель жизненного цикла разработки ПО. Была придумана в 1950-х годах, и, пока не появился Agile, все продукты и проекты реализовывали с её помощью.

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

Например, создание сайта обычно проходит в семь этапов:

Понимание структуры;
Анализ конкурентов;
Разработка прототипа;
Подготовка контента;
Дизайн;
Вёрстка, интеграция вёрстки в систему управления сайтом и наполнение контентом;
Тестирование и запуск проекта.

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

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

Как работает Waterfall

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

Схема работы в Waterfall похожа на водопад, поэтому модель называют каскадной или водопадной

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

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

Разобраться с методологиями управления IT-проектами помогут кураторы, наставники и ревьюеры на курсе «Менеджер проектов». Есть базовый и расширенный вариант прохождения программы: полгода для специалистов с опытом управления в других сферах и 9 месяцев с нуля.

Зарабатывайте, управляя проектами

Освойте профессию с нуля за 6 месяцев, научитесь вести переговоры и строить отношения с клиентами. Пройдите бесплатную вводную часть курса «Менеджер проектов», чтобы попробовать себя в новой роли.

Попробовать

Преимущества и недостатки водопадной модели

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

Преимущества

✅ Чёткость и предсказуемость
Требования заказчика собирают перед тем, как приступить к проекту. Решение, каким должен быть продукт, принимают исходя из анализа данных. Этапы разработки определяют заранее.

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

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

✅ Подходит для типовых проектов, знакомых команде
Если до этого уже были подобные проекты, Waterfall подойдёт, потому что:
● Не нужно проводить дополнительных исследований.
● Нет новых непонятных технологий, с которыми раньше не работали.
● Инструменты известны заранее.

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

Недостатки

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

❌ Высокий уровень рисков
Методология каскадной модели не предусматривает изменения на более поздних этапах разработки. Если изменения всё-таки придётся вносить, есть риск сорвать сроки либо команда вынуждена будет работать сверх плана.

❌ Бюджет жёстко ограничен и за него отвечает исполнитель
Полная ответственность за срыв сроков и за незапланированное увеличение бюджета лежит на исполнителе. Если уволится тимлид команды или объём работ неправильно оценят на старте, то исполнитель будет решать это на своей стороне.

❌ Не подойдёт для проектов, где быстро меняются требования
Если после начала проекта поняли, что нужна другая функциональность, то с Waterfall её сделать не получится. Это приводит к риску, например, делать проект пять лет по водопадной модели и столкнуться с тем, что он уже устарел, когда закончили.

❌ Заказчик не участвует в каждом этапе разработки
Клиент может неправильно сформулировать техническое задание, и в итоге продукт не будет соответствовать ожиданиям.

Отличие методологии Agile от Waterfall

И Agile, и Waterfall популярны в разработке программного обеспечения, но каждая из них подходит для разных типов проектов.

Разберëм разницу между моделями на примере создания веб-приложения для книжного интернет-магазина.

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

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

Возможные проблемы:

● Нужно что-то доработать. Например, клиент на старте не учёл в ТЗ программу лояльности, чтобы начислялись баллы за покупку. Приходится переделывать личный кабинет, из-за чего срок проекта увеличивается.

● На финальных стадиях разработки клиент просит добавить функцию как на сайте конкурента. Это возможно только в следующей версии, потому что в начале проекта это не зафиксировали.

Agile
Каждый спринт начинается с планирования — например, на первом этапе команда будет делать макет будущего приложения. Глобальные задачи — их ещё называют эпики — на этот спринт будут следующие: нарисовать mind map с функциями, затем сделать прототип в Figma, согласовать с клиентом. Задачи на спринт участники команды определяют вместе с проджект-менеджером.

Промежуточным результатом для клиента будет макет будущего приложения. Чтобы команда могла двигаться дальше, клиент комментирует, что нравится, а что хочется улучшить. Эти задачи будут решать в следующем спринте.

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

Когда стоит применять каскадную модель

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

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

Совет эксперта

Лера Фимина
Каждый проект уникален — разные требования, специфика, состав команды, заказчики, внешние условия. Поэтому удобнее совмещать разные фреймворки. Так принципы будут использоваться эффективнее, а риски ошибиться в процессе — ниже. Главное в работе с инструментами менеджера — исходить из удобства команды, тестировать разные подходы и оставлять только то, что нужно.

Статью подготовили: