ГлавнаяБлогИнструменты

Как настроить Jira для Scrum-команд: пошаговое руководство

09.09.2025

Jira — один из самых мощных инструментов для управления разработкой и проектами. Для Scrum-команды корректная настройка Jira — не просто удобство, это условие предсказуемости, прозрачности и качества поставок. Неправильная конфигурация ведёт к шуму в процессах, ошибочным метрикам и раздутым бэклогам; правильная — экономит часы и даёт менеджерам и командам ясную картину прогресса.

Это руководство шаг за шагом поможет вам настроить Jira под Scrum: от создания проекта и типов задач до автоматизации, отчётности и практик, которые сохранят фокус команды на доставке ценности.

Перед началом: что обсудить с командой

Прежде чем нажать «Создать проект», важно договориться о нескольких вещах:

  • какие типы задач будут использоваться (Epic, Story, Task, Bug, Sub-task);
  • единица оценки (story points или человеко-часы);
  • Definition of Done и Definition of Ready;
  • спринт-длительность (обычно 1–4 недели);
  • кто будет Product Owner, Scrum Master, и кто отвечает за администрирование Jira;
  • какие интеграции нужны (Confluence, Bitbucket/GitHub, CI/CD, Slack).

Эти договорённости упростят конфигурацию и помогут избежать массовой переделки позже.

Этап 1: создание проекта Scrum

В Jira выберите «Создать проект» → шаблон «Scrum» (Cloud) или «Scrum software development» (Server/Data Center). Назовите проект, задайте ключ (project key) — короткий идентификатор, который будет в ID задач (например, PROJ).

При создании обратите внимание на:

  • Тип шаблона: «Scrum» для команд, которые любят спринты; «Kanban» — для непрерывных потоков (сервис, поддержка).
  • Project lead / Administrator: назначьте человека, ответственным за настройки и управление правами.

Этап 2: настроить типы задач и схемы

По умолчанию Jira содержит стандартные типы задач, но их лучше согласовать и упростить:

  • Epic — крупная область/функция;
  • Story — пользовательская история/функционал;
  • Task — техническая работа/инфраструктура;
  • Bug — дефект;
  • Sub-task — дробление задач на подзадачи.

Создайте схему экранов (Screen Scheme) для Create/View/Edit, чтобы при создании Story были обязательные поля: Summary, Description, Acceptance Criteria, Story Points (если используете), Epic Link, Components, Labels.

Этап 3: настраиваем поля для Scrum

Ключевые поля, которые стоят добавить и сделать видимыми в бэклоге и карточках:

  • Story Points — числовое поле для оценок; если вы используете story points, добавьте кастомное поле и настройте его видимость;
  • Priority — приоритет видим в списке;
  • Epic Link / Parent Link — для привязки Story к Epic;
  • Fix Version(s) — версия релиза (используется для релиз-планирования);
  • Components — модули или подсистемы продукта;
  • Labels — для ад-hoc фильтров и поиска;
  • Acceptance Criteria — текстовое поле для приемочных условий;
  • Definition of Ready met — чекбокс/флаг, если вы практикуете DoR.

Уберите лишние поля, которые не используются — минимализм повышает скорость работы и снижает шум.

Этап 4: workflow — простой и понятный

Workflow (рабочий процесс) — основа верных метрик. Для Scrum-команды рекомендуем базовый workflow:

Open -> In Progress -> In Review -> Done
Open -> To Do (опционально)
In Progress -> Blocked (если нужна отметка)

Важные практики при настройке workflow:

  • используйте минимальное количество статусов — каждый статус увеличивает сложность;
  • настройте Conditions и Validators — например, при переходе в Done обязать заполнить Acceptance Criteria и иметь пройденные тесты;
  • добавьте Post-functions — автоматические действия при переходе: назначить релиз, снять блокер, уведомить владельца;
  • если планируете автоматизацию — интегрируйте workflow с Jira Automation or ScriptRunner для сложных сценариев.

Этап 5: настройка доски Scrum

