Ha mai senso avere più incarichi per un problema in un tracker di problemi?

StackOverflow https://stackoverflow.com/questions/7340865

Domanda

Sono stato un amministratore JIRA e Bugzilla in lavori passati e ho fatto abbastanza spesso gli utenti la possibilità di avere più di un cessionario per problema.

So che questo è possibile in Jira, ma a mio avviso non ha mai senso; Un problema dovrebbe rappresentare un lavoro e solo una persona può fare un lavoro (almeno nel software, non ho mai usato un tracker di problemi per un team di bob a 2 uomini ;-)) un grande lavoro sarà Ovviamente coinvolge più di una persona, ma penso che in quel caso dovrebbe essere diviso in sottosuccesso per consentire un report di stato accurato.

Qualcuno ha dei casi d'uso in cui è valido avere più incarichi?

È stato utile?

Soluzione

Il campo Assegnatario significa molte cose per molte persone. Un nome migliore potrebbe essere "utente responsabile". Ci sono tre casi che discuto con i miei clienti:

A. Numero di cessionari = 0 JIRA ha un'opzione per consentire problemi non assegnati, ma scoraggio l'uso di ciò perché se un elemento di lavoro non è di proprietà di nessuno, tende ad essere ignorato da tutti.

B. Numero di cessionari = 1 Il caso predefinito

C. Numero di cessionari> 1 Chi è responsabile dell'elemento di lavoro rappresentato dal problema? Il caso migliore che ho visto per questo è che quando un problema può essere gestito da una persona in una squadra, quindi prima di triage il problema viene assegnato a tutti in quella squadra. Penso che un approccio migliore sia quello di creare un utente JIRA con un indirizzo email che invia a tutto il team e assegnarlo a quell'utente. Quindi un membro del team può avere il problema assegnato in particolare.

La modifica del caso di un assegnatario ha la cronologia registrata nella scheda cronologia. Niente è perso in quel caso.

Altri suggerimenti

Avrò spesso una storia / caratteristica che può essere divisa su più sviluppatori. Avranno assegnato individualmente le sottotetti ma avrebbe senso assegnare il genitore a tutti i soggetti coinvolti, a meno che non ci sia uno sviluppatore di lead. In realtà non ero a conoscenza del fatto che avrei potuto fare più incarichi, quindi grazie per il suggerimento!

L'altro caso a cui riesco a pensare è la programmazione delle coppie.

Ho colpito questa domanda mentre cerco soluzioni per farlo. Dal momento che voglio farlo, suppongo che i miei casi d'uso contassero come risposta alla tua domanda: voglio davvero solo un cessionario nel senso di qualcuno che attualmente lavora su un problema, ma voglio monitorare l'intero ciclo di vita di un problema . Per noi, ciò può significare:

  1. Una persona di supporto riceve un rapporto da un cliente, crea un problema
  2. Un problema Wrangler esamina il problema per assicurarsi che sia valido, non duplicato, abbia tutti i dettagli appropriati, ecc.
  3. Uno sviluppatore implementa/risolve il problema
  4. Un tester esegue qualunque test sia appropriato (nel nostro caso, estendendo principalmente il nostro test di test automatizzato per testare inoltre la funzione/correzione)
  5. Una persona operativa lancia la nuova versione in un ambiente di test
  6. Una persona di supporto informa il cliente, che esegue i propri test con la nuova versione nell'ambiente di prova
  7. Una persona operativa implementa la nuova versione alla produzione

Non tutti i problemi passano necessariamente attraverso tutti i passaggi. Alcuni problemi hanno più passaggi (ad esempio una revisione del codice tra il passaggio 3 e 4). Molti problemi si sposteranno anche tra i passaggi (lo sviluppatore ha bisogno di maggiori informazioni, passiamo dal passaggio 3 a 1 o 2; il tester individua un problema, passiamo da 4 a 3).

In ogni fase, solo una persona è effettivamente responsabile di tutto ciò che deve essere fatto. Tuttavia, ci sono un sacco di persone associate al problema. I sistemi di monitoraggio che abbiamo usato sono felici di offrire facili modifiche ai precedenti proprietari del problema (mostrati come elenco), ma idealmente vorrei fare un ulteriore passo avanti, con il proprietario che ritorna automaticamente al proprietario precedente corretto a seconda del stato del problema. Al passaggio 6, la persona di supporto originale del passaggio 1 dovrebbe idealmente contattare il cliente. Al passaggio 7, la persona OPS del passaggio 5 sarebbe idealmente il cessionario.

In altre parole, anche se non voglio più incarichi per un determinato passo, voglio che ci sia un "cessionario di supporto", un "cessionario sviluppatore", un "cessionario di prova", ecc.

