Agile или Waterfall

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

Когда мы говорим «методология», то понимаем инструмент планирования работы для команды разработки. Популярные методологии — Agile и Waterfall. Существуют и другие, но их реже используют, поэтому в статье мы про них говорить не будем.

Waterfall — методика управления проектами, подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.

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

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

Критерий 1: есть четкое техническое задание или нет. Техническое задание нужно для того, чтобы разработчики верно поняли, какой именно продукт бизнес хочет получить. Архитектор, проектировщик или аналитик выясняют у заказчика какие задачи должен решить продукт и описывают функционал в виде требований. Затем рассчитываются сроки, бюджет, проект утверждается с заказчиком.

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

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

Чтобы понять степень неопределенности требований, задаем заказчику вопросы:

• Как вы можете описать проект — стартап или готовая система?
• Какие функции нужно создать?
• Есть ли документированные бизнес-требования?
• Возможны ли изменения в требованиях?
• Нужны ли будут улучшения функционала?

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

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

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

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

Чтобы понять, что важнее — сроки или качество — задаем вопросы:

• Вам необходимо разработать продукт к определенному сроку?
• Что именно должно работать к конкретному сроку?
• Без каких функций запуск проекта невозможен?
• Какими функциями можно пожертвовать ради быстрого запуска?
• Что для вас — полностью готовый продукт?

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

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

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

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

Для понимания объема бюджета задаем вопросы:

• Будут ли участвовать в разработке ваши специалисты?
• Умеют ли специалисты работать по Agile?
• Готовы ли вы нанимать специалистов в процессе разработки?
• Готовы ли вы подробно описывать продукт?

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

Критерий	Agile	Waterfall
Проект	Для стартапов и продуктов с высокой степенью неопределенности	Для небольших проектов с низкой степенью неопределенности
Функциональные требования	Не нужно подробно описать функциональные требования.	Нужно составить подробное техническое задание
Тестирование продукта	Каждый спринт тестируются отдельные готовые функции	После завершения разработки продукт тестируется комплексно
Документация	По завершению проекта. В процессе разработки вместо документирования используются доски Скрам, Канбан	Документация на этапе проектирования
Команда	Нужна кроссфункциональная команда высокого уровня	Разработчики среднего уровня
Релиз	Жизнеспособный инкремент выпускается после каждого спринта	Продукт выпускается полностью, после того, как все функции реализованы