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

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

Waterfall VS Agile: большая разница

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

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

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

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

Наш подход на стыке методологий

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

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

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

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

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

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

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

Change request: главная сложность и ключ к развитию проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

Как Wagile работает на бизнес

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

  • На старте важно выявить цели и метрики, по которым будем оценивать успех проекта. Подробнее об этом мы рассказали в статье про Impact Mapping. Пропустить этот шаг – лишиться ориентиров, которые помогают в ходе разработки.
  • Вместо составления многостраничного ТЗ проводим предпроектное исследование. Выясняем у бизнеса, какую функциональность нужно реализовать. Результат – понятная документация, которая описывает функциональность будущего решения на языке бизнеса.
  • Верхнеуровневый план развития проекта разбиваем на этапы и декомпозируем задачи. Так бизнесу удобнее отслеживать процесс и расход ресурсов. А наши разработчики в таком случае работают с разграниченными и осмысленными частями проекта по спринтам, четко зная, сколько времени нужно на выполнение задач.
  • Wagile упрощает и сверку промежуточных итогов с клиентом: показываем на демо не абстрактные доработки а проработанные сегменты создаваемого продукта. Клиент понимает, за что платит, не остается в неведении, пока идет разработка.
  • Меняющиеся требования приоритезируем и учитываем с оглядкой на изначальный план. Целостное видение функциональности закреплено с клиентом еще на старте. Поэтому change requests, возникающие далее, не берутся в разработку сразу же.
  • Сперва выясняем, насколько новые требования соотносятся с целями проекта, чтобы, например, ничего не сломать и не сойти с курса в целом. Затем распределяем изменения по итерациям или запрашиваем дополнительные ресурсы на реализацию, если получается слишком большой скоуп.

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

0
1 комментарий
Andrey Stepanov

Wagile? Вы серьезно?

Ответить
Развернуть ветку
Читать все 1 комментарий
null