В данной статье рассмотрим бизнес-процессы и статусы запросов. В данной статье мы озвучим теоретические аспекты, а в следующих статьях перейдём к практической составляющей.
Данная статья относится к циклу статей, которые помогут вам внедрить JIRA SOFTWARE в организации.
Описание бизнес-процесса
Бизнес-процесс — это жизненный цикл запроса, который состоит из статусов и переходов. Рассмотрим на примере:
Статус – это этап, на котором в определённый момент находится запрос.
Пример:
Переход – это путь, по которому может быть перемещён запрос из одного статуса в другой. Названию перехода соответствуют кнопки перехода запроса в карточке самого запроса.
Пример:
Созданный бизнес-процесс запроса привязывается к конкретному проекту. Существует несколько подходов использования бизнес-процессов в проектах JIRAЖ
— создать универсальный бизнес-процесс и использовать его во всех проектах;
— создать для каждого проекта JIRA свой бизнес-процесс;
— использовать смешанную схему из первого и второго метода.
Также надо помнить, что у каждого типа запроса в JIRA, в рамках одного проекта, может быть свой бизнес-процесс. К примеру, запрос живёт по одному бизнес-процессу, а ошибка по другому бизнес процессу, т.е. каждый тип запроса в проекте может иметь свой бизнес-процесс.
Выбор бизнес-процесса
Кто внедряет JIRA впервые, тот сталкивается с проблемой построения бизнес-процесса и не знает, из каких статусов и переходов бизнес-процесс собирать.
Рассмотрим с вами бизнес-процессы, которые многократно обкатаны в моей практике. В дальнейшем вы можете их модифицировать под свои нужды. Ниже рассматриваются бизнес-процессы для запросов, с которыми работают разработчики, тестировщики, аналитики. Запросы более высокого уровня, которые решаются и контролируются на уровне менеджеров и руководства, будут иметь другой бизнес-процесс.
Бизнес-процесс для запроса типа «Задача», «Улучшение», «Доработка», «Подзадача»:
Бизнес-процесс для запроса типа «Ошибка»:
Категории статусов
 | «К выполнению» — это некий пул, в котором находятся запросы, ожидающие, когда их возьмут в работу (анализа, уточнения, реализации…) |
 | «В работе» — запрос, находящийся в данном статусе, находится на текущий момент в работе (анализируется, реализовывается, тестируется…) |
 | «Выполнено» — это конечный статус. Запрос в этом статусе уже реализован, протестирован и закрыт. |
Описание статусов
 | Пул запросов, которые надо проанализировать и отправить в разработку. В данный статус запрос попадает при создании нового запроса. Также в данный статус запрос попадает из статуса «Уточнение». |
 | Если в описании запроса недостаточно информации для реализации или для исправления, то запрос переводят в данный статус, говоря этим, что ему нужна дополнительная информация и в комментариях поясняет, что ему требуется предоставить. В данный статус запрос переводит тот, кто занимался анализом запроса. |
 | В данном статусе запрос находится в работе у сотрудника, у которого запросили уточнение. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данном статусе запрос находится в работе у сотрудника, который проводит анализ запроса. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус запрос попадает после анализа и принятия решения о реализации описанных в запросе требований или исправлении описанной ошибки. В данный статус запрос переводит тот, кто занимался анализом. |
 | В данном статусе запрос находится в работе у сотрудника, который занимается реализацией требований (ведёт разработку). В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус запрос попадает после реализации, для того чтобы провести ревью кода. В данный статус запрос переводит тот, кто занимался реализацией (разработкой). |
 | В данном статусе запрос находится в работе у сотрудника, который занимается ревью кода. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус запрос попадает после того, как проведено ревью кода и реализация или код соответствуют определённым требованиям. В данный статус запрос переводит тот, кто занимался ревью кода. |
 | В данном статусе запрос находится в работе у сотрудника, который занимается тестированием реализации. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус переводится запрос, который не может быть протестирован, пример: наличие блокирующих тестирование ошибок, не настроена для тестирования тестовая среда. В данный статус запрос переводит тот, кто занимался тестированием. После исправления блокирующих факторов запрос снова переводится в «Тестировать». |
 | В данный статус запрос переводится, если тестируемый/проверяемый функционал не реализован или реализован не в полной мере. В данный статус запрос переводит тот, кто занимался тестированием или проверкой реализации. Также в данный статус запрос может быть переведён из других статусов, если это предусмотрено. |
 | В данный статус запрос переводится после успешного прохождения тестирования. В данный статус запрос переводит тот, кто занимался тестированием. На моей практике у ошибок данный статус не вводился, так как все ошибки отдаются на откуп отделу тестирования. |
 | В данном статусе запрос находится на проверке у заказчика доработок/улучшений. В данный статус запрос переводит сотрудник, который взял запрос в работу. На моей практике у ошибок данный статус не вводился, так как все ошибки отдаются на откуп отделу тестирования. |
 | Запрос в определённый момент может быть отклонён, к примеру, если отменены требования на реализацию или запрос не является ошибкой. В данный статус запрос переводит тот, кто принял решение об отмене/отклонении запроса. Создатель запроса изучает вопрос и возвращает запрос в работу или закрывает его. |
 | В данный статус запрос переводит сотрудник, который работал с запросом на предыдущем шаге, который был до шага «Закрыто». Запрос, находящийся в данном статусе, уже не может быть взят в работу, однако, при необходимости, создаём клон запроса, и работает с копией. |
