Мультизадачность и кроссплатформенность – два бича большинства областей IT. Вот и нам в отделе заказной и продуктовой разработки пришлось столкнуться с одновременным ведением нескольких потоков разработки на международном проекте, где то и дело было необходимо отлавливать зависимости и синхронизировать процессы.
Забегая вперед, могу сказать, что в итоге мы внедрили платформу в 18 странах присутствия заказчика, у нас на поддержке было около 10 тысяч касс в 379 магазинах. Мы выпустили 39 релизов, 82 патча и 73 хотфикса. И во всем этом нам очень помогал SAFe. Почему мы выбрали именно этот фреймворк, как внедряли в процесс международного проекта, что мы из него вынесли и при чем тут поезда, решил рассказать в этой статье.
Что было дано
Мы вели разработку для крупного европейского ритейлера из сегмента Fast Fashion. Команда должна была внедрить торговую платформу в существующих и только открывающихся точках продаж.
Необходимо было развернуть решение для торговли, состоящее из двух частей: MPE, центральное хранилище, и MP POS – приложение на кассах. POS-платформа включала в себя операционную систему, базы данных, драйверы и сторонние приложения для интеграции POS-системы.
Заказчик имел разные запросы в зависимости от географии магазинов, поэтому в дополнение к платформе с базовым набором функций POS-команда разрабатывала различные модули:
ПО для касс самообслуживания;
ПО для автоматизированного обновления программного обеспечения касс;
ПО для продажи еды и напитков;
ПО для продавцов, работающих «в поле», для доступа к складской информации с планшетов и мобильных устройств;
ПО для интеграции системы в магазине с системой онлайн-продаж;
модули интеграции с внешними поставщиками данных;
кастомизация POS-приложения с учетом особенностей каждой страны присутствия — это соблюдение фискальных требований, интеграция программ лояльности и перевод на язык пользователей.
Так как весь процесс разработки необходимо было вести с использованием гибких методологий, было решено применить Scaled Agile Framework или SAFe. Обычно его рекомендуют применять для команд с численностью от 50 человек, но впоследствии мы успешно применяли некоторые практики (о них ниже) из SAFe и в обычных командах, в проектах с одним стримом разработки.
Почему мы выбрали SAFe
Здесь обращусь к ключевым принципам методологии:
Экономический взгляд
«Всё упирается в деньги». Экономическая эффективность всегда стоит во главе угла. Поэтому необходимо фиксировать начальные и целевые метрики. Формулировка и отслеживание KPI помогут сплотиться в работе над общими целями и подтвердят правильность выбранных стратегий.
Системное мышление
Разрабатываемые системы всегда имеют более чем 1 модуль/компонент. Эти компоненты взаимосвязаны в подавляющем числе случаев. Каждый компонент вносит свой вклад в функционал системы и без совокупности этих компонентов система, как правило, не будет функционировать должным образом. Соответственно, необходимо понимать всю систему и мыслить широко, пытаясь понять взаимодействие компонентов. Это позволит определить точки воздействия и попытаться спрогнозировать влияние изменений.
Предполагать изменчивость, сохранять опции
Необходимо брать лучшие практики, но оставаться открытыми для нововведений и инноваций. Зачастую лучше попробовать что-то (пусть в рамках прототипирования), чем оставить неоптимизированный процесс.
Инкрементальные поставки с быстрыми циклами обучения, встроенными в процесс
Всё просто. Сделали объем, который может быть интересен бизнесу – показали, получили обратную связь, проанализировали, внедрили изменения.
Вехи определяются только объективной оценкой работающих систем
Настоящий успех состоит в том, чтобы не только осуществить поставку вовремя и в требуемом объеме, но и убедиться в том, что она несет ценность.
Визуализировать и ограничивать WIP, уменьшать размер порций работ и управлять длиной очередей
Часто во время выполнения задачи возникает желание переключиться на другую. На переключение тратится внимание и время, снижается концентрация. Необходимо соблюдать баланс между «задач не осталось» и «задач слишком много»
Ограничивая объем Work In Progress, можно обнаружить слабые места в процессах и оптимизировать их. Это позволяет уменьшить количество «почти выполненных задач», по сути вырабатывая у команды привычку доводить работу до конца. Когда выявляется момент, препятствующий прогрессу, его штурмует вся команда. После устранения препятствия команда продолжает движение.
Применять каденции, синхронизироваться кросс-доменным планированием
Каденции – это ограниченные во времени ритмы работы (спринты, итерации). Они позволяют уменьшить сложность, неопределенность; привить сотрудникам дисциплину и, в конце конов, «есть слона по ложечке».
Задействовать внутреннюю мотивацию сотрудников
Лучше развивать лидерство, чем насаждать контроль. Необходимо учитывать мнение сотрудника, его взгляд на мир, иногда даже склад характера. Тут сработает синергия между задачами проект и амбициями сотрудника.
Децентрализовать принятие решений
Имеет смысл централизованно принимать нечастые, долговременные и имеющие значительный эффект при масштабировании решения. А что децентрализовать? Всё остальное (частые, срочные и т.д.).
Организация вокруг ценности
Мы привыкли к функциональной структуре организации: так проще. Но это может быть палкой в колесе при ориентации на ценность. Используйте структуру команд как инструмент: она должна быть нацеленной на максимально эффективную поставку ценности.
Как мы начинали проект
Начало проекта пришлось на зиму 2018/2019. Так как для команды это был первый опыт применения SAFe, нас инструктировал опытный agile coach. Вторую половину проекта уже вели самостоятельно. И более того, на финале проекта передали все знания и практики следующей команде, которая сменила нас в силу определенных внешних обстоятельств.
Первым пилотным мини-проектом в рамках большого проекта стала новая точка (точнее, магазин в новой стране присутствия заказчика). И то, что стрим был только один, позволило нам ознакомиться с продуктом и набить первые шишки. Команда состояла из 15 человек: разработчики, тестеры, аналитики и скрам-мастер. Доработка платформы под требования заказчика заняла 3-4 месяца, и летом 2019 года мы успешно запустили новый магазин на нашей платформе и передали его в поддержку.
Ознакомившись с результатами нашей работы, заказчик доверил нам глобальный rollout – по всем своим точкам продаж. И вот тут началось самое интересное.
Глаза боятся, руки делают
Как уже говорил выше, наша команда работала по методологии SAFE + Scrum. По сути по аналогии с первой пилотной командой все остальные скрам-команды состояли из разработчиков, тестировщиков, аналитиков, собранных под руководством скрам-мастера. Для более тщательного управления в SAFе-командах есть роль RTE (Release Train Engineer), которая управляет несколькими скрам-командами (ну или делает всё возможное, чтобы не было препятствий для движения вперед). Такие команды называются ART (Agile Release Train). В свою очередь, Solution Train Engineer (STE) управляет RTE.
Возникает закономерный вопрос: при чем тут Train? Дело в том, что каждая команда представляет из себя некий вагончик. Эти вагончики и формируют паровозик, который смог поезд, который идет к общей цели.
Проект поделили надвое:
на программную часть (разработка и трансформация решения для новых магазинов сети),
и BAU-часть (Business As Usual, поддержка уже развернутого в продакшне решения).
Команда была огромной. Всего на проекте было до десяти скрам-команд с десятью скрам-мастерами, соответственно.
Скрам-команды объединялись в три ART’а по 3-4 команды в каждом. Для упрощения понимания и управления ART мы поделили их таким образом, что первый ART включал в себя так называемые Core-команды, занимающиеся масштабным общим функционалом и глобальными изменениями, второй – узконаправленные команды, занимающиеся реализацией конкретных менее масштабных требований или разработкой под конкретные страны, третий – описанный выше BAU блок. Управляли тремя артами трое RTE-ребят – и репортили, в свою очередь, единому STE-инженеру проекта.
Сложный длиннотекст преобразовал в схему ниже – для наглядности.
Церемонии SAFe
Если смотреть на разницу с классическим скрам-подходом, то в плане церемоний у нас добавилось несколько новых артефактов.
Ввели понятие PI (Programme Increment) – набор из нескольких классических 2-недельных спринтов. Одна из ключевых церемоний в SAFe – это PI Planning. В доковидные времена (а таковые были) они были оффлайн-мероприятиями, на которые съезжались десятки людей со всей планеты, и мы все вместе принимали участие в нескольких ключевых активностях:
утверждали и планировали цели PI,
выясняли зависимости между задачами,
планировали спринты каждой команды в зависимости от пунктов выше.
К классическим скрам-церемониям у нас добавились:
Scrum of Scrums – встреча скрам-мастеров, где подсвечивались основные проблемы и препятствия в работе команд,
Retro of Retros – опять же, встреча скрам-мастеров. На них обсуждались итоги ретро-встреч отдельных команд и улучшения процессов.
Также применялся Kanban подход: BAU ART-а фактически был 4 линией поддержки, а задачи поддержки практически невозможно планировать в разрезе спринтов.
А что на выходе?
К началу 2023 года мы успешно завершили разработку решения под 18 стран. Все релизы были доставлены вовремя несмотря на то, что разработка и поддержка уже выпущенного в продакшен решения велись параллельно. Качество кода становилось все лучше и лучше с каждым релизом, что подтверждалось заказчиком. На пике численность команды разработки и поддержки достигала 240 человек. Всего через проект за четыре года работы прошло 400 человек. И, на мой взгляд, все это стало возможным именно в таком объеме и с такими показателями именно благодаря использованию SAFe.
В России есть SAFe-комьюнити и, насколько мне известно, к сентябрю 2023 эта методология успешно применяется в нескольких крупных компаниях.
Если резюмировать: планирование большого проекта по разработке может быть большим испытанием. Но хорошая команда и соответствующая дисциплина могут превратить такой проект в увлекательное путешествие и добиться намеченных целей.