Как настроить 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 должен регулярно проводить «чистку» и обучать новых участников.
Готовый чек-лист внедрения
- Создать проект Scrum и назначить администратора;
- Согласовать типы задач и поля (Story Points, Epic Link, Acceptance Criteria);
- Настроить простой workflow (To Do → In Progress → In Review → Done);
- Сконфигурировать доску: колонки, swimlanes, quick filters, card layout;
- Определить DoR и DoD и сделать их видимыми в задачах;
- Настроить роли и права доступа через Project Roles;
- Внедрить автоматизации (CI/CD триггеры, уведомления о блокерах);
- Создать dashboards: Sprint burndown, Velocity, Team health;
- Интегрировать с Confluence и SCM/CI;
- Провести тренинг для команды и запуск пилота.
Заключение
Правильная настройка Jira для Scrum-команд — это комбинация технических конфигураций и организационных практик. Минимальный «рабочий набор» — корректные типы задач, простой workflow, виды для доски, ясные Acceptance Criteria и автоматизация ключевых шагов (CI/CD, уведомления, post-functions). Но без дисциплины команды и процессов никакой инструмент не даст желаемого эффекта.
Если вы хотите, мы поможем: проведём быструю диагностику вашей текущей конфигурации Jira, настроим проект под ваши Scrum-практики, внедрим автоматизации и обучим команду. Напишите нам — и мы подготовим план настройки с оценкой сроков и выгод.