Всем привет! Меня зовут Леша. Я работаю в подразделении Альфа-Банка, занимающемся развитием электронных каналов. Интернет- и мобильный банкинг – это все про нас.

Часто, говоря про Scrum, мы подразумеваем одну команду, работающую над одним продуктом и состоящую не более чем из девяти человек. Но иногда продукт бывает настолько сложным, что для его реализации к назначенному сроку девяти человек бывает мало. Что же делать?

Сегодня я хочу рассказать о нашем опыте масштабирования Scrum, когда над одним продуктом работало сразу несколько команд. Как мы до этого дошли и что из этого вышло? Всех заинтересованных прошу под кат.


В настоящее время мы развиваем множество разнообразных продуктов. Здесь можно встретить и крупные монолитные legacy-системы, наследие большого Банка, и инновационные решения, в основе которых лежат современные технологии, такие как блокчейн или технология бесконтактных платежей. Однако большинство продуктов представляют собой веб- или мобильные приложения, позволяющие клиентам пользоваться услугами Банка без необходимости физически посещать его отделения.

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

Постановка задачи

Банком была поставлена задача к указанному сроку сделать новый интернет-банк для клиентов одного из сегментов бизнеса. Конечный продукт должен предоставлять клиентам различные сервисы, такие как выполнение одиночных платежей, групповые операции над платежами, формирование выписки по платежам и прочее. Временные ограничения продиктовали необходимость в распараллеливании работ, поэтому под каждый сервис была сформирована отдельная команда.

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

Реализована низкоприоритетная функциональность

В каждой команде есть продуктолог, у которого есть видение развития своего продукта, отдельного сервиса, входящего в комплексный продукт. Это видение часто ограничено конкретным сервисом. Поэтому функциональность, реализованная к моменту запуска нового интернет-банка, могла быть значима в рамках отдельного приложения, но ничтожна в рамках комплексного конечного продукта.

Функциональность задублирована

И речь больше не о фронте приложений, а о middle-сервисах, вызываемых с фронта. Отправка платежа на исполнение в Банк должна осуществляться по единому алгоритму, независимо от того, происходит она со страницы конкретного платежа или из списка платежей клиента. Иначе конечный продукт будет слишком сложен для сопровождения и развития.

На сопровождение передана только часть комплексного продукта

Одним из требований к передачи продукта на сопровождение является наличие документации на фронт и микросервисы. Описание фронта должно быть приведено на страничке проекта в confluence. Документация на микросервисы должна размещаться рядом с кодом в git.

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

Продукт один, а дизайн разный

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

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

Наше решение

Для предотвращения рисков стали изучать подходы к масштабированию Scrum. Так познакомились с LeSS, в соответствии с которым за несколькими командами закреплен один владелец продукта с единым бэклогом, деятельность команд выровнена по спринтам, а для координации работ устраиваются общие встречи с участием представителей всех команд, участвующих в создании комплексного продукта.

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

Спринт

Команды выровнялись по спринтам. Теперь спринты стартуют одновременно и длятся ровно неделю. Это позволило совместно планировать и контролировать работу над комплексным продуктом.

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

Команды взяли эту задачу в спринт, и в предпоследний день новый дизайн был выкачен в бой сразу для всех приложений. Таким образом, удалось избежать ситуации, когда часть разделов интернет-банка оформлена в новом дизайне, а часть остается в старом.

Планирование спринта

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

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

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

Выполнение работ

Кроссфункциональность в Scrum означает, что в команде есть все необходимые для разработки продукта компетенции. Причем не обязательно, что ими обладаю абсолютно все члены команды. Так в ней может быть только один java-разработчик, и только он может понимать код сервисов, написанных на java. Кто в такой ситуации будет осуществлять ревью его кода?

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

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

Обзор спринта

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

Как известно, все познается в сравнении. Если команда, работая обособленно, не закрывает часть историй, взятых в спринт, это можно объяснить фразой «много взяли». Но если другие команды взяли столько же историй, сравнимых по сложности реализации, и закрыли их все, это повод задуматься над своей производительностью и отношением к делу.

Раз в две недели на общий обзор спринта приглашаются реальные пользователи. Цель такой активности заключается в уточнении потребностей, показе прототипов и получении обратной связи. Все это направлено на то, чтобы сделать конечный продукт наиболее ценным для клиентов Банка.

Ретроспектива

Вопросы межкомандного взаимодействия обсуждаются на общей ретроспективе, которая проводится после командных ретроспектив. Многие полезные решения были приняты именно на ней. Это и определение порядка планирования спринтов, и принятие единого для всех команд DoD, и выработка подхода к получению обратной связи от конечных пользователей нового интернет-банка.

Итого

Можно ли добиться синергии от скоординированной работы нескольких Scrum-команд? Практика показывает, что можно. Мы предотвратили риски, которые могли возникнуть в конце при сборке конечного продукта из нескольких веб-приложений. Мы стали обмениваться знаниями, работать на улучшение не только своего продукта, но и продуктов других команд.

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