Jira control chart что это

Обновлено: 15.05.2024

Тренинг по дизайну Канбан-систем Для кого: в группе вы встретите линейных руководителей, руководителей департаментов, руководителей проектов, скрам-мастеров, Agile-коучей и агентов изменений. Формат: онлайн-занятия и домашние задания. Поток:[. ]

Тренинг по управлению продуктом на базе фреймворка Fit for Purpose Для кого: для менеджеров высшего звена и лиц, принимающих решения относительно стратегии развития бизнеса и портфеля[. ]

Выбор за вами

Нам с коллегами Structure Gantt позволяет собирать всю нужную информацию из Jira в одном месте. Получается больше порядка и контроля над проектами.

При этом у Structure Gantt есть свои слабые стороны. Буду рада, если продакты ALM Works (создатели Structure) обратят внимание на них и сделают программу более простой и понятной в освоении.

Во время подготовки статьи я обнаружила, что функциональность Jira Roadmap заметно изменилась c лета прошлого года. Набор возможностей стал похож на то, что предлагает Structure Gantt.

Если выбираете приложение к Jira для ведения проектов и создания диаграмм Гантта, попробуйте оба варианта. Главное – старайтесь оптимизировать затяжную механическую работу. У нас менеджеров есть много других важных задач, помимо рутины!:)

Мои любимые фичи Structure Gantt

В этой части хочу рассказать вам подробнее о пункте “богатая функциональность” из списка сильных сторон Structure Gantt.

Связи между задачами

История декомпозирована, Jira-тикеты на задачи заведены. На следующем этапе при растягивании “колбасок” по временной ленте я расставляю связи между тикетами. Делаю так, чтобы чётко выделить, какая задача заблокирована или какие задачи должны быть закончены одновременно (классические зависимости в управлении проектами: finish to start, finish to finish).

Цвета

Цветовое разделение помогает легче ориентироваться между “колбасками”. Я делаю так: задача на бэкенд-разработку — синяя, фронт — желтая, баг — красная, поддержка — серая, история — зеленая, дизайн — фиолетовая. Это позволяет нагляднее увидеть, какого типа задач больше. Например, если багов в проекте больше, чем остальных задач, то скорее всего, это сигнал о проблеме в разработке.

Переход между режимами

В примерах использования Structure Gantt я говорила, что переключаюсь между режимами в зависимости от занятия. Помогает мне в этом кнопка, удобно расположенная в центре экрана. Переключение не занимает много времени, поэтому я часто им пользуюсь.

Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет

Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.

Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.

Статья ориентирована прежде всего на тех, кто уже использует Jira, но, возможно, испытывает сложности с интеграцией её стандартных возможностей в существующие в компании процессы. Также статья может быть полезна компаниям, которые используют другие таск-трекеры, но столкнулись с некоторыми ограничениями и подумывают о смене решения. Статья построена не по принципу «проблема — решение», в ней я описываю сложившийся инструментарий и фичи, построенные нами вокруг Jira, а также технологии, которые мы использовали для их реализации.

Дополнительные возможности Jira

Чтобы последующий текст был более понятным, давайте разберёмся, какие инструменты предоставляет нам Jira для реализации нестандартных хотелок — тех, что выходят за рамки стандартного функционала Jira.

REST API

С помощью API вы можете, используя скрипты на любом языке программирования:

создавать тикеты;
модифицировать любые свойства тикетов (встроенные и кастомные);
писать комментарии;
с помощью JQL (встроенный язык запросов) получать любые списки тикетов;
и многое другое.

Мы написали собственный высокоуровневый Jira API-клиент на PHP, который реализует все необходимые нам команды. Вот пример команд для работы с комментариями:

Webhooks

С помощью webhook можно настроить вызов внешней callback-функции на вашем хосте на различные события в Jira. При этом можно настроить сколько угодно таких правил таким образом, что различные URL будут «дёргаться» для разных событий и для тикетов, которые соответствуют указанному в webhook фильтру. Интерфейс настройки webhooks доступен администратору Jira.

