Внедрение JIRA Software #3. Описание статусов и бизнес-процессов

Внедрение JIRA Software #3. Описание статусов и бизнес-процессов
В данной статье рассмотрим бизнес-процессы и статусы запросов. В данной статье мы озвучим теоретические аспекты, а в следующих статьях перейдём к практической составляющей.

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

Описание бизнес-процесса

Бизнес-процесс — это жизненный цикл запроса, который состоит из статусов и переходов. Рассмотрим на примере:

Бизнес-процесс JIRA

Статус – это этап, на котором в определённый момент находится запрос.

Пример:

Статусы в JIRA

Переход – это путь, по которому может быть перемещён запрос из одного статуса в другой. Названию перехода соответствуют кнопки перехода запроса в карточке самого запроса.

Пример:

1Переходы в JIRA

Созданный бизнес-процесс запроса привязывается к конкретному проекту. Существует несколько подходов использования бизнес-процессов в проектах JIRAЖ
— создать универсальный бизнес-процесс и использовать его во всех проектах;
— создать для каждого проекта JIRA свой бизнес-процесс;
— использовать смешанную схему из первого и второго метода.

Также надо помнить, что у каждого типа запроса в JIRA, в рамках одного проекта, может быть свой бизнес-процесс. К примеру, запрос живёт по одному бизнес-процессу, а ошибка по другому бизнес процессу, т.е. каждый тип запроса в проекте может иметь свой бизнес-процесс.

Выбор бизнес-процесса

Кто внедряет JIRA впервые, тот сталкивается с проблемой построения бизнес-процесса и не знает, из каких статусов и переходов бизнес-процесс собирать.

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

Бизнес-процесс для запроса типа «Задача», «Улучшение», «Доработка», «Подзадача»:

Бизнес-процесс запроса в JIRA

Бизнес-процесс для запроса типа «Ошибка»:

Бизнес-процесс запроса в JIRA

Категории статусов

Синяя категория — «К выполнению» — это некий пул, в котором находятся запросы, ожидающие, когда их возьмут в работу (анализа, уточнения, реализации…)

Жёлтая категория — «В работе» — запрос, находящийся в данном статусе, находится на текущий момент в работе (анализируется, реализовывается, тестируется…)

Зелёная категория — «Выполнено» — это конечный статус. Запрос в этом статусе уже реализован, протестирован и закрыт.

Описание статусов

Открыто — Пул запросов, которые надо проанализировать и отправить в разработку. В данный статус запрос попадает при создании нового запроса. Также в данный статус запрос попадает из статуса «Уточнение».

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

Уточнение — В данном статусе запрос находится в работе у сотрудника, у которого запросили уточнение. В данный статус запрос переводит сотрудник, который взял запрос в работу.

Анализ — В данном статусе запрос находится в работе у сотрудника, который проводит анализ запроса. В данный статус запрос переводит сотрудник, который взял запрос в работу.

Сделать — В данный статус запрос попадает после анализа и принятия решения о реализации описанных в запросе требований или исправлении описанной ошибки. В данный статус запрос переводит тот, кто занимался анализом.

Реализация — В данном статусе запрос находится в работе у сотрудника, который занимается реализацией требований (ведёт разработку). В данный статус запрос переводит сотрудник, который взял запрос в работу.

На ревью кода — В данный статус запрос попадает после реализации, для того чтобы провести ревью кода. В данный статус запрос переводит тот, кто занимался реализацией (разработкой).

Ревью кода — В данном статусе запрос находится в работе у сотрудника, который занимается ревью кода. В данный статус запрос переводит сотрудник, который взял запрос в работу.

Тестировать — В данный статус запрос попадает после того, как проведено ревью кода и реализация или код соответствуют определённым требованиям. В данный статус запрос переводит тот, кто занимался ревью кода.

Тестирование — В данном статусе запрос находится в работе у сотрудника, который занимается тестированием реализации. В данный статус запрос переводит сотрудник, который взял запрос в работу.

