Методология WATERFALL как способ руководства проектами

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

Наиболее популярными считаются три основных методологии: SCRUM, KANBAN, WATERFALL.

Рассмотрим более подробно последний вариант.

Суть программы во многом определяет её название — WATERFALL (англ. «водопад»). Подобно данному явлению природы, принцип работы метода, или, точнее, порядок действий, строится по ниспадающей, каскадом, сверху вниз, по убывающей актуальности задач.

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

Автором методологии, создателем основных её принципов и названия часто считают У. Ройса, на основании опубликованной в научных журналах статьи (1970 г.). В действительности же обозначение WATERFALL впервые использовали Тайер и Белл (1976 г.). Ройс же в вышеназванной публикации указал на пять определяющих шагов, способствующих снижению потенциальных рисков в последовательности формирования проекта.

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

Основные шаги WATERFALL:

• Требования, предъявляемые к системе, которая находится в разработке, и к используемому типу программного обеспечения излагаются в соответствующем документе к продукту (PRD).
• В ходе аналитического этапа, к его окончанию, должны быть составлены конкретные модели действий, актуальные случаю бизнес-правила, функциональные схемы процессов.
• Далее следует работа веб-дизайнеров. Формируются подходящая визуальная структура, интерфейс. Конечным результатом данного этапа должен быть информативный каркас программного продукта.
• Создание кода для результатов предыдущего пункта. В данный этап входят процесс формирования, проверка того, насколько данный код работоспособен. Если необходимо, то производится интегрирование.
• Осуществление тестового запуска. В ходе испытания сравнивается имеющийся результат с запланированным, при необходимости проводится коррекция.

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

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

Вот так выглядит визуальная модель принципов WATERFALL (см. схему)

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

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

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

Ещё одним преимуществом системы WATERFALL можно считать стабильную, фиксированную структуру, не подвергающуюся изменениям во время выполнения задач: никакого перепрыгивания по темам, доработок, переходов к более важным фичам.

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

Жёсткость методологии WATERFALL, как и любых программ с подобным строгим подходом, тесно взаимосвязана с формированием детализированной документации. Наличие необходимых регламентов способствует понижению порога входа новых участников и возможности их оперативной замены в случае необходимости (например, если сотрудник заболел или уволился).

WATERFALL не позволит коллективу нарушить дедлайн, и с максимальной степенью вероятности проект будет завершён и сдан в заявленные сроки.

Жесткость подхода WATERFALL наряду с преимуществами является и её самым уязвимым местом. Объясняется всё просто: даже при эффективной командной работе не всегда возможно в точности следовать утверждённым правилам. Реальные обстоятельства могут быть изменчивыми: заказчик может внезапно изменить задачу либо требования к ней, или же в ходе разработки появится необходимость в новых опциях и подходах, и всё это придётся индивидуально согласовывать.

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

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

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

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

• Клиент точно определился с задачами, сроками исполнения и финансовыми затратами на их выполнение.
• Исполнитель отчетливо понимает и компетентен в том, каким способом будут данные задачи реализованы.

При этом масштабность проекта особой роли не играет.

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

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

#управлениепроектами #управлениеперсоналом #управлениепродуктом #управлениебизнесом #програмноеобеспечение #методология #методологияуправления #бизнес

Источник: официальный канал Projecto на Дзен