Автоматическое назначение задач в Jira

image

Распространённая проблема менеджера проектов — определить, от кого зависит дальнейшее исполнение задачи. Часто задача назначается на разработчика, да так и остаётся “висеть” на нём вплоть до релиза. Однако разработчик отвечает только за часть исполнения. 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.

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



Автор на практике применяет следующую простую схему:
Переход На кого назначается задача Как реализовано
In Progress → Done На тим лида команды QA. Он вручную перераспределяет задачу на кого-то из членов своей команды. Пост-функция Assign to role member. При этом в проекте определена роль QA team lead, которая и указана в пост-функции.
Done → To Do На разработчика, который работал над задачей до этого. Это случай, когда тест не прошёл, и тестировщик заново открывает задачу, т.е. возвращает её разработчику. Реализовано с помощью пост-функции Assign to last role member. При этом в проекте определена роль Developers, куда входят все разработчики.
Done → Released На человека, создавшего задачу (Reporter). Предполагается, что продакт-менеджер оценивает уже законченную задачу. Реализовано с помощью пост-функции Assign to reporter.

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

Comments 17

    0
    В рамках больших проектов довешивается автоматизация в виде сервисов (аналог cron'а в Linux) Jira, постфункции усложняются наличием каких-нибудь вкраплений скриптов, с более сложной логикой… например, Jython-кода (можно и Grubby, и другие языки использовать — питон здесь, кажется самым удобным), там идет напрямую взаимодействие с Jira API и \ или SOAP.
      0
      В данном случае используется Jira On-demand (по подписке от Atlassian). Большая часть таких кастомизаций там недоступна.

      Если у вас есть опыт использования каких-либо таких сложных надстроек для on-demand — буду благодарен за наводку. Интересуют в первую очередь готовые продукты, позволяющие произвести эти настройки. Ибо разработка плагинов не является нашей специализацией)

      Пока что я время от времени использую только Jira Command Line Interface для автоматизации простых повторяющихся задач.
      0
      Либо специальный человек должен вручную распределять такие задачи между членами команды. И что самое неприятное — нет гарантии, что задача не будет позабыта и не застрянет в каких-то промежуточных статусах.


      Не вижу решения, которое избавляет вас от человека, который назначает задачи внутри команды. Хотя судя по цитате этого следовало ожидать.
      Всё равно всё падает на тимлида QA. Единственный плюс, что да, задачи не будут теряться.
      По факту же вами описан базовый функционал JIRA., который и так уже многими используется.
        0
        Я тоже не вижу пока универсального решения, позволяющего освободить QA лида. Но данная функциональность всё таки покрывает значительную часть типичных ситуаций. Например, если баг не проходит тестирование, то тестировщику нет необходимости помнить, кто из разработчиков работал над этим багом. Достаточно просто переоткрыть баг, и он автоматически назначится на этого разработчика.

        Безусловно, это базовый функционал Jira, однако он скорее всего будет известен только специальному человеку, отвечающему за Jira в компании. Часто в компании нет такого человека, а остальным некогда разбираться. В нашей компании этот функционал годами не использовался.
        0
        Достаточно простенькая схема. Вот если бы кто подсказал как делать то же самое но в рамках отдельных команд(в зависимости от значения поля), не используя разные WF для разных команд и JS…
          0
          Вам сюда.

          Устанавливаете плагин JSS, разбираетесь в API Jira, пишете произвольные скрипты, вешаете их на постфункции, или выставляете в качестве сервиса. Если Jira новая есть оч. клевая jira-python либа, которая через Soap все делает — соответственно, изучаете команды которые там есть, пишете те же самые скрипты и вперед. =)
            0
            Спасибо, посмотрю.
            0
            Можно использовать один и тот же воркфлоу для разных команд. Пост-функции могут ссылаться не на конкретных людей, а на роли в проекте. Набор ролей должен быть одинаковым для всех проектов, использующих данный воркфлоу. А вот юзеры, назначенные на эти роли, могут отличаться. Например, в описанном выше примере в разных проектах разный QA лид.
              0
              Нет, хочется один WF, на одном проекте с разными командами(соответственно тимлидами, QA и прочее). Про роли как раз все понятно)
                0
                Вот ещё одна версия, которая без сомнения является костылём, но мало ли что)

                Можете попробовать использовать conditions для transitions. Например, добавить к транзишену условие User is in a group — это позволит только юзерам из определённой группы осуществлять этот транзишен. Таким образом, вы сможете реализовать как бы несколько воркфлоу в одном — определить свой набор транзишенов для каждой группы юзеров. А уж каждому транзишену сможете назначать свои пост-функции. Это гарантированно породит вам десятиэтажную конфигурацию всего воркфлоу, но если вдруг оно окажется удобным для пользователей, то почему бы и нет)
                  0
                  Хм, можно подумать. Спасибо)
            0
            Использовал подобную схему, и даже более развитую. Например, когда тестировщик отказывает задачу, задача должна автоматом вернуться именно на того разработчика, который ей занимался.
            Но этот подход изменяет концепцию жиры. Потом возникают сложности:
            1. Понять, кто делал задачу (только через историю)
            2. Собрать статистку по разработчикам.
            3. Поддерживать такое решение, особенно функции выбора, КАКОМУ тестировщику отдать эту работу, если он не один.

            Мое мнение: для описанной задачи нужно использовать несколько проектов жиры. Например, отдельно для разработки и отдельно для тестирования. При этом можно автоматом создавать задачи в другом проекте и связывать их с исходной.
            Или заводить отдельные поля тестировщик, аналитик и т.д., для каждой роли и прописывать пользователей в них.

              0
              Не расскажете, как вы автоматически создавали связанные задачи в других проектах?
                0
                Можно клонировать текущую задачу в другом проекте и автоматически связывать ее при этом с помощью скрипта.
                Скрипт запускается в postfunction в каком-то шаге workflow с помощью ScriptRuner

                  0
                  Ясно, спасибо.
                  К сожалению, это для меня сейчас не вариант, т.к. пользуемся Jira On Demand — там нет скрипт раннера.
              0
              Коллеги, переассайн одной и той же задачи в процессе ее путешествия по WorkFlow это АДЪ.
              Ну то есть так можно жить, если вас не интересует ничего, кроме дня сегодняшнего
                0
                Вы знаете, по прошествии двух лет с момента написания статьи, я с вами соглашаюсь всем сердцем :)

              Only users with full accounts can post comments. Log in, please.