Как разделить задачи в Jira и определить приоритеты выполнения

Что проверяют

Умеете ли вы превращать расплывчатую задачу в работу, которую можно оценить и сдавать по частям, и понимаете ли, кто в команде решает, что важнее. Следом обычно просят пример: как вы разбили конкретную фичу и что делали, когда приоритеты поменялись посреди спринта.

Как отвечать

Покажите иерархию и принцип деления на примере из своей работы на Python:

• эпик: крупная цель, например «экспорт отчётов для клиентов»;
• истории: вертикальные срезы, каждый даёт работающий результат. Сначала экспорт одного отчёта в CSV, потом фильтры, потом отправка на почту;
• подзадачи: технические шаги внутри истории, то есть миграция Alembic, эндпоинт в FastAPI или Django, фоновая задача в Celery, тесты на pytest;
• критерии приёмки: у каждой истории, иначе непонятно, когда её закрывать;
• связи: зависимости через ссылку «blocks», чтобы на доске было видно, что стоит из-за другой задачи.

Ориентир размера: задача помещается в один-два дня. Если оценка больше, внутри скорее всего спрятано несколько задач.

Про приоритеты скажите, что поле Priority в Jira (от Highest до Lowest) лишь метка. Реальный приоритет задаёт порядок бэклога, и выставляет его владелец продукта. Разработчик даёт ему вход: оценку трудозатрат, риски, технический долг, который тормозит остальные задачи. Для обсуждения помогают MoSCoW, RICE или простая матрица «ценность против трудозатрат».

Пример нужен ваш, с реальной фичей и тем, чем всё закончилось. Если вы работали без Jira или задачи раздавал тимлид, так и скажите и покажите, как разбили бы задачу сами.

Где спотыкаются

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

Ставят всем задачам High. Когда важно всё, приоритета нет, и порядок решает тот, кто громче.

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