Одно из первых решений, с которым люди сталкиваются при реализации каждого проекта, – “Какую методологию разработки мы должны использовать?”. Эта тема вызывает много дискуссий (и зачастую жаркие споры). Если вы не сталкивались с подобными вопросами, необходимо дать определение методологии разработки. Говоря очень просто, это способ организации работы по разработке программного обеспечения. Речь идет НЕ о стиле управления проектами или конкретном техническом подходе, хотя вы часто будете слышать, как эти термины смешивают или используют как взаимозаменяемые. Итак, давайте поговорим про наиболее популярные методологии Agile и Waterfall.

Agile и Waterfall: две основные и наиболее популярные методологии

Waterfall, которую правильнее было бы назвать “традиционным” подходом, и
Agile. Agile – это особый тип быстрой разработки приложений, более новый, чем Waterfall, но не настолько новый, как Scrum.

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

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

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

• Сбор и документирование требований
• Проектирование
• Кодирование и модульное тестирование
• Провести тестирование системы
• Провести приемочное тестирование (UAT)
• Устранение любых проблем
• Сдача готового продукта

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

В подходе Waterfall есть как положительные, так и отрицательные стороны.

Плюсы

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

• На протяжении всего процесса разработки разные члены команды могут быть вовлечены в работу или продолжать заниматься другими делами, в зависимости от активной фазы проекта. Например, бизнес-аналитики могут изучать и документировать то, что должно быть сделано, пока разработчики заняты другими проектами. Тестировщики могут готовить тестовые сценарии на основе документации по требованиям, пока идет кодирование. 
• За исключением обзоров, согласований, совещаний по статусу и т. д., присутствие заказчика после завершения этапа разработки требований не является обязательным. 
• Поскольку проектирование завершается на ранних этапах жизненного цикла разработки, этот подход подходит для проектов, в которых требуется разработать несколько программных компонентов. (иногда параллельно) для интеграции с внешними системами. 
• Наконец, программное обеспечение может быть спроектировано полностью и более тщательно, на основе более полного понимания всех поставляемых программных продуктов. Это обеспечивает более качественное проектирование программного обеспечения с меньшей вероятностью возникновения “эффекта куска”. Это явление, которое может возникнуть при разработке, когда части кода определяются и впоследствии добавляются в приложение, где они могут хорошо или плохо сочетаться.

Минусы

Вот некоторые проблемы подхода Waterfall:

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

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

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

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

Плюсы

Некоторые преимущества Agile-подхода легко заметить:

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

Минусы

И, конечно, есть и недостатки:

• Очень высокая степень вовлеченности заказчика в проект, несмотря на то, что она очень важна для проекта, может создать проблемы для некоторых заказчиков, у которых просто нет времени или интереса для такого участия. 
• Agile лучше всего работает, когда члены команды разработчиков полностью посвящают себя проекту. 
• Поскольку Agile ориентирован на выполнение работ в установленные сроки и частую перестановку приоритетов, возможно, что некоторые элементы, намеченные к выполнению, не будут завершены в отведенные сроки. Могут потребоваться дополнительные спринты (сверх первоначально запланированных), что увеличит стоимость проекта. Кроме того, вовлеченность заказчика часто приводит к тому, что в ходе проекта запрашиваются дополнительные функции. Это также может увеличить общее время и стоимость реализации. 
• Тесными рабочими отношениями в Agile-проекте легче всего управлять, когда члены команды находятся в одном физическом пространстве, что не всегда возможно. Однако существует множество способов решения этой проблемы, таких как веб-камеры, инструменты для совместной работы и т. д. 
• Итеративный характер Agile-разработки может привести к частому рефакторингу, если в первоначальной архитектуре и дизайне не учитывается полный объем системы. Без такого рефакторинга система может пострадать от снижения общего качества. Это становится более заметным при крупномасштабных реализациях или в системах с высоким уровнем интеграции.

Заключение: Agile и Waterfall

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

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

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

Дополнительные материалы