Выбор между Agile и Waterfall: что лучше для вашего проекта?

Всем привет, меня зовут Максим Дмитриев. Я руководитель проектов в компании RDN Group. Наша команда специализируется на разработке сложных и высоконагруженных решений для промышленных компаний: личных кабинетах, торговых площадках, порталах и интеграционных проектах. RDN Group один из 30 партнеров 1С-Битрикс с расширенной компетенцией крупные корпоративные внедрения Enterprise. 

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

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

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

Что такое Agile? 

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

Преимущественно работа над задачами ведется параллельно с заказчиком самоорганизованными командами, доработки вносятся на ходу. Документация здесь не выходит на первый план, однако не стоит думать, что Agile - это работа без документов. Упор в данной методологии делается на продукт. 

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

Плюсы и минусы Agile

Гибкая методология Agile состоит из этапов: 

1. Создание бэклога задач. Определяются задачи для достижения поставленной цели. 

2. Выделение итераций (спринтов). Проект разбивается на маленькие части, один интервал длится обычно от 1 до 4 недель. 

3. Разработка и тестирование. Тестирование проводится несколько раз, что позволяет увидеть ошибку сразу. 

4. Демонстрация результатов, по завершению итерации производится презентация продукта. 

5. Обратная связь. Команда обсуждает, что получилось хорошо, а что получилось плохо, вносятся правки. 

6. Внедрение. Продукт выводится в релиз.

Что такое Waterfall? 

Waterfall- традиционный, “жесткий” метод разработки ПО. Данная методология характеризуется структурностью и последовательностью. Каждый следующий этап начинается после завершения предыдущего. 

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

Плюсы и минусы Waterfall

Водопадная методология Waterfall состоит из 5 этапов:

1. Сбор требований и подготовка ТЗ. 

2. Проектирование, оно включает в себя выбор функций продукта и инструментов для реализации. 

3. Разработка продукта, данный этап проходит в строгом соответствии с ТЗ, на этом этапе уже нельзя вносить изменения. 

4. Тестирование - проверка продукта на ошибки и баги. 

5. Поддержка - выпуск продукта в релиз и поддержание его работоспособности. 

Сравнительная характеристика методологий.

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

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

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

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

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

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

Работая по методологии Agile, мы понимаем, что ход проекта идет маленькими итерациями, и в процессе мы корректируем цель, делаем MVP, который приносит результат и дальше развиваем продукт. Это является преимуществом. 

Недостатком является то, что если Agile превращается в полный T&M и наблюдается полное бесконтрольное поведение со стороны руководителя проекта, то подход становится достаточно проблематичным. С точки зрения окупаемости, можно нагнать много ресурсов, хотя столько не требуется. В результате растет себестоимость продукта. 

Waterfall - ставим задачу прийти из точки А в точку Б. Однако, если проект длится 2 года, то многое может измениться и по итогу окажется, что нужен другой результат. По окончанию проекта появится необходимость создать новый проект, чтобы прийти в точку Б, но с изменениями, которые возникли пока проект создавался. Изменения связаны с появлением новых технологий, конкуренцией на рынке. 

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

Выводы 

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

Рассмотрим 3 типа компании: 

1. Компании, которые следуют продуктовому подходу. У них есть бюджет и сроки на запуск продукта, а внутри проект делится на спринты на усмотрение команды, которая занимается продуктом. 

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

3. Компании, которые следуют Ф.З. №223, у них на каждые 1000 часов разработчика должно быть минимум 100 листов бумаги. Но в рамках повседневной деятельности такие компании все равно используют дедлайны и другие инструменты Agile. 

Если у вас ограниченный бюджет, то здесь все равно нет точного ответа, но скорее всего вам подойдет Waterfall методология, предпроектное обследование, анализ и реализация требований. Но не стоит забывать, что “аппетит приходит” во время реализации продукта, поэтому в рамках ППО зачастую возникают дополнительные требования и их бывает достаточно много. 

Есть время фокуса и время расфокуса - когда ищешь что-то. Я считаю, что в споре Agile & Waterfall, тоже есть время, когда компании нужно быстро расти и захватывать рынок, тогда она запускает больше проектов, больше тестирует гипотез - тогда она применяет Agile. Когда компании нужно оптимизировать свои расходы, системы, тогда она начинает применять жесткие методологии, но опять же с элементами Agile.