Требования к отслеживанию в нескольких проектах с помощью JIRA (или других инструментов)

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

Теперь у нас есть сценарий, когда у нас есть три разных проектных предложения, требования которых частично перекрываются (например, требование 1 относится к проектам A и B, требование 2 относится к проектам B и C и т.д.). Я хотел бы иметь возможность вводить одну проблему JIRA для каждого требования, но это не представляется возможным, поскольку вопросы и проекты JIRA имеют отношение "один к одному".

Кто-нибудь нашел способ сделать это в JIRA, или, может быть, с каким-то другим инструментом, который интегрируется с JIRA?

Ответ 1

Пока нет единого правильного ответа, я могу предложить идею. У меня недостаточно информации о вашем рабочем процессе, но вы упомянули, что у вас есть проектные предложения. Поэтому я предполагаю, что проекты A, B и C находятся на ранних стадиях. Сбор требований и т.д., Пока нет ошибок.

Настройте один проект JIRA, скажем, "Ранние требования". Поместите все требования к проектам A, B и C в этот проект JIRA. Чтобы разрешить отношения "многие-ко-многим" между требованиями и реальными проектами, настройте настраиваемое поле типа "несколько флажков" или эквивалент и настройте "проект А", "проект В" и "проект С" в качестве своих значений. Для любого требования вы можете проверить, к какому проекту он относится.

Теперь - и я делаю здесь больше предположений - пусть некоторые предложения продвигаются, а некоторые умирают. Вам понадобится процесс: a) извлечь все требования для реального проекта A во вновь созданный проект JIRA для A - это можно сделать с помощью проблемы поиска и объемного клона; б) очистить все требования, которые не связаны с ними, - поиск и массовое удаление.

Предостережения: если вам нужно обмениваться требованиями с разными клиентами, это будет сложно. Разрешения настраиваются для каждого проекта JIRA и типа выпуска.

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

Ответ 2

Мы используем функцию "дубликатов" или "относится к" из jira.

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

Вы даже можете использовать, зависит от привязки, если это имеет смысл при настройке вашего проекта.

Ответ 3

У нас та же проблема. В случае, если у вас есть проблема (ошибка или новая функция), которая включает в себя несколько продуктов и которые имеют зависимости между ними. (В качестве примера можно сказать, что у нас есть сервер, соединение api и клиентское приложение). Если есть новая идея о расширении клиентского приложения определенным образом, вполне возможно, что также для подключения api и сервера требуется какое-то расширение. Вероятно, они разрабатываются разными командами... Поэтому не обрабатываются в одном и том же спринте/итерации, но как владелец продукта вы хотите отслеживать все эти новые функции как группу.

На самом деле мы создали несколько настраиваемых полей. Первое поле, которое мы ввели, было "Cascading Select", как "Программа" и "Фаза". Это дает владельцам продуктов возможность группировать проблемы в рамках программы и выполнять приблизительное долгосрочное планирование (несколько итераций).

Затем мы добавили другое поле (текстовое поле) для "Epic" (или "Theme" ), которое связывает проблемы, связанные с определенным Epic/Theme. Идея состоит в том, чтобы использовать "Эпики" в рамках "Программы". В случае более крупной "Программы" вы можете разделить ее на разные части, которые затем отражаются в этих "Эпиках". (Это сюжетная линия. Группа историй (которые могут распространяться на несколько продуктов), которые добавляют ценность как дыра в ряд продуктов).

В обоих полях теперь легко отфильтровывать проблемы, которые пересекают несколько продуктов на основе программы (с фазой или без нее) и Epic.

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

Еще одна идея, которую я собираюсь представить, - это поле "Итерация". При входе в сеанс планирования (или сразу после него). Это поле может быть обновлено с именем этого спринта (Jira отлично подходит для редактирования/обновления нескольких выпусков). Затем это облегчает фильтрацию всех проблем для этого спринта.

То, что мне больше всего нравится в использовании Jira, также как инструмент планирования Scrum/Sprint, заключается в том, что у вас нет отдельного инструмента планирования и резервного копирования. Ошибки более заметны. Отсутствие двойного администрирования ошибок в инструменте планирования и/или планировании элементов в инструменте отслеживания ошибок (для правильных чисел cvs/svn/etc commit). Или генерация примечаний к выпуску.

Ответ 4

Вероятно, вам лучше использовать слияние в дополнение к джире в этом случае.

Используйте Jira для того, что лучше всего, и используйте Confluence для всего остального.

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

Ответ 5

Другим подходом является создание настраиваемого поля с множественным выбором с гиперссылками (например, XYZ-123 ') для проблем как параметров.

Ответ 6

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

Решение существует: RMS - плагин JIRA: