# Обработать и выполнить тикет > [HTML Version](ticket-life-cycle.html) Работа с поступившими в отдел разработки тикетами осуществляется в приложении **Тикеты**. Этапы жизненного цикла соответствуют статусам тикета. Чтобы отслеживать перемещение тикета, настройте отображение данных на странице в виде [канбан-доски](/ru/help/platform/360009923311.html). При планировании релиза владелец продукта анализирует тикеты и указывает необходимые данные: разработчика, номер релиза, спринт и т. д. Затем задачи передаются на выполнение [команде разработки](release-settings.md#dev-team). По мере подготовки текущего релиза могут поступать новые тикеты. После знакомства с ними владелец продукта может включить их в текущий релиз. Таким образом запланированный в релиз список нововведений может отличаться от фактически выполненных задач. ```` Начало внимание ```` В статье приведён рекомендуемый порядок работы с тикетами. Вы можете изменить его под бизнес-процессы вашей компании. ```` Конец внимание ## ```` Анализ нового тикета После [создания](add-ticket.md) тикету присваивается статус **Новый**. Владельцу продукта указанной в тикете [зоны ответственности](release-settings.md#responsibility-area) в [#ленту](/ru/help/platform/360014162972.html) приходит уведомление о поступлении нового тикета, с которым нужно ознакомиться. Владелец продукта анализирует тему тикета и определяет важность запрашиваемого нововведения с учётом загруженности команды разработки. После первичного ознакомления владелец продукта может выполнить следующие действия с тикетом в его карточке: - создать подзадачи в виде дочерних тикетов, например, для коллег из других отделов, если требуется привлечь их для реализации нововведения; - отслеживать выполнение подзадач на диаграмме Ганта и таким образом планировать сроки и объём работ по тикету; - привязать к тикету [заявки](applications.md), [проблемы](problems.md) и [запросы на изменение](request-for-change.md), на обработку которых влияет разрабатываемая функциональность; - отредактировать описание тикета, если у владельца продукта достаточно информации о задаче; - вернуть тикет на [уточнение автору](#add-info-by-creator), если после ознакомления с содержанием остались вопросы; - отложить тикет в [бэклог](#backlog), чтобы вернуться к более детальному анализу тикета позже или запланировать его обработку в следующем релизе. Оставьте краткий комментарий, укажите уровень приоритета тикета над другими обращениями в бэклоге и обозначьте планируемый релиз; - [отправить на оценку](#classificate-worktime) разработчику для анализа времени, которое требуется для выполнения тикета. Укажите команду, разработчика и планируемый спринт; - установить приоритет тикета над другими. Это может быть, например, число от 0 до 100, где 0 означает некритичное изменение, а 100 — выпуск результата тикета требуется в ближайшем релизе; - назначить выполнение тикета другой команде разработки. Здесь же можно изменить разработчика и заранее указать тестировщика, которые будут работать над тикетом, а также сменить зону ответственности; - [отменить обработку тикета](#cancel-ticket). ## Доработка запроса автором Если содержание тикета не позволяет владельцу продукта определить важность нововведения для пользователей, тикет следует отправить на доработку автору. Для этого в карточке тикета нажмите кнопку **На уточнение автором** и оставьте комментарий с вопросами или пожеланием к дополнению. Автор тикета должен отредактировать описание в карточке тикета, затем нажать кнопку **Описание дополнено**. Тикет по умолчанию возвращается в статус **Новый**. Владелец продукта получит уведомление об изменении тикета и сможет направить его на следующий этап: на оценку или в [бэклог](#backlog). ## Оценка затрат и проработка технической реализации Прежде чем отправить тикет в разработку или отложить в [бэклог](#backlog) владелец продукта может запросить дополнительную информацию у будущего разработчика нововведения. Для этого в карточке тикета нажмите кнопку **На оценку**, укажите [команду](release-settings.md#dev-team) и разработчика. Разработчик анализирует содержание тикета и предлагает техническую реализацию, а также определяет количество часов, необходимых на выполнение задач. Оценённый тикет по умолчанию перемещается в бэклог, чтобы владелец продукта ознакомился с предложением разработчика и назначил тикету подходящий [релиз](release.md) и [спринт](release-start.md#sprint). ## Бэклог В бэклоге хранятся все тикеты, которые по какой-либо причине не могут быть отправлены в [разработку](#development). Например, владелец продукта хочет внимательнее изучить содержание тикета, или запрошенное нововведение на данный момент некритично для пользователей. С тикетами в этом статусе можно выполнять такие же действия, как в статусе [Новый](#new-ticket). Кроме того, можно настроить сортировку тикетов, указав каждому уровень приоритета, и рассматривать более важные обращения в первую очередь. Когда владелец продукта решит, что тикет может быть выполнен в ближайший релиз, он нажимает кнопку **В спринт** в карточке тикета и указывает: - команду разработки, - ответственного разработчика, - уровень приоритета, - номер спринта и релиза. Тикет будет запланирован в [текущий спринт](release-start.md#actual-sprint) и получит статус **Готов к работе**. Команда разработки сможет приступить к выполнению тикета. Владельцы продуктов могут автоматически определять тикеты в текущий спринт. Для этого нужно перейти в приложение **Спринты** и нажать кнопку **Назначить спринт для задач без спринта**. Нераспределённые тикеты автоматически попадут в текущий спринт. Обратите внимание, используйте опцию только в том случае, если вы уверены, что приоритет тикетов без спринта позволяет им быть обработанными в ближайшее время. Действие опции не распространяется на тикеты в статусе **Новый**, **Доработка автором** и **Бэклог**. Вернуть тикет в бэклог можно на любом этапе, чтобы пересмотреть принятое техническое решение. Выход тикета в ближайшем релизе автоматически будет отменён. ## Разработка На этом этапе происходит выполнение основных задач тикета командой разработки. После того как владелец продукта проанализировал тикет, учёл оценку разработчика, он назначает тикету спринт и релиз, нажав в карточке тикета кнопку **В спринт**. Тикет переходит в статус **Готов к работе**. Команда разработки выбирает в работу тикеты в этом статусе по указанному владельцем продукта приоритету, используя [поиск по параметрам](/ru/help/platform/360009669952.html). Владелец продукта обязан следить за тем, чтобы команда успела взять тикет в работу до окончания назначенного спринта. Если этого не произошло, нужно указать новый спринт, отредактировав карточку тикета, или вернуть его в [бэклог](#backlog). Владелец продукта или лид могут отправить тикет в работу определённому члену команды, нажав в карточке тикета кнопку **Назначить**, и расписать персональные задачи. После того как разработка будет завершена, тикет можно: - отправить на проверку — специально назначенный сотрудник проанализирует работу новой функциональности и правильность выбранного технического решения; - передать на тестирование (QA) — тикет будет направлен в отдел тестирования для проверки работоспособности нововведения. Для этого разработчик должен составить и описать сценарий тестирования, чтобы тестировщик учёл все необходимые нюансы функциональности. ## Тестирование (QA) Тестировщик выполняет проверку нововведений по заданному разработчиком сценарию тестирования. После этого сотрудник описывает работу и полученный результат. QA завершается, даже если в процессе проверки были найдены ошибки. В этом случае владелец продукта или лид команды возвращают тикет из статуса **QA выполнен** в [разработку](#development). Можно также вернуть тикет в разработку до начала тестирования, если в его содержании недостаточно данных, или новая функциональность фактически ещё не готова к проверке. Если нововведение было успешно протестировано, владелец продукта отмечает тикет сделанным, нажав в его карточке соответствующую кнопку. Указывается фактический релиз нововведения и описывается результат работы. ## Выполнение тикета Когда запрошенное нововведение успешно реализовано командой разработки, тикету присваивается статус **Сделан**. Выполненный тикет автоматически будет выпущен в рамках назначенного ему фактического релиза. Тикеты, отправленные в определённый релиз, отображаются также в карточке релиза на вкладке **Тикеты**. ## Вернуть отменённый тикет в работу Вы можете вернуться к тикету, который был отменён, и продолжить его выполнение. Для этого воспользуйтесь [поиском по параметрам](/ru/help/platform/360009669952.html) и заполните поле **Статус**. Отменённый тикет можно переоткрыть или направить на любой этап работы.