Юлий Минькин, руководитель проектного офиса
В настоящее время гибкие и адаптивные методологии управления проектами стали очень популярными и часто используются в IT-отрасли. Но это не означает, что старый и проверенный подход "водопад" (Waterfall) утратил свою ценность. Напротив, он по-прежнему может быть эффективным в некоторых проектах.
Следует отметить, что методология Waterfall может быть неэффективной в проектах с высокой степенью неопределенности и необходимостью быстрой адаптации к изменениям. В таких случаях адаптивные методологии могут быть более подходящим выбором.
Однако в некоторых проектах применение методологии Waterfall оправдано. Например, в проектах с жесткими требованиями к безопасности и контролю изменений, а также в проектах с высокой степенью предсказуемости. Кроме того, в компаниях, где еще нет опыта работы с адаптивными методологиями, внедрение Waterfall может быть более простым и понятным способом управления проектами.
Эта статья содержит краткий обзор технологии управления проектами Waterfall и приводит аргументы, обосновывающие применение данной методологии в проектах.
Эволюция методологии Waterfall
Waterfall была разработана в 1950-х годах в рамках проекта разработки программного обеспечения в США. Эта методология была первоначально применена для управления проектами в области строительства, а затем распространилась на другие области, включая разработку программного обеспечения.
Термин "Waterfall" для обозначения каскадной методологии управления проектами был введен в 1970-х годах Уинстоном Ройсом (Winston W. Royce), который описал эту методологию в своей статье "Managing the Development of Large Software Systems" (Управление разработкой больших программных систем), опубликованной в журнале IEEE Transactions on Engineering Management в 1970 году.
В этой статье Ройс представил модель разработки программного обеспечения, которая состояла из последовательных этапов, где каждый этап зависел от предыдущего и являлся основой для следующего этапа. При этом, если какой-то этап не завершен успешно, то следующий этап не может быть начат. Этот процесс был назван "Waterfall model", так как он напоминал последовательное движение воды вниз по каскаду.
Хотя сам Ройс позже критиковал свою модель и отмечал, что ее следование приводило к проблемам в проектах разработки программного обеспечения, термин "Waterfall" остался в употреблении и стал широко используемым для обозначения каскадной методологии управления проектами в различных областях.
Waterfall model основывается на последовательном выполнении определенных этапов проекта, которые должны быть завершены до перехода на следующий этап:
- Определение требований (Requirements). На этом этапе определяются и документируются все требования к проекту. Включает в себя выявление потребностей заказчика, сбор и анализ требований, а также их документирование.
- Проектирование (Design). На этом этапе создается детальное техническое задание и проектируются архитектура, функциональность, интерфейс, база данных и другие компоненты проекта.
- Разработка (Development). На этом этапе осуществляется разработка кода, создание базы данных, написание документации и тестирование компонентов системы.
- Тестирование (Testing). На этом этапе выполняются тесты на соответствие требованиям и функциональности системы. Включает в себя модульное тестирование, интеграционное тестирование и приемочное тестирование.
- Внедрение (Deployment). На этом этапе происходит установка системы на производственной среде и настройка ее параметров в соответствии с требованиями заказчика.
- Эксплуатация (Operation). На этом этапе система переходит в режим эксплуатации. Включает в себя поддержку, обслуживание и исправление ошибок в работе системы.
- Обслуживание (Maintenance). На этом этапе происходит поддержка и сопровождение системы на протяжении ее жизненного цикла. Включает в себя исправление ошибок, добавление новых функций и техническую поддержку.
Каждый этап зависит от предыдущего и должен быть завершен полностью, прежде чем начать следующий. Это обеспечивает последовательное выполнение работ и контроль над процессом разработки проекта.
В 1970-х годах каскадная методология получила широкое распространение в проектах разработки программного обеспечения. На этот период пришлось появление первых стандартов по разработке программного обеспечения, таких как MIL-STD-2167A (Department of Defense) и IEEE 12207 (Institute of Electrical and Electronics Engineers), которые предписывали использование каскадной методологии.
В 1980-х годах методология Waterfall стала стандартной практикой во многих организациях и была использована для управления проектами в различных областях, включая строительство, производство, аэрокосмическую и автомобильную промышленность.
Однако в последующие десятилетия, методология Waterfall стала критиковаться за свою жесткость и недостаточную адаптивность к изменяющимся условиям проекта. В ответ на это, в 1990-х годах начали разрабатываться более гибкие методологии, такие как Agile, которые были более адаптивными к изменениям в требованиях и условиях проекта.
Эволюция представления методологии Waterfall в PMBOK
В этом ключе, интересно проследить эволюцию представления методологии Waterfall в PMBOK (наиболее авторитетное издание, посвященное аспектам управления проектами), в сочетании с адаптивными технологиями.
Waterfall model была описана в первой редакции PMBOK (Project Management Body of Knowledge), опубликованной в 1987 году. В последующих редакциях PMBOK (1996, 2000, 2004, 2008, 2013, 2017 и 2021) эта модель также была включена и описывается в главе о жизненном цикле проекта.
Адаптивные методологии управления проектами (Agile) появились в PMBOK только в 3-й редакции, опубликованной в 2004 году, где был добавлен новый раздел "Adaptive (Agile) Life Cycle". В 4-й редакции PMBOK (2008) был добавлен еще один раздел "Agile Practice Guide", в котором были описаны подходы Agile (Scrum, Lean и Extreme Programming).
В 5-й редакции PMBOK (2013) были дополнительно описаны Agile методологии и инкрементальные модели жизненного цикла проекта, такие как Iterative и Adaptive. В 6-й редакции PMBOK (2017) был добавлен еще один раздел "The Agile Practice Guide", в котором были дополнительно описаны подходы Agile и инструменты, используемые в Agile проектах. В PMBOK 7-й редакции, опубликованной в 2021 году, почти в каждой главе, начиная со 2-й, описываются применение адаптивных и гибридных методологий в процессах управления проектами.
Таким образом, модель управления проектами Waterfall была описана во всех редакциях PMBOK, а Agile методологии были введены в обращение только с 3-й редакции и с тех пор описываются в каждой последующей редакции PMBOK.
Почему методология Waterfall все еще актуальна
Несмотря на то, что в настоящее время в IT-отрасли уже стали популярны адаптивные методологии управления проектами, методология Waterfall не потеряла свою актуальность.
Несколько причин, почему ее следует использовать:
- Проекты с жесткими требованиями к контролю изменений и безопасности. В некоторых отраслях, таких как строительство технически сложных сооружений и оборудования, электроники и программного обеспечения имеющих специальное назначение или связано с вопросами безопасности. В таких проектах Waterfall может быть более подходящей методологией, чем адаптивные методологии, которые ориентированы на быструю адаптацию к изменениям.
- Проекты с высокой степенью предсказуемости. В проектах, где все требования известны заранее и немаловажно точное планирование и контроль бюджета, Waterfall может быть более подходящей методологией, чем адаптивные методологии, которые ориентированы на гибкость и возможность быстрой адаптации к изменениям.
- Отсутствие опыта внедрения адаптивных методологий. В компаниях, где еще нет опыта работы с адаптивными методологиями, внедрение Waterfall может быть более легким и простым способом управления проектами.
- Требования заказчика. Выбор методологии управления проектами должен зависеть от требований заказчика. В некоторых случаях заказчик может предпочесть Waterfall, поскольку он может обеспечить более строгий контроль над процессами, бюджетом и результатами проекта.
Таким образом, методология Waterfall не потеряла свою актуальность и может продолжать использоваться в тех проектах, где это наиболее подходящий выбор.
Waterfall в ГОСТ 34
Необходимо отметить, что при разработке российских государственных стандартов, посвященных созданию автоматизированных систем (ГОСТ 34 серии), обновление которых произошло в 2022 году, методология Waterfall также остается приоритетной.
Так в новом стандарте ГОСТ Р 59793-2021 "Автоматизированные системы. Стадии создания", который был введен в действие взамен утратившим силу ГОСТ 34.601-90, приводятся стадии проектных работ, соответствующие методологии Waterfall:
- Формирование требований к АС
- Разработка концепции АС
- Техническое задание
- Эскизный проект
- Технический проект
- Рабочая документация
- Ввод в действие
- Сопровождение АС
В последующих публикациях мы рассмотрим, как можно использовать итеративный и инкрементный подход к созданию автоматизированных систем, при этом не нарушая стандартов ГОСТ 34 серии.
Вместо выводов
В заключение хотелось бы отметить, что Waterfall model является старой (ей уже более 70 лет), но не устаревшей технологией. И сегодня Waterfall может успешно использоваться в некоторых проектах, где требуется строгий контроль и высокая степень стандартизации процессов, но в целом, Agile и другие адаптивные методологии стали более востребованными и популярными в управлении проектами.
Если статья была полезна, подписывайтесь на канал, ставьте палец вверх и делитесь ею с коллегами.
Еще больше интересных тем, связанных с управлением, методами и инструментами работы, вопросами коммуникаций в проектах, — на нашем Telegram-канале
