Опыт управления проектами по методологии 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.

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