Откройте страницу аналитики почти в любом баг-трекере, и вы увидите кучу чисел. Сколько всего заведено задач. Круговая диаграмма по критичности. Среднее время решения. По столбику на каждого исполнителя.
Почти ни одно из них не отвечает на вопрос, который команда задаёт себе в понедельник утром: успеваем мы за багами или отстаём?
У этого вопроса короткий ответ, и для него нужны четыре числа. Ниже — эти четыре числа, популярные метрики, которые незаметно вводят в заблуждение, и пятиминутный еженедельный обзор на их основе. На тех же рассуждениях построена панель пульса, которую я только что добавил над доской BugDump.
Метрики, которые выглядят полезными, но не помогают
Сколько всего багов заведено. Это число только растёт. Число, которое может только расти, говорит о возрасте проекта, а не о его здоровье.
Количество баг-репортов. Отчёты измеряют трафик не меньше, чем качество. Одна сломанная кнопка оформления заказа может за полдня принести сорок отчётов, и это один баг, а не сорок. Если считать отчёты, популярный релиз выглядит катастрофой; если считать баги — обычным вторником.
Баги по критичности в виде круговой диаграммы. Она описывает бэклог, но не подсказывает, что с ним делать. Никто ещё не закрыл ни одного тикета, глядя на круговую диаграмму.
Среднее время исправления. Эта метрика вредит по-настоящему, потому что выглядит строгой. К ней я ещё вернусь.
Общее у них то, что это запасы, а не потоки. Они описывают кучу. Вопросы, которые стоит задавать, — о том, куда эта куча движется и что застряло у неё на дне.
1. Открытый бэклог и куда он движется
Начните с самого простого числа: сколько багов открыто прямо сейчас. В BugDump это все задачи, которые не попали в закрытую колонку.
Само по себе это число мало что значит. Двадцать девять открытых багов — нормально для одной команды и тревожно для другой. Важно направление, а направление — простая арифметика за период:
чистое изменение = открыто багов − решено багов за один и тот же период
Отрицательное значение — бэклог сокращается. Положительное — растёт. Ноль при активности значит, что вы идёте ровно в темпе; ноль без активности значит, что никто ничего не трогал, а это другая ситуация, и ей нужна другая подпись.
Поэтому панель пульса показывает не просто «29 открыто». Она пишет бэклог меньше на 4 за период, бэклог больше на 6 за период, бэклог держится на месте или тихий период, ничего не двигалось. Число даёт масштаб, фраза — направление.
Бэклог, который растёт несколько периодов подряд, редко говорит о продуктивности разработчиков. Почти всегда проблема в разборе: дубликаты не объединяют, решений «исправлять не будем» никто не принимает, и каждый отчёт остаётся в бэклоге навсегда.
2. Исправлено и открыто в сравнении с прошлым периодом
Второе число — сколько багов вы решили за период, рядом с предыдущим периодом той же длины.
Сравнивать с периодом прямо перед текущим, а не со средним за всё время, важно по двум причинам. Так уходит сезонность: тихие праздничные две недели сравниваются с загруженными двумя неделями до них, а не с вашим лучшим месяцем. И на неделях релизов видно, что произошло: релиз, который исправил целую группу багов, виден как скачок, а не как шум.
Ещё лучше смотреть на открытые и решённые на одном графике. В BugDump открытые баги идут над осью, решённые — под ней, а бэклог — линией поверх обоих. Когда две области зеркалят друг друга, вы успеваете. Когда верхняя раз за разом перевешивает, линия ползёт вверх, и видно, в какие именно дни это началось.
3. Медианное время исправления, а не среднее
Время исправления — метрика, которую хочет видеть большинство команд и которую большинство инструментов считает неправильно.
Определение простое: для каждого бага, решённого за период, измерьте время от открытия до решения. Вопрос в том, как свести эти длительности в одно число, и почти никогда это не должно быть среднее.
Допустим, за две недели ваша команда исправила десять багов. Девять — в течение суток. Десятый — баг четырёхмесячной давности, который кто-то наконец закрыл во время уборки, через 120 дней после того, как его завели.
Среднее: (9 × 1 + 120) ÷ 10 = 12,9 дня
Медиана: 1 день
Среднее говорит, что команде нужно две недели на исправление бага. Медиана говорит, что команда исправляет баги на следующий день, и права именно она. Хуже того, среднее наказывает за уборку: неделя, когда вы наконец закрываете древние тикеты, — это неделя, когда среднее выглядит ужасно, и все привыкают древние тикеты не трогать.
Медиана устойчива к такому выбросу, поэтому показывает, что происходит с типичным багом. Именно её панель пульса выводит как Медианное время исправления — в минутах, часах или днях, смотря по масштабу.
У медианы есть одна честная слабость: она учитывает только баги, которые действительно исправили. Баг, который так и не решили, в расчёт не попадает, так что у команды может быть красивая медиана, пока она тихо бросает самые трудные задачи. Для этого и нужно четвёртое число.
4. Самый старый открытый баг
Медиана описывает середину. Самый старый открытый баг описывает хвост, а в хвосте и теряется доверие.
Покажите его возраст прямо рядом с медианой: 5 месяцев, а под ним ID и заголовок. Сделайте его кликабельным, чтобы посмотреть на него можно было в один шаг, без поиска.
Открытый баг пятимесячной давности почти никогда не баг, который никто не смог исправить. Это решение, которое никто не принял. Взгляд на него ведёт к одному из трёх честных исходов:
Исправить, потому что он оказался мелким.
Запланировать, потому что он важен, а им никто не занимался.
Осознанно закрыть с пометкой «не будем исправлять» или «устарело» и объяснить автору отчёта почему.
Любой из трёх лучше четвёртого месяца тишины. А когда самый старый баг разобран, его место занимает следующий, так что это число постоянно подтягивает хвост.
Бонус: откуда приходят отчёты
Четыре числа выше говорят, успеваете ли вы. Они не говорят, почему неделя прошла плохо.
Для этого разбейте отчёты за тот же период по браузеру, операционной системе, типу устройства и странице. Регрессия редко распределяется равномерно. Когда треть отчётов за неделю приходит из Safari на iOS или первая по числу отчётов страница — шаг оформления заказа, выкаченный в четверг, вы нашли причину, не открыв ни одного отчёта.
В BugDump, если развернуть панель пульса, рядом с графиком появляется именно такая разбивка, а страницы отсортированы по числу отчётов. Клик по браузеру, ОС или устройству фильтрует доску, так что от «с Safari что-то не так» до багов в Safari — один клик.
Здесь же считать отчёты, а не баги, — правильное решение. Сорок отчётов об одном баге — сорок точек данных о том, кто на него наткнулся.
Как выбрать период
От периода зависит, что могут рассказать числа, поэтому выбирайте его под вопрос:
7 дней — для недель релизов, когда хотите увидеть эффект деплоя.
14 дней — разумное значение по умолчанию: достаточно долго, чтобы сгладить ежедневный шум, и достаточно коротко, чтобы успеть отреагировать.
30 или 90 дней — для вопросов о трендах и ретроспектив.
Осторожнее с медианой за короткий период на маленьких проектах. Медиана трёх исправлений — факт о трёх багах, а не о вашей команде.
Честно определите, что значит «решён»
Каждая из этих метрик зависит от того, что считается решённым, и именно здесь дашборды врут чаще всего.
Если Готово к QA или Смержено считаются решёнными, медианное время исправления измеряет, как быстро пишется код, а не как быстро пользователи перестают натыкаться на баг. Если Не будем исправлять не считается, бэклог тащит на себе уже принятые решения.
В BugDump баг считается решённым, когда попадает в колонку закрытого типа, а если вынести его оттуда, он снова открывается. Каким бы инструментом вы ни пользовались, проверьте, что его закрытые статусы значат то же, что ваши пользователи назвали бы «исправлено».
Еженедельный обзор за пять минут
Когда эти четыре числа на одном экране, еженедельный обзор багов перестаёт быть встречей и становится чек-листом:
Бэклог сокращается или держится на месте? Если вырос, смотрите, что пришло, а не кто медленно работает.
Решено хотя бы столько, сколько пришло, по сравнению с прошлым периодом?
Сдвинулось ли медианное время исправления? Если подскочило, найдите один-два бага, которые его потянули.
Откройте самый старый баг. Исправьте, запланируйте или закройте с объяснением. Не откладывайте на следующую неделю.
Посмотрите, откуда пришли отчёты. Любой браузер, устройство или страница, на которые приходится намного больше их доли, — это регрессия, пока не доказано обратное.
Вот и весь обзор. Он помещается в стендап, ему не нужна таблица, и он отвечает на единственный вопрос, на который дашборд вообще должен был отвечать.
Читайте также
От 40 отчётов к 6 багам: как должен работать триаж — почему отчёты и задачи стоит разделять и как дубликаты из мусора превращаются в материал для отладки.
Как разбирать баги быстрее: работа с клавиатуры — разбор, в котором время уходит на решения, а не на переходы между экранами.
Уровни приоритета багов: почему четыре фиксированных варианта никогда не подходят — зачем нужна шкала приоритетов, сколько в ней уровней и почему названия должны быть ваши.