Методология Водопад (Waterfall) в IT

Мы уже ознакомились с профессией «менеджер проектов», и выяснили какими навыками он должен обладать. Пришло время рассмотреть как же он управляет проектами, какие методы при этом использует.
Ниже приведу краткий обзор методологии Водопад:

Водопад (Waterfall) - это традиционная методология, в которой задачи и фазы выполняются линейным, последовательным образом, где каждый этап проекта должен быть завершен до начала следующего. Руководитель проекта отвечает за определение приоритетов и распределение задач между членами команды. B Waterfall критерии, используемые для измерения качества, четко определены в начале проекта.

Методология разработки Waterfall строится на 8 главных принципах:

Важно, чтобы все этапы работы были задокументированы.
Следующий этап не начинается до того, как будет завершен предыдущий.
Пропуск этапов исключен.
Если в процессе разработки требования к продукту поменялись, необходимо внести изменения в ТЗ.
Нельзя откатиться на прошлый этап, чтобы что-то изменить.
Разработка происходит в рамках одного общего процесса создания продукта, итераций нет.
Выявление и исправление ошибок происходит только после окончания разработки на этапе тестирования.
Клиент не может участвовать в создании продукта, кроме этапа разработки Т3.

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

Анализ и определение требований проекта.
Команда собирает требования к будущему продукту, после чего необходимо составить подробное техническое задание. На данном шаге также планируется график работ и происходит оценка возможных рисков.
Проектирование.
На этом этапе готовят документы, в которых подробно описывается для программистов способ и план реализации сформулированных ранее требований. На этой стадии команда создает прототип и дизайн-макеты, а когда они будут готовы, подключаются разработчики.
Реализация.
После завершения проектирования программистами выполняется воплощение полноценного проекта. На этом этапе разработчики пишут код продукта согласно утвержденному плану, макетам, требованиям, работая четко по ТЗ.
Тестирование продукта.
Когда код готов, начинается тестирование и отладка ПО. На этой стадии устраняют все недочеты, которые появлялись на предыдущих стадиях разработки.
Эксплуатация и поддержка.
На заключительном этапе проект передают заказчику, продукт запускается в коммерческую эксплуатацию и обеспечивается его поддержка, включающая внесение новой функциональности и устранение ошибок.

Безусловно, в этой методологии есть свои плюсы и минусы.

Минусы:

Сегодня водопадная модель разработки ПО, которая впервые была описана в 1970 году - более чем полвека назад, из-за недостаточной гибкости и громоздкости используется нечасто.
Эта модель не позволяет предусмотреть все проблемы в проекте заранее. Поскольку этапы следуют в жестком порядке и совместить разработку и тестирование для поиска уязвимостей нельзя, недостатки всплывут лишь в конце проекта при тестировании, и чтобы исправить их, придется затратить лишние средства и рабочие часы.
Минусом является и большой объем документации, которую приходится постоянно поддерживать в актуальном состоянии. Невозможно начать работу над проектом, пока детали не согласованы со всеми участниками процесса и не формализованы в виде документа.
Недостатком для заказчика можно назвать то, что он сможет увидеть результат только в конце проекта. До разработки и процесса тестирования клиент не допускается и не сможет прокомментировать макеты или прототипы. В итоге массовый потребитель на выходе рискует получить продукт, не отвечающий его требованиям.
Проблема также возникает и с тем, что все требования следует определять заранее, тогда как клиент не всегда готов сказать, чего именно он хочет. Поэтому в случае большой неопределенности лучше использовать другие, более гибкие методологии.

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

Плюсы:

Устойчивость к замене исполнителей. Разработчики могут приходить и уходить на протяжении всего жизненного цикла проекта, но благодаря подробному документированию изменение кадрового состава практически не влияет на процесс разработки, модель управления и сроки выполнения.
Инструкции и правила по всему процессу разработки. Работа начинается с детального анализа требований заказчика и всех условий реализации проекта. Планы, стадии работы и процессы утверждают заранее, все данные фиксируются в документах, что в дальнейшем исключает возникновение вопросов. Исполнителям просто необходимо им следовать.
Строгий менеджмент. Модель Waterfall заставляет разработчиков, участвующих в проекте, быть дисциплинированными, соблюдать четкую последовательность работ и жесткие требования регламентов, оставаясь в рамках намеченного плана.
Гибкость на первых этапах работы. Изменения в первых фазах водопадного проекта могут быть произведены немедленно и с минимумом усилий, пока они не подкреплены кодом. За счет этого у заказчика и исполнителя есть значительный запас времени для кардинального изменения концепции работы программного обеспечения.
Определенность в сроках и размере бюджета. Стоимость будущего ПО, а также сроки сдачи проекта бывают рассчитаны и утверждены в самом начале и не изменяются в процессе. Это делает работу над продуктом прозрачной и помогает руководству, заранее зная, что и кто на каком этапе будет делать, составлять план расходов, собирать команду и прогнозировать сроки исполнения.

В следующей статье я расскажу подробно про методологию Agile.

Принципы водопадной модели разработки

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