Agile или Waterfall? Сравнение методологий веб-разработки
При создании нового проекта, заказчик должен определиться не только с выбором подрядчика, но и подходящей методологией разработки проекта. На современном этапе развития технологий, нет универсального подхода в создании проекта, поэтому возникает логичный вопрос: какой подход выбрать и какие «подводные камни» существуют?
Способ разработки выбирается исходя из задач бизнеса, объема работ, времени и бюджета. Наиболее популярными считаются Waterfall - каскадная, и Agile - гибкая. Отметим, что неправильный выбор методики, может отрицательно сказаться на вашем проекте, поэтому учитывайте особенности каждой из них.
Waterfall – это четко запланированный и детализированный подход, где исполнитель придерживается плану. Agile – прямая противоположность, которая предполагает гибкость разработки с возможностью внесения изменений на каждом этапе проекта.
В этой статье постараемся определить, в чем особенности этих двух методологий, назовем положительные и отрицательные стороны, а также разберемся, какой способ реализации подойдет для выбранного вами проекта.
Agile
Agile – система, основанная на принципе «гибкого» управления проектами. Сюда относят методики Scrum, FDD, Kanban, Экстремальное программирование (XP), Lean и т.д. Ключевая особенность такого подхода - создание проекта в несколько циклов (итераций), в конце каждого виден конкретный результат, который позволяет понять, по какому пути двигаться дальше.
Гибкие методологии строятся на принципе итераций. Создание нового продукта делится на несколько циклов от одной недели до месяца. В зависимости от особенностей проекта, временные рамки оговариваются отдельно. Каждый цикл представляет собой завершенный мини-проект, в котором есть этапы анализа, планирования, тестирования и реализации. В итоге клиент получает продукт, который, при необходимости, корректируется.
Главные принципы Agile:
- Эффективное взаимодействие в команде важнее процессов и технологий. Цель – создание качественного проекта.
- Внести необходимые изменения можно в любом из циклов разработки.
- Лучший способ получения обратной связи с заказчиком и коллегами – личное общение.
- Создаваемый продукт обновляется в конце каждого цикла или один раз в несколько месяцев.
- Готовность к изменениям в процессе разработки важнее, чем беспрекословное следование изначальному плану.
Наиболее популярные методики Agile:
Scrum – система гибкой разработки проектов, основанная на принципе спринта. От 1 недели до месяца должна быть готова рабочая версия продукта.
Экстремальное программирование (XP) – методика, при которой важно взаимодействие с клиентом на каждом этапе. Благодаря такому подходу, выявляются недостатки предыдущих этапов, определяется необходимый функционал продукта и другие параметры.
Lean – базируется на системе управления производством. Главное отличие – принцип постоянного совершенствования продукта на всех уровнях организации процесса.
Про гибкую модель управления можно сказать, что она универсальна, так как подойдет к любому проекту. Сложность выбора заключается только в ограничениях заказчика по времени и боязнью «дыр» в бюджете. Качество обратной связи при данном подходе поможет прийти к согласованному решению. Выбирая эту модель, заказчик может быть уверен, что его проект будет уникальным, интересным и проверенным до мелочей.
Waterfall
Waterfall (с англ. – «водопад») – предполагает последовательный переход к каждому этапу разработки и невозможностью вернуться на шаг назад. Внести какие-либо изменения будет возможно только после релиза проекта.
Выбирая данную модель для своего проекта, необходимо понимать, что конечный продукт будет иметь недочеты. Предусмотреть все на этапе анализа и планирования просто невозможно, в процессе разработки могут появится новые требования. Однако, в Waterfall сделать правки в течении проекта невозможно также, как и вернуться на шаг назад. Классический подход представляет из себя каскадную модель, которая базируется на последовательном создании проекта, разбитого на циклы.
Выделяют следующие стадии разработки в Waterfall:
- Анализ системных и программных требований, которые закреплены в документе (Word или PDF).
- Планирование всех этапов разработки. Важный пункт, так как вся последующая работа будет четко следовать составленному плану.
- Проектирование. Разрабатывается внутренняя архитектура проекта, его внешний вид, структура, рассматриваются варианты реализации.
- Реализация дизайна, верстки, программного продукта.
- Интеграция. Проводятся необходимые работы по обмену данных и пишется код программы.
- Тестирование. Готовый продукт проверяется на наличие программных ошибок, также выявляются недочеты функционала. После этого идет исправление нужных багов.
- Выпуск продукта. Релиз готового проекта и окончание разработки. Возможна также работа по адаптации проекта к иным видам систем.
- Техническая поддержка. Поддержание работоспособности ресурса и оперативное реагирование на возникающие вопросы или проблемы в системе.
Востребованные методики Waterfal:
Сашими – одна из самых популярных моделей Waterfal. Представляет собой наслаивающиеся друг на друга этапы, которые перекрываются по времени.
Waterfall с субпроектами – методика работы с тремя крупными стадиями: разработка концепции, проектирование и структурирование продукта. Каждый из этих блоков имеет свои этапы разработки. По окончании работ в каждой стадии проводится их интеграция.
Модель снижения риска – проект разделяется на более мелкие проекты, которые направлены на выявление недочетов до релиза программного продукта.
Ключевая особенность Waterfall – невозможность сделать шаг назад или перепрыгнуть через итерацию, переход на следующую стадию возможен только после прекращения всех работ на предыдущей. Изменение функционала или исправление ошибок происходит только после релиза проекта. Работа по каскадной модели четко структурирована, определи точные сроки и конкретная стоимость разработки.
Преимущества методологий
Agile:
- Внесение необходимых изменений и внедрение нового функционала может происходить независимо от цикла разработки продукта, что значительно повышает конкурентные преимущества готового проекта.
- Проект состоит из коротких и понятных циклов, по окончании которых клиент получает рабочий продукт.
- Гибкий процесс корректировок в любой итерации позволяет снизить производственные риски. - Довольно быстрый релиз пробной версии для дальнейших корректировок и тестирования.
- Высокая степень вовлеченности всех членов команды и постоянное взаимодействие с заказчиком. Он всегда в курсе, на какой стадии находится проект.
- Показателем эффективности является рабочий продукт, что требует высокого профессионализма от исполнителей и грамотной организации рабочего процесса.
Waterfall
- Стоимость и сроки выполнения понятны ещё до начала работ. Поэтому заказчик точно будет знать, когда проект завершится и какой бюджет требуется потратить.
- Интуитивно понятная структура работы, как для опытных специалистов, так и для новичков.
- Детально структурированный план работ и продуманная документация.
- Благодаря удобной отчетности легко отследить потраченное время, возможные риски и используемые ресурсы в процессе работы над проектом.
- Задачи, которые ставятся перед командой ясны и не меняются на протяжении всего проекта.
- Качество проекта занимает первоочередное место, а потраченное время и бюджет отходят на второй план.
Недостатки методологий
Agile:
- Рассчитать конечные затраты практически невозможно – требования могут постоянно меняться в зависимости от особенностей проекта. Сложность заключается в том, что они могут противоречить уже существующей структуре.
- Agile требует большой вовлеченности в процесс и полному погружению в него, что бывает сложно, особенно для молодых подрядчиков.
- Возможность частого внесения правок может обернуться риском в бесконечном совершенствовании проекта. Здесь также возможна и обратная сторона – снижение качества продукта.
Waterfall:
- Требования к проекту закрепляются в начале и не могут меняться до окончания работ. Этот факт лишает проект гибкости.
- Тратится большой объем денежных средств, времени и ресурсов.
- Невозможность внесения изменений в процессе разработки.
- Заказчик увидит готовый проект только после его релиза, при необходимости изменений могут потребоваться дополнительные средства и время.
- Взаимодействие между этапами разработки полностью отсутствует.
- При использовании каскадной модели продукт тестируется после его выпуска. Поэтому в большинстве случаев проблемы выявляются только на этапе тестирования.
Применение методологий
Agile используется:
- Когда перечень требований окончательно не определен, а изменения должны вноситься максимально быстро.
- В проекте работает опытная команда с высоким уровнем профессионализма.
- Заказчик принимает активное участие в разработке на протяжении всего проекта.
- Клиенту важно вносить изменения максимально оперативно на любом этапе работы.
- Если необходимо быстро и в короткие сроки создать рабочую версию продукта. - Новый проект является стартапом.
- Ниша, для которой разрабатывает продукт, подвержена постоянным изменениям.
Waterfall подойдет, если:
- Проектные требования тщательно продуманы и неизменны. У заказчика есть четко сформулированная концепция продукта.
- Технологии и инструменты известны заранее.
- Разрабатываемый продукт сложный и требует больших затрат.
- Приоритетом является качество продукта. Временные и денежные траты имеют второстепенное значение.
- Заказчик не планирует принимать участие в проекте. Он видит только готовый продукт. Проект полностью разрабатывается на аутсортинге.
- Клиенту важно знать точные сроки выполнения всех работ над проектом. Исполнитель полностью несет ответственность за срыв сроков и незапланированное увеличение бюджета.
- Реализация аналогичного проекта, с которым уже сталкивались разработчики.
Что из этого следует?
Каждая из моделей, рассмотренных нами выше, имеет определенный набор характеристик и подходит для реализации проектов разной направленности.
Как Agile, так и Waterfall помогут в создании практически любого продукта. Однако, в первую очередь выбирается та методология, которая может максимально эффективно и качественно реализовать проект. Быть может продукт универсален. Тогда необходимо отталкиваться от параметров, как время, бюджет, квалификация исполнителей и другие важные для вас критерии.
Гибкая модель требует высокого профессионализма от исполнителя и идеально подходит для стартапов и продвинутых нишах. Водопадная модель чаще всего используется в области строительства, инвестиций и т.д.
При выборе той или иной методологии заказчик должен внимательно изучить сильные и слабые стороны подходов, учесть советы специалистов, определить набор требований к проекту. И тогда выбор будет сделать гораздо легче. Некоторые разработчики считают, что в рамках одного проекта можно оптимально совместить Agile и Waterfall.
Помните, что, принимая решение в пользу того или иного метода, главной задачей является создание не только качественного продукта, но и возможность им решать поставленные задачи.
Ну вот какбэ да.
Выбирайте исполнителя, а с методологией уж пусть он сам пределяется. Если вы принципиально не хотите работать по предложенной методологии, а исполнитель не хочет ее менять, возможно, это не ваш исполнитель.
Ну и вопрос о месте работы автора.
Это ж каких размеров должна быть производственная махина, чтобы изменить продукт в процессе вотерфлоу было вот прям невозможно. Не дорого, не долго, не сложно, а вот прям невозможно?
Согласен, пожалуй "невозможно" слишком эмоциональное слово, по сути нет ничего не возможного, по этому да, правильней было бы сказать, что слишком дорого и не рационально.
** Преимущества Waterfall ** полный бред. Вы работали с реальными проектами?
Стоимость и сроки выполнения понятны ещё до начала работ. Поэтому заказчик точно будет знать, когда проект завершится и какой бюджет требуется потратить.
Стоимость и сроки не понятны, они взяты из носа и размазаны по бумаге. По факту сроки и бюджеты всегда нарушаются.
Интуитивно понятная структура работы, как для опытных специалистов, так и для новичков.
Структура работ не понятно, а расписана из ПРЕДПОЛОЖЕНИЙ руководителя проекта или другого руководящего лица. Это мешает контактировать, мешает помогать, все заняты своим делом и не заботятся о благополучии команды.
Детально структурированный план работ и продуманная документация.
Документация, которую никто не читает. План работ, основанный на предположениях.
Благодаря удобной отчетности легко отследить потраченное время, возможные риски и используемые ресурсы в процессе работы над проектом.
Постфактум в любом случае можно всё это отследить, если фиксировать во время работы.
Задачи, которые ставятся перед командой ясны и не меняются на протяжении всего проекта.
Для команды ясны, но в ходе проекта задачи меняются у заказчика и на выходе получается не жизнеспособный продукт, который не нужен заказчику.
Качество проекта занимает первоочередное место, а потраченное время и бюджет отходят на второй план.
А в Scrum и вообще в Agile продукт на последнем месте да?
С ** недостатками Agile ** тоже не согласен.
Рассчитать конечные затраты практически невозможно – требования могут постоянно меняться в зависимости от особенностей проекта. Сложность заключается в том, что они могут противоречить уже существующей структуре.
Требования могут меняться, но они не должны быть диаметрально противоположными. Требования могут дополняться, да. А чтобы вместо изначально запрошенного сарая, заказчик на выходе не требовал дворец, нужен грамотный Product Owner.
Agile требует большой вовлеченности в процесс и полному погружению в него, что бывает сложно, особенно для молодых подрядчиков.
Любая задача требует полного погружения и воволеченности, иначе это будет халтура, а не работа.
Возможность частого внесения правок может обернуться риском в бесконечном совершенствовании проекта. Здесь также возможна и обратная сторона – снижение качества продукта.
Опять таки, есть конечные требования, поставленные изначально, а чтобы губу клиент не раскатывал есть договор и Product Owner.
Вообще по Agile в статье много ошибок. Либо автор не до конца разобрался в вопросе, либо просто не смог правильно преподнести информацию.
А вообще советую прочитать книгу Scrum (Джефф Сазерленд). Там всё по полочкам.
Согласен по большинству пунктов! Оговорюсь только в том, что статья написана для обывателя, поэтому многие моменты упрощения для понимания. Если же освещать действительно все нюансы, то смысл статьи получится следующий - "какая-бы методология использована не была, все равно оценить нихрена не получится".
Придраться из за одного вступления, игнорируя остальную статью - как-то не true
...