1. Типы проектов в Jira

В Jira Software существует два основных типа проектов, и выбор между ними нужно делать до создания — изменить тип потом не получится.

Team-managed (Next-gen) проекты

Упрощённые проекты с минимальными настройками. Идеально для:

  • Небольших команд без сложных процессов
  • Быстрого старта без администраторских знаний
  • Экспериментальных проектов

Ограничения: нельзя использовать глобальные схемы, ограниченные возможности кастомизации.

Company-managed (Classic) проекты

Полнофункциональные проекты с поддержкой всех схем. Используйте если:

  • Нужны сложные workflow с условиями и постфункциями
  • Несколько проектов должны делить общие настройки
  • Требуются тонкие настройки прав доступа
  • Это production-среда с SLA и отчётностью
В корпоративной среде всегда создавайте Company-managed проекты. Team-managed хорошо смотрятся в демо, но быстро упираются в ограничения когда бизнес-требования усложняются.

2. Схемы: что это и зачем

Схемы — это переиспользуемые наборы настроек, которые можно применить к нескольким проектам. Это один из главных принципов администрирования Jira: настраивайте один раз, применяйте везде.

Основные типы схем:

  • Permission Scheme — кто что может делать в проекте
  • Notification Scheme — кто получает email-уведомления
  • Issue Type Scheme — какие типы задач доступны
  • Workflow Scheme — какой workflow используется для каждого типа задачи
  • Screen Scheme — какие поля показывать при создании/просмотре/редактировании
  • Field Configuration Scheme — обязательность и видимость полей

Путь к управлению схемами: ⚙️ Administration → Issues

3. Permission Scheme: права доступа

Permission Scheme определяет кто может выполнять каждое действие в проекте. Вот ключевые права которые настраивают чаще всего:

Browse Projects       — просматривать проект
Create Issues         — создавать задачи
Edit Issues           — редактировать любые задачи
Assign Issues         — назначать исполнителя
Resolve Issues        — переводить в статус Resolved
Close Issues          — закрывать задачи
Delete Issues         — удалять задачи
Manage Sprints        — управлять спринтами
View Voters/Watchers  — видеть кто следит за задачей

Для каждого права можно назначить несколько субъектов:

  • Project Role — рекомендуемый способ
  • Group — группа пользователей Jira
  • Single User — конкретный пользователь (избегайте)
  • Reporter, Assignee, Project Lead — динамические
Никогда не назначайте права напрямую на пользователей. Когда сотрудник уйдёт — придётся вручную убирать его из каждой схемы. Используйте только Project Roles и Groups.

Пример: настройка для разработческой команды

Browse Projects:
  → Project Role: Developers
  → Project Role: QA
  → Project Role: Project Managers
  → Group: jira-software-users

Create Issues:
  → Project Role: Developers
  → Project Role: QA

Edit Issues:
  → Project Role: Developers
  → Project Role: Project Managers

Delete Issues:
  → Group: jira-administrators

4. Project Roles vs Groups

Это частый источник путаницы. Ключевое отличие:

  • Groups — глобальные группы пользователей. Один и тот же пользователь входит в группу во всех проектах.
  • Project Roles — роль привязана к проекту. Один пользователь может быть Developer в проекте A, но Project Manager в проекте B.

Создать роль: ⚙️ Administration → System → Project Roles

Назначить пользователей в роль в конкретном проекте: Project Settings → People

Стандартные роли которые я рекомендую

Administrators   — Project Leads, ответственные за проект
Developers       — разработчики, QA
Viewers          — стейкхолдеры, только просмотр
Service Desk     — для SD-проектов

5. Notification Scheme

Правильно настроенные уведомления — залог того что команда не утонет в письмах. По умолчанию Jira шлёт уведомления слишком агрессивно.

Рекомендуемая минимальная настройка:

Issue Created:
  → Reporter
  → Project Lead (если нужен контроль)

Issue Updated:
  → Current Assignee
  → Reporter (опционально)
  → All Watchers

Issue Assigned:
  → Current Assignee (обязательно!)

Comment Added:
  → Current Assignee
  → Reporter
  → All Watchers
Уберите из уведомлений "All Members of Project Role: Developers" на событие Issue Updated — иначе при каждом изменении любой задачи вся команда получит письмо.

6. Issue Type Schemes

Issue Type Scheme определяет какие типы задач доступны в проекте. Стандартные типы:

  • Story — пользовательская история (Scrum)
  • Task — обычная задача
  • Bug — ошибка
  • Epic — крупный функциональный блок
  • Sub-task — подзадача (всегда есть по умолчанию)

Создать кастомный тип: ⚙️ Administration → Issues → Issue Types → Add Issue Type

7. Практические советы

Называйте схемы по смыслу, не по проекту

# Плохо:
"PROJ Permission Scheme"
"DEV-2024 Permission Scheme"

# Хорошо:
"Development Teams - Standard Permissions"
"Read-Only Viewer Permissions"

Документируйте изменения

У схем нет встроенного changelog. Заведите Confluence-страницу или просто текстовый файл где фиксируете: что изменили, когда, зачем.

Тестируйте на отдельном проекте

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

Регулярный аудит прав

# Как посмотреть кто имеет права в проекте:
Project Settings → Permissions → View (кнопка рядом с каждым правом показывает конкретных пользователей)