Waterfall методология

Что такое методология Waterfall

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

Можно встретить и другое название методологии водопада - каскадная, потому что именно такую форму имеет графическое изображение данной модели. Это отражает ее главную особенность: она направлена на последовательное и четкое выполнение задач согласно изначальному плану. То есть, подобно водопаду, любой проект постепенно проходит все шаги разработки, начиная с анализа и проектирования и заканчивая тестированием и непосредственно использованием. Эксперименты, неожиданные изменения или какие-либо еще отклонения от намеченного плана не приветствуются, так же как и нестандартное распределение задач.

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

Как работает Waterfall на практике

Рабочие группы или команды, работающие по методологии Waterfall, соблюдают ее основные принципы:

• Документация так же важна, как и будущий продукт. То есть все должно быть правильно оформлено и зафиксировано со всеми бюрократическими тонкостями. Это не тот случай, когда можно пренебрегать документами и инструкциями.

• Не следует переходить на новый этап разработки, не закончив предыдущий. Ни в коем случае нельзя пропускать этапы и отходить от намеченного плана действий.

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

• Выявление и исправление ошибок происходит уже на этапе тестирования, а не во время разработки продукта.

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

• Нет итераций, то есть процесс разработки продукта единый, он не делится на рабочие циклы, а представляет собой последовательный переход от одного этапа к другим в соответствии с поставленным дедлайном.

Этапы разработки продукта по методологии Waterfall

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

Этап 1. Составление требований

Методология Waterfall основана на следующем убеждении: все требования к проекту должны быть определены, понятны и собраны в едином документе строго заранее. Поэтому прежде всего рабочая команда вместе с заказчиком составляет требования к будущему продукту. Еще до начала разработки необходим полный перечень всех элементов и функций, которые должен содержать продукт.

Этап 2. Анализ составленных требований и планирование следующих этапов

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

Этап 3. Проектирование

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

Этап 4. Разработка

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

Этап 5. Тестирование

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

Этап 6. Внедрение

После того как в результате тестирования были выявлены и исправлены ошибки, проект передают заказчику. Однако в дальнейшем необходимо следить за развитием продукта.

Этап 7. Сопровождение

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

Разница между методологиями Agile и Waterfall

Обе эти методологии популярны и эффективны в управлении проектами, однако они кардинально отличаются друг от друга. До того как появилась Agile, было принято использовать только методологию Waterfall, поэтому она считается классической. Позже выяснилось, что гибкость и мобильность процесса разработки, которые предполагает Agile, не менее важны, чем тщательная подготовка, как в Waterfall.

Таким образом, Agile - это совокупность гибких подходов и методик, ее базовыми принципами являются следующие утверждения:

• Люди важнее инструментов.

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

• Главная цель - качественный продукт.

Технология Agile сконцентрирована, прежде всего, на конечном результате, то есть создании нового продукта, который как можно скорее будет готов к использованию и удовлетворению запросов заказчика и потребностей аудитории. Ради этого можно пренебречь многочисленной бумажной волокитой. Поэтому в процессе работы оформляется только самая необходимая документация, без бюрократических формальностей.

• Больше точек соприкосновения с клиентом.

Согласно принципам Agile, в процессе создания продукта участвуют не только сами разработчики, но и заказчик. Кроме того, эта технология предполагает активное вовлечение аудитории в разработку продукта на всех стадиях производства.

• Эксперименты.

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

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

Тем временем принципы Waterfall-методологии прямо противоположны подходам Agile. Каскадная методика относится именно к тем стратегиям продакт-менеджмента, которые предполагают наличие четкого плана, сразу учитывающего все риски, сроки реализации и затраты. Например, если в гибких методиках сроки могут меняться в зависимости от того, как проходит процесс разработки, то в модели Waterfall все дедлайны строго фиксированы с самого начала ведения проекта. То же самое касается и обратной связи от клиента: в Waterfall заказчик составляет подробное ТЗ и больше не вовлекается в процесс разработки, в то время как в Agile обратная связь от клиента важна на каждом этапе. Также в каскадной методологии должно быть строгое распределение обязанностей между членами рабочей группы, а вот в Agile разработчики могут работать над совершенно разными задачами и совмещать их.

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

