НАШИ ВЫПУСКИ

   10 января 2022 г.

 

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

Это – традиционная, самая популярная и логичная методология управления проектами. В чистом виде она может сработать совсем в простых проектах. Допустим, вам потребовалось посадить дерево. «По водопаду» выполнение проекта выглядит так:

• купить саженец;
• выкопать яму;
• поставить в неё саженец;
• присыпать землёй;
• полить дерево.

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

Итак, каскадная модель характеризуется последовательностью. Согласно Waterfall работа над проектом должна идти в несколько этапов, следующих друг за другом, от первого и до последнего. Их количество от проекта к проекту, от схемы к схеме может меняться, но суть одна: продумали и согласовали ТЗ, сделали всё в точности по нему, протестировали, отдали клиенту – все довольны.

Наглядно это выглядит следующим образом:

• Требования
  Самый первый этап, во время которого определяют и анализируют требования проекта: системные требования, требования к ПО, пожелания заказчика и т.д. и т.п. На основе всей этой информации создают входную документацию, где описывают, что должно получиться в итоге (не важно, что это будет – софт или авианосец), но не то, как именно это всё нужно будет делать. Коротко говоря, на этом этапе пишут первую, обобщённую, версию ТЗ.
• Проектирование
  Когда первая версия ТЗ готова и есть общее понимание, что нужно сделать, команда приступает к проектированию – детализирует ТЗ, согласует с заказчиком логику работы системы, описывает, что и как будет работать. На выходе этого этапа всё ещё не проясняется вопрос реализации, но уже становится примерно понятно, сколько нужно людей и часов на работу.
• Реализация
  Затем команда окончательно проясняет, как именно будет происходить разработка проекта, с помощью каких инструментов (языков программирования, оборудования, сервисов и т.д.). Каркас, который проработали на предыдущих этапах, становится более целостным, потихоньку формируется облик продукта. На этот этап приходится большая часть работы над проектом.
• Проверка
  На этом этапе проводят полноценное тестирование продукта, чтобы найти и исправить критические (и не очень) проблемы.
• Развёртывание
  И, наконец, когда всё протестировано и отлажено, переходят к последнему этапу, в рамках которого сдают проект заказчику, устанавливают, внедряют – в общем, вводят продукт в эксплуатацию. Кроме того, сюда может входить и последующее сопровождение, и поддержка, в том числе техническая.

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

	ТРЕБОВАНИЯ	Написать техническое задание
	ПРОЕКТИРОВАНИЕ	Нарисовать дизайн
	РЕАЛИЗАЦИЯ	Сверстать дизайн
		Закодить
	ПРОВЕРКА	Протестировать
	РАЗВЁРТЫВАНИЕ	Запустить проект

В рамках других проектов, например, творческих, этапы будут другими, но подход останется таким же.

Помимо этого, следует отметить, что методология Waterfall в значительной степени ориентирована на требования.

Чтобы двигаться «по водопаду», необходимо иметь абсолютно чёткое представление о том, что нужно проекту, иными словами, иметь чёткое техническое задание и понимание шагов, следующих друг за другом. КОГДА ПРОЕКТ УЖЕ БУДЕТ В РАЗРАБОТКЕ, ВЫ НЕ СМОЖЕТЕ СКОРРЕКТИРОВАТЬ ЕГО КУРС.

Постулаты каскадной методологии

У Waterfall есть свои принципы, на которых всё строится:

• документы и инструкции очень важны;
• следующий этап должен начинаться только после окончания предыдущего;
• перескакивать через этапы нельзя;
• возвращаться на предыдущие этапы, чтобы что-то изменить, нельзя;
• если изменились требования – переделывают ТЗ;
• ошибки выявляют и исправляют только во время тестирования;
• клиент не участвует в работе над проектом после создания ТЗ.

Преимущества Waterfall модели

• Простота использования
  Эту модель просто понять и использовать. Деление на этапы довольно интуитивно, его просто освоить вне зависимости от опыта.
• Структура
  Жёсткость методологии Waterfall – одновременно и недостаток, и явное преимущество. Чёткое разделение на этапы позволяет организовать и распределить работу. Поскольку назад вернуться нельзя, необходимо идеально справляться с выполнением каждого этапа, что зачастую позволяет добиться лучших результатов.
• Прозрачность
  Заранее понятно, на каком этапе что будет происходить, поэтому становится проще прогнозировать бюджеты и набирать команду.
• Подробное документирование
  Поскольку много внимания уделяется сбору и пониманию требований, модель Waterfall в значительной степени опирается на документацию. Благодаря этому новым ресурсам проще влиться в проект и начать работу над ним.
• Устойчивость к обновлению кадров
  Благодаря очень подробному документированию каждого этапа, участники могут приходить и уходить, но на сроки работы это никак не повлияет.
• Способность дисциплинировать
  Благодаря плану и чёткой последовательности этапов, а также строгому менеджменту, модель дисциплинирует.

Недостатки Waterfall модели

• Очень много документов
  Из-за этого работа над проектом часто превращается в сущую бюрократию – пока всё со всеми не согласуешь, в документах всё не пропишешь, с места ничто не сдвинется.
• Сложность первого этапа – все требования должны быть известны сразу
  Весь подход Waterfall зависит от того, насколько правильно вы поймёте и проанализируете требования. Сделать это очень сложно, потому что заказчик часто и сам не знает, чего он хочет. Если вам не удастся сделать это или если требования изменятся, придётся начинать сначала.
• Изоляция пользователя и заказчика от процесса разработки
  Как следствие, первый не может постепенно привыкать к продукту, а второй – вносить корректировки, если что-то идёт не так.
• Тестирование только в самом конце
  Проектом могут заниматься некомпетентные специалисты (а это может стать явным, когда уже будет поздно). Масса проблем, выявленных только в самом конце (на этапе тестирования), влечёт плачевные последствия.
• Повышенный риск
  Жёсткость методологии означает, что, если вы обнаружите ошибку или вам понадобится внести изменения, придётся начинать проект сначала. А это значит, что вы и вовсе можете не завершить проект вовремя.

Учитывая недостатки этой методология управления, можно отметить, что Waterfall НЕ ПОДХОДИТ СЛОЖНЫМ ДОЛГОСРОЧНЫМ ПРОЕКТАМ.

Для каких проектов лучше всего подойдёт Waterfall

Методология управления Waterfall зачастую используется в сфере разработки программного обеспечения. Она лучше всего подходит для:

• коротких несложных проектов;
• проектов с чётко установленными требованиями;
• проектов, в которых меняются ресурсы, зависимые от подробной документации.

Методология Waterfall будет уместна, если:

• заказчик хорошо понимает, что хочет, у него есть проработанная концепция, которая не изменится;
• заказчик не планирует участвовать в проекте после принятия ТЗ, а полностью отдаёт его на аутсорс'
• заказчик хочет заранее знать точные сроки и результаты каждого этапа;
• заранее понятно, что, как и с помощью каких инструментов нужно будет делать;
• это сложный продукт, который требует очень много затрат, и у которого есть очень чёткая последовательность разработки (сомнительно, что подводные лодки когда-нибудь будут делать по Agile);
• команда уже делала аналогичный проект.

Человеческая любовь к последовательности и порядку слишком сильна. Особенно у разработчиков. Поэтому Waterfall ЕЩЁ ДОЛГОЕ ВРЕМЯ БУДЕТ ДОМИНИРОВАТЬ В СФЕРЕ УПРАВЛЕНИЯ ПРОЕКТАМИ.