В результате можно создавать правила вроде этого:

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

Тут важно понимать, что Jira не гарантирует, что ваше событие будет доставлено. Если внешний URL не ответил или ответил с ошибкой, это нигде видно не будет (кроме логов, пожалуй). Поэтому обработчик событий webhook должен быть максимально надёжным. Например, события можно складывать в очередь и пытаться обработать до тех пор, пока это не закончится успехом. Это поможет решить проблемы с временно недоступными сервисами, например, какой-либо внешней базой данных, необходимой для правильной обработки события.

Подробная документация о webhooks представлена по ссылке.

ScriptRunner

Это плагин к Jira, очень мощный инструмент, который позволяет кастомизировать в Jira очень многое (в том числе он способен заменить собой webhooks). Для пользования этим плагином требуется знание Groovy. Основное преимущество инструмента для нас состоит в том, что можно встраивать во флоу кастомную логику в режиме онлайн. Код вашего скрипта будет исполняться сразу в среде Jira в ответ на определённое действие. Например, можно сделать в интерфейсе тикета свою кнопку, клик по которой будет создавать связанные с текущей задачей тикеты или запускать юнит-тесты для данной задачи. И если вдруг что-то пойдёт не так, вы как пользователь сразу об этом узнаете.

Желающие могут ознакомиться с документацией.

Гантт для (ленивых) экономящих свое время

Для построения диаграммы Гантта существует множество программ: Ganttpro, Monday, Teamgantt, старый добрый Excel и другие.

Нам с коллегами в Ozon они не подходили, потому что ежедневная работа завязана на Jira-тикеты. Чтобы пользоваться сторонними сервисами, приходилось переписывать всю информацию из Jira ещё раз (название задачи, исполнитель, связи, статус). Это требовало много времени и терпения на монотонную механическую работу.

Хорошо, подумали мы, давайте поищем инструмент для диаграмм, в котором информация будет отражаться напрямую из Jira. Такой функционал нашли в двух приложениях:

Флоу: что скрыто под капотом

А теперь о том, как мы применяем дополнительные возможности Jira в наших проектах. Рассмотрим это в контексте прохождения нашего типичного тикета по флоу от создания до закрытия. Заодно и про сам флоу расскажу.

Open/Backlog

Project = SRV AND assignee is EMPTY AND status in (Open)

In Progress

Надо отметить, что у нас работа над каждой задачей ведётся в отдельной Git-ветке. Насчёт этого у нас есть соглашение, что имя ветки в начале должно содержать номер тикета. Например, SRV-123_new_super_feature. Также комментари к каждому коммиту в ветку должны содержать номер тикета в формате [SRV-123]: . Такой формат необходим нам, например, для корректного удаления «плохой» задачи из билда. Как это делается, подробно описано в статье.

Эти требования контролируются Git-хуками. Например, вот содержимое prepare-commit-msg, который подготавливает комментарий к коммиту, получая номер тикета из имени текущей ветки:

Если коммит с «неправильным» комментарием попытаться запушить, такой пуш будет отклонён. Также отклонена будет попытка запушить ветку без номера тикета в начале.

Когда тикет попадает на разработчика, первым делом он декомпозируется. Результатом декомпозиции является представление разработчика о способах решения задачи и о том, сколько времени займёт решение. После того как все основные детали выяснены, тикет переводится в статус In Progress, а разработчик начинает писать код.

У нас принято выставлять задаче due date в момент, когда она переводится в статус In Progress. Если же разработчик этого не сделал, ему придёт напоминание в корпоративный мессенджер HipChat. Специальный скрипт раз в два часа:

выбирает с помощью REST API Jira тикеты в статусе in progress с пустым полем due date (project = SRV AND status = ‘In Progress’ AND duedate is EMPTY);
выбирает незавершённые тикеты с due date старше текущей даты (project = SRV AND status = ‘In Progress’AND duedate is not EMPTY AND duedate < now());
для каждого тикета узнаёт разработчика, читая соответствующее поле в тикете, а также лида разработчика;
группирует тикеты по разработчикам и лидам и отправляет напоминания в HipChat, используя его API.

