Как назначить задачу в jira
Постановка (создание) задач в Jira
Чтобы не забыть о своих задачах или быстро узнать чем занимаются коллеги и подчиненные, создавайте задачи в системе Jira. С помощью этой системы:
Как создать задачу
Чтобы создать новую задачу, нажмите кнопку Создать в верхней панели управления.
Откроется модальное окно создания задачи:
Что обязательно нужно указать при создании задачи
Дополнительные поля в окне создания задачи
Задачи с указанным сроком исполнения имеют более высокий приоритет по сравнению с задачами без срока
Как управлять количеством полей в форме создания задачи
Если вы не видите какие-то из этих полей, возможно они скрыты настройками карточки создания задачи. Чтобы проверить это и отобразить поля, нажмите Настроить поля в правом верхнем углу.
В открывшемся окне отметьте галками поля, которые необходимо отображать в карточке создания задачи.
Работа с задачами в программном обеспечении Jira Software
Руководство по работе с задачами в Jira Software
Учебник по задачам Jira
В этом уроке мы объясним, как работать с задачами в программном обеспечении Jira. Обратите внимание, что командные ритуалы, которые вы проводите вне Jira Software, такие как встречи по планированию спринтов, ретроспективы и ежедневные летучки, здесь не рассматриваются. Вы можете прочитать о них в разделе «Как делать scrum с Jira Software».
Время:
Аудитория:
Вы новичок в Jira Software, но не знаете, что с ним делать.
Необходимое условие (Предпосылки):
ЧТО ТАКОЕ ЗАДАЧА?
В Jira команды используют задачи для отслеживания отдельных частей работы, которые должны быть выполнены (завершены). В зависимости от того, как ваша команда использует Jira, проблема может представлять задачу (task- задание) проекта, заявку службы поддержки, форму запроса на отпуск и т. д. В Jira Software задачи обычно представляют такие вещи, как большие функции, требования пользователя и ошибки (баги) программного обеспечения.
Создайте задачу
Есть несколько способов создания задач:
Из глобального меню в любом месте Jira
В списке необходимых требований (backlog)
На вашей доске (доски для гибкости только в облаке)
Необязательно: создание подзадач (sub-tasks)
Задачи могут также иметь подзадачи, которые назначаются и отслеживаются индивидуально. Вы можете создавать подзадачи по любой из следующих причин:
Чтобы создать подзадачу:
Оценка задач в вашем списке необходимых требований (backlog) поможет вам предсказать, сколько времени потребуется для предоставления частей (порций) из списка необходимых требований (backlog).
Зачем нужно оценивать задачи?
В традиционных командах разработчиков менеджеры будут оценивать позиции в «человеко-часах». Затем они могли бы подсчитать количество часов в списке необходимых требований (backlog), разделив их на количество человек в команде и количество часов в неделе, чтобы достичь прогнозируемой даты. Конечно, эти оценки часто оказывались крайне неточными, потому что они не учитывали естественные характеристики оценки команды (для переоценки / недооценки), неожиданные перерывы или развитие производительности команды с течением времени.
После первых нескольких спринтов большинство команд наберут достаточно стабильную скорость. Вооруженные скоростью и оценками по задачам списка необходимых требований (backlog), команды могут предсказать, сколько времени потребуется для завершения частей списка необходимых требований (backlog).
Например, если у команды есть «человеко-часы» вместимостью 120 часов в каждом спринте, при скорости 60 часов. Такая скорость может быть использована для оценки количества спринтов, которые потребуются для выполнения части отставания. Может показаться заманчивым задуматься о том, куда ушли «остальные 60 часов», и это наталкивает на мысль, что с производительностью команды что-то не так. Но это, как правило, не имеет к этому никакого отношения: оценки команды просто представляют их мнение о том, насколько трудными будут элементы, и на оценки всегда будет влиять естественное поведение команды (например, переоценка / недооценка), а также организационные издержки. Скорость это все, что имеет значение с точки зрения планирования.
Большинство команд оценивают, используя сюжетные точки. Сюжетные точки измеряют сложность одной задачи по отношению к другим. Это имеет смысл, потому что основные вопросы, на которые нужно ответить: «Сколько работы мы можем реально посвятить (commit) завершению этого спринта?» и «Сколько времени займет эта часть списка необходимых требований (backlog)?». Сюжетный подход может дать ответы на эти вопросы без беспокойства по поводу «точности», которое испытывают команды, когда их просят оценить в часах.
Для получения дополнительной информации о том, как можно отслеживать оценку и скорость, ознакомьтесь с нашим уроком.
Чтобы установить оценку для задачи:
Могу ли я изменить оценку после того, как она была введена?
Коротко, да можно. Но если вы измените значение «Оценка» (Estimate) после начала спринта, оно будет отображаться как изменение масштаба действий (scope change) в диаграмме сгорания.
Если вам трудно оценить задачи, это совершенно нормально! Ознакомьтесь с нашим руководством по оценке для подсказок и трюков по поиску правильных оценок для ваших задач.
Ранжируйте свои задачи в порядке приоритета
Ранжирование ваших задач в порядке приоритета позволяет команде увидеть, над какими задачами они будут работать дальше. Чтобы ранжировать свои задачи, перейдите к своему списку необходимых требований или на доске кликните и перетащите свои задачи чтобы упорядочить, а не обосновывать на приоритете. Вот несколько примеров, где вы можете сделать это:
Примечание. У вас должны быть разрешения «Расписание задач» (Schedule Issue) и «Редактировать (Изменить) задачи» (Edit Issue) для задачи, которую вы хотите переместить выше или ниже на своей доске.
Отметьте задачу
При работе с доской Kanban или доской agility у вас есть возможность пометить задачу. На форумах по agility помеченные задачи выглядят примерно так:
Пометка задачи полезна, потому что она поощряет сотрудничество и общение в команде. Вот некоторые примеры:
Чтобы отметить задачу:
Задачи перехода
Задачи перехода показывают прогресс в вашем рабочем процессе. Чтобы перевести задачу из одного столбца в другой, перетащите задачу и поместите ее в новый столбец.
Обратите внимание, что если вы обнаружите, что не можете перенести задачу в другой столбец, это может быть связано с тем, что рабочий процесс вашего проекта ограничивает вас в этом. То, что делает Jira настолько мощным, заключается в том, что администраторы могут применять определенные правила в рабочем процессе проекта, например, заставлять баги (ошибки) проходить через столбец обеспечения качества (QA) или не позволять «Историям» (Stories) переходить прямо из «Сделать» (To to) в «Сделано (Выполнено)» (Done). Для получения дополнительной информации ознакомьтесь с нашей документацией по рабочему процессу.
Фильтрованные задачи
Фильтр задач позволяет скрыть задачи, которые вы не хотите видеть, и выделить только те, на которых вы хотите сосредоточиться. Программное обеспечение Jira Software имеет быстрые фильтры (Quick filters), которые позволяют фильтровать задачи на вашей доске. Вот как они выглядят на досках Scrum / Kanban:
Чтобы создать свои собственные быстрые фильтры (Quick filters ) (доски Scrum и Kanban):
Создание задачи JIRA
Для того, чтобы создать новую задачу в JIRA, необходимо выполнить следующие шаги:
1. Нажмите «Создать» (Create) в верхней части экрана, чтобы открыть диалоговое окно «Создать задачу» (Create Issue).
Комбинация клавиш: c
2. Выберите соответствующий проект и тип задачи в диалоговом окне «Создать задачу» (Create Issue).
Если вы хотите получить доступ к полям, которые не отображаются в этом диалоговом окне или вы хотите скрыть существующие поля:
1. Нажмите кнопку «Настроить поля» (Configure Fields) в правом верхнем углу экрана.
2. Нажмите «Пользовательский» (Custom) и выберите поля, которые вы хотите отобразить или скрыть, установив или сняв соответствующие флажки, или нажмите «Все» (All), чтобы отобразить все поля.
Когда вы создадите задачу, JIRA запомнит выбранные вами поля.
4. Необязательно: Чтобы создать серию похожих задач в том же проекте и с таким же типом задачи, установите флажок «Создать еще» (Create another) в нижней части диалогового окна.
5. Если вы удовлетворены содержанием своей задачи, нажмите кнопку «Создать» (Create).
Если вы выбрали флажок «Создать еще» (Create another) (см. выше), появится новое диалоговое окно «Создать задачу». В зависимости от вашей конфигурации и значений, которые вы указали при создании предыдущих задач, некоторые поля в новом диалоговом окне «Создать задачу» (Create Issue) могут быть предварительно заполнены. Перед созданием следующей задачи убедитесь, что все выполнено правильно.
Советы:
Скриншот: диалоговое окно «Создать задачу» (Create Issue)
Как организовать ресурсное планирование в 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 (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.
Работа с задачами в Jira Software
Руководство по работе с задачами в Jira Software
Просмотр тем
Учебное руководство по задачам Jira
Из этого учебного материала вы узнаете принципы работы с досками в Jira Software. В нем не рассматриваются командные ритуалы, которые вы проводите вне Jira Software, такие как собрания по планированию спринта, ретроспективы и ежедневные стендапы. О них можно прочитать в статье «Применение Scrum с помощью Jira Software».
10 минут на прочтение.
Вы только начинаете знакомство с Jira Software и пока не знаете, для чего этот инструмент нужен.
Вы создали проект Jira Software.
С помощью задач в Jira команды отслеживают отдельные составляющие работы, которые необходимо завершить. В зависимости от того, как команда использует Jira, задача может обозначать задание по проекту, заявку в службу поддержки, бланк заявления на отпуск и т. д. В Jira Software задачи обычно обозначают крупные функциональные элементы, требования пользователей и баги в ПО.
Создание задачи
Создать задачу можно несколькими способами.
Из верхней панели навигации где угодно в Jira
В бэклоге
На доске (только для проектов команды)
Дополнительно: создание подзадач
Задачи также могут содержать подзадачи, которые можно назначать и отслеживать в индивидуальном порядке. Подзадачи могут быть созданы, чтобы:
Чтобы создать подзадачу, выполните следующие действия.
Оценка сложности задач в бэклоге позволяет спрогнозировать, сколько времени может уйти на выполнение частей бэклога.
Зачем нужна оценка сложности задач? Оценка сложности нужна для определения скорости команды. Дать оценку сложности элементам бэклога нужно в первую очередь для того, чтобы с помощью этой информации понять, сколько времени уйдет на выполнение составляющих бэклога.
В классических командах по разработке руководители оценивали сложность задач в человеко-часах. Затем они могли подсчитать количество часов в бэклоге, разделить его на количество людей в команде и часов в неделе, чтобы получить прогнозируемую дату. Эти прогнозы часто оказывались крайне неточными, потому что они не учитывали особенности команды в плане оценки своих возможностей (склонность завышать или занижать оценку), непредвиденные перерывы в работе или развитие производительности команды со временем.
Поэтому среди тех, кто использует методику Scrum, многие команды стремятся не к точной оценке сложности, а к стабильной скорости. Скорость команды — это сумма величин сложности, на которую команда выполняет работу в большинстве спринтов. У большинства команд скорость в той или иной мере стабилизируется через несколько спринтов. Зная свою скорость и сложность задач в бэклоге, команды могут прогнозировать, сколько уйдет времени на выполнение крупных частей бэклога.
Например, если трудовой потенциал команды в человеко-часах составляет 120 часов в каждом спринте, а ее скорость — 60 часов, с помощью последнего значения все равно можно подсчитать, за какое количество спринтов удастся выполнить составляющие бэклога. Уместно будет спросить, куда подевались «остальные 60 часов»; может, что-то не так с производительностью команды? Но обычно с ней все в порядке: оценка команды всего лишь отражает ее представление о сложности задач, и на нее всегда влияют особенности команды (например, склонность к завышенной или заниженной оценке), а также потребление ресурсов в организации. Для планирования важна только скорость.
Большинство команд измеряет сложность работы в очках за пользовательские истории. С помощью них можно оценить сложность одной задачи относительно других. Это целесообразно, потому что позволяет получить ответ на такие важные вопросы, как «Какой объем работы мы можем выполнить за этот спринт, если оценивать ситуацию трезво?» и «Сколько времени уйдет на выполнение этой части бэклога?». Используя оценку сложности, команды могут ответить на эти вопросы, не беспокоясь о точности прогноза, как бывает, когда команду просят рассчитать объем работы по времени.
Подробнее о том, как можно отслеживать изменение сложности работы и скорость команды, рассказывается в нашем обучающем руководстве, посвященном диаграмме Burndown.
Чтобы оценить сложность задачи, выполните следующие действия.
Можно ли изменить оценку сложности после того, как она уже введена? Краткий ответ: да. Однако если вы измените подход к оценке после начала спринта, за этим последует изменение объема работ в диаграмме Burndown.
Не переживайте, если определить сложность задач не так просто. Обратитесь к нашему руководству по оценке сложности работы. В нем приведены советы и рекомендации по правильной оценке сложности задач.
Расстановка задач в порядке важности
Когда задачи расставлены по приоритету, команда может увидеть, над чем ей предстоит работать далее. Чтобы определить порядок задач, перейдите в бэклог или на доску и перетащите задачи, чтобы расположить их в порядке очередности. Перечислим несколько вариантов, где вы можете это сделать.
В проекте Scrum при планировании следующего спринта вы можете определить порядок задач в бэклоге, а затем поместить первые 10 задач (или столько задач, сколько может выполнить команда) в спринт.
В шаблоне Kanban порядок задач можно определить в столбце To do (К выполнению). Когда участники команды будут готовы взять дополнительную работу, им потребуется взять задачу из верхней строчки списка. Помните, что в рамках этого подхода вам нужно постоянно следить за всеми задачами в столбце To do (К выполнению), поскольку приоритеты могут измениться.
Примечание. Чтобы переместить задачу выше или ниже на доске, пользователь должен иметь на эту задачу права Schedule Issue (Составление графика задач) и Edit Issue (Редактирование задачи).
Добавление флага к задаче
Вы можете пометить задачу флагом. Помеченная задача выглядит так:
Возможность добавлять пометки к задачам способствует взаимодействию и обмену информацией в команде. Рассмотрим несколько примеров.
Вы работаете над заданием и понимаете, что вам не удастся его закончить. Вы можете пометить задачу, и коллега, у которого есть нужные ресурсы, посмотрит на доску и придет на помощь.
Вы работаете над задачей и в определенный момент сталкиваетесь с препятствием. В этом случае можно пометить задачу, добавить комментарий с описанием блокера и перейти к следующему заданию. Эту отметку можно увидеть на доске. Если открыть задачу, сразу станет понятно, в чем проблема.
Чтобы пометить задачу, выполните следующие действия.
Перейдите на доску.
Щелкните по задаче правой кнопкой мыши.
Нажмите Add flag (Пометить).
Изменение статуса задач
Изменение статуса задач отражает прогресс в рабочем процессе. Чтобы изменить статус задачи, перетащите ее из одного столбца в другой.
Если вам не удается перенести задачу в другой столбец, возможно, в рабочем процессе установлены ограничения. Широкие возможности Jira позволяют администраторам устанавливать определенные правила, например обязательное прохождение багов через столбец контроля качества или запрет на перенос историй из столбца «Предстоит сделать» напрямую в столбец «Завершено». Подробная информация приведена в нашей документации по рабочему процессу.
Фильтрация задач
С помощью фильтра задач можно скрывать задачи, которые вам не нужны, и выводить на передний план важные задачи. В Jira Software есть быстрые фильтры, с помощью которых можно фильтровать задачи на доске. Вот как они выглядят на досках Scrum и Kanban.
Строка поиска позволяет отобразить задачи, соответствующие поисковому запросу, и скрыть остальные.
Меню быстрых фильтров по умолчанию позволяет фильтровать задачи, назначенные вам, и недавно обновленные задачи. Все созданные вами быстрые фильтры также будут показаны здесь.
Меню исполнителей позволяет отобразить задачи, назначенные выбранным вами исполнителям.
Чтобы создать собственные быстрые фильтры (для досок Scrum и Kanban), выполните следующие действия.
Укажите для фильтра имя, JQL-запрос и описание. Подробную информацию о JQL-запросах см. в нашей документации по продвинутым возможностям поиска.
Нажмите Add (Добавить).
Автоматизация — ваше секретное оружие
Jira — это место, где кипит работа. Иногда работы бывает очень много! Автоматизация имеет ключевое значение для поддержания всех задач в актуальном и упорядоченном состоянии. Некоторые наиболее распространенные приемы автоматизации можно найти в библиотеке шаблонов Jira Automation.
Хотите узнать больше?
Подробнее о работе с задачами в Jira Software см. в документации по задачам.