Успех проекта разработки программного обеспечения тесно связан с выбранным подходом к разработке. Agile и Waterfall - две из самых популярных методологий SDLC в настоящее время. Таким образом, возникает вопрос: какую из них выбрать?

И Agile, и методологии Waterfall - зрелые подходы к разработке программного обеспечения. Хотя эти две модели имеют несколько общих черт, обе модели SDLC отличаются по нескольким аспектам. Так что следует помнить об этом, делая выбор среди них.

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

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

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

Скотт Эмблер начал разработку методологии Agile осенью 2000 года. Первоначально она была названа Extreme Modeling (XM), но позже была переименована в Agile Modeling по предложению Роберта Сесила Мартина.

Подход Agile - это итеративный и командный подход к разработке программного обеспечения. Это особый тип модели быстрой разработки приложений (RAD) . Хотя он и не новый, он относительно новее по сравнению с классической моделью Waterfall.

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

Каждый из результатов имеет приоритет с точки зрения бизнес-ценности, которая определяется не кем иным, как клиентом (клиентами). Методология Agile во многом зависит от высокого уровня участия клиентов на протяжении всего процесса разработки программного обеспечения.

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

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

Плюсы

1. Как процесс, ориентированный на клиента, он обеспечивает постоянное участие клиента на протяжении всего процесса, на каждом этапе.
2. Гарантирует, что качество разработки программного обеспечения поддерживается на желаемом уровне или даже лучше.
3. Клиент (ы) пользуется ранней и частой возможностью увидеть прогресс. Следовательно, можно изменять решения на протяжении всего процесса разработки проекта.
4. Придает сильное чувство сопричастности к клиенту (ам), поскольку они напрямую и широко контактируют с командой разработчиков проекта.
5. Он может создать базовую версию разрабатываемого программного обеспечения, которую можно будет использовать в последующих итерациях. Это очень полезно для проектов, где время вывода на рынок того же самого является проблемой, имеющей большое значение.
6. Вероятно, даст лучшие результаты. Это потому, что чаще всего Agile-команды исключительно мотивированы и самоорганизованы.
7. Сниженный риск отказа, поскольку процесс полностью основан на постепенном прогрессе. Следовательно, и клиент (ы), и команда разработчиков точно знают, что завершено, а что нет.

Минусы

1. Если руководитель проекта не уверен в результате, существует повышенный риск срыва проекта.
2. Требует привлечения эксперта для принятия жизненно важных решений.
3. Не подходит для небольших проектов
4. Общая стоимость внедрения гибкого подхода немного выше, чем у других подходов к разработке программного обеспечения. Кроме того, общее прогнозируемое время может увеличиваться по мере продвижения разработки программного обеспечения.
5. Характерной чертой очень высокой вовлеченности клиентов может быть не то, о чем могут просить некоторые клиенты

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

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

Первым формальным описанием модели Waterfall, хотя и лишенным слова «Waterfall» ( «водопад»), является статья Уинстона У. Ройса 1970 года. Считается, что в статье 1976 года Белла и Тайера термин « «Waterfall»» впервые упоминается.

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

Плюсы

1. Удобно для управления зависимостями
2. Участие клиента не обязательно на всех этапах разработки программного обеспечения.
3. В зависимости от текущей фазы проекта разные члены команды могут сосредоточиться на разных задачах.
4. Каждая фаза имеет отдельные результаты и процесс проверки. Следовательно, легко управлять
5. Имеет легко адаптируемый подход для сменных команд
6. Предлагает более быструю доставку продукта
7. Планирование и проектирование просты, поскольку клиент и команда разработчиков заранее согласовывают, что и как разрабатывается для программного продукта.
8. Прогресс можно легко оценить и измерить, потому что полный объем задачи известен заранее
9. Обеспечивает разработку программного обеспечения с уменьшенными шансами на частичный эффект. Это связано с тем, что программное обеспечение с самого начала разработано более тщательно и полно.
10. Подходит для проектов, где необходимо разработать несколько программных компонентов для интеграции с какой-либо внешней системой.
11. Хорошо задокументированный процесс и результаты
12. Исключительно хорошо работает для небольших проектов, особенно с легко понятными требованиями.

Минусы

1. Высокая вероятность ошибок и уязвимостей, так как процесс тестирования начинается только после завершения разработки проекта.
2. Непрактично для крупномасштабных проектов
3. Невозможно приспособить изменения, внесенные позже во время процесса
4. Менее эффективный метод, когда требования не ясны вначале
5. Представляет нечеткое представление о том, что клиенты могут ожидать в качестве конечного продукта.

Agile vs Waterfall: разница, которую вы должны знать

1. Степень гибкости

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

Методология Agile позволяет вносить изменения в требования к проекту даже после завершения первоначального планирования. Модель Waterfall не предусматривает изменения требований после начала разработки проекта.

2. Разделение всего процесса

Методология Agile разделяет весь жизненный цикл разработки на спринты. Напротив, подход водопада разделен на отдельные фазы.

3. Предпочтение в финансировании и ресурсах

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

Модель Agile не подходит для проектов с фиксированной ценой. Вместо этого сценарии с фиксированной ценой могут усилить стресс из-за Agile-проекта. Методология Agile лучше всего подходит для проектов с нефиксированным финансированием или финансированием по времени и материалам (T&M) .

4. Возникновение фаз.

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

В водопадном подходе к разработке программного обеспечения все фазы появляются один раз и только один раз в течение всего процесса.

5. Подготовка требований.

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

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

6. Основное внимание

Основное внимание в подходе Waterfall уделяется созданию продукта. Основное внимание в модели Agile уделяется удовлетворению потребностей клиента в продукте, а также изменению себя в соответствии с меняющимися или новыми потребностями клиентов.

7. Подробное описание проекта.

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

Это не относится к модели Waterfall, в которой не предусмотрено изменение описания деталей проекта после начала разработки проекта.

8. Просмотр проекта

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

9. Координация команды

Командная координация или синхронизация очень ограничены в подходе Waterfall. Размер команды не является предпочтительным. Напротив, Agile-модель предпочитает небольшую, но преданную делу команду. Следовательно, степень координации между его членами очень высока.

10. Взаимозаменяемость команд

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

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

11. Тестирование

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

Кроме того, план тестирования редко пересматривается на этапе тестирования модели Waterfall. В отличие от этого, план тестирования, относящийся к Agile-проекту, пересматривается после каждого спринта.

12. Тип требований

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

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

13. Способ приближения

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

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

Модель Agile vs Waterfall: прямое сравнение:

Заключение

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

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