Найти в Дзене
Lyakhov Eugene
13 подписчиков

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

2
8 мин
Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT Подпишись на https://t.me/IT_Interview_Partner_Bot Jira является основным инструментом управления задачами команды. Данный документ описывает правила и рекомендации по созданию, оформлению и управлению задачами в системе Jira. Следование этому регламенту позволит повысить прозрачность процессов, упростит взаимодействие внутри команды и обеспечит согласованность действий всех участников проекта.
«Зачем отдельно История, отдельно Задача?»
У нас есть два параллельных мира, которые должны пересечься, но не смешаться: Правило: Разработчик не берет в работу «Историю» как единицу исполнения. Он берет «Задачу», которая реализует часть этой Истории. Это глобальная цель. Крупный модуль или фича, которую нельзя сделать за один спринт. История представляет собой описание требования с точки зрения конечного пользователя. Этот тип задач используется аналитиками для фиксации требований и описания бизнес-процессов. Истории
Оглавление

Страховка на собеседовании

Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT

Подпишись на https://t.me/IT_Interview_Partner_Bot

Общие положения

Jira является основным инструментом управления задачами команды. Данный документ описывает правила и рекомендации по созданию, оформлению и управлению задачами в системе Jira. Следование этому регламенту позволит повысить прозрачность процессов, упростит взаимодействие внутри команды и обеспечит согласованность действий всех участников проекта.
«Зачем отдельно История, отдельно Задача?»
У нас есть два параллельных мира, которые должны пересечься, но не смешаться:

  1. User Story/История: Это работа Аналитиков. Здесь мы говорим на языке бизнеса. Здесь живут требования, макеты и логика. История отвечает на вопрос: «Какую проблему пользователя мы решаем?».
  2. Task/Задача: Это работа Разработчиков, QA, DevOps, Дизайнеров. Здесь мы говорим на языке кода, баз данных и тестов. Задача отвечает на вопрос: «Что конкретно мне нужно сделать руками, чтобы История заработала?».

Правило: Разработчик не берет в работу «Историю» как единицу исполнения. Он берет «Задачу», которая реализует часть этой Истории.

Иерархия задач

Epic (Эпик)

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

  • Пример: «Личный кабинет пользователя», «Интеграция с платежной системой»
  • Кто создает: Product Owner / PM / Tech Lead
  • Epic служит для группировки связанных историй
  • Помогает видеть "большую картину"

User Story (История)

История представляет собой описание требования с точки зрения конечного пользователя. Этот тип задач используется аналитиками для фиксации требований и описания бизнес-процессов. Истории создаются аналитиком совместно с заказчиком или владельцем продукта и отвечает обязательным принципам:

  • Владелец: Системный Аналитик (SA).
  • Связь: Всегда прилинкована к Эпику (поле Epic Link / Parent).
  • Краткое описание: Краткий заголовок истории, отражающий суть требования.
  • Описание: Подробное описание функциональности с указанием целей и ожидаемых результатов.
  • Критерии приемки (DoD): Четкие критерии, определяющие условия, при выполнении которых история считается выполненной.
  • Связанные задачи: Перечень технических задач, необходимых для реализации истории (история может иметь несколько задач).

Примеры историй:

  • [SA] Реализовать фильтрацию товаров по цене
  • [SA] Улучшить производительность страницы заказа

Аналитик работает ТОЛЬКО с Историями. Разработчики/тестировщики и т.д. работают ТОЛЬКО с Задачами.

Task (Задача)

После завершения анализа, аналитик создает задачи. Задачи представляют собой конкретные технические задания, необходимые для реализации одной истории. Этот тип задач используется всеми членами команды кроме аналитиков. Задачи формируются на основании анализа истории и отвечает обязательным принципам:

  • Исполнитель: Dev (BE/FE/), QA, DevOps, Дизайнер.
  • Связь: Всегда прилинкована к Истории (через Issue Links -> implements или relates to).
  • Название: Короткое название задачи, соответствующее конкретной технической операции.
  • Описание: Детальное техническое задание, включающее спецификации, инструкции и дополнительные детали.
  • Тип задачи: Техническое действие (разработка, тестирование, поддержка инфраструктуры и т.п.).
  • Оценка сложности (SP): Количество story points, которое отражает трудоемкость и сложность задачи.

