За почти 20 лет работы мы опробовали разные подходы и форматы сотрудничества с клиентами, разрабатывая для них IT-решения. Сейчас в fuse8 сформировался универсальный подход к разработке проектов, основанный на практиках Waterfall и Agile – моделях разработки ПО. Первая основана на структуре диаграммы Ганта и уже отметила полувековой юбилей. Вторая зародилась чуть больше 20 лет назад в ответ на неповоротливые в прошлом процессы работы в IT-компаниях. Рассказываем, как взяли лучшее из каждой для удобства работы в команде и клиентских выгод.
Waterfall VS Agile: большая разница
Waterfall и Agile различаются уровнем дозволенной гибкости. «Водопадная» или «Каскадная» система предполагает изначально четкий и структурированный план проекта на старте и исключает возможность вольностей по ходу разработки: то, что в плане не описано, не делаем. Все просто и понятно, но не слишком удобно: бизнес-требования к продукту могут поменяться в ходе разработки, когда фаза определения стартовых требований уже пройдет. Тогда мы получим нерезультативный продукт, если не проявим гибкость.
Например, мы взяли в работу проект по созданию сервиса доставки еды. Пока проектировали архитектуру решения по уже готовому ТЗ, у заказчика появилось три конкурента, запустивших аналогичные сервисы. Они уже радуют потребителей. Теперь недостаточно просто создать еще один такой же сервис – нужно сделать его уникальным, чтобы отбить клиентов у соседей по рынку. То есть, необходимо внести изменения в уже утвержденный план, что противоречит принципам Waterfall. Иначе не получится создать бизнес-ценность.
Agile предлагает работать гибче, предусматривая, что ситуация на проекте (и в мире) может измениться – нужно будет быстро подстроиться под новый контекст. Agile-философия породила множество подходов к построению процесса разработки ПО, но основные принципы в каждом из них неизменны. Нужно поставить клиенту работающий продукт и быть готовым к изменениям в ходе его создания.
Однако чем сильнее меняются требования к проекту, тем дольше двигаться до финального дедлайна – нужно будет вводить дополнительные итерации. Да и ресурсы команды конечны – придется растягивать бюджет. Снова неидеально, ведь бизнес всегда хочет знать заранее, сколько будет стоить разработка и сколько она займет времени.
Наш подход на стыке методологий
Работать исключительно по Waterfall мы не могли. Изначальный план, фиксированные сроки и бюджет хороши для любого проекта, вот только план может резко измениться, расширив и бюджет, и сроки. Что-то всегда идет не так, как задумано, и это нужно учитывать при разработке ПО. Это не обязательно вызвано плохим планированием на старте или недостаточной проработкой требований. Просто вначале сложно учесть все, и это правда для любого проекта.
С другой стороны, иметь общую структуру и план разрабатываемого решения в качестве артефактов на старте лучше, чем двигаться в условиях неопределенности. Так мы можем видеть функциональность целиком и сразу планировать построение контента внутри системы. Это полезно даже с условием возможных изменений по ходу разработки.
Классический Waterfall не предполагает участия клиента в разработке после выдачи ТЗ. Взять скоуп задач и уйти на условные полгода, чтобы по истечении этого времени выдать готовое решение, мы не можем. По ходу работы нужно презентовать реализуемую функциональность клиенту хотя бы для того, чтобы сверяться с его ожиданиями.
Полностью полагаться на Agile тоже не получается. Для удобства будем говорить о модели в контексте фреймворка Scrum, потому что используем в работе характерные для него артефакты.
Краткосрочное планирование открывает больше возможностей для гибкости, но часто провоцирует бесконечное вливание ресурсов в проект и неопределенные дедлайны. Пусть мы не просто клепаем продукты по ТЗ, а глубоко погружаемся в бизнес клиента, мы все еще остаемся исполнителями. Поэтому несоблюдения сроков и бюджетов допускать не можем.
Формировать работу по спринтам, добавляя в каждый новые требования, нельзя. Иначе снова растягиваем бюджет и время на реализацию.
Анализ всех «можно» и «нельзя» дал нам понять, что нужно использовать в работе адаптивный подход, который мы называем Wagile. Мы получили его, скорректировав и соединив принципы Waterfall и Agile.
Change request: главная сложность и ключ к развитию проекта
Мы смешали Waterfall и Agile в правильных пропорциях, чтобы коктейль «Wagile» был полезным и для нас, и для клиента. Изначально закладываем необходимую функциональность и бюджет. При этом допускаем, что в процессе разработки эти величины могут меняться, потому что одна влияет на другую.
Если появляются новые требования, которые выходят за рамки запланированного на старте скопа, мы даем клиенту возможность создавать change requests – запросы на изменение функциональности и внесение новых требований. Реализацию предлагаем либо в рамках оговоренного бюджета, но вместо какой-то части изначально запланированной функциональности, либо в рамках дополнительного бюджета, если заказчик готов его предоставить.
Обычно, чем больше нюансов учтено на старте при составлении плана проекта, тем меньше будет поступать change requests на этапе разработки. Может еще оказаться, что не хватает какой-то функциональности, которую не описали на старте, потому что «думали, что это и так понятно». Словом, вариантов масса. Однако источники запросов на изменения могут находиться за рамками планирования. В таком случае предугадать их невозможно.
Например, на стороне заказчика меняется руководитель проекта или владелец продукта. Новый человек хочет распространить свое видение и вносит изменения в уже утвержденную функциональность, причем на разных уровнях. Или другой пример: в компании заказчика приняли верхнеуровневое решение перейти с привычной CRM (с которой мы делаем интеграцию) на другую. При этом условии может потребоваться переработка всей системы, и хорошо, если об этом узнали незадолго после старта разработки. А что, если это произошло в середине проекта или за пару недель до релиза?
Еще один источник change requests – демо. Обычно мы проводим его раз в несколько спринтов. Так процесс работы над продуктом становится прозрачнее для клиента: промежуточные результаты видны, понятно, на каком этапе находится команда.
Вот клиент «потрогал» очередной билд и понял, что представлял себе взаимодействие с решением иначе.
Например, как-то мы делали сайт с блоком новостей. Каждая новость на странице должна была отображаться на отдельной плашке, содержащей название, дату публикации и набор тегов. С последним пунктом возникло несоответствие. На плашке отображался только один тег, хотя новость была отмечена, например пятнадцатью.
Оказалось, что утвержденные дизайн-макеты предполагали отображение только одного тега для новости. Дизайнерам пришлось перерабатывать макеты, а нам – переписывать код, чтобы реализовать функциональность для динамического отображения.
Сделали так, чтобы полный список тегов для новости отображался с помощью дополнительного контрола на карточке новости.
Как Wagile работает на бизнес
Мы находим баланс между Waterfall и Agile, убивая двух зайцев. Первый – удобство настройки процессов разработки внутри команды fuse8. Второй – создание бизнес-ценности для клиента прозрачно и гибко.
- На старте важно выявить цели и метрики, по которым будем оценивать успех проекта. Подробнее об этом рассказали в статье про Impact Mapping. Пропустить этот шаг – лишиться ориентиров, которые помогают в ходе разработки.
- Вместо составления многостраничного ТЗ проводим предпроектное исследование. Выясняем у бизнеса, какую функциональность нужно реализовать. Результат – понятная документация, которая описывает функциональность будущего решения на языке бизнеса.
- Верхнеуровневый план развития проекта разбиваем на этапы и декомпозируем задачи. Так бизнесу удобнее отслеживать процесс и расход ресурсов. А наши разработчики в таком случае работают с разграниченными и осмысленными частями проекта по спринтам, четко зная, сколько времени нужно на выполнение задач.
- Wagile упрощает и сверку промежуточных итогов с клиентом: показываем на демо не абстрактные доработки а проработанные сегменты создаваемого продукта. Клиент понимает, за что платит, не остается в неведении, пока идет разработка.
- Меняющиеся требования приоритезируем и учитываем с оглядкой на изначальный план. Целостное видение функциональности закреплено с клиентом еще на старте. Поэтому change requests, возникающие далее, не берутся в разработку сразу же.
- Сперва выясняем, насколько новые требования соотносятся с целями проекта, чтобы, например, ничего не сломать и не сойти с курса в целом. Затем распределяем изменения по итерациям или запрашиваем дополнительные ресурсы на реализацию, если получается слишком большой скоуп.
Фото в заголовке: by pawel_czerwinski on Unsplash
