После установки Jira Core (описанной в предыдущей статье из цикла статей инструменты для DevOps) необходима базовая настройка для работы с заявками.
Итак. С чего начать.
Начинать ( как и во многих случаях при конфигурации ИТ систем) лучше с чистого листа бумаги. На нем Вы изложите структуру Вашей компании (той ее части, которая будет работать с JIRA), опишите функционал каждой группы сотрудников. Также необходимо будет описание жизненного цикла заявки: Как она попадет в систему, кем будет обрабатываться, кем будет согласовываться и контролироваться. Не лишним будет продумать, какие типы заявок и какие поля в задаче будут нужны. Такое планирование необходимо, если вы не хотите потом переделывать заново. Если вы не готовы ответить на эти вопросы, я рекоменудю вам проконсультироваться с опытными архитекторами подобных решений. Наша компания, как всегда к вашим услугам J Или же начать с самого простого, и посмотреть в процессе работы, что вам потребуется. Но помните. Это долгий путь. И помните, что рано или поздно вы можете прийти к мысли о том, что все это нужно удалить, спланировать и установить заново.
В прошлой статье мы остановились на экране:
Еще момент: я буду строить систему управления задачами для небольшой компании, занимающейся оказанием услуг в сфере ИТ. Компания находится на стадии роста со всеми вытекающими «болезнями» детского периода. Поскольку в компании все делают все, то создадим 1 проект, и назовем его «Котел», в котором будут вариться наши задачи.
Приступим к настройке Jira. После того, как я нажала кнопку «Создать новый проект» система предложила мне 3 шаблона проекта, по сути отличающихся только бизнес-процессом (то есть жизненным циклом задачи). Их можно охарактеризовать как Простой, Средний и Сложный. Был выбран Средний вариант, указано имя проекта и проект готов.
Далее. С этим проектом должен кто-то работать. Давайте знакомиться. (Все имена вымышлены, а совпадения случайны). В моей компании есть Директор. Его зовут Виктор. Он является генератором идей, тепловозом, который заставляет компанию двигаться вперед, а еще выполняет обязанности связанные с поиском клиентов, заключением договоров, поиском сотрудников, развитием компании, ведением проектов и прочей рутиной каждого сотрудника компании. Частенько норовит часть задач спихнуть на других. Таня – занимается развитием компании: продвижением информационных ресурсов, подготовкой коммерческих предложений, является контактным лицом для всех клиентов, которые приходят с информационных ресурсов, подхватывает задачи, упущенные Виктором. Роман – ответственный за финансовую сторону вопросов. Максим – технический специалист, поддерживающий внутреннюю инфраструктуру компании. Роман и Максим могут выступать в роли руководителей проектов, а также вместе с Таней заниматься решением технических задач различного уровня сложности. За каждым из членов команды могут стоять «роботы», то есть специалисты различных областей, которые занимаются только выполнением конкретно поставленных задач.
Создадим пользователей для каждого члена команды и две группы: «Команда» и «Роботы». В группу Команда добавим созданных пользователей. А группу Роботы будем наполнять по мере создания новых пользователей для выполнения конкретных задач.
Перейдем к настройке Jira, а именно в раздел «Администрирование» -> «Управление пользователями» (скриншот с готовыми пользователями и группами) Совет: При работе с системами авторизации заранее продумывайте политики именования учетных записей и других объектов. Четкие правила позволят избежать путаницы и упростят автоматизацию, когда масштабы системы разрастутся.
Теперь нужно настроить Jira так, чтобы нужные пользователи умели выполнять нужные задачи. За это отвечают схемы безопасности. Хотелось бы, чтобы Команда видела все задачи, Роботы видели только каждый свои задачи. А задачи, касающиеся бухгалтерии видели только Виктор и Роман.
Для того, чтобы это реализовать я буду использовать схему безопасности задачи.
Создам новую схему безопасности задачи myISS, в которой создам несколько уровней безопасности:
- myISL_Standard (по умолчанию)
- myISL_Buh
Теперь перейдем к схеме распределения прав самого проекта. Проект «Котел» использует Default Permission Scheme. Значения выставленные по умолчанию достаточны для начала работы. Однако для того, чтобы заработали настроенные нами ограничения, нужно при создании задачи разрешить установку Issue Security.
Теперь я готова пройтись по основным настройкам проекта. Я:
- Изменю Project Lead и Default Assignee. Им будет Виктор.
- Добавлю созданную ранее схему безопасности задач в разделе Permissions.
- Поработаю с жизненным циклом задачи, чтобы адаптировать его под наши нужды.
Если с первыми 2мя пунктами все понятно, то по последнему — стоит пояснить. В нашей компании наблюдается острая нехватка контроля выполнения задач. Задачи ставятся, выполняются и … забываются. В связи с чем, хочется сделать акцент на финальной точке. Нужно чтобы автор задачи подтвердил качество ее выполнения. Поэтому к стандартному Workflow для задач нашего проекта, который, к слову, выглядит так:
Необходимо добавить еще 1 статус «Close». Сделаем это:
Теперь наш Workflow выглядит так:
Я намеренно не буду рассказывать об автоматизациях, которые можно настроить в Jira в процессе прохождения задачей ее жизненного цикла, поскольку это тема отдельной статьи.
Собственно – практически все. Для отделения собственных задач от общего потока можно использовать фильтры, которые настраиваются централизованно для всех пользователей или каждый сотрудник может сделать для себя самостоятельно. Также как и Дашборды, отображающие некоторую отчетность и другие, полезные для агрегации информации гаджеты.
Система готова для использования, а как сделать ее более удобной –читайте в наших будущих публикациях или обращайтесь за помощью к нашим специалистам [email protected]