Кейс Сбербанк Онлайн: как за сутки багатона мы исправили в 7 раз больше багов, чем обычно

Привет, меня зовут Игорь Дюканов, я работаю в Сбербанке в команде, которая занимается развитием Сбербанк Онлайн.

В конце августа мы провели большой внутренний марафон по исправлению багов в нашем мобильном приложении — багатон.

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

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

Результаты оказались достойными: участники за сутки закрыли 286 багов, из которых были исправлены 182 бага, а остальные переведены в реджект по разным причинам (где-то уже изменился дизайн, где-то — функционал).

Предыстория

Сначала мы планировали устроить состязание разработчиков iOS против Android на скорость и качество исправления багов — выбрали концепцию борьбы «сноубордистов против лыжников». Ведь условное противостояние этих платформ всегда есть и будет, и это бы добавило азарта участникам. В процессе выяснилось, что сталкивать две платформы нельзя, потому что у них различается скорость сборки проектов и прохождения автотестов на серверах — борьба была бы неравной. Тогда мы решили организовать совместную работу разработчиков обеих платформ, чтобы уравнять шансы на победу. А заодно чтобы ребята смогли обменяться лучшими практиками с теми, с кем обычно редко пересекаются. В итоге у нас получилось соревнование нескольких смешанных команд: по пять разработчиков iOS и Android в каждой команде. Победят те, кто закроет больше всех багов. Мы понимали, что это экспериментальный формат и он может вызвать не самую лучшую реакцию у комьюнити. Все-таки две разные платформы – две разные планеты. Так что все нужно было тщательно продумать и предусмотреть.

Организация

Мы хотели сделать именно общебанковский багатон, поэтому активно привлекали разработчиков не только из нашего подразделения, но и из других. А еще по максимуму собрали ребят из регионов – такие есть во многих командах.

Участников мы группировали заранее, чтобы не тратить на это время на площадке. И чтобы заранее настроить систему подсчета баллов, так как она привязана к аккаунтам разработчиков: это тоже занимает немало времени. Сначала мы отобрали капитанов из числа желающих проактивных разработчиков. В их задачи входило формирование команды, а также координация участников и общение с организаторами во время багатона.

На мероприятие выделили сутки: с 10.00 утра пятницы по 10.00 утра субботы. Решили так сделать из технических соображений. Нам важно было не просто пофиксить баги, а сделать это качественно. Мы долго прорабатывали, как будет выстроен процесс. Решили, что от нашей рабочей ветки отведем копию и на ней будем проводить багатон. А чтобы не тормозить day-by-day процессы, в субботу и до вечера понедельника тестировщики проведут сокращенное регрессионное тестирование (тестирование работоспособности приложения по основным пользовательским сценариям). По его итогам сможем оценить качество ветки и риски слияния обратно с основной рабочей веткой, которая за это время претерпит минимальные изменения.

Как мы сортировали баги

Отобранные нами мелкие баги можно разбить на более или менее значимые. К багатону мы отсортировали их по датам и по типам, разбили на три волны согласно внутренним приоритетам. Оценивать команды мы решили не багами, а баллами. Чем важнее исправление ошибки для работы приложения, тем больше за него начисляется баллов. Чтобы было интереснее решать задачи, внутри первой волны мы также сделали «искусственную» приоритизацию. Потому что если они все находятся на двух уровнях и за них начисляется мало очков, то какая тогда мотивация? Ребята просто бы хаотично брали те баги, которые более понятны. Нам же нужно было в первую очередь исправить определенные ошибки (регресса и обращений).

Всего получилось 490 багов. Мы в случайном порядке распределили их на пакеты по количеству потенциальных команд, в каждом из которых было по 20 дефектов. И присвоили им кодовые лейблы, чтобы с ходу не было понятно, где и что. Так мы получили пакеты с приоритетными для нас багами, выровненные по стоимости баллов и по платформам. В пакете можно было заработать одинаковое количество баллов как ребятам из платформы iOS, так и из Android.

Breaking Bugs

Одной из основных задач было совместить пользу и развлечение. Мы понимали, что нужна интересная визуальная концепция и стилистика в привязке к багфиксу. Зачастую с этого начинается восприятие любого мероприятия. Что делать? Bug - он же жук (англ.). А кто в обычной жизни приходит на помощь в борьбе с жуками? Тут сразу же возник образ дезинсектора… типа чувак в желтом комбинезоне и в респираторе травит баги. Где мы такое видели? В одном популярном криминальном сериале об учителе химии. ;) Решили замиксовать код, баги и сериал.

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

Чтобы создать запоминающиеся образы, на наклейках, футболках и других материалах мы разместили специально отрисованных Саввой героев сериала и отвлеченных персонажей по нашей теме. Самым ярким получился образ по типу главного героя сериала. Изображение с ним также сопровождалось надписью «I am the one who knocks the bugs out». Еще мы нарисовали дэшборд для отслеживания прогресса команд и создали канал в мессенджере. Для канала были придуманы прикольные стикерпаки с символикой багатона.

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

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

Викторины придумали, чтобы участники могли размять мозги. Выбрали сервис, который позволяет, открыв страницу браузера прямо со смартфона, в режиме реального времени отвечать на вопросы. Сначала была пробная викторина – чтобы показать, как это работает, и заодно проверить, что все поняли только что рассказанные правила багатона. Вечером была большая викторина. Ее мы решили сделать из трех блоков: вопросы по Android, по iOS и по сериалу. Она длилась 20 минут. Однозначно помогал коллективный разум: далеко не все знали ответы на вопросы по «не своей» платформе и не все смотрели сериал.

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

Финал

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

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

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

Ещё одна номинация – «Строгий учитель химии» по мотивам того же сериала. В ней мы отметили лучших ревьюеров. Ревьюить код необходимо, чтобы проверить его на предмет ошибок. Поэтому хотелось отметить тех, кто провел больше всех ревью запросов на изменение кода на своей платформе.

Последняя и, на мой взгляд, самая важная номинация была для тестировщиков. Они не участвовали в соревновательной части. Но от них многое зависело — они именно функционеры, ключевой механизм багатона. Их труд мы тоже отметили в нашем стиле: если разработчики образно у нас дезинсекторы, которые уничтожают баги, то тестировщики, которые в багах разбираются и проверяют на наличие, – образно энтомологи. И выбрали «Лучшего энтомолога».

Выводы

Итого почти половина из двухсот мобильных разработчиков приняла участие в багатоне. Когда у вас большая разработка, то не исключено, что не все знают друг друга в глаза. А еще есть коллеги, которые работают в других городах. Мы активно работали над тем, чтобы на багатон приехали ребята из региональных подразделений. Помимо вклада в чистоту кода Сбербанк Онлайн, разработчикам удалось классно провести время, пообщаться, обменяться полезным опытом как между командами, так и между платформами iOS и Android. Этот багатон помог нам сблизить ребят и даже познакомить между собой тех, кто работал над схожими задачами, но не знал о существовании друг друга.

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

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