связь mentioned in в jira что обозначает
Использование Jira Query Language на практике
Меня зовут Сергей Раков, я руководитель B2G-направления в компании «Ростелеком ИТ». Я хочу рассказать про язык Jira Query Language (JQL): как им пользоваться на практике, основные приемы, с какими проблемами мы сталкивались и как их решали.
Оригинал картинки взят у deviniti.com/atlassian
Таск-трекеров очень много, каждый подходит для решения одних задач и не очень помогает решать другие. Многими из них мы пользовались, но сейчас остановились на Jira — она наш основной инструмент. Лично мне очень нравится ее язык JQL, который сильно упрощает работу и позволяет из коробки иметь мощный и гибкий инструмент для поиска тикетов.
Из коробки в Jira существуют базовый и продвинутый поиски. Эти два варианта поиска позволяют решить бóльшую часть стоящих перед пользователем задач. Базовый поиск привычен глазу любого человека, кто хоть раз пользовался услугами интернет-магазинов — работает по точно такой же простой схеме. Есть множество фильтров: по проектам, типам задач, по исполнителю и статусу. Также можно добавить дополнительные поля по критериям, которые поддерживаются Jira.
Но возникает проблема, если нужно выйти за рамки базовых запросов. Например, если мы хотим найти задачи, которые были на конкретном исполнителе когда-либо, или найти все задачи, исключая один проект. Сделать хитрую выборку для проекта с одним статусом задач и исполнителем и еще одним исполнителем и другим статусом задач силами базового поиска уже сделать нельзя.
На помощь приходит продвинутый поиск. Синтаксис JQL очень похож на SQL. Но в JQL не нужно выбирать конкретные поля, которые будем селектить, указывать таблицы и базы данных, из которых будем выводить. Мы указываем только блок с условиями и работаем с сортировкой — все остальное Jira автоматически делает сама.
Jira при вводе в строку поиска сама выдает подсказки всех возможных значений, которые вы ищете: как по полям, так и по значениям этих полей. Для себя я недавно открыл интересное системное поле lastViewed. Jira хранит историю ваших просмотров тикетов.
Здесь представлены два варианта составления фильтров для просмотра последних задач. Первый — мой вариант с lastViewed, где Jira выдаст просмотренные мной задачи за последние семь дней, отсортированные по убыванию. Этот фильтр настроен на моем дашборде в виде гаджета, и я к нему часто прибегаю. Потому что тикет закрылся, вкладку и номер не запомнил, быстро открыл, посмотрел, какой был последний тикет.
Есть стандартный фильтр Viewed Recently. Он использует функцию IssueHistory(), сортировка тоже производится по полю lastViewed. Результат одинаковый, но способ, даже в Jira, можно использовать разный. Стоит отметить, что поле LastViewed и IssueHistory() возвращают только вашу историю просмотра — историю третьих лиц таким образом посмотреть не получится.
По большей части в Jira все операторы стандартные. Мне больше всего нравятся операторы WAS, WAS IN, WAS NOT IN, WAS NOT, CHANGED, потому что они работают с временем. В обычных базах данных такой возможности нет.
Jira из коробки позволяет работать с историческими данными. С помощью оператора WAS можно найти тикеты, где исполнителем был и есть User1. Если тикет был на мне, а потом перешел на кого-то еще, запрос покажет, что этот тикет когда-то был на мне. Понятно, что для более подробной выборки нужно добавить еще какие-нибудь условия, но мы к этому еще подойдем.
Правда, есть одна оговорка: Jira не хранит историю для текстовых полей: названий тикетов и их описаний. Там нельзя написать: «Выведи мне тикеты, в которых поле Summary содержало слово “Ростелеком”».
Связывание задач
Связывание задач (Issue linking) позволяет создать связь между двумя существующими задачами на одном или разных серверах JIRA. Например:
(Ваш администратор JIRA может настраивать типы связей, которые вам потребуется создать.)
Связывание задач также позволяет:
Связи задачи в пределах задачи выглядят следующим образом:
Скриншот: раздел «Связи задачи» (Issue Links) в пределах задачи
Примечание: Решенные задачи (то есть задачи с установленной резолюцией) отображаются зачеркнутым шрифтом, например, DEMO-1.
Создание связи между задачами, находящимися на одном и том же сайте JIRA
Для того, чтобы создать связь между задачами, находящимися на одном и том же сайте JIRA, необходимо выполнить следующие шаги:
1. Откройте задачу, которую вы хотите связать с другой задачей на том же сайте JIRA.
2. Выберите «Дополнительно» (More)> «Связь» (Link), чтобы отобразить диалоговое окно «Связь» (Link).
Комбинация клавиш ‘.’ + Начать вводить ссылку
3. Убедитесь, что элемент «Задача JIRA» (JIRA Issue) выбран в левой части диалогового окна, а затем выберите тип связи из раскрывающегося списка «Эта задача» (This issue).
Если ваш системный администратор JIRA настроил полностью взаимные связи приложений между сайтом JIRA и другим сервером, выпадающий список «Сервер» (Server) может появиться над списком «Эта задача» (This issue). Если это так, убедитесь, что ваш сайт JIRA появился или был выбран из списка серверов.
4. В поле «Задачa» (Issue) укажите задачу(и), связанную с вашей просматриваемой / выбранной задачей. Есть два способа сделать это:
Если вы ранее просматривали задачу, вы можете быстро найти эту задачу, введя первые несколько букв ключа задачи (или часть резюме), которые будут отображаться в раскрывающемся списке «автозаполнение» для выбора.
5. Необязательно: добавьте комментарий (Comment), чтобы описать, почему вы связываете эти задачи.
6. Нажмите кнопку «Связь» (Link) в нижней части диалогового окна.
Создание связи между задачами, находящимися на разных сайтах JIRA
Чтобы создать этот тип связи, системный администратор JIRA должен был настроить полностью взаимные связи приложений между сайтом JIRA и другим сайтом JIRA, содержащим задачи, с которыми вы хотите установить связь.
Эта функция недоступна в Облаке Atlassian
Для того, чтобы создать связь между задачами, находящимися на разных сайтах JIRA, выполните следующие шаги:
1. Откройте задачу, которую вы хотите связать с другой задачей.
2. Выберите «Дополнительно» (More)> «Связь» (Link), чтобы отобразить диалоговое окно «Связь» (Link).
комбинация клавиш: ‘.’ + Начать вводить ссылку
3. Убедитесь, что элемент «Задача JIRA» (JIRA Issue) выбран в левой части диалогового окна.
Примечание:
Это поведение означает, что связки на приложения, настроенные между вашим сайтом JIRA и удаленным сайтом JIRA, используют аутентификацию OAuth.
4. Если ваш сайт JIRA подключен к нескольким удаленным сайтам JIRA, выберите соответствующий сайт JIRA из раскрывающегося списка «Сервер» (Server).
5. Выберите тип связи из раскрывающегося списка «Эта задача» (This issue).
6. Введите в поле «Задача» (Issue) ключ задачи, находящейся на удаленном сайте JIRA, на которую вы хотите установить ссылку. Кроме того, вы можете искать задачи, находящиеся на удаленном сайте JIRA, нажав на ссылку «поиск задачи» (search for an issue), которая открывает всплывающее окно «Найти задачи JIRA» (Find JIRA issues).
Вы можете ссылаться на любую задачу на удаленном сайте JIRA, к которой у вас есть доступ на этом сайте.
7. Установите флажок «Создать взаимную связь» (Create reciprocal link), чтобы создать дополнительную связь на удаленную задачу, на которую вы ссылаетесь, назад к вашей задаче. Например, если вы создаете тип связи блоков для удаленной задачи, то обратная связь, сгенерированная при удаленной задаче, будет заблокирована по типу связи обратно к вашей локальной задаче.
8. Необязательно: добавьте комментарий (Comment), чтобы описать, почему вы связываете эти задачи.
9. Нажмите кнопку «Связь» (Link) в нижней части диалогового окна.
Исправление проблем
Проблема: Если вы выбрали флажок «Создать взаимную связь» (Create reciprocal link), но после нажатия кнопки «Связь» (Link) выяснилось, что обратная связь с удаленной задачи JIRA на вашу задачу JIRA не была создана. Скорее всего, ваш системный администратор JIRA создал только одностороннюю связь с вашего сайта JIRA на удаленный сайт JIRA.
Решение: Попросите администратора системы JIRA полностью настроить взаимные связи приложений между сайтом JIRA и удаленным сайтом JIRA.
Проблема: Допустим, вы попытались создать обратную связь, но получили следующее сообщение:
«Взаимная связь задачи « XYZ-123 » с этой задачей не была создана, так как удаленный сервер JIRA возвратил следующую ошибку: No Link Issue Permission (Нет разрешения связи на задачу) для задачи« XYZ-123 ». (Где «XYZ-123» является ключом к задаче на удаленном сайте JIRA),
потому что взаимная связь на удаленном сайте JIRA не будет создана, так как учетная запись пользователя, с помощью которой вы прошли аутентификацию на удаленном сайте JIRA (см. выше: шаг 3), не имеет разрешения проекта «Связывание задач».
Решение (Solution):
Если вы не запрашиваете аутентификацию во время авторизации, сначала попробуйте очистить файлы cookie браузера и повторите процедуру еще раз.
Создание связи со страницей Confluence
Чтобы создать этот тип ссылки, системному администратору JIRA необходимо настроить ссылку приложения между сайтом JIRA и сайтом Confluence, содержащим страницы, на которые вы хотите установить ссылку.
Для того, чтобы создать связь со страницей Confluence, выполните следующие шаги:
1. Откройте задачу, которую вы хотите связать с другой задачей.
2. Выберите «Дополнительно» (More)> > (Link), чтобы отобразить диалоговое окно «Связь» (Link).
Комбинация клавиш: ‘.’ + Начать вводить ссылку (Link)
3. Нажмите опцию «страница Confluence» (Confluence Page) в левой части диалогового окна.
Этот опция недоступна, если системный администратор JIRA не настроил связь на приложение между сайтом JIRA и сайтом Confluence.
4. Если между сайтом JIRA и другими сайтами Confluence настроено несколько связей на приложения, выберите подходящий сайт Confluence из выпадающего списка «Сервер» (Server).
5. Укажите страницу Confluence, которая будет связана с вашей просматриваемой задачей. Есть два способа сделать это:
Если вам будет предложено получить авторизацию, вам может потребоваться войти на сайт Confluence, который позволит вашему сайту JIRA получить доступ к сайту Confluence от имени вашей учетной записи на сайте Confluence.
Это поведение означает, что связь на приложения, настроенные между вашим сайтом JIRA и удаленным сайтом Confluence, используют аутентификацию OAuth.
6. Необязательно: добавьте комментарий (Comment), чтобы описать, почему вы связываете эти задачи.
7. Нажмите кнопку «Связь» (Link) в нижней части диалогового окна.
Исправление проблем
. Проблема: Если связь со страницей Confluence, которую вы создаете, показывает: «Не удалось загрузить задачу JIRA» или, если вы попытались найти страницу Confluence, но получили следующее сообщение:
«Не удалось получить доступ к контенту на сайте Confluence, потому что функция «Удаленный API» сервера Confluence отключена». Системный администратор Confluence должен включить эту функцию «Удаленный API» для успешного доступа JIRA к этому контенту».
в результате JIRA не смогла связаться с сервером Confluence:
Решение:
Попросите администратора системы Confluence включить функцию удаленного API (XML- RPC и SOAP) (Remote API (XML-RPC & SOAP), поскольку эта функция Confluence по умолчанию отключена. Подробнее см. «Включение удаленного API» в документации Confluence.
Создание связи с любой URL веб-страницей
Для того, чтобы создать связь с любой URL веб-страницей, выполните следующие шаги:
1. Откройте задачу, которую вы хотите связать с другой задачей.
2. Выберите «Дополнительно» (More)>«Связь» (Link), чтобы отобразить диалоговое окно «Связь» (Link).
Комбинация клавиш: ‘.’ + Начать вводить ссылку (Link)
3. Нажмите опцию «Веб-связь» (Web Link) в левой части диалогового окна.
4. Укажите URL- адрес веб-страницы, с которой вы хотите установить связь.
5. Укажите текст связи (Link Text), который будет отображаться в разделе «Связи задачи» (Issue Links) на странице «Просмотр задачи» (View Issue) и будет связан с гиперссылкой на ваш URL-адрес.
6. Необязательно: добавьте комментарий (Comment), чтобы описать, почему вы связываете эти задачи.
7. Нажмите кнопку «Связь» (Link) в нижней части диалогового окна.
Удаление связи
Для того, чтобы удалить связь с задачей в пределах задачи, выполните следующие шаги:
Поиск связанных задач
Вы можете искать задачи, связанные с конкретной задачей. Для получения дополнительной информации, см. документацию по расширенному поиску.
Помните, что эта функция не распространяется на задачи на удаленном сервере JIRA.
Как организовать ресурсное планирование в Jira для больших и маленьких компаний
Чтобы IT продукт вышел качественным, вам, разумеется, нужно контролировать процесс его создания. В этом помогают системы управления IT-задачами, значительно упрощающие жизнь как рядовых разработчиков и тестировщиков, так и «проверяющих».
Важно, чтобы систему контроля можно было настроить по всем важным для вас параметрам, и в этом плане отлично подходит Jira. Не зря же она фактически стала стандартом в сфере IT. В Jira пользователь может настроить всё под себя, а это дает возможность использовать самые разные методики ведения задач. Если при этом пользоваться другими продуктами компании Atlassian, то можно бесшовно расширить управление задачами до реализации CI/CD и ведения документации, это тоже облегчает жизнь.
Но нам ведь важно не только удобство. В определенный момент компании приходится контролировать реальную стоимость решений, и проблема управления ресурсами и бюджетами выходит на первый план.
Малым и средним компаниям вполне хватит стандартных инструментов Jira для управления ресурсами: контроль трудозатрат «из коробки», решения Tempo для гибкого планирования и контроля, а также Big Picture и бюджетирование. Но, когда дело касается Enterprise сегмента, всё резко усложняется. Появляются дополнительные разрезы отчетности, группы проектов, различные бюджеты. Давайте постараемся найти лучшие варианты реализации ресурсного планирования в Jira, исходя из опыта, полученного нами ранее в реальных проектах.
Для начала сформулируем бизнес-проблемы и вытекающие из них требования к решению.
Бизнес-проблемы
Требования
· Невозможность реализовать единую методику управления крупными проектами с широким технологическим стеком;
· Сложность долгосрочного планирования;
· Сложность обоснования дополнительных ставок и непрозрачная загрузка текущих;
· Сложность оценки бэклога продукта;
· Затрудненный поиск ИТ-специалистов с необходимыми навыками для решения конкретных задач внутри компании.
· Наличие справочника навыков;
· Контроль фактических трудозатрат;
· Возможность календарного планирования бэклога спринта или релиза;
· Возможность прогнозировать точность планирования;
· Оценка загрузки команд:
· В разрезе компетенций;
· В разрезе продуктов и бюджетов бизнеса.
Рассмотрим эти требования более детально.
Кто есть кто и что он умеет? Справочник навыков
Чтобы грамотно распределить ресурсы, надо понимать, какой сотрудник справится с задачей лучше всего. Для этого пригодится справочник навыков. Причем недостаточно знать, что сотрудник является разработчиком, нужно понимать, на чём он пишет, с какими фреймворками знаком. То есть в идеале справочник должен быть многоуровневым. Пригодится и возможность масштабирования.
Справочник есть в Advanced Roadmaps (formerly Portfolio), хотя для больших компаний решение не подойдет – рассчитано всего на 25 команд. Или, например, облачное решение Align, но оно позволяет управлять только Scrum командами.
Также справочник есть в Tempo Planner и многих других плагинах. Но там нет возможности сделать справочник многоуровневым, и масштабироваться они тоже не могут.
Контроль трудозатрат
На первый взгляд, весьма простая задача – оценка трудозатрат – доступна в Jira «из коробки». Но есть нюансы. Нам нужна (как минимум) возможность агрегации плановых и фактических трудозатрат разных команд. И нужно учитывать, что подходы к учету трудозатрат у команд могут различаться. Кто-то использует классические Jira worklog; кому-то удобнее отслеживать время нахождения в «рабочем» статусе; а кто-то предпочитает контролировать не время, а исполнение задач с помощью, к примеру, story point.
При этом информация по трудозатратам должна быть хорошо интегрирована с другим требованием – реализацией в системе календарного планирования.
Календарное планирование
Плагинов, позволяющих планировать сроки исполнения задач на календаре, весьма много: от Gantt Chart до Team Calendar. Последний, к слову, хорошо визуализирует задачи Jira, хотя и является плагином Confluence.
Для разных методик ведения проектов оптимальными могут оказаться разные подходы к планированию и реализации различных разрезов не только ролей, но и команд/проектов. Так что нам нужно такое решение, которое позволит использовать не только краткосрочное планирование на конкретных исполнителей, но и долгосрочное планирование сотрудников с определенными навыками.
Нужно также учитывать реальную производительность сотрудников с учетом плановых отпусков.
Вывод – нам нужен планировщик-конструктор, который позволит планировать как конкретных сотрудников в краткосрочной перспективе (релиз/спринт), так и загрузку команд на длинной дистанции (бэклог продукта).
Оценка загрузки команд
Для максимально точной оценки загрузки нужна гибкая отчетность по данным в системе ресурсного планирования. Важно, чтобы можно было:
агрегировать краткосрочные данные для представления загрузки в различных разрезах для тимлидов и менеджеров;
визуализировать оценку бэклога продукта для топ-менеджмента и представителей бизнеса,
визуализировать оценку потенциальной скорости развития продукта,
визуализировать обоснования решений о привлечении дополнительного бюджета при необходимости.
С этими задачами могут справиться построители отчетов или BI решения из стека компании. Например, можно использовать easyBI, если все необходимые данные будут вестись в Jira, нет необходимости в хранилище из разных систем, и логика системы не полностью переписана.
После детализации требований можно построить логическую модель системы:
А также вариант ее имплементации:
Попробуем обосновать этот вариант.
Каталог пользователей
Тут вариантов немного. Для вычисления согласующего лица в различных процессах может потребоваться информация о линейном руководителе сотрудника. При использовании LDAP для этих целей подойдет User Profile.
Справочник навыков
Основной объект Jira – issue (задача). Insight расширяет модель данных справочными объектами. Будет это CMDB, список клиентов CRM или иерархия организации – неважно. В итоге получаем встроенный механизм визуализации связей, отдельный механизм учета связанных задач и отдельный набор системных полей. Внедрять Insight исключительно ради справочника навыков я бы не стал, тем более что степень кастомизации карточки объекта Insight ниже, чем issue Jira. В целом оба варианта хороши.
Управление отпусками
Отпуска завязаны на отпускные выплаты и, как следствие – бухгалтерскую систему и ЗУП. Поэтому в Jira, как минимум, остается справочник отпусков, а как максимум – фронт заявки на отпуск. Отметим, что Jira не является мастер-системой отпусков, заявка на отпуск может делаться как типовой запрос проекта ServiceManagement или просто как задача Jira Work Management. Справочную информацию по отпускам можно получать из КХД, или же можно сделать прямую интеграцию с ЗУП.
Календарное планирование продукта
В рамках календарного планирования продукта происходит:
первичная оценка необходимого количества рабочих часов в разрезе навыков,
приоритизация бэклога продукта,
итоговое определение дедлайна.
Для фиксации оценки можно использовать плагин iDalko Table grid – он позволяет фиксировать необходимый набор компетенций в разрезе команд и навыков, при этом учитывая часы.
Приоритизация может быть сделана через сортировку требований на доске продукта по Rank (выше-раньше) или через вычисление какой-то частной формулы. В моей практике было и такое, что приоритет был f(ROI, влияние, ФИО автора) :-).
После приоритизации можно определить дедлайн (если он изначально не зафиксирован) и визуализовать сроки исполнения на диаграмме Гантта с использованием Structure.Gantt. В дальнейшем сроки могут корректироваться автоматически снизу вверх по факту планирования декомпозированных задач.
Планирование релиза
Выбор задач в релиз или спринт носит скорее методологический характер, как и нарезка детализованных задач. В работе нам более интересен вопрос детализации первичной оценки.
Во-первых, можно реализовать «вычерпывание» первичной оценки, когда при оценке конкретной задачи конкретным исполнителем учитывается первичная оценка и роль исполнителя. При этом выстраивается классическая цепочка: прогноз→план→факт. С точки зрения пользователя, это выглядит как обычный процесс эстимейта задачи. При этом мы можем не только сразу же визуализировать агрегированные затраты в разрезе команд и навыков в бизнес-задаче, но еще и зафиксировать данные для построения отчётности по точности прогнозирования. Переиспользование первичной оценки и немного Jira API c Groovy, никакой магии.
После оценки детализированных задач можно выстраивать календарные сроки задач в рамках релиза. Загрузка ресурсов подсвечивается, можно использовать авто корректировку ресурсов (с учетом связей Start-Start, End-Start и т.д.).
Ведение проектных задач
Тут нет ничего сложного. Нам нужен простой набор проектов с задачами, на которые декомпозируются бизнес-требования. Поля, процессы и типы задач в соответствии с потребностями команд. Кто-то живет по Scrum c User Story, кто-то хочет разделить задачи для разработки и задачи для аналитики. Методологически очень желательно обеспечить:
ведение бэклога продукта и релиза/спринта в Jira,
управление календарными сроками,
наличие практики оценки трудоемкости в часах,
управление справочниками компетенций,
интеграция с системой управления отпусками.
Отчетность
В начале статьи мы говорили о «дополнительных разрезах отчетности». Что же мы можем получить для наших топ-менеджеров и PO?
1)Долгосрочное прогнозирование загрузки команды по ролям в горизонте оцененного бэклога продукта с учетом отпусков. Можно, к примеру, заранее прогнозировать рост потребностей или вовремя подкидывать новые задачи команде.
2)Точность оценки прогнозирования загрузки команды и плановая загрузка команды в горизонте релиза.
3)Точность оценки прогноз/план/факт.
4)Прозрачный Time to Market для бизнеса с детализацией до конкретных задач разработчика при необходимости.
К чему мы в итоге пришли?
Серебряную пулю мы не нашли, хотя на самом деле и не особо искали – ее просто нет. Также мы не стремились описать архитектуры конкретных решений. В этой статье мы пытались показать, что решения на платформе Atlassin (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.