Как превратить рутинную задачу по исправлению мелких багов в увлекательную? Провести багатон! 300 ошибок разобрали за 25 часов. Участники спали меньше обычного, но все остались довольны, а некоторые даже укатили домой на новеньких электросамокатах.
Рассказываем, как это было, за что пришлось оштрафовать команду-победителя и какой вопрос организаторам задавали чаще всего.
О чем речь
Ошибки неизбежны и присутствуют во всех без исключения цифровых продуктах. Критичные и важные для бизнеса исправляют незамедлительно, а мелкие и незначительные баги копятся в ожидании, когда у команды дойдут до них руки.
В результате бэклог забивается, и чтобы разбирать его было не в тягость, а в радость, в крупных IT-компаниях проводят багатоны — конкурсы по исправлению багов. Помимо очевидной пользы исправления накопившихся ошибок, участники лучше узнают системы компании, знакомятся друг с другом да еще и призы выигрывают.
У любой крупной организации в бэклоге накапливается техдолг. В выбранных на багатон системах он состоял преимущественно из мелких ошибок UI и неактуальных дефектов. Подобные мероприятия – возможность подчистить дефекты, исправить массу незначительных ошибок.
Павел Наумов, Исполнительный Вице-Президент Газпромбанка:
Багатон стал отличной площадкой как для команд-участников, так и для владельцев продуктов. Всего за два дня ребята смогли устранить те недочеты, которые накопились во время активной работы над запуском новых дистанционных каналов банка и развитием сервисной цифровой платформы. При этом участники получили уникальный опыт, более глубокое знакомство с другими системами и классные призы. Уверен, что мы будем повторять такие активности в будущем — иногда нам всем необходимо уйти от рутины, поиграть и посоревноваться. А устранение мелких багов напрямую влияет на использование сервисов нашими клиентами, а значит в выигрыше мы все.
Организовать первый багатон в Газпромбанке было классной, но сложной задачей со множеством звездочек, — вспоминает Алина Романовская, начальник Центра по развитию и продвижению технологических сообществ. — Но многие из ребят, которые выступили в роли экспертов, ревьюеров, участников жюри, говорили, что их драйвит сама идея мероприятия и они очень хотят, чтобы всё получилось. И всё получилось!
Работа над ошибками
Главные действующие лица багатона, конечно, участники, но немалая работа предстояла организаторам. Подготовкой технической части занималась команда разработки, тестирования и DevOps.
Эксперты отобрали 300 багов из разных команд и сервисов продуктовых команд всех Value Stream банка. Большинство ошибок, взятых на багатон, были связаны с Мобильным банком, Интернет-банком и Сервисной цифровой платформой. Последняя представляла наибольший интерес.
Сервисная цифровая платформа — это программно-аппаратный комплекс, который дает возможность продуктовым командам, используя готовые сервисы, библиотеки, инфраструктуру и практики, развивать продукты и размещать их в любом из цифровых каналов банка.
Платформа Газпромбанка включает в себя современный стек разработки, микросервисную архитектуру и производительный кэширующий слой на базе NoSQL базы данных Tarantool, благодаря чему в банке могут горизонтально масштабировать сервисы с ростом нагрузки.
Большая часть багов, отобранных на платформе, тоже была связана с интернет- и мобильным банкингом, но касались не фронтенда, а бэкенда. Кстати, с тем, чтобы собрать ошибки платформы, возникли сложности — у каждого сервиса на ней свой владелец, и с каждым из них договаривались отдельно.
Также организаторы багатона сделали дашборд мероприятия, на котором участники видели доступные для исправления баги и, конечно, могли в режиме реального времени отслеживать рейтинг команд.
Как всё это было
Мероприятие решили делать гибридным: онлайн и офлайн. Как правило, багатон проходит в формате марафона, поэтому участникам важно минимально отвлекаться на сон и еду. Для ребят из московского офиса, помимо питания, организовали удобное место с пуфами, а для тех, кто решал баги онлайн, разослали промокоды, чтобы обед или ужин можно было заказать домой.
Всего в багатоне участвовали 67 разработчиков и тестировщиков из 18 городов, которые объединились в 14 команд. 80% из них подключились к соревнованию онлайн.
Все баги участники видели на дашборде. Ошибки делились на три категории: ошибки Мобильного банка (iOS/Android), Интернет-банка и Сервисной цифровой платформы. Участники выбирали те баги, которые казались им наиболее интересными, назначали их себе и ставили метку своей команды.
Для каждой команды действовало правило: один разработчик — одна ошибка в работе. После исправления дефекта разработчик указывал в задаче номер сборки, куда попало исправление бага, и переводил ее на тестировщика. Тестировщик команды проводил ретест и, если всё ок, закрывал ошибку. Дашборд автоматически пересчитывал исправленные ошибки в баллы и обновлял рейтинг команд.
Правило «количество багов в работе равно количеству разработчиков» было нужно для того, чтобы команды не могли набрать себе ошибки про запас, а значит, у всех были равные условия по их выбору.
Организаторам было важно, чтобы всё прошло честно. Поэтому в преддверии мероприятия нужно было придумать, как обмануть нашу систему подсчета результатов. Гипотез было множество: от заранее исправленных ошибок до смены приоритетов для получения большего количества баллов.
В результате на базе EazyBI реализовали несколько дашбордов. Они индикативно показывали, были ли изменения приоритетов ошибок и превышался ли лимит багов на одного человека. Также дашборд следил за тем, чтобы в выбранном скоупе ошибок не появилось ничего лишнего.
При этом наблюдательность самих участников работала ничуть не хуже: они пристально следили за тем, чтобы другие команды не читерили. Именно благодаря внимательности одного из участников выявили нарушение правил. Команда, в которой это произошло, получила штраф — минус один балл. Но (спойлер) всё равно победила.
Дело в том, что у команды-нарушительницы и у той, что в итоге заняла второе место, на финише после штрафа оказалось одинаковое количество баллов — по 94. И чтобы определить победителя, жюри анализировало работу обеих команд.
Вопрос стоял так: что важнее — количество или критичность исправленных ошибок? В итоге оштрафованная команда оказалась впереди по количеству как багов в целом, так и критичных ошибок — ровно на одну больше в каждой категории.
Победа и участие
В первом багатоне Газпромбанка победила команда «Карамельки» — за 25 часов ребята пофиксили 50 багов. Правда, позже признались, что почти не спали, но такую стратегию выбрали осознанно. Каждый из них получил главный приз — игровую приставку Sony PlayStation.
Второе место заняла команда Payment_Hub, которая провела в офисе всю ночь и исправила всего на одну ошибку меньше — 49. Ее участники стали обладателями электросамокатов. А команда «Тест_на_проде», которая решила 30 багов, была рада гиковским клавиатурам Ducky One 3 Mini.
Неизвестно, какой подарок будет востребован больше, но кажется, что все были довольны.
Александр Черушников, Вице-Президент, начальник Департамента инженерной экспертизы и инструментов разработки:
Никто не любит исправлять баги, и такое мероприятие как багатон позволяет, с одной стороны, выделить время на эту задачу, с другой, продвинуть среди разработчиков «правило Бойскаута» — оставь после себя код лучше, чем он был. Данное правило — часть нашей инженерной культуры, которую мы активно развиваем в Газпромбанке.
Кстати, решение не делать денежные призы было неслучайным. Организаторы хотели, чтобы участники боролись именно за подарок, а не за деньги. Приставка и самокат приносят яркие эмоции и лучше соответствуют настроению багатона, который объединяет развлечение и высокотехнологичность.
В общем, в банке не прогадали — борьба была жаркой. И да, подарок получил каждый участник команды. Забавно, что самым популярным оказался вопрос, придется ли делить приз.
Участники, которые зарегистрировались самостоятельно, были рады познакомиться с коллегами после того, как организаторы объединили их в команды. После мероприятия все обменивались впечатлениями и рассказывали, что хотели в атмосфере соревнования сделать полезное: не только почистить бэклог, но лучше узнать, как работают другие команды, пофиксить дефекты, до которых в рамках спринтов никогда не доходило дело.
Читать первым в Telegram-канале «Код Дурова»
