Опыт управления проектами по методологии Waterfall

Опыт управления проектами по методологии Waterfall

В небольших проектных командах обычно используют гибкие и понятные методологии с короткими циклами итераций. Однако, у каждой команды могут быть свои предпочтения. Где-то уже могли сложиться определённые механики, а где-то применения конкретной системы управления требует сам проект / объект разработки.

Обычно выбор стоит между методологиями Scrum (по модели спортивных схваток/забегов за новыми фичами), Kanban (с переносом табличек-задач по столбцам/состояниям) или Waterfall («Водопад», она же каскадная модель).

Ниже максимально подробно остановимся на практике управления проектами по методологии Waterfall.

Основные принципы работы проектов на методологии Waterfall (как работает эта модель)

Как можно понять из названия, основной порядок действий будет направлен по ниспадающей – сверху вниз, по мере важности и срочности задач, то есть каскадом (как в водопаде, отсюда и название Waterfall).

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

Принципы Waterfall-подхода и название методологии часто приписывают У.У. Ройсу и его научной статье 1970-го года. В реальности название Waterfall было впервые применено в работах Белла и Тайера в 1976 году. А Ройс в своей статье упоминал лишь 5 шагов, которые призваны снизить риски последовательной разработки проекта. Например, в качестве проблемы был обозначен тот факт, что тестирование происходит лишь на последних этапах. Это может приводить к серьёзным последствиям и даже полному провалу проекта.

Итак, что включает в себя Waterfall:

  1. Требования к разрабатываемой системе и к программному обеспечению должны быть изложены в Product requirements document (PRD).
  2. Этап анализа (на выходе должны быть модели, схемы и конкретные бизнес-правила).
  3. Разработка дизайна/интерфейса (на выходе должна получиться внятная архитектура программного продукта).
  4. Написание кода (разработка, проверка работоспособности, при необходимости интеграция).
  5. Тестирование (этап сравнения планируемого функционала с реальным/фактическим, отладка ошибок).
  6. Дальнейшие операции – установка, миграция (при наличии старого ПО), обслуживание и поддержка продукта.

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

Вот так эти принципы выглядят на схеме:

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

В чём плюсы Waterfall-модели

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

Поэтому водопадная модель максимально простая и понятная. Всё логично и протекает в рамках привычных фаз.

Второй важный плюс – внятная структура. Костяк проекта жёсткий, и не подразумевает отклонений по мере работы над задачами. Никаких неожиданностей, переключения на более важные фичи, доработок на ходу, смены парадигм и т.п.

Благодаря наглядному сетевому графику вы сможете детально распланировать загрузку сотрудников и отслеживать ход выполнения задач. Прозрачный контроль – это всегда залог успеха.

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

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

Минусы Waterfall методологии

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

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

В Waterfall максимально высокие риски. Если что-то не было учтено на этапе проектирования, то переделать «на ходу» уже ничего не получится. Нужно будет останавливать весь процесс разработки и начинать всё сначала. А это потери времени, ресурсов и денег.

Сложность проектирования. Очень многое зависит от опыта и навыков разработчиков. Без наличия накопленных знаний вы не сможете правильно спланировать сложный/объёмный проект. Велика вероятность того, что вы выбьетесь за пределы бюджета или времени, необходимого для разработки основного функционала/доработки.

В каких проектах стоит применять методологию Waterfall

Многие источники заявляют, что модель подходит исключительно для небольших и малоответственных проектов. Но в реальности это не так.

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

Такой исход можно получить в двух случаях:

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

А в остальном проект может быть какого угодно размера и степени ответственности.

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

Как снизить риски

В реальности можно комбинировать разные подходы. Никто не запрещает использовать у себя в команде связку из Waterfall+Kanban+Scrum. Главное, чтобы это работало и давало реальный результат.

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

Второй момент – разбитие конечного продукта на разные модули. Тогда с каждым из них можно будет работать по модели водопада. Сроки итераций от постановки требований до сдачи проекта значительно сократятся, как и объём рисков.