Всем привет! Меня зовут Лёша.
Я работаю в подразделении Альфа-Банка, которое занимается развитием электронных каналов.
Интернет и мобильный банкинг – это все о нас.
Часто, когда мы говорим о Scrum, мы имеем в виду одну команду, работающую над одним продуктом и состоящую не более чем из девяти человек.
Но иногда продукт настолько сложен, что девяти человек не хватает, чтобы реализовать его к назначенному сроку.
Что делать?
Сегодня я хочу рассказать о нашем опыте масштабирования Scrum, когда над одним продуктом работали сразу несколько команд. Как мы дошли до этого и что из этого вышло? Прошу всех желающих под кат. 
В настоящее время мы разрабатываем множество различных продуктов.
Здесь можно найти и крупные монолитные унаследованные системы, и наследие крупного Банка, и инновационные решения, основанные на современных технологиях, таких как блокчейн или технология бесконтактной оплаты .
Однако большинство продуктов представляют собой веб- или мобильные приложения, которые позволяют клиентам пользоваться услугами Банка без необходимости физического посещения его филиалов.
Основной боевой единицей нашего подразделения является коллектив, работающий над созданием и развитием конкретного продукта.
Большинство команд являются кросс-функциональными и живут по Scrum, что позволяет им самостоятельно организовывать и осуществлять свою деятельность.
И эта независимость сохранялась до тех пор, пока мы не поняли, что наши продукты взаимосвязаны и мы делаем не просто отдельные приложения, а комплексные решения, предоставляющие клиентам широкий спектр услуг.
Постановка задачи Банк поставил задачу к указанному сроку создать новый интернет-банк для клиентов одного из сегментов бизнеса.
Конечный продукт должен предоставлять клиентам различные сервисы, такие как проведение разовых платежей, групповые операции по платежам, формирование платежных ведомостей и т. д. Ограничения во времени диктовали необходимость распараллеливания работы, поэтому для каждого сервиса была сформирована отдельная команда.
В Scrum команды независимы и самостоятельно определяют длину спринта, его цель и список историй, которые необходимо закрыть для получения инкремента.
Независимость, в свою очередь, может повлечь за собой ряд рисков.
Реализована функциональность с низким приоритетом
В каждой команде есть специалист по продукту, у которого есть видение развития своего продукта — отдельной услуги, входящей в комплексный продукт. Это видение часто ограничивается конкретной услугой.Поэтому функционал, реализованный к моменту запуска нового онлайн-банка, мог быть значительным в рамках отдельного приложения, но незначительным в рамках сложного конечного продукта.
Функционал дублируется
И мы говорим уже не о фронте приложений, а о мидл-сервисах, вызываемых с фронта.Отправка платежа на исполнение в Банк должна осуществляться по единому алгоритму, независимо от того, происходит ли это со страницы конкретного платежа или из списка клиентских платежей.
В противном случае конечный продукт будет слишком сложен для поддержки и развития.
На поддержку передана только часть сложного продукта
Одним из требований передачи продукта на сопровождение является наличие документации по фронтенду и микросервисам.Описание фасада должно быть дано на странице проекта в слиянии.
Документацию по микросервисам следует размещать рядом с кодом в git. Над новым интернет-банком работали пять команд. Две группы вели документацию в соответствии с требованиями функциональной поддержки.
Остальные решили хранить всю документацию в git, включая документацию по фронту.
Решение разумное, но оно может привести к трудностям при передаче некоторых приложений на обслуживание.
Тот же продукт, другой дизайн
В каждой команде есть дизайнер, который отвечает за внешний вид приложения.Поэтому, даже если между дизайнерами существуют определенные договоренности на момент сборки конечного продукта из отдельных приложений, могут обнаружиться несоответствия в используемых командами компонентах, шрифтах, отступах и т.п.
Команды работают слаженно уже несколько месяцев.
Однако несоответствия все равно выявляются в процессе рассмотрения проекта и оперативно устраняются.
Трудно представить, какая нагрузка легла бы на команды, если бы обо всех неточностях мы узнали в самом конце при сборке нового интернет-банка.
Наше решение Чтобы предотвратить риски, мы начали изучать подходы к масштабированию Scrum. Так мы познакомились с LeSS, согласно которому за несколькими командами закреплен один Product Owner с единым бэклогом, деятельность команд выстраивается в спринты, а для координации работы проводятся общие собрания с участием представителей всех команд. участие в создании сложного продукта.
Конечно, у каждого есть свои особенности, и полученный LeSS в чем-то отличается от фреймворка, описанного на официальном сайте.
Но мы не стремились к идеальному совпадению.
Важно было наладить слаженную работу нескольких команд над одним продуктом.
И вот что из этого вышло.
Спринт
Команды сравнялись по спринтам.Теперь спринты стартуют одновременно и длятся ровно неделю.
Это позволило совместно планировать и контролировать работу над сложным продуктом.
Одной из задач, с которой столкнулись все команды, стал переход приложений на новый дизайн.
Раньше главное меню было сверху, а фон приложения был серым.
В целевом состоянии меню расположено в левой части экрана на белом фоне.
Команды взяли эту задачу в спринт, и в предпоследний день новый дизайн выкатили сразу на все приложения.
Таким образом, нам удалось избежать ситуации, когда некоторые разделы интернет-банка выполнены в новом дизайне, а другие остаются в старом.
Планирование спринта
Продуктовые команды консолидировали свои очереди и выполнили сквозную приоритезацию историй.Обзор единого отставания и обновление приоритетов происходит еженедельно перед планированием спринта.
Это снижает риск того, что команды будут работать над историями с низким приоритетом как частью сложного продукта.
После обновления приоритетов владельцы продуктов разбиваются на команды, где совместно определяют цель и планируют следующий спринт. Более того, команды берутся за истории только под свои приложения, что позволяет им сохранять и накапливать экспертизу в конкретном сервисе конечного продукта.
Процесс завершается общим совещанием по планированию, на котором представители команды намечают список историй, которые они планируют взять в спринт. Формулируется общая цель спринта, после чего команды приступают к работе.
Выполнение работ
Кросс-функциональность в Scrum означает, что команда обладает всеми компетенциями, необходимыми для разработки продукта.При этом не обязательно, чтобы ими обладали абсолютно все члены команды.
Таким образом, Java-разработчик может быть только один, и только он сможет понять код сервисов, написанный на Java. Кто будет проверять его код в такой ситуации? Раньше написанный код часто проверяли разработчики, не погруженные в проект. Теперь в обзорах кода участвуют разработчики команд, работающих над одним сложным продуктом.
Они знакомы с его особенностями и нюансами, что позволяет говорить об улучшении качества кода, раннем обнаружении ошибок и предотвращении дублирования функций.
Взаимодействие наблюдается по всем функциям.
Автоматизаторы проверяют автотесты.
Аналитики договорились о едином формате проектной документации.
Дизайнеры работают вместе, чтобы согласовать внешний вид своих приложений.
Все это направлено на улучшение качества конечного продукта.
Обзор спринта
Свой вклад в создание сложного продукта команды видят на общем обзоре спринта, когда каждая команда демонстрирует другим, чего они достигли за спринт. Как известно, все познается в сравнении.Если команда, работая изолированно, не закрывает некоторые истории, снятые в спринте, это можно объяснить фразой «взяли много».
Но если другие команды взяли такое же количество историй, сопоставимых по сложности реализации, и закрыли их все, это повод задуматься об их продуктивности и отношении.
Раз в две недели реальных пользователей приглашают на общий обзор спринта.
Цель этого мероприятия — уточнить потребности, показать прототипы и получить обратную связь.
Все это направлено на то, чтобы конечный продукт был максимально ценным для клиентов Банка.
Ретроспектива
Вопросы межкомандного взаимодействия обсуждаются на общей ретроспективе, которая проводится после командных ретроспектив.Там было принято много полезных решений.
Сюда входит определение порядка планирования спринта, принятие единого DoD для всех команд и разработка подхода к получению обратной связи от конечных пользователей нового интернет-банка.
Общий Можно ли добиться синергии от слаженной работы нескольких Scrum-команд? Практика показывает, что это возможно.
Мы предотвратили риски, которые могли возникнуть в итоге при сборке конечного продукта из нескольких веб-приложений.
Мы начали обмениваться знаниями и работать над улучшением не только своего продукта, но и продуктов других команд. Конечно, есть и минусы — команды утратили часть самостоятельности, увеличилось количество встреч, отвлекающих участников от разработки продукта.
Но в целом преимущества сотрудничества перевешивают недостатки.
Поэтому, если у вас есть несколько Scrum-команд, работающих над связанными продуктами, не бойтесь координировать их деятельность.
Возможно, слаженная работа принесет им дополнительную выгоду, а вашим клиентам дополнительную ценность.
Теги: #Управление продуктами #работа в команде #Альфа-Банк #Управление продуктами #Управление персоналом
-
Щепка Во Flutter, Или Как Работает Прокрутка
19 Oct, 24 -
Windows Vista Перегрузит Систему Dns
19 Oct, 24 -
Уборка Снега? Без Проблем
19 Oct, 24 -
Прилетел Нло И Удалил Эту Тему Здесь
19 Oct, 24