Запрещено создавать Истории для технических задач («рефакторинг», «обновление либ»). Такие работы оформляются как Задачи напрямую под Эпиком «Технический долг» или «Инфраструктура». История всегда должна нести бизнес-ценность, в остальных случаях задача НЕ привязывается напрямую к Эпику! Только через родительскую Историю

Примеры задач:

  • [FE] Изменение отображения фильтров на странице каталога
  • [BE] Оптимизация запросов базы данных

Правила оформления: User Story (История)

DoR (Definition of Ready) для Истории Перед тем как отдать историю на оценку, проверь:

  1. Понятное название.
  2. Подробное описание задачи, может быть разбита по шагам, пример:Описать структура бд application-service
    Собрать требования на UI и описать тз
    Описать метод создания заявки
  3. Нет блокеров
  4. Выставлен приоритет
  5. Приложены все необходимые бизнес-требования (если имеются)
  6. Прикреплен к эпику

Важно: История НЕ уходит в "Завершено" , пока к ней не прилинкованы технические Задачи (Tasks) и они не описаны. После создания задач, тех.лид должен назначить исполнителей, исполнители должны оценить свои задачи

DoD для истории:

1. Функциональность:

  • Код полностью реализует функциональные требования, описанные в истории.
  • Новая функциональность протестирована и работает согласно Acceptance Criteria (Критериям приемки).
  • Регрессионное тестирование не выявило побочных эффектов для существующей системы.

2. Качество кода и ревью:

  • Весь новый или измененный код прошел Code Review (два глаза смотрят, один пишет). Ревью проводил хотя бы один член команды (не автор).
  • Код соответствует стандартам и гайдлайнам проекта (code style, принципы SOLID/DRY/KISS и т.д.).
  • Все мерж-конфликты разрешены (если были).
  • Код успешно влит в целевую ветку (обычно develop или main после ревью).

3. Тестирование:

  • Разработчик выполнил ручное тестирование (dev-test) своей функциональности.
  • Автоматические тесты (unit, integration, API, e2e — согласно политике проекта) написаны для нового кода и успешно проходят.
  • Тесты не упали в CI/CD пайплайне.
  • Тестировщик (или другой разработчик) провел независимое тестирование (QA) и поставил статус "Passed" или аналогичный в задаче/истории.

4. Документация:

  • Обновлена техническая документация (Swagger/OpenAPI для API, комментарии в коде, README, схемы БД — если изменения этого требуют).
  • Обновлена пользовательская документация (User Guide, Wiki, раздел "Помощь" — если применимо к истории).

5. Сборка и деплой:

  • Код успешно собран (build) без ошибок в CI/CD.
  • Приложение успешно задеплоено на тестовый/стейджинг-стенд.
  • Функциональность проверена на стейджинг-стенде (финальная проверка перед продакшеном).

6. Подготовка к релизу и процесс:

  • Все связанные с историей технические задачи (Tasks) находятся в статусе "Завершено".
  • Связанные баг-репорты (если возникали в процессе) закрыты.
  • Product Owner или ответственный лицо провел финальное демо (Showcase) или подтвердил, что результат соответствует ожиданиям (Acceptance Criteria).
  • Вся информация по истории (комментарии, тестовые данные, результаты) актуализирована в инструменте управления (Jira, Yandex Tracker и т.д.).

Связь DoR и DoD на примере одной истории

