Что такое модель водопада? What is a Waterfall?

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

Модель водопада подчеркивает, что проекты должны следовать логической последовательности шагов на протяжении всего жизненного цикла разработки программного обеспечения (SDLC).

Как следует из названия, каждая фаза проекта каскадом переходит в следующую, постепенно спускаясь вниз подобно водопаду.

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

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

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

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

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

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

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

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

Лучший способ понять, является ли методология водопада наилучшей для вашего проекта, — это проанализировать преимущества ее использования, а также недостатки. Давайте исследуем:

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

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

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

Заинтересованы в обсуждении методологии водопада с другими менеджерами по продуктам? Познакомьтесь и пообщайтесь с лидерами продуктов по всему миру в нашем сообществе ProductCamp!