Possiamo farlo con sottotitoli e possiamo farlo selezionando manualmente i proprietari precedenti quando cambiano gli stati, ma nessuno dei due è l'ideale e penso che la situazione sopra sia quella in cui più incarichi avrebbero senso.

Nella mia azienda, abbiamo un flusso di lavoro simile a Nikhil. Lavoriamo in un modello Scrum, con sviluppatori, tester e uno scrittore tecnico in ogni squadra.

Il flusso di lavoro di un'attività di sviluppo è

Sviluppo -> Revisione degli sviluppatori -> Test QA -> PO Accettazione -> Fatto

Il flusso di lavoro di un'attività QA è

QA scrive un caso di test / test automatizzato -> recensione QA -> Fatto

Avevamo uno strumento che JIRA ha sostituito che ci ha permesso di assegnare più persone a un'attività, che abbiamo trovato molto utile per il nostro flusso di lavoro. In un'attività di QA, potrei facilmente vedere se l'altro tester del mio team avesse già fatto il lavoro e avevo bisogno di fare il passo successivo.

Senza questo, trovo difficile identificare rapidamente i compiti scritti dall'altro tester nel mio team di Scrum che sono pronti a rivedere (rispetto a quelli che ho scritto che devono rivedere).

Così tante persone hanno chiesto la possibilità di avere più incarichi da almeno 2007. Hanno casi d'uso validi e variabili. Sono rimasto deluso dal fatto che il team di sviluppo JIRA abbia detto unilateralmente che non lo implementerà e avrebbe chiesto loro di riconsiderare.

https://jira.atlassian.com/browse/jra-12841

  1. Mentre il gruppo di coppie funziona (programmazione coppia ecc.) Sarebbe bello assegnare entrambe le persone al problema.

  2. Le attività si muovono attraverso diversi passaggi attraverso lo sviluppo (esempio: sviluppo, revisione, test). Persone diverse possono essere responsabili per ogni passaggio. Anche se l'attività potrebbe essere in revisione o test, il revisore avrà materia da correggere lo sviluppatore. Avere ruoli diversi da assegnare aiuterebbe a organizzare il lavoro.

Nel nostro team di solito sviluppiamo 1 o 2 persone insieme. Quindi il codice viene rivisto da circa 2-5 persone in coppia individualmente o in coppia, quindi viene inizialmente testato da 1-2 persone, finalmente testate da tutto il team.

Attualmente il nostro sistema ci consente di assegnare una sola persona in un determinato momento. Ciò limita la nostra capacità di seguire chi sta lavorando a cosa senza guardare attraverso il registro per il problema. I Benifits di Abeing in grado di assegnare più persone sarebbero bene per noi.

Cosa succede se a John viene assegnato un compito e non può finirlo, ed è spostato nella lista di Jane perché John era un fannullone?

Stai bene con la perdita di storia di chi è stato originariamente assegnato e le ore spese / fatturate su di esso?

In uno scenario di e-learning, ha senso avere un problema assegnato a più utenti. Ecco cosa voglio fare: ho uno storyboard che voglio assegnare a 3 persone allo stesso tempo: gli animatori, gli artisti di registrazione e i grafici. Una volta che queste persone finiscono i loro compiti, lo trasmetteranno a un revisore comune, che esaminerà e chiuderà il problema. Graficamente sembrerebbe qualcosa di simile:

                   Storyboard
                 /     |     \
           graphics animator recording
                 \     |     /
                    reviewer
                       |
                     done

I tre ruoli lavorativi dipendono solo da uno storyboard. La raccolta dei tre deve andare a un recensore. Mi sto scherzando il cervello per far funzionare questo su Redmine. Non ho ancora trovato una soluzione.

Ho ricevuto questa risposta da un partner atlassiano https://www.isostech.com/solutions/e poi più tardi da Atlassian

Obiettivo: vuoi impostare chi fa i lavori per ogni passo su un problema

Riepilogo: utilizzare un plug -in per copiare i valori dai campi personalizzati nel campo Assegnatario ogni volta che il problema passa a un nuovo passaggio.

Come: 1. Installa il plug-in sui servizi suite: questo plug-in aggiunge un sacco di nuove funzionalità ai flussi di lavoro.

Utilizzerai il plug-in per copiare il valore di un campo personalizzato nel cessionario:

  1. Crea un campo personalizzato come selettore utente singolo per ogni ruolo, cioè, dev, tester, revisore da assegnare a diversi passaggi del problema

  2. Aggiungi questi campi allo schermo del tipo di problema

  3. Modifica la funzione post-funzione sulla transizione del flusso di lavoro tra ogni passaggio Aggiungi una funzione "Copia valore dall'altro campo" e impostalo per copiare il valore dal campo personalizzato utente appropriato nel campo assegnatario.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top