имя Git-ветки, а также комментарии к коммитам проверяются на соответствие нашим правилам;
проверяется, что тикет, с которым ассоциируется ветка, не закрыт (в закрытые тикеты пушить новый код нельзя);
проверяется синтаксис изменённых PHP-файлов (PHP -l file_name.php);
проверяется форматирование;
если тикет, в который пушится ветка, находится в статусе Open, то он автоматически переводится в статус In Progress;
тикет привязывается к ветке, делается соответствующая запись в кастомном поле тикета Commits с помощью Jira API. Выглядит это так:

(branchdiff — это ссылка на diff ветки с головой, от которой взяла своё начало текущая ветка, в нашем инструменте ревью кода Codeisok);

On Review

Написав код и самостоятельно убедившись, что все требования к задаче выполнены, а тесты не сломаны, разработчик назначает тикет ревьюверу (статус On Review). Обычно разработчик сам решает, кто будет ревьювить его тикет. Скорее всего, это будет другой разработчик, который отлично разбирается в нужной части кода. Ревью происходит с помощью инструмента Codeisok, который открывается сразу с нужным diff по клику на ссылку branchdiff в поле тикета Commits или на ссылку в виде хеша коммита в комментариях.

Ревьювер видит примерно такую картину:

Закончив ревью, ревьювер нажимает кнопку Finish, и, помимо всего прочего, в этот момент происходит следующее:

с помощью API JIra создаётся комментарий в тикете с замечаниями ревьювера в контексте кода. Выглядит это примерно так:

если замечания к коду были и ревьювер решил переоткрыть тикет, то разработчику придёт уведомление об этом в HipChat (это делается с помощью правила webhook, которое срабатывает на переоткрытие);
заполняется поле тикета Reviewers.

Resolved

Далее, если ревью прошло успешно, тикет отправляется в беклог QA-инженеров в статусе Resolved. Но вместе с этим с помощью webhook на событие resolved в фоне запускаются автоматические тесты на коде ветки. Спустя несколько минут в тикете появится новый комментарий, который сообщит о результатах тестов.

Также в любой момент можно вручную инициировать повторный прогон тестов, кликнув по специальной кнопке Run unit tests в меню тикета. После успешного прогона в тикете появится новый комментарий, аналогичный предыдущему.

По сути, эта кнопка — один из дополнительных статусов задачи в workflow Jira, перевод в который инициирует срабатывание скрипта на Groovy для плагина ScriptRunner. Скрипт вызывает внешний URL, который инициирует прогон тестов, и если URL ответил успехом, то тикет возвращается в предыдущий статус (в нашем случае Resolved).

In Shot / In Shot — OK

Задача сначала тестируется в devel-окружении. Если всё хорошо, создаётся шот (например, кликом по ссылке Create shot в поле Commits) — директория на выделенном сервере, в которую копируются изменения из тикета, смёрженные с текущим master. Сервер работает с продакшен-данными: базы и сервисы те же, что обслуживают реальных пользователей. Таким образом, тестировщик может открыть web-сайт или подключиться к шоту с помощью мобильного клиента и «изолированно» проверить фичу в продакшен-окружении. «Изолированно» значит, что никакой другой код/функционал, кроме нового из ветки и текущего master, не исполняется. Поэтому этот этап тестирования является, пожалуй, основным, так как позволяет QA-инженеру максимально достоверно найти проблему непосредственно в тестируемой задаче.

Доступ к ресурсам шота осуществляется по специальным URL, которые генерируются в скрипте создания шота и с помощью API Jira помещаются в шапку тикета. В результате мы видим ссылки на сайт, админку, логи и прочие инструменты, которые исполняются в шот-окружении:

Также в момент генерации шота запускается скрипт, который анализирует содержимое изменённых файлов и создаёт заявки на перевод найденных новых лексем. После того как перевод закончен, значение поля Lexems меняется на Done и тикет может быть добавлен в билд.

