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