На форумах очень часто спрашивают о существовании готовых отчетов или плагинов (даже платных!), которые позволяют решить определенную управленческую задачу. И часто такие вопросы остаются без ответа. Можем сказать с уверенностью, что все бы эти задачи решились с помощью SQL и прямых обращений к БД JIRA. В данной статье рассмотрим несколько примеров SQL-запросов, которые можно выполнять напрямую к БД системы JIRA.
» Read more
В данной статье затронем вопрос, связанный с version scope management Представим, что очередная версия в JIRA запланирована, все естимейты указаны, определена дата релиза и команда приступает к выполнению задач в текущей версии. Пока все идет своим чередом, постепенно объем работ осваивается, ничто не угрожает срыву озвученных сроков. Но стоит только на пару дней отвлечься от контроля скоупа версии (например, переключившись
» Read more
Перед оценкой бюджета и сроков нового проекта необходимо задать один очень важный вопрос: «Выполнялись ли похожие проекты?». Если были похожие завершенные проекты, то значит база для оценки нового проекта есть. Но это не значит, что достаточно просто получить общие трудозатраты и срок выполнения завершенного проекта и перенести их в оценки для нового проекта. Необходимо провести ретроспективный анализ, проанализировать сработавшие риски,
» Read more
В прошлой статье был рассмотрен SQL-запрос, получающий список задач в системе JIRA, которые возвращались на доработку с указанием количества возвратов (фактически — количество переходов в статус Reopen). SELECT ji.pkey, ji. summary, count(*) FROM changeitem ci join changegroup cg on (cg.id = ci.groupid) join jiraissue ji on (cg.issueid = ji.id) join project p on (p.id = ji.project) where ci.field = ‘status’ and
» Read more
Если в качестве системы управления задачами вы используете JIRA, то наверняка в ваших workflow для задач предусмотрен статус Reopened. В большинстве случаев перевод в этот статус в нашем случае читается как «перевод задачи на доработку при тестировании на тестовой площадке». Полагаю, не стоит переводить задачу в Reopened в случае обнаружения любой баги по задаче. Бага — это отдельный объект учета
» Read more
В прошлой статье была рассмотрена простая задача по определению доли трудозатрат, которая приходится на исправление багов в проекте. Немного усложним задачу и зададимся вопросом «Как распределяются трудозатраты на исправление багов в разрезе категорий?». Категории — это определенный классификатор, который позволяет группировать баги по определенной характеристике. Для возможности выбора категории бага, в системе Jira необходимо создать отдельный списочный кастомный атрибут, например BugProperty.
» Read more
Аналитику багов в JIRA предлагаю начать с рассмотрения простого кейса №1: Узнать долю трудозатрат, которая приходится на исправление багов в проекте Кейс №1 Баги на проектах разработки ПО всегда были, есть и будут. Порой, когда баги или долго не появляются или их найдено крайне мало, мне как менеджеру даже как-то не по себе. Закрадывается подозрение, что с quality assurance
» Read more
Предположим, вы уже столкнулись с ситуацией, когда стандартные инструменты системы JIRA, не справляются с возникшей перед вами задачей. В моей практике часто возникали ситуации, когда по первичным данным из JIRA требовалось выполнить определенную аналитику. При чем — это не обязательно была сложная аналитика. Даже такой простой запрос как «получить список всех проектов, в которых отмечал ворклоги сотрудник А, за такой-то
» Read more