Agile VS Водопад: какой подход выбрать для проекта?

Управление проектами


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

Каскадный метод


Каскадный метод применяется примерно с 70-х годов ХХ века и по сей день распространен достаточно широко. Согласно этому методу вам необходимо совершить определенную последовательность действий в течение жизненного цикла проекта. Обычно проект проходит следующие стадии:

— анализ технических требований;
— дизайн;
— реализация;
— тестирование;
— установка;
— обслуживание.

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

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

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

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

Гибкий метод


Гибкий метод относится к группе итеративных методов, основанных на сотрудничестве заказчиков и разработчиков, совместно определяющих требования и решения. Термин возник в 2001 году, когда был составлен «Манифест гибкой методологии разработки ПО» («Agile Manifesto»).

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

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

Однако, мой менеджер увидел в этом ошибку команды, не способной выполнить требования заказчика. По моему мнению, требования были соблюдены на 90%, а работа над оставшимися 10% заняла бы лишь несколько дней. Эта итерация позволила нам более полно понять требования клиента, а заказчик получил четкое представление о том, чего ему ожидать.

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

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

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

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

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

Заключение


Какой же метод лучше: каскадный или гибкий? Однозначного ответа нет.

Ваш выбор метода зависит от нескольких факторов. Вот лишь некоторые из них.

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

Тип заказчика. Готов ли клиент работать с итерациями? Достаточно ли у него времени, чтобы регулярно просматривать и комментировать их?

Точка зрения менеджера. Есть ли у менеджера собственные предпочтения по выбору метода? Насколько быстро он способен адаптироваться к изменениям?

Точка зрения IT-отдела компании. Будут ли IT-специалисты, вовлеченные в проект, ценными партнерами или «неизбежным злом»? Во втором случае лучше применять каскадный метод.

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

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

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

Коммантарий Игитяна Тачат
Хочется со своей стороны отметить. Исходя из своего опыта, я советую использовать Agile в случае, если проект длительностью более 3х месяцев. Т.к. в длинных проектах, всегда меняются требования и это не зависит от заказчика, ведь время идет, бизнес меняется, а продукт должен соответствовать бизнесу.
  • ,
  • ,
  • ,
  • ,
  • ,
  • avatar
  • 1
  • +1
  • 9969

0 комментариев

Оставить комментарий

Комментировать при помощи:


Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.