Раньше наша команда собиралась с определенной периодичностью (обычно раз в 2 недели) и оценивала баги. Приходили менеджер, QA-лид и лид-разработки. Встреча занимала 0.5 - 1 ч. Не всегда успевали все оценить и хвост неоцененных тасок тянулся, и даже что-то терялось. Однажды нашего менеджера осенило оценивать баги через телеграм бота, чтобы (1) в моменте знать насколько критичный баг, (2) не тратить время на встречу и (3) оценивать в любой момент времени. В итоге, запилили логику по схеме:
Создаем багу в трекере
Трекер вызывает тг-бота
Тг-бот отправляет в чат нотификацию "Проставить важность багу" со ссылкой на баг и призывает 3-амиго (менеджер, разраб и тестер)
3-амиго реплаят сообщение бота цифрами от 1 до 100, где 1 - блокер, 100 - когда-то однажды поправим.
После того как оценку проставили все амиго бот находит среднее и проставляет багу важность. Кстати, есть опция - если хотя бы один оценщик поставил оценку и отправил реплай "стоп", то бот берет имеющиеся оценки, находит среднее и проставляет багу важность.
В трекере ранее создали фильтр куда попадают таски отсортированные по важности.
Что вышло
Из плюсов:
Мы избавились от неоцененных багов,
В канале обсуждаем почему такая оценка, влияние и т.п. Кстати, из-за обсуждений сокращалось кол-во оцененных багов во время встречи.
Сэкономили ~2 ч. в месяц :),
Фичу начали использовать другие команды, а еще экономия времени (супер!)
Кстати, кто-то из команд начал использовать тг-уведомления, как нотификацию о заведенных багов.
Из минусов:
Столкнулись с проблемой, что в потоке нотификаций теряются таски на оценку или кто-то из амиго не проставляет важность, а значит снова не оцененные таски :(
Не подумали, что должна быть возможность переоценивать багу, пока не проставили оценку.
Что делаем дальше
Чтобы не терять оценки сделаем фичу, которая будет каждый день в заданное время собирать тг-ссылки на неоценные баги и скидывать подборку в канал.
По багам, которые оценили не все амиго тоже уведомляем, но в заданное время ежедневно брать имеющиеся оценки и проставлять.
Дать возможность переоценивать баги, пока кто-нибудь не отправил стоп или не проставили все оценки.
И как говорится "на правах рекламы" подписывайтесь на мой тг-канал "Тестировщик", делитесь бустами и оставляйте комментарии :)
Комментарии (15)
icya
22.06.2024 10:14+4А можете раскрыть выводы хотя бы в грубом приближении:
сколько багов оценивали тогда и сейчас
на сколько изменилась точность оценки
как размазали 6 чел/часов (ну не может оценка в тг стоить ничего)
Sovetkali Автор
22.06.2024 10:14Сейчас ~75-80% заведенных багов за день оцениваются. Оставшийся хвост хотим править ежедневными напоминания о неоцененных/недооцененных багах. Про ранее заведенные сложно сказать. Точнее так - мы в любом случае оценивали бэклог, но были боли. Первоочередная проблема была в том, что мы долго оценивали (т.е. не блокеры и криты (которые на грани блокера) ждали своего часа на встрече) и, конечно же, встречи не хватало, чтобы оценить по максимуму.
Точность у нас не хромает. Жалоб не было, поэтому не замеряли)
Как не звучало по дилетантски, но действуем по ощущениям. Т.е. каждый оценщик оценивает по мере возможности. Жалоб на то, что занимает много время не поступало. Ощущения пока такие, что команде удобнее оценивать в течение дня или даже дней (призывы ведь никуда не деваются из канала)
dopusteam
22.06.2024 10:14+2Сэкономили ~2 ч. в месяц :),
А как вы сэкономили время? Раньше было
" (обычно раз в 2 недели) ... Встреча занимала 0.5 - 1 ч", т.е. примерно 2 часа.
А теперь получается вы вообще перестали время тратить?
Раньше вы целенаправленно могли собраться и оценить, застолбив заранее время у каждого сотрудника. А теперь сообщения прилетают в рандомное время и отрывают от работы?
В итоге кто то может быть занят, кто то не ответит, кто то не захочет обсуждать, ну и т.д.
Можете в абсолютных числах поделиться цифрами, сколько багов в день заводится?
Sovetkali Автор
22.06.2024 10:14Надо признать формулировка слишком оптимистичная и не отражает реальность в том плане, что время мы, конечно же, тратим. Но тратим уже не на встрече и не откладываем оценку до митинга. Не замеряли потраченное время (но думаю ради интереса посмотрим) после введения новой схемы.
Наш бот имеет логику, которая учитывает занятость. Т.е. если оценщик в отпуске, болеет и т.п., его не призываем, а также в выходные дни. Кстати, поднимался вопрос не призывать во время дежурства. Тут еще думаем как улучшить.
По поводу потерянных тасок, как писал в посте, мы дорабатываем логику по которой каждый день собираем скоуп неоценнеых/недооцененных тасок и просим оценить. Частично оцененные бот оценивает автоматически по расписанию.
dopusteam
22.06.2024 10:14Вы всё ещё не делитесь абсолютными цифрами :(
Не получается ли так, что проблему нужно решать в другой плоскости, например, не оценивать больше, а разобраться откуда столько багов берётся, что вы не успеваете их оценивать.
2 часа в месяц, это примерно 6 минут в день, не проще ли после дейли остаться на 6 минут, обсудить новые баги и в моменте выяснить их приоритет.
Ну и странно, что для оценки приоритета нужно собирать какое то невероятное количество людей.
pv_belov
22.06.2024 10:14Почему не научите тестировщиков расставлять приоритеты и серьезность для багов? освободите менеджера, лидов и того кто бота пилит и поддерживает и избавите проект от лишних телодвижений
Sovetkali Автор
22.06.2024 10:14Наше тестирование проставляет приоритеты. А бот проставляет важность :) Плюс не всегда тестировщик, или какой-либо другой участник команды, может знать все о значимости для бизнеса или пользователя, и поэтому оценивают разные участники команды (и выводим среднее).
Пилит бота тестирование)
dkfbm
22.06.2024 10:14+2Наше тестирование проставляет приоритеты. А бот проставляет важность :) Плюс не всегда тестировщик, или какой-либо другой участник команды, может знать все о значимости для бизнеса или пользователя
Простите, а как такое может быть? Приоритет зависит от важности для бизнеса и более ни от чего. Если тестировщик её оценить не в состоянии, как он(а) может проставить приоритет? Да и вообще: если не может, то это плохой тестировщик. То, что проверяемо независимо от важности для бизнеса, должно покрываться автотестами, а QA нужны именно для проверок соответствия бизнес требованиям и экспертной оценки юзабилити.
Конечно, люди ошибаются - но в норме любой тикет, прежде чем уйти в работу, проходит через тимлида, и мониторится ПМ - кто-то да поправит приоритет.
ozzyBLR
22.06.2024 10:14+1Красивый замок из песка, который нужно успеть показать всем, пока он не рассыпался)
Вопрос, который уже накинули здесь и он остался без ответа, это замена выделенного слота на "ещё одно уведомление, на которое нужно ответить". Раньше у трёх амиго был один одинаковый слот. Сейчас амиго всё равно должны находить время, но теперь уже "кто когда сможет".
Далее, а есть ли смысл в "непрерывной" оценке багов через бота? Что с ними дальше происходит? Разработка может сразу брать их в работу? Или всё же есть некий буфер, он же бэклог, который наполняется и оттуда забираются задачи в замисимости от срочности? Если второе, то в чём выигрыш?
Ещё я не заметил упоминания классического фоксу оценивания: если есть хотя бы две сильно отличающиеся оценки, эта задача/баг оценивается отдельно. Потому что это признак некого понятийного разрыва в команде. А тут просто считается среднее.
И это подводит нас к последней мысли. Шакала от 1 до 100? Серьёзно? Кто-то понимает "в граммах" разницу между 60 и 61? Какие у вас в принципе значения приоритетов в тасктрекере?
manyakRus
22.06.2024 10:14+1https://github.com/ManyakRus/telegram_loki
У нас ещё проще:
Телеграм бот присылает ошибки со всех микросервисов в один чат,
в итоге:
1) не надо следить (искать) за ошибками
2) все ошибки быстро находятся и исправляются
3) не осталось ни одной ошибки теперь уже :-)
остались ошибки типа как бы предупреждения
vilgeforce
по оценкЕ
Sovetkali Автор
Спасибо. Поправил