Почему мы выбираем Waterfall вместо Agile

Все мы обожаем разные виды организации и дисциплины... Или нет. Честно говоря, нам больше нравится находить наиболее эффективные и гибкие способы достижения поставленных целей.

Waterfall – методология, которую мы выбираем вместо вездесущего Agile. Нет, мы не сошли с ума, и нет, мы не отрицаем Agile только из-за «попсовости». В этой статье поговорим о том, что нам дает Waterfall и какие минусы Agile мы для себя выделили.

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

Для начала обратимся к открытым источникам и проведем небольшой сравнительный анализ.

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

Основные этапы:

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

Ключевые концепции:

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

Agile предлагает итеративный и гибкий подход, позволяет принимать быстрые решения, быстро адаптироваться к изменениям рынка и требованиям бизнеса.

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

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

1. Люди и взаимодействие важнее процессов и инструментов

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

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

2. Работающий продукт важнее исчерпывающей документации

Пока мы не заменили всех сотрудников на ИИ, с нами остается человеческий фактор.

Мы уже писали статью про Bus-фактор, где говорили о подобных рисках.

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

3. Сотрудничество с заказчиком важнее согласования условий контракта

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

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

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

4. Готовность к изменениям важнее следования первоначальному плану

Мы думаем, работа над любым проектом должна начинаться с детальной аналитики. Хороший системный аналитик должен как психолог «вытащить» из заказчика его боль, понять запрос и помочь сформировать четкое ТЗ.

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

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

Ключевые принципы:

1. Строгая последовательность этапов

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

2. Документирование каждого шага

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

3. Ясные требования и ожидания

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

4. Согласование условий контракта

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

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

В конце концов, не стоит ограничивать себя только двумя методологиями. Есть еще куча других подходов, с которыми можно поиграться.

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

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