Abbiamo lo stesso problema.Nel caso in cui si presenti un problema (un bug o una nuova funzionalità) che coinvolge più prodotti e che hanno dipendenze tra di loro. (Ad esempio, diciamo che abbiamo un server, una connessione API e un'applicazione client). Se c'è una nuova idea sull'estensione dell'applicazione client in un certo modo, è abbastanza probabile che anche la connessione API e server necessiti di qualche tipo di estensione. Probabilmente sono sviluppati da team diversi ... Quindi non vengono gestiti nello stesso sprint/iterazione, ma come proprietario del prodotto si desidera tenere traccia di tutte queste nuove funzionalità come gruppo.
Quello che abbiamo fatto è stato in realtà creato alcuni campi personalizzati. Il primo campo che abbiamo introdotto è stato un "Selezione a cascata", come "Programma" e "Fase". Ciò offre ai proprietari del prodotto la possibilità di raggruppare i problemi nell'ambito di un programma e di eseguire una pianificazione approssimativa a lungo termine (diverse iterazioni).
Quindi abbiamo aggiunto un altro campo (campo di testo) per "Epic" (o "Tema") che raggruppa i problemi relativi a una certa Epica/Tema. L'idea è di usare "Epics" all'interno di un "Programma". Nel caso di un "Programma" più grande, puoi probabilmente separarlo in parti diverse, che poi si riflettono in queste "Epiche". (Una sorta di trama. Un gruppo di storie (che possono diffondersi su più prodotti) che aggiungono valore come un buco alla serie di prodotti).
Entrambi i campi consentono ora di filtrare facilmente i problemi, che attraversano più prodotti, in base al Programma (con o senza la sua fase) e all'epica.
Infatti, con il collegamento abilitato, è ora possibile creare anche dipendenze tra i diversi problemi, nei diversi prodotti. Ed è completamente separato dalla versione di prodotto predefinita di Jira. Il che è fantastico, quindi il normale processo di rilascio rimane così com'è.
Un'altra idea che sto pensando di introdurre è il campo "Iterazione". Quando si entra nella sessione di pianificazione (o subito dopo). Questo campo potrebbe essere aggiornato con il nome di quello sprint (Jira è eccezionale nell'elaborazione/aggiornamento di più problemi). Che poi rende facile filtrare tutti i problemi per lo sprint.
Ciò che mi piace di più dell'uso di Jira come strumento di tracciamento di pianificazione/sprint di Scrum, è che non si dispone di uno strumento di pianificazione e backlog separato. Gli insetti sono più visibili. Nessuna doppia amministrazione di bug nello strumento di pianificazione e/o pianificazione di elementi nello strumento di tracciamento dei bug (per i numeri di commit cvs/svn/etc corretti). O la generazione di note di rilascio.
Grazie, è un'idea interessante; Preferirei davvero avere i problemi dei requisiti nei progetti a cui si riferiscono, ma vedrò come funziona il tuo suggerimento. –