Доска — основной рабочий инструмент команды. Перейдите в Board settings и настройте:

  • Columns — соответствуют статусам workflow. Сгруппируйте статусы так, чтобы отражать реальный поток;
  • Swimlanes — по Epic, по приоритетам или по assignee; чаще всего удобны swimlanes «by Epic» или «by Queries»;
  • Quick filters — фильтры вида «My issues», «Bugs», «High priority», «Blocked»;
  • Card layout — укажите какие поля показывать на карточке: Story Points, Assignee, Priority;
  • Estimation — если вы используете story points, включите их в настройках доски. Можно выбрать «Estimation: Story points»;
  • Working days — задайте рабочие дни, чтобы отчёты (burndown) корректно считались.

Проверьте board filter — JQL запрос, который определяет набор задач для доски. Убедитесь, что в JQL включены нужные Issue Types, статусы, проект и версии.

Пример. Базовый фильтр для Scrum-доски

project = "PROJ" AND issuetype IN (Story, Bug, Task, Epic) AND status IN ("To Do", "In Progress", "In Review", "Done")

Показывает только задачи проекта PROJ, относящиеся к указанным типам и находящиеся в нужных статусах.

Этап 6: бэклог и спринты — правила работы

Бэклог — сердце Scrum. Настройте его так, чтобы менеджмент и команда могли быстро приоритизировать и планировать:

  • используйте Epic для крупной функциональности и Fix Version для релизов;
  • включите в карточку Story поле Acceptance Criteria и DoR чекбокс;
  • делите большие истории на MMF (minimum marketable feature) или технические таски;
  • настройте фильтры в бэклоге для просмотра только готовых к планированию задач (DoR = true);
  • во время Sprint Planning используйте планирование по capacity: проверьте доступность команды и суммируйте story points в спринт.

Рекомендуемая практика — держать бэклог «зрелым» на 2–3 спринта вперёд: детализируйте ближайшие задачи, верх бэклога.

Этап 7: роли и права доступа

Jira имеет гибкую модель прав. Настройте схемы так, чтобы:

  • Product Owner имел права редактировать backlog, версии и компоненты;
  • Scrum Master имел права администрирования доски и управления спринтами (start/complete sprint);
  • Разработчики имели права transition/assign/resolve;
  • QA имел права на просмотр и создание багов, а также запуск автотестов (если используется интеграция).

Используйте группы (groups) и роли (project roles) вместо назначения прав пользователям поимённо — так проще масштабировать и поддерживать безопасность.

Этап 8: отчётность и дашборды

Отчёты — то, на что менеджеры смотрят ежедневно. Базовый набор:

  • Burndown chart — показывает прогресс спринта (work remaining vs time);
  • Velocity chart — средняя скорость команды (story points per sprint);
  • Control chart — cycle time / lead time;
  • Epic burndown / Release burndown — для релизного планирования;
  • Custom dashboards — виджеты: Filter Results, Created vs Resolved, Cumulative Flow Diagram (CFD).

Совет: создайте дашборд «Team health» с показателями: sprint burndown, velocity, open bugs, blocked issues. Публикуйте дашборд в еженедельных отчетах.

Этап 9: автоматизация процессов

Jira Automation (Cloud) или Automation for Jira (Server) дают мощный набор триггеров и действий. Примеры полезных автоматизаций:

  • при переходе Story в Done автоматически проставлять Fix Version = текущая версия релиза;
  • если статус = Blocked — уведомлять Slack-канал и назначать тег „blocked“;
  • при создании баг-типа автоматически назначать priority = High если label = production;
  • еженедельное создание отчёта и рассылка по email о состоянии бэклога.

Автоматизация снижает рутину и гарантирует, что ключевые поля заполнены последовательно.

Этап 10: интеграции с Confluence, SCM и CI/CD

Интеграции делают Jira полноценной средой разработки:

  • Confluence — храните спецификации, критерии приёмки и definition of done рядом с задачами (ссылки в Description или issue links);
  • Bitbucket/GitHub/GitLab — прикрепляйте коммиты, pull-requests к задачам, чтобы видеть код прямо в задаче;
  • CI/CD (Jenkins/GitLab CI/Bitbucket Pipelines) — автоматическое обновление статусов при успешном билде/деплое;
  • Slack/MS Teams — события Jira → уведомления в каналах (компилируйте только важные события: релизы, блокеры, критические баги).

