Внедрение JIRA Software #1. Теоретические основы

Внедрение JIRA Software

С данной статьи начинаю цикл статей по внедрению и настройке 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: Пользователь => Группа => Схема прав доступа => Проект

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

  • Понравилось? Добавьте в избранное или поделитесь с друзьями:

Добавить комментарий

Ваш e-mail не будет опубликован.