Strategia componente JIRA

Question

Recentemente sono passato a JIRA da un altro sistema di tracciamento dei bug, e in precedenza non stavamo usando il campo "componente". Il progetto era piuttosto piccolo, quindi non sembrava averne bisogno al momento. Dato che il progetto sta diventando un po 'più grande, sto scoprendo che il campo componente può essere utile, ma non sono esattamente sicuro di come suddividere i componenti.

Ad esempio, supponiamo di avere un'applicazione bancaria e sto aggiungendo una funzionalità per trasferire denaro tra conti. Quella funzione potrebbe essere classificata come componente "Account", ma influirebbe anche sull'interfaccia utente, oltre ad avere alcuni problemi di sicurezza associati. Sembra che molti problemi avranno questa preoccupazione trasversale.

Esiste una best practice per determinare come suddividere un progetto in componenti? Cose come "Interfaccia utente" e "Sicurezza" sono troppo ampie?

Non sono sicuro che questa domanda abbia una risposta corretta, quindi forse dovrebbe essere spostata su una wiki della comunità, ma qualsiasi informazione che la gente può fornire sarebbe utile qui.

Answer 1

I componenti sono molto utili se hanno assegnatari predefiniti evidenti per ciascuno (lead di componente). Un altro approccio è aspettare un po 'e usare le etichette. Verifica se esistono etichette comuni che i tuoi utenti desiderano utilizzare e quindi crea componenti in poche settimane per tali etichette.

~ Matt

Answer 2

Un utente che crea un bug può aggiungere più componenti quando segnala il problema. Quindi potevano selezionare Account, trasferimenti e problemi di sicurezza (o prestito, pagamenti e problemi di sicurezza) come tutti i componenti interessati da un particolare bug. Qualsiasi combinazione di componenti può essere combinata in modo che il team di sviluppo sappia esattamente dove si sta verificando questo errore.

Answer 3

Usiamo il campo del componente nella nostra azienda per lo più a raggrupparsi i problemi in modo significativo, in modo che le relazioni a questi componenti possono dare un feedback quale parte del vostro sviluppo applicazione ottiene il maggior numero di problemi, o dove stanno accadendo le maggiori modifiche (con gli errori più riusciti). A volte, i componenti riflettono l'organizzazione di un progetto, quindi l'aspetto dell'assegnatario predefinito è valido (come risposta da @mdoar). Ma anche in questo caso, la panoramica del progetto è l'aspetto più interessante qui.