Как создать собственный workflow в Jira
Практика4 минРедакция Innovialabs
Коротко
Workflow в Jira — это статусы, связанные переходами; условия решают, кто может двигать задачу, валидаторы проверяют данные перед переходом, пост-функции действуют после него, а хороший workflow повторяет реальный процесс с минимумом статусов.
Из чего состоит workflow
Workflow — путь задачи от создания до завершения. В нем пять элементов:
| Элемент | Что делает | Пример |
|---|---|---|
| Статус | Где задача сейчас | In Progress, QA |
| Переход (transition) | Разрешенное движение между статусами | «Отправить в QA»: из In Progress в QA |
| Условие (condition) | Кто видит и может использовать переход | Только группа QA отмечает, что тестирование пройдено |
| Валидатор (validator) | Что должно быть выполнено до перехода | Заполнено поле Fix version |
| Пост-функция (post-function) | Что происходит автоматически после перехода | Проставить резолюцию, назначить исполнителя |
Каждый статус относится к категории: To Do, In Progress или Done. На эти категории опираются доски, отчеты и поиск, поэтому выбирайте их внимательно.
Где редактировать workflow
- Company-managed проекты: администратор редактирует workflow в глобальных настройках Jira в разделе задач и workflow. К проекту workflow подключается через схему workflow, которая связывает типы задач с workflow. Изменения сохраняются как черновик и затем публикуются.
- Team-managed проекты: откройте настройки проекта, выберите тип задачи и отредактируйте его workflow. Вместо классических трех видов правил здесь более простые: ограничить, кто двигает задачу, проверить поля и выполнить действия после перехода.
Логика одинаковая, отличается только глубина настройки.
Переносим реальный процесс разработки, QA и релиза
Начинайте с того, как работа движется на самом деле, а не с возможностей Jira. Типичная продуктовая команда:
To Do -> In Progress -> Code Review -> QA -> Ready for Release -> Done
^ | |
+--------------+-----------+
(changes requested / QA failed)
Теперь превращаем схему в переходы с правилами:
| Переход | Откуда и куда | Правила |
|---|---|---|
| Взять в работу | To Do в In Progress | Пост-функция: назначить на текущего пользователя |
| Отправить на ревью | In Progress в Code Review | Без правил, переход должен быть быстрым |
| Вернуть на доработку | Code Review в In Progress | Валидатор: обязателен комментарий |
| Одобрить | Code Review в QA | Условие: пользователи с ролью разработчика |
| QA не пройден | QA в In Progress | Валидатор: комментарий с описанием проблемы |
| QA пройден | QA в Ready for Release | Условие: только группа QA. Валидатор: заполнен Fix version |
| Релиз | Ready for Release в Done | Условие: роль релиз-менеджера. Пост-функция: резолюция Done |
Категории: To Do — в To Do, четыре средних статуса — в In Progress, Done — в Done.
Пошагово
- Нарисуйте процесс вместе с командой на бумаге или доске. Договоритесь, что значит каждый статус и кто за него отвечает.
- Скопируйте существующий workflow, а не правьте стандартный напрямую. Так останется запасной вариант.
- Добавьте статусы и задайте каждому правильную категорию.
- Создайте переходы с понятными названиями-глаголами: «Отправить в QA», а не «Далее».
- Добавьте правила только там, где они предотвращают реальные ошибки.
- Подключите workflow к типам задач через схему и опубликуйте. Если у существующих задач есть статусы, которые исчезают, Jira попросит сопоставить их с новыми.
- Обновите колонки доски, чтобы каждый новый статус попал в нужную колонку.
- Протестируйте на нескольких задачах и аккаунтах с разными ролями.
Как не переусложнить workflow
- Меньше статусов. Добавляйте статус, только если в нем кто-то действует иначе. «Ждет ревью от Анны» — это не статус, а исполнитель.
- Без статуса на каждый отдел. Статусы описывают состояние работы, а не оргструктуру.
- Осторожно с переходами «из любого статуса в любой». Они удобны, но делают процесс невидимым.
- У каждого валидатора есть причина. Каждое обязательное поле замедляет переход. Оставляйте те, что защищают релизы и отчеты.
- Не забывайте про резолюцию. В company-managed проектах, если по пути в Done резолюция не проставляется, задачи остаются «Unresolved», и фильтры с отчетами начинают врать.
- Один workflow на несколько проектов. Общий workflow проще поддерживать, чем уникальный для каждой команды.
Частые вопросы
Условие решает, доступен ли переход пользователю вообще, — кнопка может просто не появиться. Валидатор позволяет попробовать, но блокирует переход с ошибкой, если данные неполные.