что такое релизы в jira
Как выпустить релиз в проекте
Чтобы отследить прогресс по задачам, необходимо регулярно (примерно раз в 2 недели) выпускать релизы, в которые будут входить все выполненные на неделе задачи.
После того как релиз создан, задачи скрываются из столбца Выполнено на канбан доске.
Чтобы выпустить релиз, нажмите ссылку Релиз над канбан панелью.
В открывшемся окне введите имя релиза:
Имя релиза (продукта) строится из кода продукта и даты выпуска в формате ДДММГГ. Например, для проекта RTFM релиз, выпущенный 26 сентября, будет называться: RTFM-260916.
После ввода имени, нажмите кнопку Выпуск.
Список всех релизов можно найти в разделе проекта, нажав в боковой панели иконку с изображением корабля:
В этом разделе вы можете сразу запланировать выпуск следующего релиза. Для этого введите его название в поле над таблицей и нажмите Добавить.
Как найти и проверить задачи, в которых вы автор
Чтобы найти решенные задачи, которые нуждаются в вашем утверждении откройте системный рабочий стол и на нем таблицу Проверить Выполненные Задачи.
Чтобы открыть список всех задач, нажмите на их количество внизу данной таблицы. Чтобы перейти к задаче, нажмите на её название.
Все задачи, которые нуждаются в проверке имеют статус Выполнено. Чтобы утвердить задачу, нажмите кнопку Проверено. Если она нуждается в доработках, опишите их в комментарии и верните задачу в работу на исполнителя с помощью кнопку На доработку.
Узнайте, как использовать версии в Jira Software
Руководство по использованию версий в Jira Software
Просмотр тем
Учебное руководство по версиям Jira
Из этого учебного руководства вы узнаете, как можно работать с версиями в Jira Software.
10 минут на прочтение. Прохождение учебного курса занимает не менее 2 недель.
Вы знакомы с принципами работы с досками Scrum и (или) Kanban в Jira Software
У вас есть права на администрирование всех проектов на вашей доске Scrum или Kanban. Дополнительную информацию см. на странице «Управление правами на уровне проекта».
Вы создали проект Scrum или Kanban в Jira Software
Вы добавили в проект задачи
Версии в Jira Software отражают состояние проекта на определенный момент времени. Они помогают организовать работу посредством создания контрольных точек, которых необходимо достичь. Вы можете связать задачи проекта с конкретной версией и организовать спринты для выполнения работы в рамках этой версии.
Шаг 1. Создание версии в Jira Software
В меню проекта нажмите Releases (Релизы).
Выберите текстовое поле Version name (Имя версии), введите имя и нажмите Add (Добавить).
Имена версий обычно состоят из цифр, например 1.0 или 2.1.1. Можно также использовать внутреннее кодовое имя.
Вы можете создать ровно столько версий, сколько необходимо. Создание нескольких версий поможет спланировать работу заранее, однако для начала можно ограничиться лишь одной или двумя.
После создания версии для ваших задач станут доступны поля Affects version (Затрагиваемая версия) и Fix version (Версия фикса).
Шаг 2. Добавление задач к версии
Если у проекта есть бэклог
Перейдите в бэклог проекта.
Откройте панель Versions (Версии) слева.
Перетащите задачу в нужную версию для добавления.
Если у проекта нет бэклога
Откройте задачу, которую нужно добавить в версию.
Найдите поле Fix version/s (Версия исправления) и введите имя версии, в которую нужно добавить задачу.
Затрагиваемая версия — это версия, в которой были обнаружены баг или проблема. Информация о таких версиях может быть полезна при отслеживании проблем, однако они используются в Jira довольно редко.
Версия фикса — это версия для клиентов, в рамках которой планируется выпуск новой возможности или устранение багов. Это поле используется для планирования релизов, отслеживания работы и скорости ее выполнения, а также для составления отчетов. Скорее всего, вы будете пользоваться им чаще остальных в процессе работы.
Шаг 3. Отслеживание работы над версией
Jira Software содержит множество инструментов, с помощью которых вы можете следить за работой над версией. Далее мы поговорим о некоторых из них.
Центр управления релизами
В центре управления релизами вы можете управлять всеми релизами, а также просматривать сведения о состоянии релизов и количестве задач в каждой версии.
Переход в центр управления релизами.
В меню проекта выберите Releases (Релизы).
Быстрые фильтры. Отобразите конкретные версии, исключив все остальные.
Список версий. Перетаскивайте версии, чтобы изменить их порядок.
Состояние. Версии могут находиться в одном из трех состояний: Unreleased (Не выпущена), Released (Выпущена) или Archived (В архиве).
Прогресс. Здесь показано количество задач, связанных с конкретной версией, а также состояние каждой задачи.
При интеграции Jira Software с репозиторием Bitbucket вы также увидите здесь информацию о разработке, связанную с коммитами, ветками и запросами pull.
Burndown-диаграмма релиза (только для Scrum)
На диаграмме Burndown релиза показан объем выполненной и оставшейся работы. С помощью таких диаграмм можно спрогнозировать, выполнит ли команда работу в срок. Они также отлично подходят для того, чтобы сообщить команде о расширении области проекта.
Обратите внимание: прежде чем использовать диаграмму Burndown релиза, необходимо оценить сложность задач. Подробнее см. в нашем руководстве по диаграммам Burndown.
Чтобы просмотреть диаграмму Burndown релиза, выполните следующие действия.
В меню проекта выберите Reports (Отчеты).
Выберите Release burndown (Диаграмма Burndown релиза).
Меню релизов. Выбор релиза, информацию по которому нужно просмотреть.
Добавленная работа. Сегменты темно-синего цвета отображают объем работы, добавленный в каждый спринт релиза. В этом примере объем работы измеряется в очках за пользовательские истории.
Оставшаяся работа. Сегменты светло-синего цвета отображают оставшийся объем работы в релизе.
Выполненная работа. Сегменты зеленого цвета отображают объем работы, выполненной в рамках каждого спринта в релизе.
Ожидаемое время завершения. В отчете показано, сколько спринтов потребуется для завершения работы над релизом с учетом скорости работы команды.
Шаг 4. Завершение работы над версией
Ваша команда усердно потрудилась — настало время выпустить релиз ПО. На этом этапе вы должны быть уверены, что версия готова к релизу. Убедитесь, что все задачи выполнены, код загружен и проверен, выполнено его слияние, сборки успешно протестированы и т. д.
Для развертывания релиза чаще всего необходимо выпустить версию в Jira Software, после чего выполнить сборку релиза и его развертывание в нужной среде.
Завершение работы над версией
Перейдите в проект.
В меню проекта выберите Releases (Релизы).
Кнопка «. »Выберите Actions (
) > Release (Действия > Выпустить) для версии, которую нужно выпустить.
На досках Kanban можно также выпустить все задачи из столбца Done (Выполнено) в качестве новой версии прямо со страницы доски.
Автоматизация позволяет оптимизировать работу с версиями в Jira. Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation. Перейти в библиотеку
Хотите узнать больше?
Подробнее о работе с версиями в Jira Software см. в нашей документации по версиям.
Путь к релизам без стресса
Это видео гарантированно понизит уровень напряжения при подготовке вашего следующего крутого релиза.
Просмотр тем
Лучшим мерилом успеха любой agile-команды является скорость поставки рабочей версии ПО клиентам. Даже опытным командам разработчиков становится не по себе, когда приходит пора проверять, соответствуют ли результаты выполнения задач тем требованиям, что к ним предъявлялись. И выясняется, что где-то была пропущена проверка кода, где-то не выполнили слияние, в сборках после слияния возникают ошибки… Знакомо?
Из этой презентации вы узнаете следующее.
Смотрите и учитесь
Вопросы и ответы
Джейсон Вон и Меган Кук, которые провели эту презентацию, выбрали свои любимые вопросы от зрителей. Прочитайте ответы на них ниже, чтобы узнать, как гарантировать успех релизов, не напрягаясь.
Вопрос 1. Назовите три главных преимущества использования центра управления релизами, помимо технических.
Ответ 1. (1) Уверенная поставка продукта. Заинтересованные стороны в команде и за ее пределами смогут в любой момент цикла релиза узнать, что именно готово к выпуску.
(2) Экономия времени, более быстрое принятие решений. Информация о готовых к поставке функциях и проблемах выдается автоматически за считаные минуты. Центр управления релизами сам проверяет все задачи в выпускаемой версии, чтобы вам не нужно было вручную приводить в соответствие задачи и код.
(3) Учет релизов. Узнать, что вышло (когда и в каком релизе), можно в списке выпущенных версий. Информация о том, что планируется в данный момент для каждого из будущих релизов, содержится в списке невыпущенных версий.
Вопрос 2. Кто обычно управляет версиями релизов в Atlassian?
Ответ 2. У каждой команды в Atlassian есть свой особый подход. При этом мы обычно стремимся максимально автоматизировать процесс, чтобы выпустить исправления багов рабочей версии или новую версию продукта мог любой разработчик команды, приложив минимум усилий.
Обычно команды ведут список актуальных задач, но мы всеми силами пытаемся отказаться от этого. Такой инструмент, как центр управления релизами, очень в этом помогает. Он гарантирует, что версия, которую мы планируем выпустить, будет наивысшего качества и что стадии процесса, на которых находятся задачи в Jira Software, точно отражают их фактическое состояние.
В некоторых командах покрупнее (например, в командах разработчиков Jira Software и Confluence) заведено, чтобы всеми релизами поочередно управляли несколько менеджеров по релизам.
Когда дело касается крупных основных и вспомогательных версий, обычно за релиз отвечает специально назначенное лицо, которое следит за объемом работ, управляет рисками, угрожающими подготовке релиза, и планирует график. Этим может заниматься руководитель команды или руководитель по разработке, но мы стараемся, чтобы каждый участник команды поочередно принимал на себя эту обязанность. Так каждый знакомится с процессом и начинает понимать, какие требования предъявляются к выпуску качественного ПО.
При составлении графика работы руководители команд общаются с менеджерами по продукту и маркетологами, чтобы сформировать ожидания о сроках готовности релиза и понять, нужно ли менять объем или временные рамки работы. Именно эти люди решают, какие функции будут выпущены в рамках тех или иных версий.
Вопрос 3. Каким образом вы устанавливаете связь между веткой/коммитом/запросом pull/сборкой/развертыванием и задачей?
Ответ 3.
1. Ветка — ключ задачи добавляется в имя ветки.
2. Коммит — ключ задачи указывается в комментарии к коммиту.
3. Запрос pull — ключ задачи указывается в имени исходной ветки, добавленном комментарии к коммиту или заголовке запроса pull.
4. Сборка — ключ задачи указывается в добавленном комментарии к коммиту.
5. Развертывание — ключ задачи указывается в добавленном комментарии к коммиту.
Вопрос 4. Как вы обычно устраняете конфликты, возникающие при работе над одним и тем же кодом в отдельных ветках задач?
Ответ 4. Мы редко сталкиваемся с подобной проблемой. Большинство задач предполагает работу над разными фрагментами кода, но иногда конфликты все же возникают.
Все потенциальные проблемы можно поделить на два типа.
Для решения проблем первого типа рекомендуется вести поэтапную разработку и выполнять слияния часто, но сами новые функции вводить через специальные флаги, чтобы доступ к актуальным изменениям имели только сотрудники компании или избранные клиенты. Благодаря этому код, в котором могут возникать конфликты, будет внедряться постоянно, вероятность возникновения конфликта уменьшится, равно как и риск, и негативные последствия, связанные с добавлением крупных функциональных изменений в основную ветку разработки.
Если это невозможно, а также в случае крупномасштабного рефакторинга мы стараемся как можно чаще сливать ветвь разработки в функциональную ветку (передавая изменения в основной ветке/ветке разработки в функциональную ветку). Тогда вся текущая работа по разработке продолжается, и основная ветка приводится в соответствие с долгосрочной функциональной веткой с максимально возможной частотой. При возникновении конфликтов слияния авторам изменений будет гораздо проще помочь решить их или по крайней мере их работа будет сведена к минимуму, чтобы решить конфликты было проще.
Идеальное решение — делить всю работу на части, которые можно было бы сливать в основную ветку как можно чаще. За счет этого уменьшается вероятность, что одни и те же файлы в функциональных ветках изменяются одновременно.
Вопрос 5. Какой стратегии следует придерживаться при управлении параллельными ветками текущей разработки (функциональными ветками), ветками исправлений и их развертывании в различных средах (в среде контроля качества, промежуточной и рабочей средах)?
Ответ 5. В нашем арсенале есть несколько стратегий управления ветками, которые описаны на нашем веб-сайте, посвященном Git. В частности, рекомендуем заглянуть в раздел «Сравнение процессов».
Подробную информацию можно получить, просмотрев запись предыдущего выступления Правильный подход к Git. Рабочие процессы непрерывного развертывания были подробно рассмотрены на вебинаре Рабочие процессы Git для SaaS-команд.
Если коротко, существует два основных рабочих процесса: рабочий процесс для выпуска загружаемых продуктов и рабочий процесс для онлайн-сервисов (рабочие процессы Git для команд, выпускающих программное обеспечение как сервис (SaaS))
Для выпуска загружаемых продуктов большинство команд пользуется вариациями модели Gitflow Workflow, в которой текущая разработка ведется в главной ветке, а каждой предыдущей промежуточной версии соответствует отдельная ветка, от которой отходят (и впоследствии с ней сливаются) ветки исправлений. При необходимости выполняется сборка релиза с исправлениями. Все изменения в каждой предыдущей ветке релиза включаются в последующие ветки релиза и главную ветку, чтобы ни одна из последующих версий не была выпущена без исправлений.
Вопрос 6. Удобно ли использовать центр управления релизами при использовании доски Kanban и частом выпуске релизов?
Ответ 6. Да, вполне. Кнопку Release (Выпустить) на доске Kanban можно использовать для создания новой версии, в которую включаются все задачи, запланированные для этого релиза. После создания версии в центре управления релизами можно просмотреть предупреждения (при наличии) или получить общее представление о версии.
Даже при работе без доски kanban можно в любой момент создать версию и добавить в нее задачи, даже если они еще не завершены. После этого в центре управления релизами можно просмотреть, есть ли предупреждения. Если их нет, значит, релиз готов.
Вопрос 7. Можно ли просматривать в центре управления релизами информацию о задачах из нескольких проектов Jira Software, или в нем всегда отображается информация только по какому-то конкретному проекту и версии исправления?
Ответ 7. В центре управления релизами имеется подробная информация о версии. Поскольку в настоящее время версии относятся к одному определенному проекту, центр управления релизами также соотносится с одним определенным проектом.
Вопрос 8. Можно ли настроить центр управления релизами так, чтобы предупреждения автоматически передавались в комнату Hipchat?
Ответ 8. На данный момент интеграций, которые связывали бы предупреждения центра управления релизами с Hipchat, не существует, и пока что их разработка не планируется. Были разные идеи о том, как расширить возможности командной работы в Hipchat с помощью центра управления релизами. Мы приглашаем наших клиентов поделиться мыслями о том, как они могли бы использовать подобную интеграцию, равно как и любые другие интеграции с другими нашими продуктами.
Вопрос 9. Для чего нужна кнопка Release (Выпустить)? Она запускает сценарий для развертывания релиза на рабочем сервере в виде задачи в Bamboo?
Ответ 9. Кнопка Release (Выпустить) выполняет несколько функций.
Вопрос 10. Планируете ли вы интеграцию центра управления релизами с GitHub/GitHub Enterprise?
Ответ 10. Центр управления релизами уже можно использовать с GitHub и GitHub Enterprise. Для этого нужно подключить экземпляр Jira Software к аккаунту GitHub, нажав DVCS Accounts (Аккаунты распределенных систем управления версиями) в меню администратора аддонов в Jira Software. После этого можно начать отслеживать состояние любой версии, так как вся соответствующая информация о разработке появится в центре управления релизами.
Лаура — бывший менеджер по маркетингу продуктов. У нее есть опыт работы с различными командами по продуктам, включая Jira Software, Portfolio for Jira и Bitbucket. Когда она не занимается разработкой рекомендаций по использованию методик agile, ее можно встретить в горах — во время штурма очередного перевала или при попытке отыскать удобный уступ.
Подпишитесь и получайте больше статей
Thanks for signing up!
Изучите версии с помощью Jira Software
Узнайте, как использовать версии для организации рабочего процесса с разбивкой на практически достижимые контрольные точки. Узнайте, как назначать задачи в проекте в соответствии с определенной версией.
Как ускорить процесс контроля качества
Узнайте, как небольшая команда специалистов по содействию в обеспечении качества агитирует за применение методов сбалансированного тестирования в команде разработчиков и обучает их этим методам.
BYTEX BLOG
JIRA: ПОДРОБНОЕ РУКОВОДСТВО ДЛЯ НОВИЧКОВ
JIRA — приложение, разработанное австралийской компанией Atlassian. Его название произошло от японского слова «Gojira», что значит «Годзилла».
В основном используется для учета багов, обнаруженных в компьютерных и мобильных приложениях. Панель управления JIRA предоставляет множество полезных возможностей и функций, позволяющих легко собрать и упорядочить все найденные проблемы. Ряд из них мы рассмотрим ниже.
1. Система JIRA
JIRA состоит из ряда компонентов, каждый из которых можно настроить. Это:
2. Задачи JIRA и их типы
JIRA позволяет отслеживать баги и задачи, лежащие в основе проекта. Как только вы импортируете проект в JIRA, вы можете создавать задачи.
Во вкладке «Задачи» (Issues) можно обнаружить следующие функции:
9
Типы задач (Issue Types)
Во вкладке «Типы задач» отображены все типы задач, которые можно создавать и отслеживать в JIRA. Как можно увидеть на скриншоте, задачи классифицируются различными видами функций, подзадач, багов и т.д.
В JIRA есть две системы организации типов задач.
Стандартная система организации типов задач (Default Issue Type Scheme).
В стандартной системе организации типов задач все новые созданные задачи автоматически добавляются на схему.
Agile Scrum система организации типов задач (Agile Scrum Issue Type Scheme).
Задачи и проекты, которые ассоциируются с Agile Scrum, используют эту систему.
Помимо этих двух схем вы можете создавать собственные типы задач, настраивая функционал под себя. Например, мы можем создать схему IT и Поддержка (IT & Support), перетащив типы задач из вкладки «Доступные типы задач» (Available Issue type) на вкладку «Типы задач для текущей схемы» (Issue type for current scheme), как показано на скриншоте ниже.
3. Компоненты JIRA
Компоненты — это подразделы проекта. Они используются, чтобы комбинировать задачи текущего проекта в малых разделах. Компоненты добавляют проекту структурированность, разбивая его на функции, группы, модули, подпроекты и прочее. Используя компоненты, вы можете генерировать отчеты, собирать статистику, отображать ее на панелях управления.
Как показано на скриншоте, вы можете добавлять новые компоненты, такие как Название (Name), Описание (Description), Руководитель отдела/команды (Component lead) и Назначенный ответственным по умолчанию (Default assignee).
4. Окна JIRA (JIRA screen)
Если задача создана в JIRA, она будет организована и представлена на различных рабочих пространствах, которые называются экранами. Эти рабочие пространства могут переводиться и редактироваться в ходе рабочего процесса. Как можно увидеть на скриншоте, каждой задаче вы можете назначить тип экрана. Чтобы ассоциировать осуществление задачи с определенным экраном, нужно зайти в главное меню, кликнуть Задачи (Issues), кликнуть Схемы (Schemes), после этого кликнуть Ассоциировать осуществление задачи с экраном (Associate an issue operation with a screen) и добавить экран, соответствующий требованиям.
5. Свойства задач (Issue Attributes)
5. Свойства задач (Issue Attributes)В свойства задач входят:
Различные статусы используются, чтобы обозначить прогресс проекта: Ожидает выполнения (To do), Выполняется (InProgress), Открыт (Open), Закрыт (Closed), Переоткрыт (ReOpened), Решен (Resolved). Также имеются решения и приоритеты. Решения обозначают прогресс выполнения задачи: Исправлено (Fixed), Не будет исправлено (Won’t fix), Дубликат (Duplicate), Не завершено (Incomplete), Не воспроизводится (Cannot reproduce), Выполнено (Done). Также вы можете указать приоритеты задач: Критический (Critical), Высокий (Major), Малозначимый (Minor), Блокирующий (Blocker) и Тривиальный (Trivial).
6. Схемы защиты задач JIRA (Issue Security Schemes)
Эта функция JIRA позволяет вам контролировать доступ к задачам. Она включает в себя несколько уровней доступа, которые распределяются между пользователями и группами. Вы можете указать уровень доступа к задачи во время ее создания или редактирования.
Также имеется Стандартная схема защиты (Default Permission Scheme), которая будет назначена любому новому проекту. Схемы защиты позволяют вам создавать наборы уровней доступа и применять их к любому проекту.
Системная администрация (System Administration)
Вот несколько полезных функций, которые JIRA предоставляет администраторам:
Логи ревизий (Audit Log). В этой вкладке вы можете увидеть детали созданной задачи, а также изменения, внесенные в задачу.
Связывание задач (Issue Linking). Здесь указывается связана ли ваша задача с какой-то другой, существующей в данном проекте. Также в этой панели можно отменить данную связь.
Система почты JIRA (Mail in JIRA). Используя систему почты в качестве администратора, вы можете пересылать задачи на почтовые сервера POP и IMAP, а также отправлять их в виде сообщений на внешние почтовые ящики.
События (Events). В этой вкладке описан статус, стандартный шаблон, схемы оповещения и передача ответственности за событие. События разделены на два типа: Системные события (System event, те, что установлены в JIRA по умолчанию) и Пользовательские события (Custom event, соответственно, те, что были созданы пользователями).
Контрольный список (Watch list). Позволяет просматривать определенные задачи, видя уведомления, связанные с ними. Чтобы просмотреть задачу, кликните «просмотр» в окне задачи, а если вы хотите увидеть, кто еще просматривает эту задачу, вы можете нажать на число в скобках.
Счетчик задач (Issue Collectors). Позволяет собирать информацию с любого сайта. Будучи администратором, можно кликнуть по счетчику задач, после чего появится опция, позволяющая его добавить. Как только вы настроите внешний вид счетчика, автоматически сгенерированный JavaScript можно перенести на сайт для передачи информации.
Инструменты разработки (Development Tools). Вы можете также подключить ваши инструменты разработки ПО к JIRA, используя функции администратора. Вам необходимо ввести URL приложения для подключения его к JIRA.
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), как показано на скриншоте ниже.
Таким образом вы создадите подзадачу, прикрепленную к основной задаче, а на странице подзадач вы сможете увидеть время, отведенное на ее выполнение.
Несколько важных вещей, которые нужно помнить, создавая подзадачи:
Рабочий процесс (WorkFlow)
Рабочий процесс в JIRA представляет из себя набор статусов и переходов, через которые проходит задача во время своего жизненного цикла. Он может включать в себя пять основных стадий:
Рабочий процесс JIRA состоит из статусов (statuses), переходов (transitions), назначений (assignee), решений (resolution), условий (conditions), проверок (validators), и свойств (properties).
Статусы определяют статусы задач во время рабочего процесса.
Переходы подразумевают под собой процесс смены статуса.
Назначения указывают ответственных за определенные задачи и определяют пути решения задачи.
Решения объясняют, по какой причине задача может считаться закрытой.
Условия контролируют доступ к переходам.
Проверки позволяют убедиться, что переход может быть произведен соответственно статусу задачи.
Свойства определяются JIRA при переходах.
Вы можете назначить статус задаче в соответствующем ей окне, кликнув на флажок статуса В работе (IN Progress), как показано на скриншоте ниже. Это отобразит статус задачи на ее рабочей панели, выделив его желтым цветом.
Для созданной нами задачи JIRA отобразит таблицу рабочего процесса, на которой указан путь, пройденный задачей во время работы над проектом. Все статусы, которые мы устанавливали для задачи, отображаются на таблице. Как показано на скриншоте, в нашей таблице появился ряд статусов, а статус «В работе» (IN Progress), который является текущим, выделен желтым цветом. Таблица рабочего процесса дает возможность быстро просмотреть, через какие стадии прошла задача.
Плагины JIRA (Plug-ins in JIRA)
Для JIRA существует множество плагинов, позволяющих вам эффективнее работать. Это такие плагины, как Zendesk, Salesforce, GitHub, Gitbucket и т. д. Часть из них позволяет команде поддержки отчитываться о работе напрямую в JIRA, создавать неограниченные приватные репозитории с полной поддержкой задач, инструментов управления тестированием и т. д.
JIRA Agile (JIRA Agile)
Agile метод в основном используется командами разработчиков, которые пользуются концепцией «дорожная карта» (roadmap), подразумевающей под собой последовательный переход между запланированными функциями в процессе разработки новых версий продукта. Agile следует той же «дорожной карте», что и другие проекты в JIRA «Ожидает выполнения — В работе — Завершено» (To do — In Progress — Done). Как вы можете увидеть на скриншоте ниже, у нас есть одна задача со статусом «Ожидает выполнения» и вторая со статусом «В работе». Как только задача «В работе» будет решена, ее статус изменится на «Завершено», и точно так же задача «Ожидает выполнения» получит статус «В работе».
Создание задачи в Agile
Чтобы создать agile-задачу, перейдите в главное меню на вкладке «Agile», нажмите «Начать работу» (Getting Started), после чего вас попросят выбрать, какой использовать метод управления: «Scrum» или «Kanban». Вы можете выбрать одну из опций в зависимости от ваших требований. В данном примере мы выбрали «Scrum».
Создания Эпика в Agile
Эпик (Epic) — способ описания требований к разрабатываемой системе, представляющий из себя большую user story («пользовательскую историю»), которая может состоять из нескольких меньших. В JIRA эпик представляет из себя еще один тип задач, охватывающий огромный объем работы. Для завершения эпика потребуется несколько спринтов (sprint — список работ на ближайший отчетный период, который команда определила и согласовала с владельцем продукта). Вы можете либо создать новый эпик в Agile, либо использовать задачу, которую вы создали на обычной рабочей панели JIRA. Точно так же вы можете создать пользовательскую историю для agile scrum.
Режим планирования (Plan Mode) в Agile:
Режим планирования отображает все пользовательские истории, созданные для проекта. Вы можете воспользоваться меню, расположенным с левой стороны, чтобы определить условия, согласно которым будут отображаться задачи. С правой стороны расположено меню, с помощью которого вы можете создавать задачи, логи и т.д.
Режим работы (Work Mode) в Agile:
Отображает информацию о текущем спринте. Все задачи и истории пользователя разделены на те же три категории «Ожидает выполнения», «В работе», «Завершено», отображающие прогресс работы над проектом или задачами.
Связывание и клонирование (Clone and Link) задач в JIRA
В JIRA вы также можете клонировать задачу. Преимущество этой функции в том, что над задачей сможет отдельно работать другая команда, позволяя решить задачу быстрее.
Помимо этого в JIRA есть такая полезная функция, как «Связывание» (Link). Связывание задач, что понятно из названия, позволяет создавать связи между существующими задачами на этом же или другом сервере JIRA. Как показано на скриншоте, мы связали задачу «ST-6 Выпадающее меню не работает» (ST-6 Drop down menu is not working) с другой «ST-4 Интерфейс не работает — необходим ретест функционала интерфейса» (ST-4 GUI is not responsive- retest GUI functions).
Создав данную связь, мы запустили однодневный спринт, который будет продолжаться определенный период времени, как можно увидеть на скриншоте ниже. Если вы работаете со «scrum» и хотите изменить приоритет или ранг задачи, вы просто можете перетащить ее в бэклог (backlog — журнал оставшейся работы, которую необходимо выполнить команде).
Помимо этого здесь же есть еще множество возможностей, которыми можно воспользоваться. Например, если вы кликните по иконке в верхнем правом углу окна, появится выпадающий список с функциями, которые вы можете применить при необходимости.
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) и т. д.
Вы также можете настроить то, как будет отображаться рабочая панель Scrum — для этого имеется множество опций. Элементы Scrum, которые можно настроить подобным образом, включают в себя: колонки (Columns), Swim Lane блок-схемы, быстрые фильтры (Quick Filters), цвета элементов (Card colors) и т. д. Здесь, например, мы выбрали управление колонками, а для типа отображаемой информации указали «Подсчет задач» (Issue count), что позволило нам увидеть точное число задач, находящихся в процессе выполнения, выполненных и ожидающих выполнения. Помимо этого можно выбрать множество других типов колонок, которые будут отображать ту информацию, которая вам необходима.
Фильтры (Filters)
Вы можете создавать свои фильтры в придачу к установленным по умолчанию. Фильтры могут быть по данным (date), компонентам (component), приоритетам (priority), решениям (resolution) и т.д.
Kanban-панели и управление задачами
Точно так же, как с панелью Agile Scrum, мы можем создать Kanban-панель. В данном примере мы создали проект под названием «Облачное тестирование» (Cloud Testing). Kanban-панель полезна для управления и ограничения находящейся в процессе выполнения работы. Kanban-панели отображаются в режиме работы, но не в режиме планирования.
Так мы создали две задачи на Kanban-панели: «Баг, обнаруженный во время нагрузочного тестирования» (Bug detected while load testing) и «Проверить задачи, относящиеся к облачному серверу» (Check issues related to cloud server).
Kanban считается лучшим методом для работы с багами и поддержки релизов, когда новые задачи соответственно приоритезируются и обрабатываются. Есть несколько способов повысить эффективность вашей работы в Kanban:
Сравнение JIRA Scrum и JIRA Kanban