Распространённая проблема менеджера проектов — определить, от кого зависит дальнейшее исполнение задачи. Часто задача назначается на разработчика, да так и остаётся “висеть” на нём вплоть до релиза. Однако разработчик отвечает только за часть исполнения. QA — тестирует, DevOps — включает в релиз, продакт-менеджер — оценивает готовую работу (в каждой организации эта цепочка своя). Задача путешествует от статуса к статусу (In Progress, Done, Tested, Shipped, Closed и т.п.), но исполнителем значится всё тот же разработчик.

В небольших командах это не представляет сложности, ведь и так примерно понятно, кто должен тестировать, кто релизить и т.д. Но даже команде из нескольких QA уже необходимо изобретать правила, по которым тестировщики должны разбирать себе задачи, помеченные разработчиками как Done. Либо специальный человек должен вручную распределять такие задачи между членами команды. И что самое неприятное — нет гарантии, что задача не будет позабыта и не застрянет в каких-то промежуточных статусах.

Предлагаемое решение — автоматическая установка исполнителя задачи при переходе её в новый статус. Например, как только разработчик пометит задачу как Done, она автоматически будет назначена на QA-инженера.

Преимущества такого решения:

• персонализация ответственности за задачу на каждом этапе её жизни
• новый исполнитель получит уведомление от системы о назначенной ему задаче
• более точная отчётность — например, можно сформировать списки задач, принадлежащих в данный момент каждому члену команды
• повышается читаемость задач во всех интерфейсах Jira (детальный просмотр задачи, Agile-доски, и т.п.)

Jira содержит в своих закромах необходимую функциональность. Давайте рассмотрим, как же вся эта полезность настраивается.

В качестве простого примера предположим, что в команду входит QA-инженер Johnny Testcase, на которого должны автоматически назначаться все задачи, поставленные разработчиками в статус Done.

Jira позволяет настраивать дополнительные действия, совершаемые при переходе задачи из одного статуса в другой. Вся система статусов и переходов называется workflow, переходы — transitions, а дополнительные действия при переходах — post-functions. Наша задача — добавить к переходам пост-функции, которые будут устанавливать нового исполнителя.

Перед редактированием workflow, используемого на живом проекте, рекомедуется скопировать его и тренироваться на копии.

Итак, открываем экран редактирования нашего workflow:

В схеме переходов нас интересует переход из статуса In Progress в статус Done. Открываем экран редактирования этого перехода:

На вкладке Post Functions выбираем Add post function:

Из длинного списка возможных пост-функций выбираем Update Issue Field:

Таким образом мы настроим автоматическое обновление значения в заданном поле задачи. Выбираем поле Assignee (исполнитель), и указываем нашего воображаемого QA-инженера Johnny Testcase в качестве нового исполнителя:

Обратим внимание, что новая пост-функция добавилась в список:

Настройка workflow закончена, осталось его опубликовать:

Изменения вступят в силу для всех проектов, которые используют данный workflow. Все задачи, переведенные в статус Done, автоматически будут назначаться на указанного выше Johnny Testcase.

На практике такая прямолинейная схема вряд ли будет очень применимой. Однако богатый набор доступных пост-функций позволяет настроить весьма полезные правила. Вот часть пост-функций, наиболее подходящих для боевого применения:

Автор на практике применяет следующую простую схему:

Читатели приглашаются к дележу опытом и предложениями по возможной организации схем автоматического перехода задач между исполнителями.

Автор: alexandermarinich

Источник