Поделиться
Agile и «водопад». Сравнение подходов
Выбор правильной методологии управления проектами — первый шаг к успеху проекта. Однако выбор непрост — и классическая «каскадная» разработка («водопад»), и модная ныне «гибкая» (agile) имеют свои преимущества и недостатки. Выбор в пользу одной из них зависит от таких факторов, как тип планируемого проекта, организационная структура, экспертиза и навыки команды.
Что такое agile?
Гибкая разработка впервые упоминается в опубликованной в 1970 г. статье Уильяма Ройса о создании больших программных систем. Четыре ее фундаментальных ценности и 12 принципов были сформулированы позднее в «Манифесте Agile». Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. Каждый цикл нацелен на непрерывное улучшение разработки продукта или сервиса.
Agile предусматривает итеративный и ориентированный на пользователей подход к разработке программного обеспечения и включает несколько стадий. Первая — планирование. Она предполагает совместную работу заказчиков и исполнителей над концептуализацией, определением, приоритезацией, распределением ресурсов и бюджетированием проекта. Вторая стадия — проектирование, в ходе которой заинтересованные стороны определяют, как должен выглядеть продукт и какие необходимые элементы он должен содержать. Далее идет собственно разработка, в ходе которой команда разработки создает продукты короткими итерациями, называемые «спринтами». Тестирование призвано выяснить, соответствует ли продукт требованиям. При выявлении недостатков он возвращается на стадию разработки для устранения проблем перед повторным тестированием. Этот цикл продолжается пока продукт не станет соответствовать спецификациям. Главная особенность подхода agile – постоянная обратная связь между разработчиками, тестировшиками и заказчиком, позволяющая улучшать продукт понемногу, но непрерывно.
Для того, чтобы команда разработки была способна работать в agile, она, по мнению Мойры Александер (Moira Alexander), должна соответствовать ряду критериев. Команды гибкой разработки должны уметь фокусироваться на запросах пользователей, адаптироваться к изменениям и быть способными работать «под давлением». От участников команды требуются развитые навыки командной работы и сильное чувство ответственности не только перед командой, но и перед заказчиком.
Что такое «водопад»?
Каскадная методология, или «водопад», также используется при разработке продуктов, но процесс разработки носит линейный характер и выполняется в предопределенной последовательности от начала до завершения проекта и предоставления результатов. Этапы «водопадной» разработки схожи с вышеописанными этапами agile-разработки. Также есть этап сбора и анализа требований; этап проектирования, на котором определяется, как должен выглядеть продукт и какие необходимые элементы он должен содержать. После разработки продукта идет его тестирование и приемо-сдаточные испытания для определения соответствия предопределенным требованиям. Выявленные недостатки и ошибки устраняются перед поставкой продукта. Потом следует представление заказчику финальной версии продукта (в соответствие со спецификациями). После чего он передается клиенту, дальнейшая поддержка и доработка возможна за дополнительную плату (если какой-то ее объем не был внесен в договор).
Проектные команды, следующие этой традиционной методологии разработки, хорошо себя чувствуют в структурированной среде, где процессы и процедуры давно отлажены. Такая разработка предполагает размеренность и сосредоточенность на требованиях. Команды не любят неожиданностей, они строго следуют принятым политикам и правилам.
Agile или «водопад»: за и против
Оба метода разработки имеют свои достоинства и недостатки. Основные из них Мойра Александер свела в таблицу.
Достоинства и недостатки «гибкого» и «традиционного» подходов к разработке
| Agile | «Водопад» |
|---|---|
| Преимущество подхода | |
| Быстрый и при этом гибкий процесс разработки | Хотя циклы носят более формальный и последовательный характер, длительные и упорядоченные процессы могут быть легко освоены командами любого размера |
| Благодаря коротким итеративным спринтам и фокусу на качестве, команды выявляют и исправляют недостатки быстрее, чем при каскадной разработке | Заданные циклы разработки обеспечивают большую стабильность для вновь сформированных команд |
| Задачи могут быть распределены между небольшими командам таким образом, чтобы они не затрагивали другие аспекты или фазы разработки | Требования к проекту задаются в самом начале, а цели редко меняются в ходе проекта. Это упрощает выполнение проекта |
| Итерации позволяют быстро вносить изменения в продукт в процессе разработки, если в том возникает необходимость | Бюджет и необходимые ресурсы выделяются для всего проекта в самом начале, это упрощает управление ожиданиями и рисками |
| Недостаток подхода | |
| Agile | «Водопад» |
| Для гибкой разработки необходим scrum-мастер с опытом проведения спринтов, способный держать ситуацию под контролем при быстром характере итераций | Разработка ведется последовательно и поэтому медленней и менее гибко — переход к следующей фазе возможен только по завершении предыдущей |
| Частые запросы на оценку изменений могут вызвать раздражение клиентов | Проблемы обычно выявляются позднее, чем при гибкой разработке — на стадии тестирования |
| Если команды недостаточно хорошо организованы или не способны к самоуправлению, могут возникнуть проблемы, особенно у территориально распределенных команд | Требования определяются и одобряются в начале проекта, поэтому что-либо изменить в ходе работ становится гораздо трудней |
| Для каких команд разработчиков, клиентов и проектов подходит наилучшим образом | |
| Для опытных команд, сфокусированных на постоянном улучшении качества продукта | Для менее опытных проектных команд |
| Для проектных команд, которые тесно и регулярно взаимодействуют с заказчиками | Проектным командам, клиенты которых не имеют времени и ресурсов для частого общения с разработчиками |
| Для проектных команд, которые не хотят ждать завершения проекта, чтобы получить отзыв на свои продукты | Для проектов с простыми требованиями, сроки готовности которых могут быть отодвинуты |
| Для заказчиков со сложной структурой, которым гибкая разработка поможет быстрее реагировать на изменения | Для заказчиков, которым не подходят быстрые изменения и риск внедрения «частично готового» ПО |
Короткая ссылка