История: "Как зарегистрированный пользователь, я хочу сбросить пароль, чтобы восстановить доступ к аккаунту, если забыл его."

  • DoR (Перед началом работы):
    Название: [AUTH-15] Восстановление пароля
    Описание и шаги: 1) Поле для email, 2) Отправка письма со ссылкой, 3) Страница ввода нового пароля, 4) Валидация токена.
    Нет блокеров: Требования от бизнеса согласованы.
    Приоритет: High.
    Прикреплена к эпику: [EPIC-2] Управление аккаунтом пользователя.
    Созданы и оценены задачи: [AUTH-15-1] Бэкенд: метод отправки email, [AUTH-15-2] Фронтенд: форма восстановления, [AUTH-15-3] Интеграция с почтовым сервисом.
  • DoD (После завершения работы, для перевода в "Завершено"):
    Функциональность: Пользователь получает письмо и может установить новый пароль.
    Код и ревью: Код задач AUTH-15-1, AUTH-15-2, AUTH-15-3 влит в develop после ревью.
    Тестирование: Написаны unit-тесты для методов. QA проверил кейсы: правильный email, несуществующий email, просроченная ссылка.
    Документация: В Swagger добавлено описание нового API-метода /auth/password-reset.
    Сборка и деплой: Сборка прошла, функциональность развернута на staging.
    Процесс: Product Owner на демо нажал кнопку "Забыли пароль?" и получил письмо на тестовый ящик. Все задачи закрыты. История готова к включению в ближайший релиз.

Правила оформления: Task (Задача)

Процесс создания: После завершения анализа истории, аналитик создает и описывает задачи, прикладывая все необходимые артефакты

  • Одна История может породить: 1 BE задачу, 1 FE задачу, 1 QA задачу.

Структура Задачи:

  1. Название: [Роль] Суть действия.
  • Пример: [BE] Создать API метод POST /orders
  • Пример: [FE] Сверстать модальное окно корзины
  1. Описание: Технические детали, описанs DoR и DoD, приложены артефакты.
  2. Связь: Поле Linked Issues -> is implemented by (или просто relates to) -> Ссылка на родительскую Историю.
  • Зачем: Чтобы когда Аналитик открыл свою Историю, он видел статус всех технических задач внутри неё.
  1. Оценка (Estimation): В SP .

DoR (Definition of Ready) для Задачи Задачу можно брать в работу, когда:

  • Задача чётко описана и связана с историей
  • Технические требования понятны
  • Доступы есть, среды готовы для разработки
  • Оценка трудозатрат проведена
  • Нет блокеров
  • Все необходимые артефакты реализованы

DoD (Definition of Done) для Задачи Задача считается закрытой, когда:

  • Код написан.
  • Код прошел Code Review.
  • Пройдены Unit-тесты.
  • Функционал залит в ветку develop/test.

Жизненный цикл (Workflow)

Чтобы не было путаницы, как движутся задачи:

  1. Backlog: Аналитик пишет Историю. Она лежит в бэклоге.
  2. Оценка: Команда собирается, читает историю/задачу. Задаем вопросы. Если все понятно переходим к оценке.
  3. To Do: Таски оценены и готовы к взятию в спринт.
  4. In Progress: Исполнитель переводит свою задачу в работу.
  5. Review/QA: Исполнитель закончил задачу/историю-> переводит на Ревью/Тест.Нюанс: Если это история, то после ее завершения, аналитик должен выполнить все требования описанные в "Правила оформления: Task (Задача)"
  6. Done

Нейминг и Теги (Гигиена)

Чтобы можно было быстро найти задачу и понять какому профилю она адресована, используем префиксы в названии Задач и Историй:

  • [BE] — Backend
  • [FE] — Frontend
  • [QA] — Тестирование/Автотесты
  • [DevOps] — DevOps/Инфраструктура
  • [SA] — Аналитика
  • [UI] —  Дизайнер

Пример списка задач внутри одной Истории "Оплата картой":

  1. (История) Реализовать сценарий оплаты банковской картой
  • link -> (Task) [BE] Интеграция с API Stripe
  • link -> (Task) [FE] Форма ввода данных карты и валидация
  • link -> (Task) [QA] Написание тест-кейсов на оплату

Страховка на собеседовании

Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT

Подпишись на https://t.me/IT_Interview_Partner_Bot

Подпишись на https://t.me/LyakhovEugene