Внедрение JIRA Software #11. Полезные инструменты, настройки и методы работы

В предыдущих статьях мы рассмотрели создание проекта со всеми сущностями. Дальше остаётся разобрать администрирование и настройка JIRA со стороны администратора системы. Этой информацией я обладаю, однако не буду её озвучивать в статьях, иначе на это уйдёт ещё не один десяток статей. Опубликованными статьями в вас заложены основы, а далее вы можете постепенно осваивать инструменты администрирования, которые имеются в JIRA.

Данная статья относится к циклу статей, которые помогут вам внедрить JIRA SOFTWARE в организации.

Сейчас мы с вами рассмотрим моменты, которые нам помогут облегчить работу. Надеюсь, вы прошлые статьи изучили внимательно и описанное ниже будет вам понятно.

ТОНКАЯ НАСТРОЙКА БИЗНЕС-ПРОЦЕССА

При создании задач и перемещении их из статуса в статус нам придётся постоянно назначать исполнителя вручную и на это затрачивается лишнее время. Мы можем настроить бизнес-процесс так, чтобы система автоматически назначала запрос определённым сотрудникам в момент перехода запроса в какой-либо статус.

Сейчас опишу более тонкую настройку ранее созданного бизнес-процесса:

Для настройки нам необходимо установить в JIRA плагин и добавить определённое количество пользовательских полей.

Добавлены плагины:
— «JSU — Suite Utilities for Jira» (платный). Плагин позволяет добавлять в рабочий процесс валидаторы, условия и post-функции, которых нет в стандартной поставке JIRA. Плагин доступен в Atlassian Marketplace.
— «AM Utils» (бесплатный). Плагин позволяет добавлять в рабочий процесс валидаторы, условия и post-функции, которых нет в стандартной поставке JIRA. Плагин доступен в Atlassian Marketplace.

Добавляемые поля:
— Сотрудник: кто анализировал
— Сотрудник: кто уточнял
— Сотрудник: кто разрабатывал
— Сотрудник: кто проводил ревью кода
— Сотрудник: кто тестировал

Добавленные поля будут служебными, поэтому их не надо добавлять на экраны для отображения.

На картинке отображены действия, о которых будет идти речь дальше:

Ниже буду обозначать переходы из статуса в статус, и какие операции необходимо добавить на этих переходах. Во время настройки не трогайте созданные JIRA post-функции, валидаторы и условия.
Если в переходах будут похожие операции, то скриншоты не буду повторно публиковать, будут публиковаться только скриншоты уникальных операций.

«Открыто» => «Анализ»
Действие: Исполнителем назначается пользователь, который перевёл задачу по данному маршруту (текущий пользователь) и в системное поле «Сотрудник: кто анализировал» заносится информация о нём.

«Анализ» => «Сделать»
Условие: Данный переход может совершать только сотрудник из группы «Группа: Разработчик»
Действие: В поле «Сотрудник: кто анализировал» заносится информация о пользователе, который перевёл задачу по данному маршруту (текущий пользователь)

«Анализ» => «Требует уточнения»
Действие: Исполнителем назначается автор запроса. В поле «Сотрудник: кто анализировал» заносится информация о пользователе, который перевёл задачу по данному маршруту (текущий пользователь).

«Анализ» => «Отклонено»
Действие: Исполнителем назначается автор запроса. В поле «Сотрудник: кто анализировал» заносится информация о пользователе, который перевёл задачу по данному маршруту (текущий пользователь).

«Отклонено» => «Переоткрыто»
Нет специальных условий и действий.

«Отклонено» => «Закрыто»
Экран: Запрашивается ввод «Решения» (обязательно).
Условие: Данный переход может совершать только Автор запроса или сотрудник из группы «Группа: Тестировщик».

«Переоткрыто» => «Анализ»
Действие: Исполнителем назначается пользователь, который перевёл задачу по данному маршруту (текущий пользователь) и в поле «Сотрудник: кто анализировал» заносится информация о нём.

«Требует уточнения» => «Уточнение»
Действие: Исполнителем назначается пользователь, который перевёл задачу по данному маршруту (текущий пользователь) и в поле «Сотрудник: кто уточнял» заносится информация о нём.

