Багфиксинг – нудная, но обязательная часть любой разработки, и заниматься ей хотят далеко не все. Как превратить багфиксинг в нечто увлекательное? Устроить соревнование! В этом посте мы подробно расскажем о нашем 24-часовом «багфикс-марафоне» — от предварительной подготовки до разгребания последних коммитов после награждения победителей.
Заражаем идеей
Масштаб разработки нашего приложения Сбербанк Онлайн за последний год заметно увеличился. Вместе с этим начали копиться мелкие баги, которые на ключевых метриках никак не отражались. Но мы понимали, что это бомба замедленного действия и с ней надо что-то делать.
Нас вдохновило, как подобные проблемы решают наши коллеги из Avito, и мы решили организовать массивное наступление на баги в формате багатона — с учетом нашей структуры разработки, культуры и специфики флоу.
Нужно было устроить все так, чтобы ребята сами захотели поучаствовать в багатоне и доказать свою крутость без директив сверху. Для этого у соревнования должна быть классная атмосфера. Решили придумать особенную стилистику, что-нибудь узнаваемое и про баги. Баги — это жуки. Кто в обычной жизни уничтожает жуков? Дезинсекторы — парни в желтых костюмах химзащиты. Где они засветились в последние годы? В одном популярном сериале об учителе химии. Основа есть, допиливаем активностями. Организовали турнир по видеоиграм, викторину с призами, прикольные индивидуальные номинации… и конечно, много вкусной еды. Но главное, как ни крути, соревнование по ликвидации багов. Об этом напоминал дэшборд с веб-интерфейсом, показывающий прогресс команд, их текущие позиции, количество баллов и т.п. Обсудили все с тимлидами — они наши планы одобрили.
Android vs iOS — так нечестно
Сначала мы хотели столкнуть Android-разработчиков Сбербанк Онлайн с их iOS-коллегами, сыграть на соперничестве платформ. Но в процессе организации поняли, что это не лучшее решение, потому что технически платформы работают в неравных условиях. Так сложилось, что на iOS у нас быстрее собираются билды и прогоняются автотесты.
Тогда мы изменили формат и сделали смешанные команды: по пять Android- и iOS-разработчиков в каждой. Предварительно из числа проактивных разработчиков выбрали капитанов, чтобы они помогали формировать команды. Получилось девять команд. И несмотря на то, что мы разобрались с вопросом железа с точки зрения fair play, нужно было еще убедиться, что на пути нашей армии багфиксеров не встанут другие ограничения.
Следующим квестом стал выбор даты багатона. Даты релизов у каждой из платформ разные — подбирали так, чтобы всем было удобно. Старались, чтобы дата была максимально близка к дате, когда отводят релиз-кандидата.
Кроме того, багатон сильно нагружает инфраструктуры платформ. Когда идет соревнование, кто быстрее пофиксит баги, количество пулл-реквестов взлетает. Еще за полтора месяца до багатона был риск, что наше оборудование не справится с прогнозируемыми пиками. Но в тот момент мы ожидали новое железо, и оно подъехало как раз вовремя. Мы успели все подключить, настроить и усилить пропускную способность инфраструктуры обеих платформ в несколько раз.
Пайплайн — как не спустить все в трубу
Здесь сделали все следующим образом: непосредственно перед началом багатона от нашего develop’а мы отвели ветку, в которой командам предстояло работать. В нее во время багатона заливалась куча пулл-реквестов с исправленными багами. На каждом из них прогонялись автотесты, разработчики ревьюили пулл-реквесты, а тестировщики проверяли новые сборки на исправление бага. И так все 24 часа соревнования.
Также нужно было распределить нагрузку тестировщиков. Мы составили почасовой график прогнозируемого количества пулл-реквестов в 24-часовом интервале багатона — в зависимости от количества участников, нагрузки на сервера, сторонних активностей и т.д. Сопоставили со средней производительностью тестировщиков и количеством эффективных часов работы каждого сопровождающего багатон. Распределили «дежурства» так, чтобы к утру субботы очереди были как можно меньше. В общем, заморочились.
При этом учли, что после багатона нужно было сразу начинать регрессионное тестирование, чтобы как можно быстрее оценить качество ветки и принять решение о ее вливании в dev-ветку. Это дополнительная нагрузка на тестировщиков.
Особенности ревью
Для нас очень важно было не просто пофиксить баги, а сделать это качественно. Три процедуры обеспечивают проверку кода, отправляемого разработчиками в пулл-реквестах. Чтобы код заапрувили, они должны пройти успешно:
- три опытных разработчика просмотрели и одобрили код;
- код нормально сбилдился и не провалил автотесты;
- после билда и вливания баг в сборке на описанных условиях не возобновляется.
Мы опасались, что в соревновательном режиме никто не будет ревьюить друг друга. А внутри команды оставлять ревью нельзя. Поэтому решили ничего не изобретать и действовать по стандартному флоу, как в рабочем режиме: произвольное кросс-ревью — кто свободен, тот и берет процесс на себя.
Еще нужно было отслеживать, чтобы ревью не собирались в очередь. Чтобы перестраховаться, мы привлекали к ревью синьоров (даже тех, кто не участвовал в самом багатоне) и активно напоминали участникам об ориентации на качество. Один синьор-разработчик iOS параллельно с фиксом багов для своей команды за день проревьювил 80 пулл-реквестов — вчитывался, разбирался. Это реально много!
Отбираем и оцениваем баги
Мы взяли баги с низким приоритетом, по лейблам и датам отсеяли очевидный мусор. Всего получилось 490 багов — в основном маленькие и средние, до которых не доходили руки из-за более важных задач. Это все вменяемые тривиалы и миноры:
- баги, которые многократно переезжали из версии в версию
- баги, заведенные по обращениям пользователей
- свежайшие крэши
- баги регресса
- баги, которые влияют на UX
Все баги распределили на три волны по приоритетности закрытия:
- Первая волна — около 230 багов
- Вторая волна — около 150 багов
- Третья волна (запасная) — около 110 багов
Дефекты оценивались не по сложности, а по критичности для бизнеса. Самые критичные мы «искусственно» и временно перевели в приоритет «блокер» и «критикал». Чем выше приоритет бага, тем больше за него начислялось баллов. Сложность при этом не учитывалась — бывало, что баг-блокер закрывался за 20 минут, а тривиал – за 4 часа. За один баг можно было заработать от 1 до 7 баллов.
Счет каждой команды мы вели по закрытым багам согласно их стоимости в правилах багатона. Если у команд оставалось время, они брали в работу следующий дефект. Мотивация через стоимость позволила закрыть в первую очередь более критичные баги.
Как закрывали баги
Первую волну багов мы поделили на 11 групп (с запасом), равных по количеству баллов и по соотношению Android и iOS. Первая волна — это «дорогие» баги, приоритетные, с повышенной стоимостью. Для удобного поиска в Jira мы назначили им соответствующие лейблы. Вышло примерно по 20 багов в каждой группе.
В начале багатона мы собрали капитанов команд и разыграли лейблы. Дальше капитаны у себя в фильтре обозначали нужный лейбл и распределяли соответствующие баги внутри команды. Так удалось исключить хаотичный багфиксинг, где ребята бы попросту брали что для них понятнее.
Первые четыре часа командам начислялись очки только за баги с лейблами выпавшей им группы, чтобы задать определенный ритм. Когда время истекло, по-прежнему открытые баги перешли во вторую волну, дополнив другие, которые имело смысл закрывать в рамках багатона.
К 19:00 все незакрытые баги перешли в третью волну — в дополнение к тем багам, что уже были там запланированы. В итоге на вечер у нас остались «быстрые» баги, которые закрылись бы в обычном флоу: крэши и текущие, выгруженные буквально за день до багатона, а также баги с самым низким приоритетом. В работу пошли все три волны. В итоге за багатон закрыли 286 из 493 выделенных багов.
Багатон объединяет
Штаб багатона разместился в нашем конференц-зале, там же проходили викторины и турнир по видеоиграм. Команды не были ограничены, разбегались куда им удобно. В итоге о багатоне узнал весь банк. Один продакт-оунер с четвертого этажа рассказывал: «Иду я на встречу по 14-му этажу, ищу нужную переговорку. Вдруг понимаю, что только что видел знакомые лица, возвращаюсь — мои разрабы сидят фигачат вовсю, а на меня ноль внимания. Ха — думаю — от своего продукт-оунера и за 10 этажей не спрячутся, ладно, сидите уж, багфикс — дело правое».
Была команда, в которой на багатон пришел только один Android- и при этом шесть сильных iOS-разрабов. Мы в исключительном порядке выбили этой команде другой пакет с iOS-багами.
Кроме того, на багатон приехали семь разработчиков из регионов. Некоторые первый раз встретились со своими командами, с которыми раньше виделись только по видеоконференцсвязи. Было очень круто наблюдать, как эти ребята активно влились в процесс.
Как оценивали результаты
На почти сотню разработчиков у нас было всего 15 тестировщиков. А ночью и вовсе четверо. На все их не хватало, поэтому тестирование продолжили на следующий день. Именно тестировщики начисляли баллы командам, так что мы вывели их из состава команд, чтобы исключить предвзятость. В обычном рабочем процессе тестировщик может позвонить разработчику и узнать: «Слушай, чувак, тут такая проблема…». На багатоне было строго: тестировщики должны заворачивать все, что четко не проходит.
Так мы смогли увидеть, что некоторые разработчики работают не в принятом флоу. Хакатон стал своеобразным катализатором всех отклонений. Те, кто работает четко по флоу, успели пройти тестирование в первой волне и получить баллы. Все, кто не очень соответствовал, попали в очередь, которую уже разгребали после багатона. В ней набралось 60 багов.
Инциденты
В целом все прошло в штатном режиме, инциденты были типовые и устранялись в рабочем порядке. Когда что-то ломалось, некоторые синьоры сразу переключались с багфикса на устранение инцидента.
Был один забавный случай. Когда готовили дэшборд, мы расписали возможные риски: доступы в Jira, раскатка обновлений и т.д. Уведомили всех администраторов, что на время багатона нужно приостановить все профилактические работы, обновления Jira и серверов. Создали резервные учетные записи для доступа к Jira. И вдруг около 18:00 понимаем, что дэшборд перестал собирать данные. Предположения были разные. Может не учли какой-то протокол безопасности? Причина оказалась неожиданной. Организация у нас очень большая, получить полную информацию обо всех запланированных процессах удается не всегда. Наш дэшборд был развернут на виртуалке на одном из второстепенных серверов. Оказалось, что именно в этот день, вечер пятницы, именно этот сервер по неизвестному нам плану был физически отключен от розетки, погружен в машину и отправлен на ПМЖ в наш новый дата-центр. В итоге к утру субботы нам пришлось собирать все данные и рассчитывать баллы в ручном режиме.
Мердж веток и другие итоги
В обычном рабочем режиме вся ветка прогоняется вручную по 800+ тест-кейсам. Полная команда тестировщиков делает у нас штатное регрессионное тестирование за две недели. Мы не могли позволить себе так долго держать develop без изменений. Чтобы сократить время тестирования, выбрали основные тест-кейсы работоспособности приложения – порядка 107. До конца понедельника прогнали 80% iOS, 50% Android и ни одного критичного бага не выявили. Решили, что ветки можно сливать.
Из 286 багов, закрытых на багатоне, 182 бага были исправлены. Остальные — это реджекты, не актуальные по разным причинам баги (где-то уже успел измениться дизайн или функционал). Эти баги не критичны, но зато на них теперь не нужно будет отвлекаться и можно спокойно фокусироваться на важных задачах.
Также у многих по итогам багатона возник вопрос: а сколько багов мы внесли? Всего восемь багов на iOS и семь багов на Android.
Для нас важно, чтобы разработчики чувствовали ответственность за код продукта наравне с другими членами команды. Это важно в любой разработке, но в разработке распределенной это становится необходимым условием для успешной работы. И на наш взгляд, нам удалось повысить уровень той самой сопричастности и командный дух. В результате получилась история с кучей профита: в сжатые сроки мы пофиксили кучу багов, разгрузили бэклоги, прокачали командные навыки и получили массу фана.
Материал подготовлен командой Digital Business Platform Сбербанка
Автор: Sberbank