Тестирование невозможно — В данный статус переводится запрос, который не может быть протестирован, пример: наличие блокирующих тестирование ошибок, не настроена для тестирования тестовая среда. В данный статус запрос переводит тот, кто занимался тестированием. После исправления блокирующих факторов запрос снова переводится в «Тестировать».

Переоткрыто — В данный статус запрос переводится, если тестируемый/проверяемый функционал не реализован или реализован не в полной мере. В данный статус запрос переводит тот, кто занимался тестированием или проверкой реализации. Также в данный статус запрос может быть переведён из других статусов, если это предусмотрено.

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

Проверяется — В данном статусе запрос находится на проверке у заказчика доработок/улучшений. В данный статус запрос переводит сотрудник, который взял запрос в работу. На моей практике у ошибок данный статус не вводился, так как все ошибки отдаются на откуп отделу тестирования.

Отклонено — Запрос в определённый момент может быть отклонён, к примеру, если отменены требования на реализацию или запрос не является ошибкой. В данный статус запрос переводит тот, кто принял решение об отмене/отклонении запроса. Создатель запроса изучает вопрос и возвращает запрос в работу или закрывает его.

Закрыто — В данный статус запрос переводит сотрудник, который работал с запросом на предыдущем шаге, который был до шага «Закрыто». Запрос, находящийся в данном статусе, уже не может быть взят в работу, однако, при необходимости, создаём клон запроса, и работает с копией.

Стремитесь к тому, чтобы в бизнес-процессе у вас был один статус зелёного цвета, т.е. конечный статус запроса, который означает, что над запросом работы завершены.

В JIRA работают люди, которые имеют определённые роли. Рассмотрим, с какими статусами, какие роли работают.

Аналитик работает с запросами, которые находятся в статусах:
— Открыто
— Анализ

Разработчик работает с запросами, которые находятся в статусах:
— Открыто
— Анализ
— Сделать
— Реализация
— На ревью кода
— Ревью кода
— Переоткрыто

Тестировщик работает с запросами, которые находятся в статусах:
— Требует уточнения
— Уточнение
— Тестировать
— Тестирование
— Отклонено (если созданный тестировщиком запрос отклонён)
Если тестировщик является и заказчиком, то он может работать дополнительно с запросами, которые находятся в статусах:
— Проверить заказчику
— Проверяется

Заказчик работает с запросами, которые находятся в статусах:
— Проверить заказчику
— Проверяется
— Отклонено (если созданный заказчиком запрос отклонён)

Некоторых ролей может в организации и не быть или могут быть другие роли, которые работают с запросами в определённых статусах.

Переходы

Переход – путь по которому запрос может перемещаться с одного статуса в другой. На картинках переходы показаны стрелками. Если нет перехода связывающего определённые статусы, то и запрос не может быть переведён с одного статуса в другой. К примеру, согласно приведённым выше схемам мы не сможем перевести запрос из статуса «Реализация» в «Закрыто». Со статуса «Реализация» запрос может быть переведён в статус «На ревью кода».

Переходы мы создаём сами, однако при создании переходов надо учитывать, чтобы количество переходов было оптимальным, а также разумным. Я в своей практике если сомневаюсь в необходимости какого-либо перехода, то я с помощью JQL запроса в JIRA делаю выборку «сколько запросов за год (полгода) было перемещено по определённому переходу» и если получаю ничтожно малое количество запросов, то принимаю решение об удалении перехода, так как он никому практически не нужен. Пример JQL-запроса:

status changed from (Тестировать) to (Тестирование) during ("2018-01-01 00:01", "2018-07-31 23:59")

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

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

Бизнес-процесс запроса JIRA

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

Просмотреть бизнес-процесс запроса в JIRA

В следующей статье мы будем создавать статусы и бизнес-процессы.

Добавить комментарий

Ваш e-mail не будет опубликован.