Связь Jira → CI/CD помогает быстро определить, какой релиз содержит фикс и какие тесты упали.

Практические советы: как не сломать метрики

  • не меняйте структуру workflow в середине спринта — это «ломает» отчёты;
  • ограничьте использование custom fields — каждый новый поле влияет на UI и фильтры;
  • используйте JQL для точных фильтров и сохранённых запросов (например, «Sprint in openSprints() AND assignee = currentUser()»);
  • периодически чистите проект: архивируйте старые версии, удаляйте неиспользуемые компоненты и метки;
  • обучите команду правилам работы: как создавать задачу, что писать в Acceptance Criteria, когда переносить Story между спринтами.

Частые ошибки и как их избежать

  • Слишком детализированный workflow. Решение: упростите статусы и используйте метки/fields для дополнительной информации.
  • Использование story points на все типы задач. Решение: оценивайте баги в отдельной шкале или делите на types (новая функциональность — story points, баги — время/priority).
  • Нечёткие Acceptance Criteria. Решение: добавьте шаблон для описания критериев в Description и сделайте их обязательными через Validator.
  • Перемешивание проектов на одной доске. Решение: используйте отдельные boards или scope в JQL (project = PROJ AND issuetype in (Story, Bug)).
  • Изменение оценок mid-sprint. Решение: запретите редактирование story points после начала спринта — это сохраняет доверие к velocity.

Настройка под масштабирование (несколько команд)

Если в продукт вовлечено несколько Scrum-команд, подумайте о следующих подходах:

  • унификация полей и workflow для всех команд — это упрощает агрегирование метрик;
  • использование одной общей Product Backlog (один проект) и отдельных boards для команд;
  • Epic как инструмент координации между командами; добавьте поле «Team» или компонент для распределения задач;
  • использование Advanced Roadmaps (Jira Premium) для планирования на уровне программы/релиза;
  • создание шаблонов проектов и shared schemes для упрощения создания новых команд.

Культура использования Jira — важнее настроек

Инструмент — всего лишь отражение процессов и культуры. Если команда продолжит работать «в стол», а не синхронизироваться ежедневно — никакая конфигурация не поможет. Внедряйте правила: ежедневные стендапы у доски, ретроспективы, регулярные grooming и дисциплина в заполнении полей. Администратор Jira должен регулярно проводить «чистку» и обучать новых участников.

Готовый чек-лист внедрения

  1. Создать проект Scrum и назначить администратора;
  2. Согласовать типы задач и поля (Story Points, Epic Link, Acceptance Criteria);
  3. Настроить простой workflow (To Do → In Progress → In Review → Done);
  4. Сконфигурировать доску: колонки, swimlanes, quick filters, card layout;
  5. Определить DoR и DoD и сделать их видимыми в задачах;
  6. Настроить роли и права доступа через Project Roles;
  7. Внедрить автоматизации (CI/CD триггеры, уведомления о блокерах);
  8. Создать dashboards: Sprint burndown, Velocity, Team health;
  9. Интегрировать с Confluence и SCM/CI;
  10. Провести тренинг для команды и запуск пилота.

Заключение

Правильная настройка Jira для Scrum-команд — это комбинация технических конфигураций и организационных практик. Минимальный «рабочий набор» — корректные типы задач, простой workflow, виды для доски, ясные Acceptance Criteria и автоматизация ключевых шагов (CI/CD, уведомления, post-functions). Но без дисциплины команды и процессов никакой инструмент не даст желаемого эффекта.

 

Если вы хотите, мы поможем: проведём быструю диагностику вашей текущей конфигурации Jira, настроим проект под ваши Scrum-практики, внедрим автоматизации и обучим команду. Напишите нам — и мы подготовим план настройки с оценкой сроков и выгод.

Получить консультацию

Популярные статьи по теме

Посмотреть все статьи