Рабочий процесс Jira для реализации кода и управления ошибками

Я только начал работать в компании, которая использует тот же рабочий процесс Jira Issue для управления задачами разработки и ошибками. введите здесь описание изображения

Должен признаться, что в течение последних 5 лет я немного работал за рамками QA. Когда я работал надлежащим QA, клиенты, с которыми я работал, использовали ALM для управления дефектами или, по крайней мере, они имели дело с дефектами в отдельном представлении от задач реализации. Итак, я пытался понять, какой подход является лучшим при использовании JIRA и ее рабочего процесса для управления дефектами. Я уже создал (см. изображение ниже) отдельный рабочий процесс для дефектов, но я все еще не понимаю, имеет ли смысл отделить его от рабочего процесса реализации (который в настоящее время в компании также применяется к дефектам). введите здесь описание изображения

Я хотел бы спросить ваше мнение по этому поводу. Что вы думаете и что вы обычно видите, когда дело доходит до использования JIRA в качестве самостоятельного инструмента для управления дефектами и разработки?

Заранее спасибо!


testing jira qa jira-plugin jira-agile
person Vinicius Correia    schedule 24.02.2020    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я видел использование обоих подходов и вижу их преимущества и недостатки.

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

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

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

person Barnaby Golden    schedule 25.02.2020