какой инструмент можно использовать для иерархического отображения задач в jira

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

Время чтения: 5 минут

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

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

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

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

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

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

Jira Roadmap

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

Jira Roadmap

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

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

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

Structure Gantt

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

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

В чате Slack #jira-structure можно было оперативно получить ответ на вопрос по работе приложение или поделиться своими находками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цвета

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

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

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

Выбор за вами

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

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

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

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

Ссылки

Описание функционала на сайте Atlassian Jira Roadmap и Structure Gantt

Источник

Как организовать ресурсное планирование в 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 (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.

Источник

Issue types в Jira: что делать, чтобы команда не путалась в задачах и всегда доводила проект до конца

Речь пойдет о базовых принципах работы в Jira: проектах (epic), задачах (task) и подзадачах (sub-task). Разберем этапы планирования проектов на доступных примерах. Считаем, это полезно знать при работе не только с Jira, но и со всеми другими таск-трекерами, CRM и планировщиками. Увы, менеджеры часто забывают с чего начать постановку задачи, чтобы ее потом довели до конца.

Jira — мощный таск-менеджер. Для простых проектов часто слишком мощный. Зато в нем можно сделать все, что вам нужно. А если разберетесь в основах, поймете, что работать в нем просто. К сожалению, часто мы наблюдаем такую картину:

Менеджер видит огромный функционал.

Чтобы этого не допустить, достаточно на старте правильно описать работу компании. Разобраться, с какими типами задач вы сталкиваетесь. Создать и настроить 5-10 процессов, которые смогут закрыть все потребности бизнеса. Все станет прозрачно и понятно для руководителя, менеджера проектов и всех сотрудников.

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

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

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

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

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

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

Правильное определение горизонтов планирования — большая тема. Если нужно, сделаем по ней отдельную статью.

Главная основополагающая сущность Jira — Issue (в переводе «проблема»). Можно сказать, что Issue — это любая работа, которую нам предстоит сделать.

Чтобы упорядочить все «проблемы», в Jira предусмотрена многоуровневая настройка интерфейса. Выделим три базовых типа Issue Type:

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

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

Эпиками в Jira называют относительно большие объемы работ, которые состоят из нескольких задач.

Когда начинаем работать, мы представляем себе общую цель проекта (эпика). Но детально планируем только первое целевое состояние (первый видимый результат). Именно от этого отталкиваемся в дальнейшей работе. Если потребуется, можем корректировать последующие шаги. Такой способ планирования называется гибким подходом. Он позволяет достигать целей, не зная наперед все этапы проекта, своевременно реагировать на изменившиеся обстоятельства и избежать глобального краха проекта. Вернемся к примерам.

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

Протестировать форму, отрендерить изображение, испечь бисквит — это все таски.

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

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

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

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

Таск и эпик — это самые универсальные сущности. На простых проектах их достаточно. Но в Jira существуют и другие стандартные типы «проблем»:

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

Чтобы описать в Jira все этапы работы компании, необходимые типы Issue выстраивают между собой в иерархическую древовидную структуру, которая состоит из проектов, задач и подзадач — максимум три ступени иерархии.

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

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

Мы рассказали лишь о базовых принципах работы над проектами в Jira.

Процессы могут быть очень простыми:

Задача поступила в работу, ее сделали, отправили на проверку и окончательно завершили.

Бывают процессы сложнее:

Программист пишет код, отправляет на проверку, передает на тестирование и, если все хорошо, завершает задачу.

Или можно описывать все максимально подробно:

Дизайнер создает макет — согласовывает, подбирает шрифт — согласовывает, подбирает палитру — согласовывает и т.д.

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

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

Плюсану. Просто у товарищей свое видение, которое они проецируют на всех.

Если бы было:
Issue types в Jira: как мы с ними работаем, чтобы команда не путалась в задачах и всегда доводила проект до конца

То и вопросов не было.

Epic в джира это агрегатор для фич. Фичи включают в себя user story (отобразить таблицу, редактировать строку, удалить строку) и tasks (задеплоить, развернуть, закупить). каждая из story или task может включать sub-tasks (сделать фронт, чтобы отобразить грид, сделать запросы к БД для чтения данных на грид, сделать запросы к API чтобы вернуть данные из БД)

Ради ускоренных курсов по разработке Lambda School студенты бросали работу и колледж, ведь школа заявляла, что 74% выпускников успешно находят высокооплачиваемые места. Business Insider пишет, что трудоустраивается только 30%, а студенты зарабатывают после обучения даже меньше, чем раньше.

Источник