«Уточнение» => «Открыто»
Действие: Исполнителем назначается пользователь, который прописан в поле «Сотрудник: кто анализировал».

«Уточнение» => «Закрыто»
Экран: Запрашивается ввод «Решения» (обязательно).

«Сделать» => «Реализация»
Действие: Исполнителем назначается пользователь, который перевёл задачу по данному маршруту (текущий пользователь) и в поле «Сотрудник: кто разрабатывал» заносится информация о нём.

«Реализация» => «Анализ»
Действие: Исполнителем назначается пользователь, который прописан в поле «Сотрудник: кто анализировал».

«Реализация» => «На ревью кода»
Действие: В поле «Сотрудник: кто разрабатывал» заносится информация о пользователе, который перевёл задачу по данному маршруту (текущий пользователь).

«На ревью кода» => «Ревью кода»
Действие: Исполнителем назначается пользователь, который перевёл задачу по данному маршруту (текущий пользователь) и в поле «Сотрудник: кто проводил ревью кода» заносится информация о пользователе, который перевёл задачу по данному маршруту (текущий пользователь).

«Ревью кода» => «Тестировать»
Условие: Данный переход может совершать только сотрудник из группы «Группа: Разработчик».
Действие: Исполнителем назначается автор запроса.

«Ревью кода» => «Реализация»
Действие: Исполнителем назначается пользователь, который прописан в поле «Сотрудник: кто разрабатывал».

«Тестировать» => «Тестирование»
Действие: Исполнителем назначается пользователь, который перевёл задачу по данному маршруту (текущий пользователь) и в системное поле «Сотрудник: кто тестировал» заносится информация о нём.

«Тестирование» => «Тестирование невозможно»
Нет специальных условий и действий.

«Тестирование» => «Переоткрыто»
Действие: Исполнителем назначается пользователь, который прописан в системном поле «Сотрудник: кто разрабатывал».

«Тестирование» => «Закрыто»
Действие: Поле «Решение» автоматически заполняется значением «Готово».

«Тестирование невозможно» => «Тестировать»
Нет специальных условий и действий.

Если настроить бизнес-процесс, так как описано выше, то практически исчезает необходимость назначать исполнителя вручную. Принцип описанного выше прост, и вы можете более сложно настраивать процесс.

НАСТРОЙКА ЗАКРЫТИЯ ЭПИКА

Если мы хотим привязать запрос к эпику, то выбираем требуемый эпик из списка открытых эпиков при создании запроса или после создания:

Здесь отображаются эпики, которые имеют «Epic Status» отличный от «Готово», т.е. не закрытые эпики, которые в работе.

Однако многие, закрывая эпик, забывают его статус перевести в «Готово», как итог при выборе эпика в задаче мы видим в списке и эпики, которые уже закрыты, но у которых забыли перевести «Epic Status» в «Готово». Чтобы этого не происходило необходимо добавить валидатор в бизнес-процесс проекта, по которому живут эпики, чтобы система не позволяла закрывать эпик, если у него не выставлен «Epic Status» в «Готово», и чтобы система предупреждала об этом. Если эпик живёт по общему бизнес-процессу, то можно валидатор добавить и в общий бизнес-процесс на все переходы, которые ведут в статус «Закрыто». Если рассматривать бизнес-процесс, который указан в данной статье, то мы установим валидатор на следующие переходы:
— «Уточнение» => «Закрыто»
— «Тестирование» => «Закрыто»
— «Отклонено» => «Закрыто»

issue = %THIS% AND issuetype = Epic AND "Epic Status" != "Готово"

Мы указываем, что надо найти с помощью JQL текущий запрос, в котором мы находимся и если он эпик, и у него «Epic Status» не равен «Готово», то не переводить запрос в следующий статус и вывести текст указанный нами текст.

Теперь если попытаться закрыть эпик, у которого «Epic Status» не равен «Готово», то увидим следующее:

Больше мы не будем забывать выставлять закрываемым эпикам требуемый статус, и у нас не будет разрастаться количество эпиков в списке выбора.