Что такое Waterfall и чем он отличается от Agile

Что такое водопадный подход

Водопадная или каскадная модель разработки программного обеспечения (waterfall, водопад) – это процесс разработки, в котором последовательно идут фазы сбора и анализа требований, проектирования и прототипирования, реализации, тестирования, интеграции и поддержки. Линейный подход к разработке программного обеспечения состоит из нескольких этапов:

1. Требования. Ключевой аспект водопадного подхода заключается в том, что все требования заказчика собраны в самом начале работы. Это позволяет заранее спланировать каждую из последующих фаз следовать намеченному плану без значительных отклонений.
2. Проектирование. Лучше всего фаза проектирования работает при делении на две подфазы: логическую, когда возможные решения обдумываются, и физическую, когда предложенные решения собираются в определенные требования.
3. Внедрение. Эта фаза подразумевает непосредственно работу программистов в соответствии с заранее установленными на предыдущих этапах требованиями.
4. Подтверждение. На этом этапе заказчик проверяет продукт и удостоверяется в том, что все требования совпадают и изначальными. Данный этап завершается выпуском продукта на рынок.
5. Обслуживание. Заказчик регулярно использует продукт во время этого этапа, обнаруживает недочеты и ошибки в работе приложения. Команда разработчиков исправляет их до тех пор, пока заказчик не будет удовлетворен.

 Плюсы

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

1. Разработчики и заказчики «на берегу» договариваются о результатах работы. Это позволяет спланировать и набросать макет финального продукта, не переживая о концептуальных изменениях по ходу работы;
2. Прогресс работы легче измерить, так как итоговый продукт обозначен заранее;
3. По ходу разработки разные члены команды могут заниматься другими проектами, в зависимости от стадии разработки продукта. Например, бизнес-аналитики могут подготовить документацию, пока программисты заняты другой работой, а тестировщики могут определить важные для рассмотрения и тестирования области в тот момент, когда программа еще находится в разработке, так как у них заранее есть необходимая документация, и они знают, какой продукт получится на выходе, и где возможно возникновение слабых мест;
4. Присутствие заказчика необходимо только на начальных и финальных этапах.
5. Наконец, программное обеспечение может быть более качественно спроектировано, основываясь на более полном понимании всех частей поставляемого продукта. Благодаря этому удается избежать так называемого «фрагментарного эффекта», когда части кода разработаны и добавлены в приложение без учета того, будут ли они хорошо в нём работать.

Минусы Waterfall 

Но ни одна методология не обойдется без минусов, и в водопадном подходе есть, по меньшей мере, два существенных:

1. Самый серьезный недостаток – это проблемы со сбором и подготовкой требований к финальному продукту. Оформление требований в документ, который понравится заказчику – часто самый трудный из этапов разработки. Клиенты часто путаются в деталях и особенностях, которые при Waterfall необходимо учитывать на стадии планирования. К тому же, даже с необходимой документацией, заказчик не всегда может визуализировать финальный продукт. Проекты и макеты способны помочь, но ни для кого не секрет, что большинство конечных пользователей могут испытывать некоторые сложности с сопоставлением всех элементов из документации с тем, что получится в итоге. 
2.  Еще один потенциальный минус водопадного подхода в его чистом виде (о других видах речь пойдет ниже) в том, что заказчик, с некоторой вероятностью, может остаться недовольным конечным продуктом. Так как все требования обговариваются заранее, и присутствие заказчика на всех этапах разработки необязательно, неправильное представление результата может очень сильно увеличить стоимость разработки, ведь водопадный подход не обладает гибкостью Agile, а значит, все изменения вносятся после окончания работы, и это гораздо дороже и дольше, чем корректировка курса работ на каждом из этапов.

Sashimi Waterfall

Некоторые из недостатков водопадной модели попытались исправить в одной из ее модификаций: Sashimi Waterfall (Сашими). В ней этапы, как и в оригинальной методике, идут друг за другом, но при этом перекрываются один другим во времени. Это позволяет начать разработку дизайна еще на этапе сбора информации, а значит, добавляет так сильно недостающую гибкость в процесс. Затраты при этом растут не сильно, а сама методология не превращается в Agile.

 Waterfall или Agile: какой подход выбрать?

Возможно, перед менеджерами подразделений будет стоять вопрос, какая из методологий более предпочтительна при разработке IT продуктов. Данная таблица поможет расставить все на места.