1. Основные концепции Workflow

Workflow в Jira — это конечный автомат: набор статусов и переходов между ними. Каждая задача в любой момент времени находится ровно в одном статусе.

Переход — это действие которое переводит задачу из одного статуса в другой. К каждому переходу можно добавить:

  • Conditions — условия при которых переход доступен
  • Validators — проверки данных перед выполнением перехода
  • Post-functions — действия выполняемые после перехода
  • Trigger — автоматический триггер из внешней системы (GitHub, Jenkins)
Workflow нельзя редактировать пока он активен в каком-либо проекте. Сначала нужно создать Draft (черновик), отредактировать его, затем опубликовать. Это защита от случайных изменений в продакшене.

2. Статусы и их категории

Каждый статус принадлежит одной из трёх категорий — это важно для отчётности и автоматизаций:

  • To Do (серый) — задача не начата
  • In Progress (синий) — работа идёт
  • Done (зелёный) — задача завершена

Создать новый статус: ⚙️ Administration → Issues → Statuses → Add Status

Примеры кастомных статусов которые я использую:

Статус              Категория     Описание
──────────────────────────────────────────────
Open                To Do         Задача создана
In Analysis         In Progress   Аналитик изучает
In Development      In Progress   Разработчик пишет код
Code Review         In Progress   Ревью PR
In Testing          In Progress   QA тестирует
UAT                 In Progress   Приёмочное тестирование
Ready to Deploy     In Progress   Ждёт деплоя
Done                Done          Завершено
Won't Fix           Done          Отклонено

3. Переходы: Conditions, Validators, Post-functions

Conditions (Условия)

Контролируют кто и когда видит кнопку перехода. Примеры:

User Is In Project Role
  → Только члены роли "QA" видят переход "Start Testing"

Only Assignee Can Execute Transition
  → Только назначенный исполнитель может взять задачу в работу

Sub-Tasks Must Be Complete
  → Нельзя закрыть задачу пока открыты подзадачи (очень полезно!)

Validators (Валидаторы)

Проверяют данные перед выполнением перехода. Если проверка не прошла — переход отменяется с сообщением об ошибке:

Field Required Validator
  → Поле "Fix Version" обязательно при переходе в "Ready to Deploy"

Regular Expression Validator
  → PR ссылка должна соответствовать шаблону https://github.com/...

Post-functions (Постфункции)

Выполняются автоматически после перехода. Самые полезные:

Assign to Current User
  → При переходе "Start Development" задача назначается тому кто нажал

Update Issue Field
  → При переходе в "Done" автоматически ставить Resolution = Fixed

Fire Issue Event
  → Отправить событие во внешнюю систему (webhook)

Trigger a webhook
  → Вызов внешнего API (деплой, Slack-уведомление)

4. Пример: Scrum Workflow

Классический Scrum-workflow для команды разработки:

Backlog ──→ Selected for Sprint ──→ In Progress ──→ Code Review ──→ In Testing ──→ Done
   ↑                                      |                |              |
   └──────────────────────────────────────┘                └──────────────┘
              (возврат на доработку)                    (баг найден — назад)

Ключевые переходы и что на них вешать:

In Progress → Code Review

Validator: Field Required — поле "Pull Request" должно быть заполнено
Post-function: Assign to Current User → снять назначение (очистить)
Post-function: Fire event → уведомить ревьюеров в Slack

In Testing → Done

Condition: User Is In Role "QA" — только QA может закрыть
Validator: Sub-Tasks Must Be Complete
Post-function: Update Field: Resolution = Fixed
Post-function: Update Field: Fix Version = текущая

Любой статус → Backlog (возврат)

Condition: User Is In Role "Project Managers" OR "Developers"
Post-function: Clear field: Assignee
Post-function: Add comment screen — заставить написать причину возврата

5. Пример: Kanban Workflow

Для Kanban делаем проще — меньше статусов, больше свободы переходов:

Backlog → Ready → In Progress → In Review → Done

В Kanban обычно не ставят жёстких Conditions — важна скорость потока, а не контроль. Из постфункций достаточно:

Ready → In Progress:
  Post-function: Assign to Current User

In Progress → Done:
  Post-function: Update Resolution = Done

6. Привязка к проекту через Workflow Scheme

Один workflow обычно применяется не ко всем типам задач. Workflow Scheme — это таблица соответствий:

Issue Type          Workflow
────────────────────────────────────────
Story               Development Workflow
Bug                 Bug Fixing Workflow
Task                Simple Task Workflow
Epic                (Default Workflow)
Sub-task            (Default Workflow)

Создать Workflow Scheme: ⚙️ Administration → Issues → Workflow Schemes

Применить к проекту: Project Settings → Workflows

При изменении Workflow Scheme у проекта с существующими задачами Jira запустит маппинг статусов. Все задачи в старых статусах нужно перевести в новые. Подготовьтесь к этому заранее.

7. Частые ошибки

Слишком много статусов

Видел Workflow с 15+ статусами. Команда не понимает где задача, отчёты не читаются. Держите workflow простым: максимум 7-8 статусов.

Global Transition "To Do" (любой → любой)

Соблазнительно добавить переход из любого статуса в любой "для гибкости". В итоге никто не понимает текущее состояние задачи. Делайте только те переходы которые реально нужны.

Забыть про Sub-task workflow

Sub-task имеет свой отдельный workflow. Если закрыть родительскую задачу не закрыв подзадачи — Jira не предупредит (если не добавить Validator). Всегда добавляйте Sub-Tasks Must Be Complete на переход в Done.

Редактировать активный workflow

Если сделать ошибку в опубликованном workflow который используется в продакшн-проекте — придётся заново создавать Draft. Всегда тестируйте на тестовом проекте.