Рабочий процесс выпуска Jira для реализации кода и управления ошибками - PullRequest
1 голос
/ 24 февраля 2020

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

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

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

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

1 Ответ

2 голосов
/ 25 февраля 2020

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

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

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

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

...