Wagile: как мы смешиваем разные модели ведения проектов

За почти 20 лет работы мы в fuse8 сформировали универсальный подход к разработке проектов, основанный на практиках Waterfall и Agile. Рассказываем, как взяли лучшее из каждой для удобства работы в команде и клиентских выгод.

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

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

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

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

Работать исключительно по Waterfall мы не могли. Что-то всегда идет не так, как задумано, и это нужно учитывать при разработке ПО. Вначале сложно учесть все, и это правда для любого проекта.

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

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

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

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

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

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

Мы смешали Waterfall и Agile в правильных пропорциях, чтобы коктейль «Wagile» был полезным и для нас, и для клиента.

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

Change requests – это и добро и зло для проекта одновременно. С одной стороны, они помогают справиться с трудностями в ходе разработки и сделать правильный продукт. С другой – влекут за собой риски поломок и частые изменения скопа задач, если поступают регулярно и в большом количестве.

Обычно, чем больше нюансов учтено на старте проекта, тем меньше будет поступать change requests на этапе разработки. Может еще оказаться, что не хватает какой-то функциональности, которую не описали на старте, потому что «думали, что это и так понятно» Словом, вариантов масса и порой изменения предугадать невозможно.

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

Или другой пример: в компании заказчика приняли верхнеуровневое решение перейти с привычной CRM (с которой мы делаем интеграцию) на другую. При этом условии может потребоваться переработка всей системы, и хорошо, если об этом узнали незадолго после старта разработки. А что, если это произошло в середине проекта или за пару недель до релиза?

Еще один источник change requests – демо. Обычно мы проводим его раз в несколько спринтов. Так процесс работы над продуктом становится прозрачнее для клиента: промежуточные результаты видны, понятно, на каком этапе находится команда.

Вот клиент «потрогал» очередной билд и понял, что представлял себе взаимодействие с решением иначе.

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

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

Мы находим баланс между Waterfall и Agile, убивая двух зайцев. Первый – удобство настройки процессов разработки внутри команды fuse8. Второй – создание бизнес-ценности для клиента прозрачно и гибко.

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