Что такое каскадная разработка

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

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

Что такое каскадная разработка

Эту модель придумали в 1970 году, когда программирование стало развиваться и надо было как-то стандартизировать подход к разработке. Смысл в том, чтобы и программисты, и клиенты одинаково понимали ход процесса и примерно представляли себе, на каком этапе находится создание программы. 

Главная идея каскадной разработки: 

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

Звучит очень здраво и помогает программистам не распылять свои силы, а сосредоточиться на текущих задачах. А ещё не нужно возвращаться к предыдущему этапу и что-то доделывать, потому что всё делается сразу и навсегда. 

В классической каскадной разработке 7 этапов:

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

Почему все её критикуют

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

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

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

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

В чём сила модели

Сила каскадной модели — в ответственности и порядке. 

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

А порядок в том, что все чётко понимают, где начинается и заканчивается их зона ответственности. 

Это всё в идеальном мире. В реальности менеджеры могут и развернуть каскад вспять, если клиенту приспичило поменять техзадание; и поставить дедлайн на вчера; и ещё как угодно надорвать ткань реальности. 

Что дальше

У каскадной модели есть полная противоположность — RAD-разработка.