Сабтаски в jira что это
Создание подзадачи
Задача с подзадачами (разделение родительской задачи на ряд небольших задач), полезна тем, что ее можно назначать и отслеживать отдельно другим пользователям JIRA. Это может обеспечить ускорение работы по этой задаче и позволяет каждому пользователю из команды лучше понять, за какую подзадачу он отвечает при решении задачи.
Все подзадачи, связанные с родительской задачей, суммируются на главном экране родительской задачи (см. «Работа с подзадачами» ниже). Подзадачи всегда относятся к тому же проекту, что и их родительская задача.
Подзадачи имеют все те же поля, что и стандартные задачи, например, резюме, описание, репортер, правообладатель, статус. Обратите внимание, что подзадачи имеют разные типы задач из стандартных типов задач.
Подзадачи не могут иметь свои подзадачи. Для того, чтобы разбить подзадачу на более мелкие подзадачи, сначала необходимо преобразовать ее в стандартную задачу. После этого для этой задачи вы сможете создавать подзадачи.
Создание подзадачи
Для создания подзадач пользователю JIRA нужно иметь разрешение: «Создать задачу» в родительском проекте задачи. Невозможно установить защиту для подзадачи, поскольку подзадачи наследуют уровни безопасности своих родительских задач, если они были установлены.
Подзадачи могут быть созданы только в том случае, если администратор JIRA включил подзадачи и добавил тип подзадачи в проектную схему типа задачи.
Для того, чтобы создать подзадачу, необходимо выполнить следующие шаги:
1. Перейдите к задаче, которую вы хотели бы иметь родительской задачей для подзадачи, которую вы собираетесь создать
2. Выберите «Дополнительно» (More)> «Создать подзадачу» (Create Sub-Task). Появится экран «Создать подзадачу» (Create Subtask).
3. Заполните необходимые данные, а затем нажмите «Создать» (Create) в нижней части страницы.
Совет: Вы можете настроить диалог «Создать подзадачу» (Create Subtask), чтобы показывать наиболее часто используемые вами поля. Для этого нажмите «Настроить поля» (Configure Fields) в правом верхнем углу диалогового окна и используйте ссылки «Все» (All) и «Пользовательские» (Custom) для переключения между экраном по умолчанию и вашими пользовательскими настройками. Ваши изменения будут сохранены для будущего использования.
Работа с подзадачами
Если задача связана с подзадачами, на экране задач отображается список всех подзадач задачи:
Совет: Вы также можете ввести точку « . » для доступа к действиям по задаче.
Поиск подзадач
Если подзадачи включены, в раскрывающемся списке «Тип задач» (Issue Type) формы поиска отображаются две дополнительные записи.
Если в списке «Тип задачи» (Issue Type) не выбрано ни одной записи, поиск возвращает все стандартные задачи и подзадачи, соответствующие критериям поиска.
Преобразование стандартной задачи в подзадачу
1. Перейдите к задаче, которую вы хотите преобразовать.
2. Выберите «Дополнительно» (More) > «Преобразовать в подзадачу» (Convert to Sub-Task). Далее выполните следующие шаги.
3. На шаге 1. На экране «Выбор родительской задачи и типа подзадачи» (Select Parent Issue and Sub-Task Type) введите или выберите соответствующий родительский тип задачи и новый тип задачи (т. е. «Тип подзадачи»). Нажмите «Далее» (Next).
4. На шаге 2. Если текущее состояние задачи не является разрешенным статусом для нового типа задачи, отображается «Выберите новый статус» (Select New Status). Выберите новый статус и нажмите «Далее» (Next).
6. На шаге 4. Появится экран «Подтверждение» (Confirmation). Если вас устраивают новые изменения, нажмите «Готово» (Finish).
7. Подзадача будет отображаться. Вы увидите, что теперь эта подзадача, имеет номер ее родительской задачи, который отображается в верхней части экрана.
Преобразование подзадачи в стандартную задачу
1. Перейдите к подзадаче, которую вы хотите преобразовать.
2. Выберите «Дополнительно» (More)> «Преобразовать в задачу» > (Convert to Issue). Далее выполните следующие шаги.
3. На Шаге 1. На экране «Выбор типа задачи» (Select Issue Type) выберите новый тип задачи (т. е.«Стандартный тип задачи» (Standard Issue type) и нажмите «Далее» (Next).
4. На Шаге 2. Если текущее состояние подзадачи не является разрешенным статусом для нового типа задачи, отображается «Выбор нового статуса» (Select New Status). Выберите новый статус и нажмите «Далее» (Next).
6. На Шаге 4. Появится экран «Подтверждение» (Confirmation). Если вас устраивают новые изменения в задаче, нажмите «Готово» (Finish).
7. Задача будет отображаться. Вы увидите, что это уже не подзадача, то есть больше нет номера родительской задачи, отображаемой в верхней части экрана.
Наш опыт использования Jira: cоздание подзадач по шаблонам
В предыдущей статье «Несколько примеров успешного изобретения велосипеда» мы поделились рядом решений, полученных путем комбинирования наших плагинов для Atlassian, таких как MyGroovy, JSIncluder и MyCalendar. На этот раз мы рассмотрим еще один плагин из нашей коллекции — Custom Select List.
Custom Select List в сочетании с Groovy или JavaScript превращается в очень мощный инструмент по автоматизации, главная особенность которого — это метаданные опций. Очень много решений реализовано у нас с применением именно этой особенности. В основном, это блоки согласования. С помощью метаданных удобно хранить цепочки согласования с заранее определенными этапами и ответственными, но этим сфера его применения не ограничивается. Рассмотрим на примере реальной задачи, как можно с помощью данного плагина реализовать создание подзадач по шаблону.
Проблема
Команда разработки проводит сессии по планированию спринтов для быстрой декомпозиции и оценки историй. Необходим удобный способ создания подзадач, чтобы можно было использовать «шаблоны» — заранее заготовленные списки задач для типов историй. Это многократно ускорило бы процесс.
Решение
Сначала мы проверили наличие готовых решений. Сразу на маркетплейсе нашли подходящий плагин, перекрывающий данную потребность, но так как у этого плагина нет поддержки версии Data Center Jira Software, это не гарантирует его соответствие большим кластерным средам. Также плагин не состоит в программе Atlassian Marketplace Bug Bounty, поэтому от идеи со сторонним решением пришлось отказаться.
В итоге решили, что создание сабтасков по шаблону будет через loop-переход. Для этого на экран перехода нужно вывести поле для выбора шаблона и настроить форму для редактирования данных и управления количеством создаваемых сабтасков.
Итоговый вид перехода Quick Sub-Task будет выглядеть так:
Реализация
Шаг 1: создаем список шаблонов.
В данном примере дополнительные поля могут быть только с типом «список», в дальнейшем при необходимости можно добавить поддержку и других типов полей. Это задается на шаге 3 в groovy-скрипте.
Шаг 2: создание формы редактирования подзадач.
Готовим frontend-часть, в этом нам поможет JS Includer.
Код должен уметь получать данные из шаблона и формировать на их основе форму. Также код должен уметь добавлять или удалять элементы формы, чтобы можно было управлять количеством создаваемых через форму подзадач. Ну и, конечно же, код должен уметь сохранять итоговую форму в какое-нибудь поле (его создадим далее), чтобы с помощью пост-функции парсить данные и на их основе создавать подзадачи.
Шаг 3: MyGroovy post-function (создание подзадач).
У нас готова форма и заведены все необходимые поля, пора приступать к backend-части. Так как одна из задач, которая перед нами стояла — это дать возможность заказчику самому выбирать поля, которые необходимо добавить в шаблон, то нужно учесть это в скрипте и завязаться на имена полей и опций, а не на их id.
Дополнительно к этому можно добавить переиндекс создаваемых задач и обернуть создание в отдельный поток.
Чтобы переход не дожидался создания подзадач, можно добавить в код запуск отдельного потока (thread) для создания.
Смотрим, что получилось
Для примера создадим 3 подзадачи по шаблону и немного скорректируем входные параметры. Так выглядит наша кнопка:
Выберем шаблон «Ручное тестирование»:
Появилась кнопка «Добавить подзадачу». Нам нужно создать их 3, поэтому нажимаем 3 раза на кнопку добавить:
Все 3 формы не умещаются на экране, но на примере двух мы видим, что из шаблона подтянулись следующие значения:
Поменяем значения summary и estimate у двух подзадач и после создания получим следующий результат:
В заключение
Custom Select List можно использовать не только для создания шаблонов к подзадачам. Сценариев множество, например, для заполнения полей на форме запроса при создании или кастомизации рассылки уведомлений на переходах. Но самое частое применение — это согласование, где есть множество вводных и сложная матрица ответственных с различными этапами и условиями. Так мы в рамках одного статуса зацикливаем все согласование по запросу и, тем самым, избегаем избыточности статусной модели.
И это далеко не весь список возможных реализаций. При должном уровне фантазии и времени можно делать достаточно интересные вещи, главное — не переусердствовать, ведь кому-то это потом еще и поддерживать.
Настройка подзадач
Подзадачи обычно используются для разделения родительской задачи на части, которые можно назначать и отслеживать отдельно. (подробнее см. в разделе «Создание подзадачи»).
Подзадачи имеют все те же поля, что и стандартные задачи, хотя обратите внимание, что их тип должен быть одним из типов подзадачи (см. ниже), а не одним из стандартных типов задач.
Если режим создания подзадач включен, и Вы определили хотя бы один тип подзадачи, ваши пользователи смогут:
Отключение режима создания подзадач
Подзадачи включены по умолчанию. Однако эту функцию (Sub-Tasks) можно отключить на странице администрирования подзадач.
Подзадачи будут отключены по умолчанию, если ваша установка JIRA была обновлена с версии 4.2 (и более поздней), в которой отключены подзадачи.
Комбинация клавиш: g + g + набор подзадач
Обратите внимание: подзадачи не могут быть отключены, если в системе создана одна или несколько подзадач. Вы должны удалить любые существующие подзадачи (или преобразовать их в стандартные задачи), прежде чем вы сможете отключить эту функцию.
Включение режима создания подзадач
Для того чтобы включить подзадачи, выполните следующие шаги:
Комбинация клавиш: g + g + набор подзадач
По умолчанию доступен доступен для использования один тип подзадачи. Вы можете отредактировать его, щелкнув ссылку «Изменить» (Edit) в столбце «Операции» (Operations).
Определение типов подзадач
Для подзадачи должен быть определен тип подзадачи (который отличаются от стандартных типов задач). Обратите внимание, что в JIRA должен быть определен хотя бы один тип подзадачи, чтобы пользователи могли создавать подзадачи.
Типы подзадачи могут быть настроены на странице администрирования Sub-Tasks (описано выше). Страница администрирования подзадач также позволяет вам создавать, редактировать свойства, удалять и переводить типы подзадач.
Создание типа подзадачи
Чтобы создать новый тип подзадачи, выполните следующие шаги :
Комбинация клавиш: g + g + начало ввода подзадач
3. Нажмите кнопку «Добавить новый тип подзадачи» (Add New Sub-Task Issue Type), чтобы открыть диалоговое окно «Добавление типа подзадачи» (Add New Sub-Task Issue Type).
Редактирование типа подзадачи
Чтобы изменить тип задачи подзадачи, выполните следующие шаги:
Комбинация клавиш: g + g + начало ввода подзадач
Удаление типа задачи подзадачи
Вы можете удалять тип подзадачи с помощью страницы «Управление типами задач» (Manage Issue Types). Подробнее см. в разделе «Удаление типа задачи».
Блокирование рабочих процессов задачи по статусу подзадачи
Настройка полей подзадачи, отображаемых по родительским задачам
Системные администраторы JIRA могут определять, какие поля подзадач отображаются в разделе «Подзадачи» (Sub-Tasks) на странице просмотра родительской задачи (которая содержит одну или несколько подзадач). Это делается путем редактирования значения свойства jira.table.cols.subtasks на странице дополнительных настроек JIRA.
Укажите, какие поля вы хотите отобразить в разделе «Подзадачи» (Sub-Tasks) на странице родительской задачи, введя соответствующее значение для каждого поля в списке, разделенном запятыми. Свойство jira.table.cols.subtasks может принимать значения, указанные в правом столбце таблицы «IssueFieldConstants» на странице Constant Field Values (документации API 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 (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.