С данной статьи начинаю цикл статей по внедрению и настройке JIRA Software (далее JIRA). Изначально не хотел писать цикл данных статей, так как JIRA развивается быстрыми темпами и в будущем цикл статей может устареть. Однако чувство помощи другим взяло верх, поэтому если вы этот цикл статей читаете в 2999 году, то не судите строго за актуальность данного материала.
Начнём мы с вами с азов и постепенно будем двигаться погружаясь в тонкости системы. Об установке системы мы с вами говорить не будем, так как ничего сложного в установке системы нет, поэтому этот момент мы опустим. Мастер установки у JIRA Software простой и интуитивно понятный.
После того как мы установили систему нам требуется систему полностью настроить, а для этого мы должны знать о сущностях системы и их взаимосвязях. В данной статье кратко пройдёмся по теории и сущностям, а в следующих статьях начнём на практике осваивать настройку JIRA.
Проект
В JIRA центральное место занимает «Проект». В разных организациях под проектом понимают различные сущности. В организациях, в которых я работал, а также в которых выстраивал работу в рамках JIRA, бралось за правило, что «проект JIRA» = «разрабатываемому программному продукту». К примеру, если у кого-то в организации разрабатывается два программных продукта «УХО» и «НОС», то в JIRA создаётся два проекта с аналогичным названием.
Кто-то проекты воспринимает в том понимании, в котором его привыкли воспринимает проектные менеджеры. В этом случае, если у нас по «УХО» ведутся постоянные проекты по внедрению и реализации какого-либо функционала, то в JIRA на одно программное обеспечение «УХО» заведут десятки проектов. Это неудобно и со временем забивает JIRA простынями проектов, в каждом из которых будет всего по нескольку десятков задач.
В связи с вышесказанным рекомендую следовать правилу при создании проектов: 1 разрабатываемый продукт = 1 проект в JIRA. На вопрос «Как разделять в JIRA проекты по одному разрабатываемому продукту, если для реализации функционала запускается проектная деятельность менеджера по проекту?» ответ простой «Эпиками» и о них мы упомянем дальше.
Запрос
В JIRA все задачи, подзадачи, доработки ошибки, называются Запросами. Т.е. у нас есть запросы различных категорий: ошибка, задача, подзадача и т.д. Перед началом настройки вам требуется определиться, какие типы запросов вам нужны в системе. В системе есть как стандартные типы запросов, которые можно править и удалять, так можно создавать и свои типы запросов.
Стандартный набор:
• Ошибка
• Задача
• Подзадача
• Улучшение
• Доработка
• Эпик
Каждый проект может иметь свой набор запросов.
Немного отвлечёмся на Эпик. Эпик — это, по сути, большая пользовательская история, способ описания требований к разрабатываемой системе. Эпик, как правило, используется для описания крупных и сложных элементов, разработок продукта. В рамках Эпика можно вести проекты по разрабатываемому продукту менеджерам проектов, в этом случае все задачи в рамках проектной деятельности группируются Эпиками.
Схемы типов задач
Схемы типов задач отвечают за доступность определённых типов задач в каждом проекте.
Чтобы запросы определённых типов были доступны в проекте необходимо:
1. Создать схему типов задач.
2. Добавить в схему определённые типы задач.
3. Привязать к проекту схему типов задач.
Бизнес-процессы
У каждого типа запроса может быть свой жизненный цикл. За это отвечают настраиваемые схемы бизнес-процессов. В схемах бизнес процессов мы указываем, какой тип запроса, по какому бизнес-процессу может двигаться. Пример: Новое => В работе => Проверка => Завершено
Экраны
За отображение на карточке запроса определённых полей отвечают экраны. Экран позволяет настраивать какие поля, и данные будут видеть пользователи при открытии карточки задачи, ошибки и т.д.
Есть также такие сущности как «схемы экранов» и «схемы экранов для типов задач», которые привязываются к проекту и позволяют настраивать отображение различных полей для различных типов запросов.
Настраиваемые поля
Если нам не хватает стандартных полей в наших проектах и запросах, то мы можем создать свои поля с различными типами: выпадающие списки, текстовые, группы и т.д. В полях можно задавать предустановленные значения. Поля к проектам привязываются через «схемы конфигураций полей».
Приоритеты
У задач есть приоритеты: критический, высокий, низкий и т.д. У каждого проекта могут быть свои приоритеты. Это делается благодаря созданию «схем приоритетов» и привязки их к проектам.
Статусы
Бизнес-процессы используют статусы (Новое => В работе => Проверка => Завершено) и они как раз могут гибко нами настраиваться, удаляться, редактироваться.
Оповещения
В системе есть схемы оповещений, благодаря которым мы гибко настраиваем оповещения о различных действиях в различных проектах.
Схема прав доступа
К проектам привязываются схемы прав доступа. К одному проекту может быть привязана одна схема прав доступа. Схема прав доступа содержит перечень различных разрешений проекта для конкретных пользователей или групп.
Чтобы пользователь получил доступ к определённому проекту и мог что-либо в проекте делать нам необходимо, чтобы его добавили в схему прав доступа определённого проекта и предоставили определённое разрешение или же он должен быть включён в определённую группу, а в схему прав доступа уже добавляется группа. Рекомендую использовать второй вариант, так как он правильный и позволяет облегчить вам управление JIRA.
Вариант 1: Пользователь => Схема прав доступа => Проект.
Вариант 2: Пользователь => Группа => Схема прав доступа => Проект
В данной статье дан минимальный набор теоретических знаний, чтобы у вас в голове сложилось общее представление. В следующих статьях приступим к настройке всего вышеописанного.
Весь цикл статей:
#1. Теоретические основы (текущая статья)
#2. Типы и схемы типов задач
#3. Описание статусов и бизнес-процессов
#4. Создание статусов и бизнес-процессов
#5. Создание экранов и схем экранов
#6. Создание настраиваемых полей
#7. Создание приоритетов и схем приоритетов
#8. Создание схем оповещения
#9. Создание групп, ролей и схем прав доступа
#10. Создание и настройка проекта
#11. Полезные инструменты и методы работы
вести проекты отдельно в каком-то смысле может и удобнее, но бизнес-процессы у каждого направления деятельности сильно разнятся. А так как к 1 проекту можно подключить только 1 схему типов запросов — то получается, что эффективнее будет работать всё, если создавать проекты по направлениям, а эпики по продуктам/релизам и тд.
В Jira «релизы» являются отдельной сущностью и эпики для этого не нужны.
В проекте разным типам запросов можно присваивать отдельные бизнес-процессы.