Separazione dei problemi su più prodotti (JIRA)

Jira tende a essere centrata sul progetto, non sul prodotto. Quindi, come hai capito, i prodotti non hanno un modello molto ricco (in Jira). È un "componente" di campo standard che potrebbe esprimere qualcosa di simile a quello che stai cercando. Anche l'approccio di mappatura di un "progetto" Jira su ciascun prodotto funziona, ma rende più difficile avere una visione consolidata dei tuoi prodotti.

Alla fine, dipende molto da come lavori.

Personalmente andrei in questo modo (lo stiamo utilizzando attualmente nella mia agenzia digitale):

Avere un distinto progetto JIRA per ogni progetto che stai gestendo. Ciò semplifica il monitoraggio dei problemi e di ciò che viene fatto su ogni singolo worke che stai facendo.

Quindi un altro progetto JIRA impostato come Kanban board per monitorare lo stato generale dei progetti .

La nostra ad esempio ha le seguenti colonne:

• Ghiacciaia
• Stima
• In attesa dell'approvazione
• Requisiti funzionali
• contabile
• design
• sviluppo
• Rifiutato
• Stampa
• Fine

Non necessariamente ogni progetto passa attraverso ognuno di essi nell'ordine indicato. Ciò consente anche alle persone non coinvolte direttamente in ogni singolo progetto di ottenere una rapida visione di ciò che sta accadendo.

Dovresti quindi avere un campo personalizzato per i progetti nella colonna Sviluppo che tiene traccia dello sprint corrente che è in fase di sviluppo in questo momento.

Non so se ci sono alcune pratiche migliori, ma posso dirti dalla mia esperienza che questo funziona abbastanza bene per noi!

Le migliori pratiche per me potrebbero non essere le migliori pratiche per te, ma posso mettere in relazione la mia esperienza, che è quella di creare diversi prodotti commerciali in un singolo sistema Jira poiché progetti separati sono stati davvero indolori per me.

Questi prodotti sono separati e non vanno tutti a tutti i clienti, ma sono anche abbastanza integrati e correlati e condividono le dipendenze.

Il prefisso del progetto di Jira è diventato molto utile per scrivere e leggere i commenti di commit git e per trovare rapidamente e filtrare i problemi.

Separare i progetti rende semplice se i cicli di rilascio e i numeri di versione differiscono.

Generalmente sfrutta le capacità di Jira, nella mia esperienza. Tuttavia, possiamo ancora vedere i problemi di tutti i prodotti / sottoprodotti nel dashboard e nei risultati di ricerca.

Per il mio lavoro è stato un gioco da ragazzi, lavori separati e l'utilizzo di un attributo personalizzato sarebbe stato un problema per noi.

Se avessi nuovi sottoprodotti ogni poche settimane, prenderei in considerazione la possibilità di cambiare la mia storia, solo a causa della configurazione e della manutenzione dell'amministratore e mi chiedevo se la proliferazione dei progetti di prodotto diventasse tanto confusa quanto i codici contabili e anche l'interfaccia utente ingombra. Quindi se significa passare rapidamente da 1 a 20 progetti, mi fermerò a pensarci su. 5 o 6, nessun problema.

Se i prodotti / sottoprodotti vengono sempre rilasciati e messi in versione insieme, averli nello stesso progetto non farebbe male così tanto, e ad un certo punto si sta davvero parlando di componenti o moduli. Preferisco fare quelli con i tag, perché non voglio pagare qualcuno per mantenere i termini aggiornati in un elenco di componenti che si escludono a vicenda. Gli elenchi di componenti tendono ad avere bisogno di un aggiornamento periodico man mano che i team e i prodotti cambiano. I clienti non pagano per quello. I commit Git sono comunque più definitivi dopo che è stato effettuato un cambiamento. Prima che sia fatto, ciò che è importante per me è a quale persona è assegnato.

Dichiarazione di non responsabilità: non sono interessato alle metriche elaborate, ai grafici aggregati di prodotti / sottoprodotti e non ho bisogno di tracciare o fatturare il tempo. Quindi non ho mai guardato per vedere come sono influenzate queste cose.