Аналитика багов в JIRA с помощью SQL. Часть I
Аналитику багов в JIRA предлагаю начать с рассмотрения простого кейса №1:
Узнать долю трудозатрат, которая приходится на исправление багов в проекте
Кейс №1
Баги на проектах разработки ПО всегда были, есть и будут. Порой, когда баги или долго не появляются или их найдено крайне мало, мне как менеджеру даже как-то не по себе. Закрадывается подозрение, что с quality assurance что-то не так. Но вот несколько багов обнаружены тестировщиками — значит все в порядке :).
Почти уверен, что в ваших моделях управления в багтрекерах для фиксации багов используется тип запроса Bug. Если при этом разработчики и тестировщики отмечают ворклоги в запросах данного типа, то появляется замечательная возможность отследить долю трудозатрат на исправление багов относительно общих трудозатрат на проекте. Это отличная аналитика, которая расширит проектный lessons learned. Ключевая важность данного показателя — понимание того какой резерв закладывать на исправление багов в дальнейшем при планировании очередной версии или похожего проекта. Данный показатель — подходящее оправдание заложенным резервам на исправление багов. Такой подход намного серьезнее чем взятая с потолка цифра. В серии похожих проектов, в которых мне приходилось участвовать, данный показатель был приблизительно на уровне 20-25%. Зная этот показатель, я умножаю оценки исполнителей соответственно на коэффициент 1.2-1.25. И это один из факторов, который позволяет не промахнуться со сроками (нужно учитывать еще и управленческий резерв). При этом и для участников упрощается процесс оценки. Они оценивают задачи без учета времени на исправление багов.
Рассмотрим фрагмент модели данных JIRA, который понадобится для создания SQL-запросов:
Необходимо использовать данные из 3-х таблиц: JIRAISSUE, PROJECT, ISSUETYPE.
Напомню, что таблица JIRAISSUE — это ключевая таблица, в которой содержится информация про все запросы существующие в JIRA. PROJECT — это таблица, содержащая список всех проектов JIRA. Она необходима для фильтрации запросов по наименованию проекта. Каждый запрос в таблице JIRAISSUE содержит ссылку на проект. Ссылка хранится в поле JIRAISSUE.project.
ISSUETYPE — это словарь типов запросов. Данная таблица необходима, чтобы отфильтровать запросы с типом Bug. Каждый запрос содержит идентификатор типа, который хранится в поле JIRAISSUE.issuetype.
Выполните предварительно следующий запрос, чтобы узнать полный список типов запросов существующий в вашей JIRA.
SELECT * FROM [issuetype]
В результате вы увидите результат похожий на такой список:
Выполним соединение трех таблиц используя оператор JOIN:
SELECT ji.* from project p join jiraissue ji on (ji.project = p.id) join issuetype it on (it.id = ji.issuetype) where ji.project = p.id and p.pkey = 'DEMO' and it.pname in ('Bug')
Запрос читается следующим образом «Выбрать все запросы с типом Bug в проекте DEMO». Это очень распространенный шаблон для написания более сложных запросов, который будем использовать в новых кейсах.
Обязательным правилом при создании SQL-запросов является присваивание алиасов для каждой используемой таблицы. Алиасы указывася сразу после названия таблицы. В нашем случае были присвоены алиасы P, JI, IT. В дальнейшем при обращении к полям таблиц необходимо использовать алиас, например ji.project. Такой подход гарантировано позволит избежать возможных коллизий в случае одинакового наименования полей в разных таблицах.
Фактические трудозатраты по запросу хранятся в таблице JIRAISSUE в поле timespent. Нужно учитывать, что значение указывается в секундах. Для того, чтобы перейти к часам, необходимо разделить timespent на 3600. Получаем следующую редакцию нашего основного запроса:
SELECT ji.timespent/3600 from project p join jiraissue ji on (ji.project = p.id) join issuetype it on (it.id = ji.issuetype) where ji.project = p.id and p.pkey = 'DEMO' and it.pname in ('Bug')
Последнее что остается сделать — это воспользоваться агрегирующей функцией SUM, чтобы просуммировать все трудозатраты по всем багам. Итак:
SELECT SUM(ji.timespent/3600) from project p join jiraissue ji on (ji.project = p.id) join issuetype it on (it.id = ji.issuetype) where ji.project = p.id and p.pkey = 'DEMO' and it.pname in ('Bug')
Общие трудозатраты на проекте можно получить с помощью запроса
SELECT SUM(ji.timespent/3600) from project p join jiraissue ji on (ji.project = p.id) where ji.project = p.id and p.pkey = 'DEMO'
Разница только в том, что нет необходимости фильтровать запросы по типу. Учитываем только фильтрацию по проекту.
В результате выполнения последних двух запросов получаем два числа. На моем примере это значения:
23535.381499 124157.280762
Данные взяты с одного из проектов, который длился около 3-х лет, поэтому не удивляйтесь таким большим значениям. Соответственно в данном проекте на исправление багов приходилось порядка 19% от общих трудозатрат.
Интересно узнать какой процент трудозатрат приходится на исправление багов в ваших проектах?