Аналитика багов в JIRA с помощью SQL. Часть I

Аналитику багов в JIRA предлагаю начать с рассмотрения простого кейса №1:

Узнать долю трудозатрат, которая приходится на исправление багов в проекте

 

Кейс №1

Баги на проектах разработки ПО всегда были, есть и будут. Порой, когда баги или долго не появляются или их найдено крайне мало, мне как менеджеру даже как-то не по себе. Закрадывается подозрение, что с quality assurance что-то не так. Но вот несколько багов обнаружены тестировщиками — значит все в порядке :).

Почти уверен, что в ваших моделях управления в багтрекерах для фиксации багов используется тип запроса Bug. Если при этом разработчики и тестировщики отмечают ворклоги в запросах  данного типа, то появляется замечательная возможность отследить долю трудозатрат на исправление багов относительно общих трудозатрат на проекте. Это отличная аналитика, которая расширит проектный lessons learned. Ключевая важность данного показателя — понимание того какой резерв закладывать на исправление багов в дальнейшем при планировании очередной версии или похожего проекта. Данный показатель — подходящее оправдание заложенным резервам на исправление багов. Такой подход намного серьезнее чем взятая с потолка цифра. В серии похожих проектов, в которых мне приходилось участвовать, данный показатель был приблизительно на уровне 20-25%. Зная этот показатель, я умножаю оценки исполнителей соответственно на коэффициент 1.2-1.25. И это один из факторов, который позволяет не промахнуться со сроками (нужно учитывать еще и управленческий резерв). При этом и для участников упрощается процесс оценки. Они оценивают задачи без учета времени на исправление багов.

Рассмотрим фрагмент модели данных JIRA, который понадобится для создания SQL-запросов:

art3_sch1

Необходимо использовать данные из 3-х таблиц: JIRAISSUE, PROJECT, ISSUETYPE.

Напомню, что таблица JIRAISSUE — это ключевая таблица, в которой содержится информация про все запросы существующие в JIRA. PROJECT — это таблица, содержащая список всех проектов JIRA. Она необходима для фильтрации запросов по наименованию проекта. Каждый запрос в таблице JIRAISSUE содержит ссылку на проект. Ссылка хранится в поле JIRAISSUE.project.

ISSUETYPE — это словарь типов запросов. Данная таблица необходима, чтобы отфильтровать запросы с типом Bug. Каждый запрос содержит идентификатор типа, который хранится в поле JIRAISSUE.issuetype.

Выполните предварительно следующий запрос, чтобы узнать полный список типов запросов существующий в вашей JIRA.

SELECT * FROM [issuetype]

В результате вы увидите результат похожий на такой список:

 

art3_sch2

 

Выполним соединение трех таблиц используя оператор 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% от общих трудозатрат.

 

Интересно узнать какой процент трудозатрат приходится на исправление багов в ваших проектах?