Как лучше связать официальные спецификации с запросами на усовершенствование JIRA?

Question

Какой лучший способ связать формальные спецификации с запросами на усовершенствование JIRA?

Я хочу отслеживать изменения в спецификациях, используя JIRA.

В идеале я хотел бы сослаться на ссылку функционального идентификатора в билете JIRA (например, MYAPP> ЛОГИКА УТВЕРЖДЕНИЯ> ОСНОВНОЙ ЭКРАН), чтобы руководители программ могли ретроспективно классифицировать дефекты.

Причина этого заключается в том, что в системе отслеживания можно найти / классифицировать сценарии QA и заявки на документацию.

Кажется, есть миллион возможных способов сделать это, например,

• мне написать собственный компонент для выбора функциональных идентификаторов из дерева?
• Должен ли я написать спецификации в слиянии или другую CMS с возможностью TrackBack?
• мне включить ссылку на URL документации?
• я должен использовать какое-нибудь другое стороннее приложение плагина?
• мне использовать какое-нибудь приложение Atlassian, о котором я не знаю?
• Я использую неправильный инструмент / процесс отслеживания для измерения роста спецификации?

Какой самый лучший способ, по вашему опыту?

---

Спасибо за ответ!

Есть еще один вариант, который я рассматриваю, который заключается в том, чтобы реализовать функциональное требование как фактический билет.

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

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

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

Я не могу быть первым человеком, который захочет это сделать - я не думаю, что вы знаете кого-то, кто пробовал это, о котором вы знаете, или выпустил инструмент, чтобы сделать это проще?

Answer 1

Один из подходов состоит в том, чтобы выполнить полный дизайн как функциональных, так и нефункциональных требований исключительно в JIRA.

Настольное приложение JIRA Client (almworks.com) может упростить и упростить процесс.

Answer 2

1. Если вы можете позволить себе написать спецификации в Confluence, то я думаю, что использование перекрестных ссылок между Jira и Confluence - лучший способ. Есть несколько плагинов, которые реализуют такие ссылки (например, ссылки на приложения).
   • Так как страница Confluence должна быть уникальной в пределах пространства, иерархическое наименование, которое вы показываете выше, будет уместным.
   • Слияние - это хороший инструмент для совместной разработки документов, но для поддержания организованности требуется много дисциплины, организации и усилий.
2. Кроме того, вы можете использовать плагин Labels jira, чтобы помечать проблемы со строками, такими как «myapp-reputationLogic-mainScreen». Это позволяет быстро найти все связанные проблемы, но не переходить к спецификации
3. Хотя ни один из вышеперечисленных подходов не обеспечивает иерархию.
   • Jira + Agile (он же Greenhopper) предоставляет иерархию версий, которая очень полезна для гибкого планирования. Но обычно одна версия (выпуск) работает с функциями из многих требований, поэтому вы, вероятно, не сможете использовать эту иерархию
   • Компоненты Jira не являются иерархическими, и проблемы находятся на двух уровнях (проблема обсуждалась в течение 4 лет ...)