Про метрики «С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов» Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д. ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии. Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI: — Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели. — Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ? — Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup — Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен. — Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные__ профессионалы.__». Профессионалы найдут выход :) — Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис. — Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать) — Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :) — Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность. И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!
Про метрики «С этого дня мы оцениваем качество QA-команды по количеству…
Из этого канала
- #259Свеженький гайд по безе подъехал
Свеженький гайд по безе подъехал
- #261Казалось бы, причем тут микросервисы. Но если прочитать внимательно…
Казалось бы, причем тут микросервисы. Но если прочитать внимательно определение, сформулированное Мартином Фаулером в 2014-м году…
- #262Давно не писал в канал, не мог найти времени, а все от того, что параллельно…
Давно не писал в канал, не мог найти времени, а все от того, что параллельно работаем над такими вещами, как: - референс-архитектуры, в том числе…
- #257Гипотезу Данбара про 150 контактов опровергли.…
Гипотезу Данбара про 150 контактов опровергли. https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158 Опровержение научное, наборы данных общедоступны.
- #256ECommerce Microservices is a fictional eCommerce, based on different software…
ECommerce Microservices is a fictional eCommerce, based on different software architecture and technologies like Microservices Architecture, Vertical Slice…