В прошлый раз мы закончили историю на том, что придя со сбора жуков с картофельного поля, Григорич наткнулся на статью про баги. Первую реакцию вы помните (кто не помнит, идите почитайте).
“Картошка жареная, отварная, пюре, картофель фри, картофель пай. Картофельные пирожки с мясом, с грибами и так далее. Картофельные оладьи, картофельная запеканка…” - бурчал Григорич, читая статью и попутно комментируя каждую из метрик в “НаЗавалинке”.
Кстати, в компании, опубликовавшей статью про учет жуков, на ниве жукоизведения трудился давнишний приятель Григорича дед Сергеич, с которым было испито немало жидких шпал.
Ниже бурчание Григорича и ответы ему от Сергеича.
Метрика: "Количество заведенных и закрытых дефектов" - без понимания того, какой объем кода появился/изменился или какие задачи решали, бесполезная метрика. Но хороший маркер "обсудить".
Дед Сергеич: - Это про то фиксят или нет, объем кода вторичен тут. Хорошо стреляет на командах которые регулярно делают бизнес-рывочек.
Григорич: - Ну 10 багов на 100 строк и 10 багов на 1000 - это разные 10 багов. Не?
Сергеич: - Неа. Потому что модульность/микросервисы/кафка-мать-её-в-сраку и вот это вот все. Плотность багов на единицу строк кода тогда и сейчас - это арифметически одно и то же , а по природе разные вещи.
"Соотношение дефектов и задач" - очень усредняющая метрика, прям как средняя температура по больнице. Причины слабо диагностируются.
Сергеич: - Это ещё один маркер того, что команда тонет в бизнесовых задачах или успевает выгребать тех долг
Григорич: - или просто код херовый пишет :)
"Количество отмененных дефектов по месяцам для теста и прода" - думаю, зависит от продукта, структуры компании (а-ля тестеры "отдельно" от разработки), модели использования продукта. Спорно. Я бы не считал
"Коэффициент ошибок, пропущенных на прод" - вот кажется, что полезна. А на самом деле скорее для ЧСВ тестировщиков. А польза зависит от модели использования: для SaaS (того софта, что сами менеджерим в проде) важнее скорость обнаружения/отката/зачинки. А вот для On-Premise (разворачивание в среде и силами заказчика) может быть интересна: скорость и возможность применения фикса ограничены.
"Распределение дефектов по приоритетам для теста и прода" - имхо баг надо или чинить, или не чинить. Не очень понимаю этих приоритетов. Но я разраб в прошлом, мне простительно.
Ответ Сергеича "Оно работает в паре - если ты на проде вылавливает больше Critical и Blocker чем на тесте - значит у тебя уже есть проблема."
"Распределение дефектов по категориям для теста и прода" - самая полезная метрика, но самая затратная: требует доп.усилий по классификации категорий, компонентов, коду и установки этого в самом дефекте. Будут просто забиывать, а если установка поля будет форсится, то ставить дефолт в джире или “от балды”.
"Время жизни дефектов, найденных на проде, по приоритетам" - норм
"Время жизни дефектов, найденных на проде или тесте, в разбивке по месяцам для каждого приоритета" - норм, похоже на то, про что я выше писал про скорость скорость обнаружения/отката/зачинки
"Количество Acceptance Bug на задачу" - подсвечивает проблемные задачи: с точки зрения проработки и технического качества кода. Маркер для "обсудить"
__________________
Хмм, ну то есть в целом то, вроде не все так и плохо. Какую-то пользу от учета жуков можно получить.
Вся тонкость в том, как, кто и для чего этими циферками потом пользуется. Если "по людям" считать, то будут "ломать", как и любые другие циферки.
Ну и не надо называть это “качеством” - пробурчал напоследок Григорич, закрыл ноут, снова взял баночку для жуков и пошел оглядывать картофельную делянку, которую не посмотрел с утра.
#григорич #качество #metrics