Если тестирование в шоте прошло успешно, то тикет переводится в статус In Shot — OK.

In Build / In Build — OK

Мы выкладываем код два раза в день — утром и вечером. Для этого создаётся специальная build-ветка, которая в итоге будет слита с master и выложена «в бой».

В момент сборки build-ветки специальный скрипт с помощью JQL-запроса получает список тикетов в статусе In Shot — OK и пытается замёржить их в ветку билда при выполнении всех перечисленных ниже условий:

перевод для тикета закончен или переводить ничего не нужно (Lexems in (‘No’, ‘Done’));
разработчик присутствует на рабочем месте (система автоматического слияния проверяет по внутренней базе, не находится ли разработчик в отпуске или на больничном, и если да, то тикет может быть замёржен только вручную релиз-инженерами или другим ответственным разработчиком, который указан в специальном поле Vice Developer; лид отсутствующего разработчика в этом случае получает уведомление о том, что тикет не может быть автоматически добавлен в билд);
у тикета не установлен флажок Up in Build в значение by Developer (это специальное кастомное поле тикета, которое даёт возможность разработчику самому определять, когда тикет попадёт в билд);
ветка тикета не зависит от другой ветки, которая ещё не попала в master или текущий билд. Мы всячески стараемся избегать подобной ситуации, но иногда такое происходит, когда разработчик создаёт свою ветку не от master, а от ветки другого тикета, либо когда вмёрживает к себе чужую ветку. Это можно сделать в том числе и случайно, поэтому мы решили, что дополнительная защита не помешает.

Если же всё хорошо и ветка тикета замёржилась в билд, тикет автоматически переводится в статус In Build, а в кастомное поле тикета Build_Name пишется название билда.

Далее, используя это значение, легко получить список тикетов, которые были выложены с каждым билдом. Например, для поиска виноватого, если что-то пошло не так.

На следующем этапе QA-инженеры дополнительно проверяют, корректно ли работает код задачи совместно с другими задачами в билде. Если всё хорошо, тикету вручную выставляется статус In Build — OK.

On Production / On Production — OK / Closed

Далее на билде прогоняется весь наш набор тестов (Unit, интеграционные, Selenium- и т. д.). Если всё хорошо, билд мёржится в master, а код выкладывается на продакшен. Тикет переводится в статус On Production.

Далее разработчик (или заказчик) убеждается, что на продакшене фича работает корректно, и выставляет тикету статус On Production — OK.

Спустя две недели тикеты в статусе On Production — OK автоматически переводятся в статус Closed, если кто-то ранее не сделал это вручную.

Также стоит упомянуть дополнительные статусы, в которых может находится тикет:

Requirements — когда не получается оперативно получить от заказчика необходимые уточнения по задаче, а без них дальнейшая работа по тикету невозможна, тикет переводится в этот статус и назначается тому, кто должен дать разъяснения;
Suspended — если работа по тикету приостановлена, например, если разработчик заблокирован задачами смежной команды или был вынужден переключиться на более срочную задачу;
Reopened — задача может быть переоткрыта на разработчика после ревью, после тестирования, после неудачной попытки слияния ветки с master.

3. Компоненты JIRA

Как показано на скриншоте, вы можете добавлять новые компоненты, такие как Название (Name), Описание (Description), Руководитель отдела/команды (Component lead) и Назначенный ответственным по умолчанию (Default assignee).

1. Система JIRA

JIRA состоит из ряда компонентов, каждый из которых можно настроить. Это:

Рабочий процесс (Workflow);
Типы задач (Issue Types);
Пользовательские рабочие пространства (Custom Fields);
Окна (Screens);
Настройка рабочих пространств (Field Configuration);
Уведомления (Notification);
Решения (Permissions).

Примеры использования Structure Gantt

Два слова о специфике работы. Я менеджер команды разработки, отвечающей за загрузку товаров на сайт Ozon Marketplace. Менеджер проекта, Product Owner и культорг в одном лице. Мне нужно координировать проекты внутри команды и между отделами, планировать спринты и распределять задачи между разработчиками, следить за поддержкой и контролировать выполнение задач к сроку.

