Багодельня — марафон по убийству престарелых багов

    Сколько открытых багов у вас в бэклоге? 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%) всего за один день. У нас это мероприятие взлетело только благодаря мотивированным ребятам, которые болеют за продукт и заботятся о счастье наших пользователей.



    Всем добра и меньше багов!

    Авито

    361,98

    У нас живут ваши объявления

    Поделиться публикацией
    Комментарии 43
      +4
      Зачем же так загонять людей, чтобы у них не было хотя-бы 5-6 часов в неделю на исправление багов хотя-бы в той функциональности, которую они сами породили?
      И еще, у вас все на ноутбуках работают? Будет у вас команда сутулых ребят скоро…
        +7
        И еще, у вас все на ноутбуках работают?


        Я думаю, это потому, что они не на своих привычных рабочих местах с мониторами. Отцепили буки от них и принесли в переговорку с собой, дело обычное.
          –3
          А когда ноутбук подключается к монитору, в него мы больше не смотрим что-ли?
          И чего все минусят? Объясните в чём я не прав…
            +3
            Ноутбук на рабочем месте подключается к монитору (опционально двум) кто-то использует сам ноутбук кто-то нет, дело каждого. Кто не хочет сидеть сгорбившись за ноутбуком вполне может этого не делать.
              0
              Сейчас существуют doc-станции, в которые можно вставить ноутбук, а потом подключить уже к этой станции мониторы, клавиатуру и мышь. Например, image
                0
                обычно не смотрят, да, подключают клавиатуру и рабоают как со стационартным
            +2
            Зачем же так загонять людей

            К сожалению, на исправление всех багов не хватает времени.


            Я думаю, это потому, что они не на своих привычных рабочих местах с мониторами

            Да, верно.

              +15
              Но у них не хватает времени потому, что компания не дает им этого времени! Мне кажется, это отжимание сотрудников в чистом виде. Сначала давайте работайте как угорелые, да так чтоб у вас времени не было даже не исправление багов, а потом давайте еще за день исправьте багов сколько сможете и получите мягкую «чтобы это ни было» на ленточке за свои труды. То есть, вместо того, чтобы нанять немного больше людей, которые бы разгрузили разработчиков, лучше устроить им тест-драйв по исправлению дефектов, которые вообще не должны копиться, при чем в таком темпе можно и еще выродить несколько новых.
              Но зато вы прекрасно спонсируете иностранных владельцев.
              Я не пытаюсь дерзить или хамить, это скорее попытка разобраться чего можно ожидать от работы в такой компании, как Авито.
                +2
                Приведите пример компании в которой нету пары тысяч багов в беклоге ;)
                  –1
                  В компании, название которой вам все равно ничего не скажет, где я работаю, в QC висит аж 5 багов в трекере, которые ожидают ответа от других команд, бизнес отдела и тп., то есть численность открытых багов и никем не обработанных, стремится к нулю. Я думаю, тут в первую очередь играет роль то, как организован процесс разработки. У нас, как только баг появляется, тот, кто разрабатывал — в течении недели его и правит. Для этого выделяется время специально. А если ты багов не плодишь — пожалуйста, время твоё, иди пей кофе.
                    0
                    А если ты багов не плодишь — пожалуйста, время твоё, иди пей кофе.
                    Как вы сказали, ваша компания называется?
                    +5
                    Стартап, у которого бэклог ещё не вырос? :))
                      +1
                      Организация, у которой 16 тыс корпоративных клиентов и 1400 человек в IT отделе. Все у нас выросло, потому и процесс налажен. И еще управленцы хорошие, денег не жалеют на нормальную технику и сотрудников нанимают достаточно, чтобы работники от дедлайнов невыполнимых не страдали.
                      +1
                      Открытых? И как оно живёт? В системе, которая стоит на многих сотнях рабочих мест у большого количества клиентов открытых тикетов на программиста или тестера с десяток, причём часть из них — «у нас тут идея, но мы не знаем зачем оно нам и что это даст клиенту». Потому КТТС. Или ждут поставки оборудования под задачу. Часть активных с разным приоритетом. Тикеты бывают разные — может быть «поправить сообщение в отчёте», а может быть «реализовать приложенное масштабное ТЗ», которое потом может разделиться на группу тикетов по задачам, а может и нет.
                      Там тысячи за годы работы, но тысячи открытых — это какой-то сюрр.
                  +12

                  А вы не пробовали в обязательном порядке добавлять в спринты время на исправление багов?

                    0
                    Мне кажется, 3 фидбэка из 4х отвечают на этот вопрос. Всегда есть мелочь, на которую нет времени, но ее хочется поправить.
                      +1
                      Идея отличная, но не для всех команд применима. Реальность такова, что для многих быстрая доставка важных фич приоритетнее исправления сразу всех багов.
                        0

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

                      0
                      Отличная идея! Нужно предложить Баготон руководству — ведь это сразу несколько зайцев убивает: закрывает баги, улучшает качество продукта, мотивирует и сплочает команду, да и вообще весело!
                        –7
                        Похоже на субботники в СССР. Некоторым нравится коллективный труд во благо…
                        А первая фотка ужасна, если честно. Смертная казнь в 21 веке — это варварство, ужасный акт насилия.
                          +11

                          Чего вы накинулись-то? Команды по исправлению багов работали в РАБОЧИЙ ДЕНЬ!
                          Т.е. специально выделили один рабочий день на фикс багов. Мне кажется это хороший подход. Когда перманентный цейнтнот в виде "если мы исправим этот баг — нам это не принесёт денег! Забейте!" — то бэклог реально растёт как не знаю кто.
                          А здесь специально выделяют день на фикс багов. Это конечно не совсем то, чтобы брать в спринт баги, но тоже очень крутая тема. Ну конечно на мой взгляд человека, который устал видеть огромный бэклог на который "у нас нет времени!".

                            +1
                            Просто смешно, что фикс багов представлен ну прям как «мероприятие», «соревнование» и аж целый ивент. Людям дали 1 раз в чёрт-знает сколько времени не писать быстрый говнокод, а поработать как люди, разгрести проблемы.
                            +2
                            Как можно пофиксить трудновоспроизводимый баг?
                            Ну вот правда — его же нужно сперва увидеть?
                            Вот у меня есть тикет «Device hangs over weekend» — это тестеры оставляют его работать на выходные, приходят, а устройство висит.
                            Ну сделали они мне этот тикет, а что там на самом деле происходит — да ктож его знает…
                              0
                              Дату/время сдвинуть не пробовали?
                                –1
                                Нет, не пробовал и не буду. Это что-то с железом — там специфичный микрокомпьютер, что-то или с драйверами или с АПИ, которое плохо документированно, но используется методом проб и ошибок.
                                0
                                Ставится на пару дней стенд в рабочее время (викенд — два дня), он двое суток пашет, плюёт непонятный лог, но примерно понятно где. Улучшаем логирование (если лог понятен, то это уже не непонятный баг), ставим снова. И так несколько недель (повисание раз в неделю в среднем), находим что ускоряет повисание в процессе и вот виновник найден и исправлен (или сделан обход, если виновник — компонент другого производителя, используемый и без аналогов — потому незаменим). Так тоже получается и в данном случае «багодень» ничего не даст.
                                –1
                                Ага, только починят самые простые баги. На лицо попытка очень весело задорно со смузи прикрыть проблемы в организации процесса разработки.

                                И я искренне не понимаю, как можно делать что-то разумное за ноутбуками с такими маленькими экранами.
                                  0

                                  А от чьего лица статья? Почему где-то разработчики это «мы», а в абзаце про подарки это «они»?


                                  Я не придираюсь, просто хочу уточнить

                                    +1
                                    Статья от лица организатора, относящегося к команде разработки и тестирования)
                                    +3

                                    Люто возопил от одного названия — "багодельня"! Плюсанул уже только за это. А тут и еще сама идея оказалась творческой — ввести соревновательный элемент в достаточно унылый процесс разгрёба багов. ОК, пусть идея не новая, но ругать ссср'овские субботники могут только те, кто ни на каких не был. Там обычно бывает весело ;)

                                      0
                                      В вопросе дебагинга важно не столько время, сколько мотивация.
                                      Если с унылым лицом и мыслями исправлять баг, то на его исправление условно уйдет 1 час. И настроение ниже плинтуса.
                                      А если в азартном соревновательном порыве решать проблему, то уйдет условно 15 минут.
                                        0
                                        И потом ещё несколько часов на разгребание побочек, которые обязательно проявятся спустя какое-то время, т.к. в соревновательном угаре совершенно забыл о косвенных зависимостях, державшихся на этом баге.
                                        0
                                        Самое интересное — как попытаться донести идею о чем-то подобное в своей компании и встретить одобрение команды? -_-
                                          0

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

                                            0
                                            Все зависит от мотивации вашей команды) Попробуйте просто закинуть идею, выслушайте мнения.
                                              0
                                              Если учесть, что мотивация персонала — это искусство… Скорее всего мотивация будет нулевой или отрицательной.
                                            +2

                                            Мне интересно где и как они исправляли баги? Ну вот какоц продукт у вас, в котором можно отдельно от других отделов разработки самому что-то исправить?


                                            Всем раздали исходники проекта и они на нем фиксили баги? Мне интересна техническая основа самого багфикса и его проверки.

                                              0

                                              Можно разобраться со своим участком ответственности и передать задачу смежникам…
                                              [например](https://yandex.ru/search/?text='схема решения любой проблемы' )

                                                +1
                                                Разработчики исправляют баги в своей платформе и, отправляя исправление на ревью, добавляют тех, кто ответственен за задетый код.
                                                0
                                                А мне больше всего интересно сколько новых багов появляется при таком подходе.
                                                  +1
                                                  В статье есть упоминание про это:
                                                  «А теперь ответ на самый каверзный вопрос, который все любят задавать: «А сколько новых багов вы посадили?».
                                                  Ответ: не больше 2% от всех обработанных.»
                                                  0
                                                  Когда наша команда практиковала скрам, мы на ретроспективе договорились что в каждый спринт обязательно втягиваем 3 бага из бэклога + правим асапом все баги, которые делаем во время спринта. В целом идея оказалась удачной но были некотрые особенности:
                                                  • Общее число багов не сильно уменьшалось, т.е отношение прироста багов к их сокращению менялось очень слабо. Почему? Просто находились какие-то новые баги, про которые до этого никто не знал + баги от спринтовых задач, упущенные во время спринта
                                                  • Не всегда ошибка правится быстро, поэтому было введено правило что если какой-то из багов превышает время работы в 1 день, то мы переносим его в тех. работу
                                                  • Также не стоит забывать что баги могут терять свою актуальность со временем, например, кто-то во время рефакторинга мог его случайно пофиксить, поэтому QA должен актуализировать и приоритезировать баги в бэклоге
                                                    +1
                                                    Как вариант можно использовать zero-tolerance политику в отношении багов и чёткое разделение на баги и на фичи (улучшения). В этом случае команда не разрабатывает новый код, пока все баги (может быть за исключением трудновоспроизводимых и Low) не закрыты. Улучшения же идут напрямую в бэклог и там ждут своего часа. (При этом если какой-либо функционал меняется в рамках задачи, то выбираются все фичи связанные с ним и реализуются, если это возможно).
                                                    Это конечно замедляет процесс разработки, но зато улучшает качество продукта и повышает удовлетворёность пользователей от продукта.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое