Сколько открытых багов у вас в бэклоге? 100? 1000?
А сколько времени они там лежат? Неделю? Месяц? Годы?
А почему так происходит? Нет времени? Надо делать более приоритетные задачи? «Вот сейчас все срочные фичи реализуем, а потом точно будет время на разгребание багов»?
… Некоторые используют Zero Bug Policy, у кого-то хорошо развита культура работы с багами (своевременно актуализируют бэклог, пересматривают ошибки при изменении функциональности и т.д.), а кто-то выращивает волшебников, которые пишут вообще без багов (маловероятно, но, может, и такое бывает).
Сегодня я расскажу вам про наше решение по чистке бэклога багов — проект «Багодельня».
С чего все началось?
В очередной раз просматривая все увеличивающийся бэклог по открытым багам, мы дошли до точки кипения. Жить так дальше было нельзя, решили сокращать его любой ценой. Идея очевидная, но как это сделать? Сошлись на том, что самым эффективным способом будет мероприятие, похожее на хакатон: оторвать команды от повседневных задач и выделить 1 рабочий день на обработку только багов.
Прописали регламент, кинули клич и стали ждать. Были опасения, что желающих будет мало, очень мало, но результат превысил наши ожидания — записалось целых 8 команд (правда, в последний момент 3 слились). На мероприятие выделили целый рабочий день в пятницу, забронировали большую переговорку. Обеды организовали на базе офисной столовой, для перекусов добавили печеньки.
Реализация
Утром в день Х собрали всех желающих в переговорке и провели краткий брифинг.
Основные правила:
- в одной команде сражается от 2 до 5 человек, минимум один из них — QA;
- баги должны закрываться членом команды по всем внутренним продакшн-стандартам;
- у каждой команды должен быть как минимум один закрытый баг, требующий исправлений в коде;
- исправлять можно только старые баги (дата создания бага < даты начала багодельни — 1 месяц);
- за исправленные баги баллы (от 3 до 10) начисляются в зависимости от критичности (чтобы не было читерства, нельзя менять критичность после анонсирования даты проведения Багодельни);
- за закрытие неактуальных, невоспроизводимых багов начисляется по 1 баллу;
- за соблюдением всех правил следит команда аудита, которая аннулирует очки за переоткрытые баги.
Другие детали
- Мы никого не ограничивали в выборе локации: можно было оставаться на рабочем месте или сидеть со всеми в переговорке, в которой ребят не отвлекали и чувствовался накал страстей.
- Чтобы поддержать соревновательный дух, на большом экране была выведена рейтинговая таблица, а в slack-канале постоянно шла текстовая трансляция боя. Для подсчета очков использовали лидерборд, который обновлялся через вебхуки.
Лидерборд
- За соблюдением всех правил следила команда аудита (по опыту, для этого достаточно 1-2 человек).
- Через час после окончания Багодельни были объявлены перепроверенные результаты.
Победители получили подарочный сертификат в бар, а все участники — памятную сувенирку (брелоки с «багами»).
Результаты
За последние полгода мы провели уже три Багодельни. Что же мы в итоге получили?
- Среднее количество команд — 5.
- Среднее количество обработанных багов — 103.
- Среднее количество неактуальных/невоспроизводимых багов — 57% (а ведь этот мусор постоянно мозолил глаза и пугал своим количеством).
Момент объявления результатов
А теперь ответ на самый каверзный вопрос, который все любят задавать: «А сколько новых багов вы посадили?».
Ответ: не больше 2% от всех обработанных.
Отзывы
После проведения Багоделен мы собирали фидбэк с участников. Вот ответы на вопрос «Что больше всего понравилось в процессе участия?»:
- Очень круто разбирать бэклог с такой мотивацией! Обычно это очень унылый процесс, надо проводить такое периодически).
- Азарт, печеньки.
- Это долгожданная возможность поправить те мелочи, которые не критичны, но править хочется.
- Понравилось, что можно, наконец, пофиксить старые, неприятные баги вне спринта, на такие никогда не будет времени т. к. всегда будут задачи с более высоким приоритетом. Удалось собрать в одном месте всех нужных людей (в нашей команде был dba, например), коллективно обсудили актуальность поставленных багов и техническую возможность их поправить.
Заключение
Багодельня — не панацея, но вполне жизнеспособный вариант уменьшения бэклога багов (в разных командах от 10 до 50%) всего за один день. У нас это мероприятие взлетело только благодаря мотивированным ребятам, которые болеют за продукт и заботятся о счастье наших пользователей.
Всем добра и меньше багов!
Комментарии (41)
J_eve Автор
22.03.2018 15:45+2Зачем же так загонять людей
К сожалению, на исправление всех багов не хватает времени.
Я думаю, это потому, что они не на своих привычных рабочих местах с мониторами
Да, верно.
aPiks
22.03.2018 17:05+5Но у них не хватает времени потому, что компания не дает им этого времени! Мне кажется, это отжимание сотрудников в чистом виде. Сначала давайте работайте как угорелые, да так чтоб у вас времени не было даже не исправление багов, а потом давайте еще за день исправьте багов сколько сможете и получите мягкую «чтобы это ни было» на ленточке за свои труды. То есть, вместо того, чтобы нанять немного больше людей, которые бы разгрузили разработчиков, лучше устроить им тест-драйв по исправлению дефектов, которые вообще не должны копиться, при чем в таком темпе можно и еще выродить несколько новых.
Но зато вы прекрасно спонсируете иностранных владельцев.
Я не пытаюсь дерзить или хамить, это скорее попытка разобраться чего можно ожидать от работы в такой компании, как Авито.
DragonFire
22.03.2018 22:58Приведите пример компании в которой нету пары тысяч багов в беклоге ;)
aPiks
23.03.2018 01:57В компании, название которой вам все равно ничего не скажет, где я работаю, в QC висит аж 5 багов в трекере, которые ожидают ответа от других команд, бизнес отдела и тп., то есть численность открытых багов и никем не обработанных, стремится к нулю. Я думаю, тут в первую очередь играет роль то, как организован процесс разработки. У нас, как только баг появляется, тот, кто разрабатывал — в течении недели его и правит. Для этого выделяется время специально. А если ты багов не плодишь — пожалуйста, время твоё, иди пей кофе.
Femistoklov
23.03.2018 15:27А если ты багов не плодишь — пожалуйста, время твоё, иди пей кофе.
Как вы сказали, ваша компания называется?
shogunkub
23.03.2018 09:38+5Стартап, у которого бэклог ещё не вырос? :))
aPiks
23.03.2018 12:51+1Организация, у которой 16 тыс корпоративных клиентов и 1400 человек в IT отделе. Все у нас выросло, потому и процесс налажен. И еще управленцы хорошие, денег не жалеют на нормальную технику и сотрудников нанимают достаточно, чтобы работники от дедлайнов невыполнимых не страдали.
ToshiruWang
23.03.2018 13:42+1Открытых? И как оно живёт? В системе, которая стоит на многих сотнях рабочих мест у большого количества клиентов открытых тикетов на программиста или тестера с десяток, причём часть из них — «у нас тут идея, но мы не знаем зачем оно нам и что это даст клиенту». Потому КТТС. Или ждут поставки оборудования под задачу. Часть активных с разным приоритетом. Тикеты бывают разные — может быть «поправить сообщение в отчёте», а может быть «реализовать приложенное масштабное ТЗ», которое потом может разделиться на группу тикетов по задачам, а может и нет.
Там тысячи за годы работы, но тысячи открытых — это какой-то сюрр.
Finesse
22.03.2018 16:28+7А вы не пробовали в обязательном порядке добавлять в спринты время на исправление багов?
SkuFu
23.03.2018 11:19Мне кажется, 3 фидбэка из 4х отвечают на этот вопрос. Всегда есть мелочь, на которую нет времени, но ее хочется поправить.
J_eve Автор
23.03.2018 14:16+1Идея отличная, но не для всех команд применима. Реальность такова, что для многих быстрая доставка важных фич приоритетнее исправления сразу всех багов.
Finesse
23.03.2018 15:56В скраме есть одно правило. Обязательно должно выделяться время для улучшения взаимоотношений в команде, условий труда и прочих вещей, призванных сделать разработчиков счастливее. Если баги беспокоят разработчиков, то их можно чинить как раз в это время. Если баги никого не беспокоят, то тогда вообще нет проблемы.
zenkz
22.03.2018 16:53-1Отличная идея! Нужно предложить Баготон руководству — ведь это сразу несколько зайцев убивает: закрывает баги, улучшает качество продукта, мотивирует и сплочает команду, да и вообще весело!
rule
22.03.2018 16:58-3Похоже на субботники в СССР. Некоторым нравится коллективный труд во благо…
А первая фотка ужасна, если честно. Смертная казнь в 21 веке — это варварство, ужасный акт насилия.
janson
22.03.2018 18:52+1Чего вы накинулись-то? Команды по исправлению багов работали в РАБОЧИЙ ДЕНЬ!
Т.е. специально выделили один рабочий день на фикс багов. Мне кажется это хороший подход. Когда перманентный цейнтнот в виде "если мы исправим этот баг — нам это не принесёт денег! Забейте!" — то бэклог реально растёт как не знаю кто.
А здесь специально выделяют день на фикс багов. Это конечно не совсем то, чтобы брать в спринт баги, но тоже очень крутая тема. Ну конечно на мой взгляд человека, который устал видеть огромный бэклог на который "у нас нет времени!".tangro
23.03.2018 15:41+1Просто смешно, что фикс багов представлен ну прям как «мероприятие», «соревнование» и аж целый ивент. Людям дали 1 раз в чёрт-знает сколько времени не писать быстрый говнокод, а поработать как люди, разгрести проблемы.
nckma
22.03.2018 19:37Как можно пофиксить трудновоспроизводимый баг?
Ну вот правда — его же нужно сперва увидеть?
Вот у меня есть тикет «Device hangs over weekend» — это тестеры оставляют его работать на выходные, приходят, а устройство висит.
Ну сделали они мне этот тикет, а что там на самом деле происходит — да ктож его знает…ToshiruWang
23.03.2018 13:47Ставится на пару дней стенд в рабочее время (викенд — два дня), он двое суток пашет, плюёт непонятный лог, но примерно понятно где. Улучшаем логирование (если лог понятен, то это уже не непонятный баг), ставим снова. И так несколько недель (повисание раз в неделю в среднем), находим что ускоряет повисание в процессе и вот виновник найден и исправлен (или сделан обход, если виновник — компонент другого производителя, используемый и без аналогов — потому незаменим). Так тоже получается и в данном случае «багодень» ничего не даст.
Naglec
23.03.2018 00:21-1Ага, только починят самые простые баги. На лицо попытка очень весело задорно со смузи прикрыть проблемы в организации процесса разработки.
И я искренне не понимаю, как можно делать что-то разумное за ноутбуками с такими маленькими экранами.
flancer
23.03.2018 10:55+3Люто возопил от одного названия — "багодельня"! Плюсанул уже только за это. А тут и еще сама идея оказалась творческой — ввести соревновательный элемент в достаточно унылый процесс разгрёба багов. ОК, пусть идея не новая, но ругать ссср'овские субботники могут только те, кто ни на каких не был. Там обычно бывает весело ;)
Dart_Zaiac
23.03.2018 11:18В вопросе дебагинга важно не столько время, сколько мотивация.
Если с унылым лицом и мыслями исправлять баг, то на его исправление условно уйдет 1 час. И настроение ниже плинтуса.
А если в азартном соревновательном порыве решать проблему, то уйдет условно 15 минут.ITurchenko
23.03.2018 14:34И потом ещё несколько часов на разгребание побочек, которые обязательно проявятся спустя какое-то время, т.к. в соревновательном угаре совершенно забыл о косвенных зависимостях, державшихся на этом баге.
ranfree4ka
23.03.2018 11:18Самое интересное — как попытаться донести идею о чем-то подобное в своей компании и встретить одобрение команды? -_-
izuware
23.03.2018 13:45Какая нибудь третья Пятница Весны, обычный график до обеда. Далее все домой. Ну кроме тех кто замотивирован поскорее подавить клопов ) Вопрос что важнее, чистый код или возможно безлюдный офис.
J_eve Автор
23.03.2018 13:51Все зависит от мотивации вашей команды) Попробуйте просто закинуть идею, выслушайте мнения.
Daniil1979
23.03.2018 19:40Если учесть, что мотивация персонала — это искусство… Скорее всего мотивация будет нулевой или отрицательной.
smidl
23.03.2018 11:18+2Мне интересно где и как они исправляли баги? Ну вот какоц продукт у вас, в котором можно отдельно от других отделов разработки самому что-то исправить?
Всем раздали исходники проекта и они на нем фиксили баги? Мне интересна техническая основа самого багфикса и его проверки.
izuware
23.03.2018 14:03Можно разобраться со своим участком ответственности и передать задачу смежникам…
[например](https://yandex.ru/search/?text='схема решения любой проблемы' )
Solkin
23.03.2018 15:40+1Разработчики исправляют баги в своей платформе и, отправляя исправление на ревью, добавляют тех, кто ответственен за задетый код.
snaumov
23.03.2018 13:39А мне больше всего интересно сколько новых багов появляется при таком подходе.
J_eve Автор
23.03.2018 13:41+1В статье есть упоминание про это:
«А теперь ответ на самый каверзный вопрос, который все любят задавать: «А сколько новых багов вы посадили?».
Ответ: не больше 2% от всех обработанных.»
aPiks
Зачем же так загонять людей, чтобы у них не было хотя-бы 5-6 часов в неделю на исправление багов хотя-бы в той функциональности, которую они сами породили?
И еще, у вас все на ноутбуках работают? Будет у вас команда сутулых ребят скоро…
JC_IIB
Я думаю, это потому, что они не на своих привычных рабочих местах с мониторами. Отцепили буки от них и принесли в переговорку с собой, дело обычное.
aPiks
А когда ноутбук подключается к монитору, в него мы больше не смотрим что-ли?
И чего все минусят? Объясните в чём я не прав…
RedRover
Ноутбук на рабочем месте подключается к монитору (опционально двум) кто-то использует сам ноутбук кто-то нет, дело каждого. Кто не хочет сидеть сгорбившись за ноутбуком вполне может этого не делать.
AngelZeruel
Сейчас существуют doc-станции, в которые можно вставить ноутбук, а потом подключить уже к этой станции мониторы, клавиатуру и мышь. Например,
zzzzzzzzzzz
обычно не смотрят, да, подключают клавиатуру и рабоают как со стационартным