Является ли водопад лучшим подходом для вашего проекта?
Мы прекрасно знаем, что водопад в большинстве случаев рассматривается как устаревший и немодный подход к разработке программного обеспечения - нечто, что следует оставить в 90-х годах прошлого века. Мы также прекрасно знаем, что современные проекты огромны, сложны и гибкие настолько, что мы и мечтать не могли о том, чтобы использовать водопад.
Мы также являемся большим сторонником agile-методологии. Нам нравится ее дзен-подобный подход к разработке программного обеспечения. Мы на собственном опыте убедились, чего может добиться хороший Scrum-мастер. Поэтому мы не собираемся говорить вам, что Agile - это плохо, или сравнивать эти два подхода.
Во многом Agile возник как ответ на культуру водопада, причем не на методологию как таковую, а на упрямое представление о том, что она - это все и вся в разработке программного обеспечения. Это был ответ руководителям проектов, которые принимали принципы Waterfall как евангелие, в то время как на самом деле они были руководством к действию для решения предполагаемой проблемы.
Waterfall был успешным решением, которое в то время придавало структуру хаотичному процессу разработки крупномасштабного программного обеспечения. Но было ли оно идеальным? Ничто не идеально, но оно было достаточно хорошим, чтобы надолго стать подходом по умолчанию. Если уж на то пошло, то "водопад" и по сей день продолжает развиваться.
Давайте посмотрим на факты. По данным исследования Project Management Institute, проведенного в 2022 году, более 37% завершенных проектов использовали водопад в качестве метода выбора, что делает его наиболее распространенной методологией управления проектами во всем мире. Если учесть те 20%, которые сообщили о гибридных методах, то получается, что более половины опрошенных проектов в той или иной форме используют водопад, что вряд ли можно назвать цифрами умирающей технологии.
Так стоит ли вам следовать за массами и принимать водопад как методологию? Если бы ответ был простым "да" или "нет", мы бы не вели этот разговор.
Определение водопадных рамок
В самом общем виде водопад - это последовательный и дискретный подход к разработке программного обеспечения. Предполагается, что команды должны следовать строгому набору фаз, которые начинаются со сбора требований и заканчиваются поставкой и сопровождением проекта.
Мы называем его последовательным, потому что фазы образуют последовательность шагов, которые должны быть пройдены в определенном порядке, как вода, падающая с водопада. Назад дороги нет, обходных путей и быстрых выходов тоже.
Каждый этап является дискретным, поскольку они независимы друг от друга (или, по крайней мере, настолько независимы, насколько это возможно), и этот этап не может начаться, если не завершены предыдущие этапы. Вы не можете начать тестирование своей работы, пока не закончены проектирование системы и ее реализация.
Несмотря на некоторые различия, большинство водопадных систем имеют одни и те же основные этапы:
- Сбор требований: Команда собирает информацию о характере проекта, например, об ожидаемых возможностях, типе данных, с которыми будет работать система, среде, в которой она будет развернута, и т.д.
- Проектирование системы: Команда формулирует план действий и принимает стратегические решения, например, о том, какие технологии будут использоваться в проекте.
- Реализация: Команда приступает к работе над проектом, основываясь на выбранном дизайне.
- Тестирование: Команда запускает прототип проекта и проверяет его на наличие багов и ошибок.
- Поставка/развертывание: Проект запускается и передается владельцу.
- Сопровождение: Команда обеспечивает поддержку и исправляет ошибки, о которых сообщают пользователи.
Следует помнить, что, несмотря на то, что эта схема может показаться довольно жесткой, в ней есть определенная свобода действий. Например, команда может вернуться к проектированию системы, чтобы переосмыслить свой подход, или вернуться к реализации и работать над проектом в зависимости от характера ошибок, обнаруженных при тестировании. Конечно, идея состоит в том, чтобы по возможности избежать такого возврата.
Водопадные фреймворки и вы
Чтобы понять, подходит ли вам водопадная методология, сначала нужно понять ее сильные стороны и то, как она решает определенные задачи лучше, чем другие методы.
Водопадные методологии используют очень четкую структуру, которая может привести в бешенство разработчиков, но для клиентов или коллег из других областей является гораздо более понятной и легко усваиваемой. Например, легче обосновать бюджет, когда у вас есть четкая цель и график.
Поэтому если ваш проект предполагает внешние инвестиции, должен быть одобрен другими отделами или окажет неожиданное влияние на другие области, водопадный подход будет более привлекательным для людей, не связанных с проектом. Задачи выглядят более организованными и их легче объяснить.
Поскольку требования определяются на ранних этапах и остаются неизменными на протяжении всего процесса, водопадные схемы с самого начала ставят очень четкие цели и не позволяют командам слишком сильно отклоняться от них.
Небольшие проекты и небольшие команды выигрывают от целенаправленного подхода. Проекты завершаются быстрее, а разработчики не склонны тратить ресурсы и время на второстепенные функции, которые могут не иметь принципиального значения для продукта. Если ваша команда невелика, а проекты предсказуемы, то водопад может стать идеальной основой.
Водопад отличается высокой методичностью, поэтому неудивительно, что в рамках этой системы на каждом этапе четко прописаны процедуры коммуникации.
Поскольку каждый процесс тщательно документируется, становится проще обмениваться информацией между различными командами, работающими на разных этапах разработки. Кроме того, новые члены команды могут ознакомиться с документацией и быстрее освоить проект.
Если вы считаете, что состав вашей команды может в какой-то момент измениться или в нее могут добавиться новые члены, то водопад обеспечивает хорошую коммуникационную структуру, позволяющую держать всех в курсе событий.
Хотя поведение группы трудно предсказать, новым командам часто приходится сталкиваться с трудностями при знакомстве друг с другом и понимании рабочего процесса. Жесткие рамки, такие как Waterfall, создают рабочий распорядок, который легче установить и согласовать, что облегчает работу в команде, по крайней мере, на ранних стадиях проекта.
Наконец, Agile требует определенных управленческих нагрузок, которые не каждый руководитель проекта может выдержать. Понятие управления проектом в Agile существенно отличается от привычного нам.
Поэтому водопад, при всех его причудах, может оказаться более простой методологией для новичка - если только у вас нет менеджера, который обучен agile, или если в вашей команде есть менеджер проекта, не являющийся разработчиком программного обеспечения.
В конечном счете, нет двух одинаковых проектов. Поэтому думать, что какая-то одна методология может стать решением любой проблемы, с которой вы столкнулись, в лучшем случае обнадеживающе, а в худшем - наивно.
Вдумчивый подход к разработке программного обеспечения, позволяющий диагностировать природу проблемы, является ключом к выбору правильной методологии для проекта. Дело не в том, что популярно, а в том, что работает.