Управляйте ошибками между Dev, QA и Production

Question

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

Системы, которые мы создаем, ориентированы на внутренние приложения или на веб-приложения, ориентированные на клиента, и мы выпускаем в эти среды по запросу на изменение на основе запроса на изменение, а не через жизненный цикл продукта жизненного цикла разработки.

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

• Код разработчиков и модульные тесты до готовности к интеграционному тестированию
• Разработчики начинают интеграционное тестирование, и все ошибки обнаруживаются в Jira в версии с именем Development.
• Как только все ошибки разработки устранены, мы переходим в QA, где передаем сборку команде тестирования.Создается новая версия «QA», и все найденные в QA ошибки регистрируются в этой версии.
• Как только все ошибки закрыты, проект переходит в режим реального времени, и проект закрывается в Jira.

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

Буду признателен, если вы услышите от кого-то, кто использовал Jira в такой среде, чтобы понять, как правильно использовать Jira.

Answer 1

Вот что я бы порекомендовал после использования JIRA в различных средах с различными размерами команды и типами проектов.

• Используйте проекты JIRA для обозначения больших, но отдельных функциональных областей работы, которые соответствуют подгруппе членов команды в вашей организации, например, новое веб-приложение или внутреннее клиентское приложение.
• Если проект или команда, работающая над ним, достаточно велики, чтобы это оправдать, используйте компоненты JIRA для определения различных функциональных областей. Затем вы можете назначить потенциальных компонентов, которым будут автоматически назначаться новые проблемы для их компонентов, и вы сможете отслеживать, какие функциональные области содержат больше ошибок и, возможно, нуждаются в большем внимании со стороны группы тестирования.
• Для версий вы, безусловно, можете настроить версии для разработки, live и QA, как вы описали, но они более традиционно соответствуют статусу проблемы JIRA. При стандартном рабочем процессе JIRA проблема будет открыта, пока над ней работает разработчик, решена после завершения функции или исправления ошибки, а затем закрыта, если QA проверит функцию или исправление, или снова откроется, если QA выявит проблему.
• Если у вас есть долгоживущие приложения, в которых вы получаете несколько CR, которые определяют новые функции для одного и того же приложения, я бы использовал версии JIRA для определения различных выпусков приложения на основе набора функций и / или расписания.

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