У нас в команде семь бэкенд-разработчиков, два фронта, один аналитик, один QA и техлид. Держать информацию по всем задачам в голове нереально, поэтому важно уметь её быстро находить.

Есть несколько режимов Structure Gantt, которые я меняю в зависимости от контекста, чтобы минимизировать объём работы.

Планирование и мониторинг проектов

Использую этот режим при декомпозиции задач и определении сроков реализации проекта. Особенно помогает, когда нужно оценить время реализации больших проектов на несколько месяцев.

На ранних стадиях проекта разработчики не всегда сразу могут сказать, сколько в точности нужно времени на ту или иную задачу. Поэтому я стараюсь завести больше тикетов и растащить один за другим на временной ленте: на одну задачу – месяц, на другую – две недели, на третью – неделю. Так прогноз на протяжённость проекта становится яснее.

Конечно, это только предварительная картина. Во время хода проекта появляются новые задачи, какие-то вылетают за ненужностью, сроки старта и финиша задач двигаются. Я сохраняю оттиск расположения задач на временной ленте в начале проекта и сравниваю с диаграммой в середине и конце.

Описание статуса проекта – только структура без диаграммы Гантта

Использую, когда нужна конкретная информация в срезе всех Jira-тикетов. Например, необходимо быстро проверить, что даты начала и конца всех проектов совпадают с цифрами в отчёте. В таком случае я сворачиваю Гантт и в столбиках структуры быстро вижу необходимые цифры. Собирать информацию по временной ленте было бы неудобно.

Планирование спринта

Группирую тикеты по исполнителю, чтобы видеть занятость конкретного разработчика в следующий спринт и прогноз, когда разработчик должен освободиться. Подобное представление задач на диаграмме я не рекомендую показывать разработчикам, если вы используете Kanban: я считаю, что инженерам следует фокусироваться на задачах в работе и не отвлекаться на другие. Диаграмма Гантта — всё- таки инструмент для специфических менеджерских задач.

6. Схемы защиты задач JIRA (Issue Security Schemes)

Эта функция JIRA позволяет вам контролировать доступ к задачам. Она включает в себя несколько уровней доступа, которые распределяются между пользователями и группами. Вы можете указать уровень доступа к задачи во время ее создания или редактирования.

Также имеется Стандартная схема защиты (Default Permission Scheme), которая будет назначена любому новому проекту. Схемы защиты позволяют вам создавать наборы уровней доступа и применять их к любому проекту.

Системная администрация (System Administration)

Вот несколько полезных функций, которые JIRA предоставляет администраторам:

Логи ревизий (Audit Log). В этой вкладке вы можете увидеть детали созданной задачи, а также изменения, внесенные в задачу.

Связывание задач (Issue Linking). Здесь указывается связана ли ваша задача с какой-то другой, существующей в данном проекте. Также в этой панели можно отменить данную связь.

События (Events). В этой вкладке описан статус, стандартный шаблон, схемы оповещения и передача ответственности за событие. События разделены на два типа: Системные события (System event, те, что установлены в JIRA по умолчанию) и Пользовательские события (Custom event, соответственно, те, что были созданы пользователями).

Счетчик задач (Issue Collectors). Позволяет собирать информацию с любого сайта. Будучи администратором, можно кликнуть по счетчику задач, после чего появится опция, позволяющая его добавить. Как только вы настроите внешний вид счетчика, автоматически сгенерированный JavaScript можно перенести на сайт для передачи информации.

Инструменты разработки (Development Tools). Вы можете также подключить ваши инструменты разработки ПО к JIRA, используя функции администратора. Вам необходимо ввести URL приложения для подключения его к JIRA.

Тикет — центр коммуникаций по задаче

В результате прохождения тикета по флоу его шапка приобретает примерно такой вид:

Что здесь ещё интересного, что мы настроили под себя и о чём я ещё не упомянул?

Component

Помимо «человеческих» текстов, как я уже упоминал выше, в комментарии много всего пишется автоматически с помощью API:

