Всем привет, меня зовут Максим Дмитриев. Я руководитель проектов в компании RDN Group. Наша команда специализируется на разработке сложных и высоконагруженных решений для промышленных компаний: личных кабинетах, торговых площадках, порталах и интеграционных проектах. RDN Group один из 30 партнеров 1С-Битрикс с расширенной компетенцией крупные корпоративные внедрения Enterprise.
Сегодня мы поговорим о том, какой все-таки подход выбрать Agile & Waterfall? Достаточно долго распространенной проблематикой было какую методологию выбрать: гибкую или тяжелую, однако в какой-то момент эта дискуссия перестала быть актуальной, потому что большинство продуктовых компаний стали использовать гибкие методологии.
На сегодняшний день, мне кажется, эта дискуссия становится вновь популярной. Объясню почему: многие крупные энтерпрайз компании, в том числе разрабатывающие свои продукты или внедряющие большие системы, конгломераты систем, большие связки систем, много взаимосвязанных проектов, имеют некую усталость от Agile подхода и частично возвращаются к “старому, доброму” Waterfall, или частично смешивают эти практики .
В данной статье мы разберем гибкое и водопадное управление проектами и сравним их. Однако, прежде чем сравнивать эти методологии, нужно разобраться в каждой из них.
Что такое Agile?
Agile - семейство гибких методологий проекта. Данный подход про сотрудничество, адаптивность, постоянное совершенствование, удовлетворенность клиента. В работе с большими и длинными проектами он позволяет разбить его на мелкие компоненты и проявить гибкость на каждом этапе, учитывая меняющиеся потребности клиента.
Преимущественно работа над задачами ведется параллельно с заказчиком самоорганизованными командами, доработки вносятся на ходу. Документация здесь не выходит на первый план, однако не стоит думать, что Agile - это работа без документов. Упор в данной методологии делается на продукт.
Проект разделяется на этапы с установлением дедлайнов. Это хорошо сказывается на продуктивности команды, что несомненно отражается на результате.
Плюсы и минусы Agile
Гибкая методология Agile состоит из этапов:
Создание бэклога задач. Определяются задачи для достижения поставленной цели.
Выделение итераций (спринтов). Проект разбивается на маленькие части, один интервал длится обычно от 1 до 4 недель.
Разработка и тестирование. Тестирование проводится несколько раз, что позволяет увидеть ошибку сразу.
Демонстрация результатов, по завершению итерации производится презентация продукта.
Обратная связь. Команда обсуждает, что получилось хорошо, а что получилось плохо, вносятся правки.
Внедрение. Продукт выводится в релиз.
Что такое Waterfall?
Waterfall- традиционный, “жесткий” метод разработки ПО. Данная методология характеризуется структурностью и последовательностью. Каждый следующий этап начинается после завершения предыдущего.
Waterfall из-за линейности подходит для повторяющихся и предсказуемых проектов. Одним из принципов разработки является подробная документация, а также согласование каждого этапа. Каждая деталь фиксируется на бумаге, прописывается четкое и подробное ТЗ для каждой итерации проекта.
Плюсы и минусы Waterfall
Водопадная методология Waterfall состоит из 5 этапов:
Сбор требований и подготовка ТЗ.
Проектирование, оно включает в себя выбор функций продукта и инструментов для реализации.
Разработка продукта, данный этап проходит в строгом соответствии с ТЗ, на этом этапе уже нельзя вносить изменения.
Тестирование - проверка продукта на ошибки и баги.
Поддержка - выпуск продукта в релиз и поддержание его работоспособности.
Сравнительная характеристика методологий.
Мы, как компания исполнитель, компания-подрядчик, больше приветствуем наличие гибких методологий. Они при правильной организации, с нашей точки зрения, более комфортные как для исполнителя, так и для заказчика.
Гибкие методологии позволяют добиться более быстрого результата, быстрее внедрить MVP. Однако есть заблуждение, что классический Agile дает слишком много преференций исполнителю и неограниченный бюджет со стороны заказчика.
Однако, если правильно готовить Agile, то это наоборот позволяет держать исполнителя в тонусе, потому что методология включает в себя дедлайны, планирование бэклога, ретроспективу спринта. Ошибочно полагать, что где Agile там T&M, неограниченные и неуправляемые бюджеты.
Приведу пример из жизни. Моя знакомая устроилась программистом в компанию на удаленку. Она думала, что сможет работать и успевать делать домашние дела. Но не тут то было, в компании устанавливались ежедневные дедлайны, планирование, задач при этом ставилось больше, чем потенциально сотрудники могут выполнить. Поэтому расслабиться и заниматься посторонними делами у нее не получилось.
Если мы вернемся к началу, где я говорил, что есть усталость от Agile, то это происходит там, где классический T&M, где нет ограничения бюджета, ограничения спринтов, четкого менеджмента со стороны заказчика. На сегодняшний день зрелые заказчики используют все инструменты, чтобы этого избежать.
Agile будет плох в сильно бюрократических структурах, где много различных согласований, где функциональный заказчик должен согласовать каждую часть проекта с информационной безопасностью, с ИТ-департаментом и т.д. При этом согласования длятся долго, и это может стать причиной, что команда будет выпадать из спринтов.
Работая по методологии Agile, мы понимаем, что ход проекта идет маленькими итерациями, и в процессе мы корректируем цель, делаем MVP, который приносит результат и дальше развиваем продукт. Это является преимуществом.
Недостатком является то, что если Agile превращается в полный T&M и наблюдается полное бесконтрольное поведение со стороны руководителя проекта, то подход становится достаточно проблематичным. С точки зрения окупаемости, можно нагнать много ресурсов, хотя столько не требуется. В результате растет себестоимость продукта.
Waterfall - ставим задачу прийти из точки А в точку Б. Однако, если проект длится 2 года, то многое может измениться и по итогу окажется, что нужен другой результат. По окончанию проекта появится необходимость создать новый проект, чтобы прийти в точку Б, но с изменениями, которые возникли пока проект создавался. Изменения связаны с появлением новых технологий, конкуренцией на рынке.
В классической методологии больше внимания уделяется предпроектной аналитике, проектной аналитике, предварительному ТЗ, проработке ТЗ на этапе ППО. В гибкой методологии больше внимания уделяется прототипированию, запуску MVP, ТЗ тоже выделяется.
Выводы
В конечном счете заказчиком выбирается не методология проекта, не методология портфеля проекта, а методология ведения бизнеса и инвестиционных проектов. Выбор происходит на уровне долгосрочной стратегии заказчиков, он не должен делегироваться исполнителю.
Рассмотрим 3 типа компании:
Компании, которые следуют продуктовому подходу. У них есть бюджет и сроки на запуск продукта, а внутри проект делится на спринты на усмотрение команды, которая занимается продуктом.
Компании, у которых смешанный подход. У них на каждый проект есть достаточно жесткий бюджет и жесткие сроки, жесткие метрики эффективности, понимания результата. Проект внутри делится на спринты, с точки зрения совместного управления, совместной отчетности.
Компании, которые следуют Ф.З. №223, у них на каждые 1000 часов разработчика должно быть минимум 100 листов бумаги. Но в рамках повседневной деятельности такие компании все равно используют дедлайны и другие инструменты Agile.
Если у вас ограниченный бюджет, то здесь все равно нет точного ответа, но скорее всего вам подойдет Waterfall методология, предпроектное обследование, анализ и реализация требований. Но не стоит забывать, что “аппетит приходит” во время реализации продукта, поэтому в рамках ППО зачастую возникают дополнительные требования и их бывает достаточно много.
Есть время фокуса и время расфокуса - когда ищешь что-то. Я считаю, что в споре Agile & Waterfall, тоже есть время, когда компании нужно быстро расти и захватывать рынок, тогда она запускает больше проектов, больше тестирует гипотез - тогда она применяет Agile. Когда компании нужно оптимизировать свои расходы, системы, тогда она начинает применять жесткие методологии, но опять же с элементами Agile.
