Nous avons le même problème.Dans le cas où vous avez un problème (un bug ou une nouvelle fonctionnalité) qui implique plusieurs produits et qui ont des dépendances entre eux. (A titre d'exemple, disons que nous avons un serveur, une connexion API et une application cliente). S'il y a une nouvelle idée sur l'extension de l'application client d'une certaine manière, il est tout à fait possible que la connexion API et le serveur nécessitent une sorte d'extension. Probablement, ils sont développés par différentes équipes ... Donc pas géré dans le même sprint/itération, mais en tant que propriétaire de produit, vous voulez garder une trace de toutes ces nouvelles fonctionnalités en tant que groupe.
En fait, nous avons créé quelques champs personnalisés. Le premier champ que nous avons introduit était un «Sélection en cascade», en tant que «Programme» et «Phase». Cela donne aux propriétaires de produits la possibilité de regrouper les problèmes dans le cadre d'un programme et d'effectuer une planification approximative à long terme (plusieurs itérations).
Ensuite, nous avons ajouté un autre champ (Champ de texte) pour 'Epic' (ou 'Thème') qui regroupe les problèmes liés à un certain Epic/Theme. L'idée est d'utiliser 'Epics' dans un 'Programme'. Dans le cas d'un plus grand «programme», vous pouvez probablement le séparer en différentes parties, qui se reflètent ensuite dans ces «épopées». (Une sorte d'histoire.) Un groupe d'histoires (qui peuvent s'étendre sur plusieurs produits) qui ajoutent de la valeur comme un trou à la série de produits).
Les deux champs facilitent maintenant le filtrage des problèmes, qui traversent plusieurs produits, en fonction du programme (avec ou sans sa phase) et de l'Epic.
En effet, avec la liaison activée, vous pouvez maintenant créer des dépendances entre les différents problèmes, dans les différents produits. Et il est complètement séparé du versionnement par défaut des produits Jira. Ce qui est génial, alors le processus de publication normal reste tel quel.
Une autre idée que je pense introduire est le champ 'Itération'. Quand vous allez dans la session de planification (ou juste après). Ce champ pourrait être mis à jour avec le nom de ce sprint (Jira est génial dans l'édition/mise à jour de plusieurs éditions). Ce qui le rend facile de filtrer tous les problèmes pour ce sprint. Ce que j'aime le plus à propos de l'utilisation de Jira en tant qu'outil de planification Scrum/Sprint, c'est que vous n'avez pas d'outil de planification et de backlog séparé. Les bugs sont plus visibles. Pas de double administration des bogues dans l'outil de planification et/ou de planification des éléments dans l'outil de suivi des bogues (pour les bons numéros de validation cvs/svn/etc). Ou la génération de notes de version.
Merci, c'est une idée intéressante; Je préférerais vraiment avoir les problèmes d'exigences dans les projets auxquels ils se rapportent, mais je vais voir comment votre suggestion fonctionne. –