коммиты;
результаты ревью;
результаты прогона тестов.

JS-код скрипта, который мы встроили в шаблон тикета

7. Как создать задачу в JIRA (How to create an issue in JIRA)

Панель задач JIRA откроется, как только вы введете свой ID и пароль. Под панелью управления вы обнаружите вкладку Проекты (Project). Кликнув по ней, вы откроете окно со списком таких опций, как Простое отслеживание задач (Simple Issue Tracking), Управление проектами (Project Management), Agile Kanban, Классическая JIRA (Jira Classic), соответственно скриншоту.

Если вы кликните по опции Простое отслеживание задач (Simple Issue Tracking), откроется другое окно, в котором упоминаются детали задачи, а также назначение определенному ответственному лицу.

После нажатия кнопки Подтвердить (Submit) откроется окно, в котором можно выполнить ряд действий, вроде создания и назначения задач, проверок их статуса и т. д.

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

Теперь, если вы захотите отредактировать задачу или экспортировать ее в виде XML/Word документа, вы можете навести курсор на главную панель и кликнуть Задачи (Issues). В появившемся списке выберите Поиск задач (Search for issues), после чего откроется окно, с помощью которого вы можете обнаружить ваши задачи и выполнить другие действия.

Когда вы выберете Поиск задач (search for Issues), откроется такое же окно, как на скриншоте ниже.

В этом же окне вы можете установить фильтр для задачи и сохранить его в Избранные фильтры (Favorite Filters), так что если вам потребуется найти данную задачу, вы легко сможете сделать это, воспользовавшись фильтром.

Воспользовавшись функцией Сводка (Summary), вы откроете окно с диаграммой, на которой можно увидеть все детали, связанные с вашим проектом, и прогресс работы над ним. В правой части окна сводки вы можете увидеть Журнал активности (Activity Stream), на котором отображаются детали, связанные с задачей, и комментарии, оставленные ответственным за задачу человеком.

Подзадача (Sub-Task)

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

Как создать подзадачу

Подзадача может быть создана двумя способами:

Чтобы создать подзадачу в JIRA, вам нужно выбрать задачу, к которой вы хотите ее прикрепить. В окне задачи выберите опцию Назначения. Прочее (Assign more), после этого выберите Создать подзадачу (Create sub-task), как показано на скриншоте. Вы можете также конвертировать задачу в подзадачу (convert to sub-task), выбрав соответствующую опцию.

Выбрав опцию Создать подзадачу (Create sub-task), вы откроете соответствующее окно. Заполните поля с деталями, касающимися данной задачи, и нажмите кнопку Создать (Create), как показано на скриншоте ниже.

Таким образом вы создадите подзадачу, прикрепленную к основной задаче, а на странице подзадач вы сможете увидеть время, отведенное на ее выполнение.

Несколько важных вещей, которые нужно помнить, создавая подзадачи:

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

Рабочий процесс (WorkFlow)

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

задача открыта (Open Issue);
задача решена (Resolved Issue);
задача в процессе решения (InProgress Issue);
задача переоткрыта (ReOpened Issue);
задача закрыта (Close Issue).

Рабочий процесс JIRA состоит из статусов (statuses), переходов (transitions), назначений (assignee), решений (resolution), условий (conditions), проверок (validators), и свойств (properties).

Статусы определяют статусы задач во время рабочего процесса.

Переходы подразумевают под собой процесс смены статуса.

Назначения указывают ответственных за определенные задачи и определяют пути решения задачи.

Решения объясняют, по какой причине задача может считаться закрытой.

Условия контролируют доступ к переходам.

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

Свойства определяются JIRA при переходах.

Вы можете назначить статус задаче в соответствующем ей окне, кликнув на флажок статуса В работе (IN Progress), как показано на скриншоте ниже. Это отобразит статус задачи на ее рабочей панели, выделив его желтым цветом.

Плагины JIRA (Plug-ins in JIRA)

Для JIRA существует множество плагинов, позволяющих вам эффективнее работать. Это такие плагины, как Zendesk, Salesforce, GitHub, Gitbucket и т. д. Часть из них позволяет команде поддержки отчитываться о работе напрямую в JIRA, создавать неограниченные приватные репозитории с полной поддержкой задач, инструментов управления тестированием и т. д.

JIRA Agile (JIRA Agile)

Создание задачи в Agile

Создания Эпика в Agile

Режим планирования (Plan Mode) в Agile:

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

Режим работы (Work Mode) в Agile:

Связывание и клонирование (Clone and Link) задач в JIRA

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

Помимо этого здесь же есть еще множество возможностей, которыми можно воспользоваться. Например, если вы кликните по иконке в верхнем правом углу окна, появится выпадающий список с функциями, которые вы можете применить при необходимости.

4. Окна JIRA (JIRA screen)

Если задача создана в JIRA, она будет организована и представлена на различных рабочих пространствах, которые называются экранами. Эти рабочие пространства могут переводиться и редактироваться в ходе рабочего процесса. Как можно увидеть на скриншоте, каждой задаче вы можете назначить тип экрана. Чтобы ассоциировать осуществление задачи с определенным экраном, нужно зайти в главное меню, кликнуть Задачи (Issues), кликнуть Схемы (Schemes), после этого кликнуть Ассоциировать осуществление задачи с экраном (Associate an issue operation with a screen) и добавить экран, соответствующий требованиям.

Что ещё?

Ещё с помощью API и webhooks Jira мы делаем такие вещи:

отправляем уведомление в HipChat, если в комментарии был упомянут кто-то из сотрудников (очень способствует оперативному решению вопросов);
отправляем уведомления в HipChat при назначении тикета на ревью и когда тикет попадает на продакшен (как именно мы это реализовали, расскажу в следующей статье);
системные архитекторы с помощью специального интерфейса в пару кликов создают тикеты различным командам (клиентским и серверным) для реализации проекта (при этом тикеты корректно заполняются нужными полями и линкуются между собой; это помогает нам эффективно организовать синхронизацию работы команд);
мы автоматически отслеживаем появление новых версий клиентов; после этого специальный скрипт создаёт тикет серверной команде, чтобы мы внесли изменения в некоторые конфиги;
скрипт периодически снимает срезы по задачам в статусе In progress для статистики;
скрипт определяет задачи, которые надолго «зависают» в определённых статусах (например, On Review), и отправляет соответствующие уведомления ответственным сотрудникам;
если сотрудник в этот день отсутствует в офисе и об этом есть соответствующая запись во внутренней базе, то к его имени в Jira добавляется информация об этом (например, «d.semenihin (Day off)»). Очень полезная фича.

5. Свойства задач (Issue Attributes)

В свойства задач входят:

Статусы (Statuses);
Решения (Resolutions);
Приоритеты (Priorities).
9

8. Отчеты (Reports) в JIRA

Для отслеживания прогресса в Agile существует диаграмма сгорания задач (Burndown Chart), отображающая выполненный и запланированный объем работы, необходимый для завершения спринта. Типичная диаграмма будет выглядеть примерно так же, как на скриншоте ниже. Красная линия отображает фактический объем выполненной работы, в то время как синяя отображает идеальный объем выполненной на протяжении scrum-цикла работы.

Помимо диаграммы сгорания задач в JIRA существует множество других опций: Отчет по спринту (Sprint Report), Отчет по эпику (Epic Report), Отчет по версиям (Version Report), Диаграмма производительности (Velocity Chart), Диаграмма управления (Control Chart), Диаграмма совокупного потока (Cumulative flow diagram). Вы можете использовать разные способы отслеживания прогресса работы над вашим проектом.

Как вы можете увидеть на скриншоте ниже, мы выбрали круговую диаграмму для отображения задач по приоритетам. На ней в процентном формате отображена статистика по задачам, включающая в себя их количество и важность. Круговая диаграмма может быть использована для отображения различных типов данных: Назначения (Assignee), Компоненты (Components), Типы задач (Issue Type), Приоритеты (Priority), Решения (Resolution), Статусы (Status) и т. д.