Стремитесь к тому, чтобы в бизнес-процессе у вас был один статус зелёного цвета, т.е. конечный статус запроса, который означает, что над запросом работы завершены.
В JIRA работают люди, которые имеют определённые роли. Рассмотрим, с какими статусами, какие роли работают.
Аналитик работает с запросами, которые находятся в статусах:
— Открыто
— Анализ
Разработчик работает с запросами, которые находятся в статусах:
— Открыто
— Анализ
— Сделать
— Реализация
— На ревью кода
— Ревью кода
— Переоткрыто
Тестировщик работает с запросами, которые находятся в статусах:
— Требует уточнения
— Уточнение
— Тестировать
— Тестирование
— Отклонено (если созданный тестировщиком запрос отклонён)
Если тестировщик является и заказчиком, то он может работать дополнительно с запросами, которые находятся в статусах:
— Проверить заказчику
— Проверяется
Заказчик работает с запросами, которые находятся в статусах:
— Проверить заказчику
— Проверяется
— Отклонено (если созданный заказчиком запрос отклонён)
Некоторых ролей может в организации и не быть или могут быть другие роли, которые работают с запросами в определённых статусах.
Переходы
Переход – путь по которому запрос может перемещаться с одного статуса в другой. На картинках переходы показаны стрелками. Если нет перехода связывающего определённые статусы, то и запрос не может быть переведён с одного статуса в другой. К примеру, согласно приведённым выше схемам мы не сможем перевести запрос из статуса «Реализация» в «Закрыто». Со статуса «Реализация» запрос может быть переведён в статус «На ревью кода».
Переходы мы создаём сами, однако при создании переходов надо учитывать, чтобы количество переходов было оптимальным, а также разумным. Я в своей практике если сомневаюсь в необходимости какого-либо перехода, то я с помощью JQL запроса в JIRA делаю выборку «сколько запросов за год (полгода) было перемещено по определённому переходу» и если получаю ничтожно малое количество запросов, то принимаю решение об удалении перехода, так как он никому практически не нужен. Пример JQL-запроса:
status changed from (Тестировать) to (Тестирование) during ("2018-01-01 00:01", "2018-07-31 23:59")JQL-запросы — это отдельная тема, которая в данной статье рассматриваться не будет.
При создании бизнес-процесса выстраивайте статусы и переходы так, чтобы они хорошо читались. Взгляните на бизнес-процессы выше и сравните их со следующим бизнес-процессом:
Если кто-то попытается понять, из приведённой картинки, в какой статус запрос может быть переведён из определённого статуса, то у него возникнут с этим проблемы. Любой сотрудник может в запросе посмотреть бизнес-процесс, по которому живёт запрос, для этого необходимо находиться в карточке запроса:
В следующей статье мы будем создавать статусы и бизнес-процессы.
