Waterfall методология разработки

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

Что такое методология Waterfall: как работает водопадная модель, где используется, отличия от Agile

Как будто водопадный подход придумал не разработчик программного обеспечения, а государство и крупные корпорации. Водопадную модель чаще всего сравнивают с другой методологией https://deveducation.com/ — Agile. Если не вдаваться в подробности, во главу угла в Agile ставится качество продукта и удовлетворенность заказчика, а также скорость реализации проекта. Первые упоминания о методологии относятся к 1970 году, а автором подхода считают американского программиста Уинстона Ройса.

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

А после тестирования почти всегда идет устранение выявленных недочетов. И так далее, но самое важное — следующий этап начинается только тогда, frontend разработчик когда успешно закончен предыдущий. Как помните, аджайл — это итеративный подход. Работа ведется короткими фиксированными итерациям. Скажем, команда создает какой-то функционал в течение 2 недель, а потом смотрит на него и корректирует общий план.

Чем «водопадный» подход отличается от аджайла

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

Модель водопада: как работает методология Waterfall

Но подготовительный этап в самом разгаре.

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

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

Каскадная модель подходит при разработки сложных и больших проектов и систем со строго определённой функциональностью. Использовать при разработке больших гос.заказов или научных разработках. Использовать данную методология для разработки бизнес-приложений крайне не желательно.

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

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

Каскадная модель основана на последовательном выполнении этапов разработки. При этом не возврат на предыдущие этапы, не перескакивание с этапа на этап не допускаются. Заказчик не всегда готов сказать, чего он хочет — не всегда он это знает. На случай большой неопределенности и придумали гибкие методологии.

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

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