Фильтры (Filters)

Вы можете создавать свои фильтры в придачу к установленным по умолчанию. Фильтры могут быть по данным (date), компонентам (component), приоритетам (priority), решениям (resolution) и т.д.

Kanban-панели и управление задачами

Kanban считается лучшим методом для работы с багами и поддержки релизов, когда новые задачи соответственно приоритезируются и обрабатываются. Есть несколько способов повысить эффективность вашей работы в Kanban:

Итоги

Jira — прекрасный инструмент, который в стандартной поставке позволяет решать большинство проблем, связанных с организацией ведения проектов. Но, как известно, в любом бизнесе есть свои нюансы. И для адаптации Jira к особенностям ваших процессов этот продукт обладает дополнительными возможностями, которые в умелых руках позволят вам решить практически любую проблему.

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

2. Задачи JIRA и их типы

JIRA позволяет отслеживать баги и задачи, лежащие в основе проекта. Как только вы импортируете проект в JIRA, вы можете создавать задачи.

Типы задач (Issue Types);
Рабочий процесс (Workflow);
Окна (Screens);
Рабочие пространства (Fields);
Свойства задач (Issue Attributes).

9
Типы задач (Issue Types)

В JIRA есть две системы организации типов задач.

Стандартная система организации типов задач (Default Issue Type Scheme).

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

Agile Scrum система организации типов задач (Agile Scrum Issue Type Scheme).

Задачи и проекты, которые ассоциируются с Agile Scrum, используют эту систему.

Как строить диаграмму Гантта по Jira-тикетам

Статья для менеджеров, которым необходимо вести управление проектами и ставить сроки в изменчивом мире Agile. Поделюсь опытом использования двух приложений Jira Roadmap и Structure Gantt.

Пример Диаграммы Гантта

BYTEX BLOG

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

Jira Roadmap

Этим приложением я пользовалась несколько месяцев, когда заказчикам и руководству нужно было срочно показать план реализации проектов. На временной ленте отражались “колбаски” эпиков, историй и некоторых задач. К нему удобно было обращаться для иллюстрации картины большими мазками: проекты на год, на кварталы. Для ежедневной работы с Jira-тикетами и детального планирования проектов оно не подходило: не получалось вместить все задачи.

Jira Roadmap

О приложении Structure в Ozon было известно давно. Однако оно не бросалось в глаза, пока не обратили внимание на его возможность строить диаграмму Гантта. Рекламное видео отправило всех в менеджерский рай: информация из Jira-тикетов отражается, можно группировать задачи по статусу, связи подсвечиваются, не мешает командным Kanban-доскам. Минимум монотонной механической работы.

Structure — список всех задач с данными из Jira-тикетов, распределённых по столбикам. Список можно группировать, фильтровать, выводить ту информацию, которая требуется.

Structure Gantt — к функционалу Structure добавляется возможность видеть Jira-тикеты и связи между задачами на временной ленте.

Structure Gantt

В конце 2020 года руководители Ozon приобрели Structure Gantt для удобного и наглядного ведения проектов. Однако в менеджерском раю оказаться сразу не получилась. Причины: сложная функциональность и отсутствие наглядного обучающего материала.

Перестать страдать от Structure и начать использовать его для работы я смогла где-то через месяц. Разобраться удалось благодаря тому, что мы обсуждали проблемы функциональности совместно и подсказывали друг другу решения в кругу менеджеров:

Ходили друг к другу в настройки Structure – подсмотреть, как ребята в других командах справляются с похожими задачами.

Созванивались и пытались “коллективным разумом” найти выход из тупиковых ситуаций.

Слабые стороны Structure Gantt

Сильные стороны Structure Gantt

Сложно разобраться с инструментом

Невозможно увидеть время перехода Jira-тикеты из одного статуса в другой

Вся информация автоматически дублируется между Jira-тикетами и Structure Gantt

В мануалах нет примеров использования на практике

На одном экране помещается большое количество данных

Читайте также: