Использование одного билета задачи JIRA или создания подзадач

Question

Мы используем JIRA для работы с командой разработчиков и командой QA. В настоящее время «Dev Team Leader» создает билет «Задача», назначает его участнику разработки, который работает над этим билетом, а затем сообщает номер билета JIRA команде QA, которые создают отдельный билет QA для его тестирования. И тест прошел или не прошел, они сообщают команде DEV, которые либо исправляют ее, либо меняют статус билета на «В развертывании».

Мой вопрос заключается в следующем:

1. Если они создают единый билет и использовать, чтобы сделать разработку и тестирование? (т. е. сменить билет между командой DEV и командой QA)

2. Если команда DEV создала билет для родительского TASK для разработки, а затем назначила его команде QA, которая создаст подзадачу для тестирования и связать его с Билетом Родительского Развития?

Вопросы:

1. Нам нужно определить, какой член команды работал над разработкой задачи?
2. Какой член команды работал над тестированием?
3. Сколько галстуков потрачено на развитие в целом?
4. Сколько времени потрачено на тестирование в целом?

Каков наилучший способ сделать это?

Answer 1

Вам нужен только один билет или проблема в контексте JIRA. Ваш проект должен иметь рабочий процесс, например, со следующими статусами: To Do ->In development ->In testing -> здесь проблема может идти в двух направлениях, обратно до In development, если QA не выполняется или Done.

Когда Issue перемещаются к следующему шагу, он будет/должен быть отнесен к нужному человеку, то есть в To Do это назначенном для лидера проекта или тот, кто распределяет задачи, In Development это разработчик, In testing по КАМ, и т.д. .

Это самый широко распространенный способ использования JIRA в качестве трекера. Каждый переход будет записан в журнале активности проблем с соответствующими датами времени, назначенными лицами и т. Д. У вас будет доступ ко всей запрошенной вами информации.

Answer 2

Мне кажется, что рабочий процесс нуждается в детальном отслеживании разработки и тестирования, когда один билет (предлагаемая идея) не удовлетворяет.

Я нашел следующий дизайн полезным: 1. Создайте ИДЕНТИФИКАТОР ПОЛЬЗОВАТЕЛЯ, у которого есть набор критериев, которые необходимо выполнить. 2. Sub TASKS могут быть созданы как дети ИСТОРИИ, особенно если им нужно работать разными людьми. 3. После завершения всех задач ИДЕНТИФИКАТОР ПОЛЬЗОВАТЕЛЯ может быть перенесен на ТЕСТИРОВАНИЕ/ИСПЫТАНИЕ (независимо от рабочего процесса). 4. Затем инженер QA/QE может создать TESTS/TEST CASES (children) для пользовательских историй и выполнить их соответственно.Аналогичным образом, дефекты могут быть поданы как ОШИБКИ как дети истории.

В конечном итоге в этом рабочем процессе история должна соответствовать набору критериев и уровня качества (основанных на том, что приемлемо для передачи истории для бизнеса), чтобы считаться «завершенной» или готовой к выпуску.