Среди преимуществ такой модели можно выделить следующие:

• Понятность и предсказуемость. Методология Waterfall - это простой, четко определенный и проверенный временем способ управления проектами. Поскольку все требования изложены с самого начала работы над продуктом, а также составлено подробное техническое задание, каждый участник команды знает, что и когда должно быть сделано.

• Грамотное распределение задач и ресурсов. Точность и определенность процессов позволяют наиболее эффективно планировать временные, энергетические, материальные и финансовые ресурсы на протяжении всего проекта.

• Отсутствие вмешательств со стороны. То есть клиент не участвует в разработке, не видит промежуточных результатов и не вносит свои коррективы после составленного ТЗ. Это является преимуществом в том случае, если заказчик не может быть постоянно на связи с рабочей группой.

• Масштабируемость. Именно в процессе работы над крупными проектами заказчик в силу занятости и других причин не всегда может дать обратную связь команде. Также в разработке масштабных проектов для руководителя рабочей группы особенно важно держать все под контролем, что обеспечивает каскадная методология. Кроме того, в крупных проектах важна точность и определенность как сроков, требований, бюджета, так и желаемого результата.

• Актуальность и для привычных типовых проектов. Наряду с масштабными проектами, методология Waterfall способна успешно контролировать и управлять более привычными и уже знакомыми команде разработками. В том случае, если рабочая группа занималась подобными проектами, ей не нужно проводить дополнительных исследований, использовать новые инструменты и технологии. Поэтому многие компании успешно используют отлаженный алгоритм для создания новых продуктов и не спешат переходить к более гибким методам.

Однако наряду с преимуществами методология Waterfall имеет и недостатки. Как и в любом рабочем процессе, сильные стороны могут обернуться слабостями. Например, упор каскадной методологии на предварительное планирование проекта и приверженность определенным и четко обозначенным правилам означает, что она менее гибкая и мобильная на более поздних этапах разработки. Из-за этого необходимые изменения могут отнимать много времени и финансов. Так, среди недостатков методологии Waterfall выделяют:

• Недостаток гибкости. В том случае, если на каком-то из этапов возникнут проблемы или изменятся требования, нужно будет начинать весь процесс сначала.

• Высокий уровень рисков. Несмотря на предсказуемость, методология Waterfall очень рискованна. Это связано именно с тем, что на этапах разработки не предусмотрены никакие изменения, однако если их все-таки придется вносить, то возникает риск пропустить дедлайн или работать сверх нормы. Кроме того, есть риск столкнуться с тем, что проект устареет к тому времени, как закончится его разработка по каскадной модели.

• Ограниченность. В процессе разработки продукта по методологии Waterfall жестко ограничены как бюджет, так и используемые инструменты, количество участников команды, дедлайны. При этом вся ответственность лежит на одном человеке - руководителе рабочей группы. Поэтому если на его место будет выбран некомпетентный специалист, то весь проект может быть испорчен.

Когда лучше всего использовать методологию Waterfall

В реальной жизни каскадную модель почти не применяют в чистом виде именно из-за отсутствия гибкости. Поэтому многие проект-менеджеры совмещают несколько методик Agile, например Scrum и Waterfall. Это позволит тщательно подготовиться к началу разработки продукта, однако в дальнейшем обеспечит большую гибкость и возможность исправлять ошибки в процессе работы, экономя время и финансы.

Однако можно смело использовать методологию Waterfall в том случае, если клиент точно знает, чего он хочет, выдвигает четкие требования, имеет фиксированный бюджет и дедлайн. Чаще всего такие клиенты не готовы к неожиданным экспериментам, они предпочитают следование конкретному плану и предсказуемость. Особенно актуально это для разработки программного обеспечения. Ведь классический Waterfall - это базовая систематизированная и последовательная модель жизненного цикла создания ПО.

Главное - понимать, в каком случае использование Waterfall будет наиболее целесообразным. Если компания успешно использует отлаженный алгоритм для создания новых продуктов, то можно и дальше придерживаться модели водопада. В любом случае не бывает таких методов работы, которые не имели бы недостатков. А в Waterfall все изначально продуманно и фиксированно, поэтому если все требования заранее известны, а риски сведены к минимуму, то многие минусы методологии уступают ее преимуществам.