Uno sviluppatore dovrebbe chiudere un ticket nello strumento di tracciamento dei bug?

Come tutti gli altri hanno menzionato, dipende dalle regole della compagnia o della casa del team

ma secondo il post di Joel: Monitoraggio dei bachi indolore

I bug dovrebbero essere chiusi dall'emittente del bug per assicurarsi che il bug sia effettivamente corretto. Quindi nel tuo caso, uno sviluppatore dovrebbe chiudere il ticket? Sì, se lo sviluppatore è colui che ha sollevato il ticket del bug.

In azienda, lavoro solo alle pm, posso chiudere un biglietto. Tuttavia, lo sviluppatore può impostarlo su risolto.

Loro fanno in modo che ogni correzione ottenga un assegno dal pm.

Ma dipende dalla compagnia.

Dipende completamente dalla politica applicata nel tuo team.

E questa politica potrebbe evolversi con lo stato di avanzamento del progetto.

In una squadra agile, questo può essere discusso all'inizio di ogni sprint.

La procedura esatta dipenderà dalla struttura del tuo team, dalla natura dello sviluppo che stai facendo (app su misura per i clienti, applicazione web utilizzata dal pubblico in generale, strumenti interni, ecc.) e dal punto nel ciclo di sviluppo ( pre-lancio, manutenzione del sistema di produzione).

Tuttavia, come principio generale, direi che la persona che dovrebbe effettivamente chiudere un ticket di bug dovrebbe essere la persona (o il membro del team) che ha aperto .

Quindi, se questo ticket proviene dal QA, lo sviluppatore dovrebbe contrassegnarlo come risolto e assegnarlo di nuovo al QA, ma dovrebbe essere una persona che controlla effettivamente la correzione e la chiude.

Nella fase di pre-lancio, potrebbe essere il PM che ha aperto il ticket e chi dovrebbe chiuderlo.

E ovviamente potrebbe essere uno sviluppatore. Quando trovo un bug mentre lavoro su qualcos'altro, creo un bug nel nostro sistema di tracciamento, e spesso sono io che lo risolvo, nel qual caso lo chiuderò io stesso. Tuttavia, a seconda delle dimensioni e della modalità di sviluppo del team, potresti persino assegnare casi come questo al controllo qualità, in modo che possano verificare il bug originale, verificare la correzione e chiudere il ticket.

Dipende dai processi all'interno del tuo team.

Chiuderei un bug solo se avessi eseguito il test di accettazione e verificato che il bug fosse stato effettivamente corretto. Anche in questo caso, a seconda della gravità del bug, probabilmente lo supererei con il lead di garanzia della qualità.

Normalmente non riesco a coinvolgere i master SCRUM nella risoluzione dei bug / test in quanto non è il loro lavoro.

Si è opposto a diverse risposte qui: nel caso in cui un utente finale abbia alzato il ticket, dovrebbe non essere ritenuto responsabile della sua chiusura.

Quando si verifica un problema, la maggior parte degli utenti ha interesse a far sì che uno sviluppatore risolva un problema. Ecco perché sono motivati ad aumentare i biglietti in primo luogo. Tuttavia, non hanno assolutamente alcun interesse a chiudere il biglietto, perché significa solo lavoro extra per loro, senza alcun vantaggio sostanziale (al contrario, chiudendo il ticket, si assumono alcune responsabilità indesiderate per segnalare che il problema è stato risolto ora, il che sarebbe significa che devono testare accuratamente il problema).

Quindi chi è responsabile in un'organizzazione di parlare con gli utenti e gestire i loro problemi, dovrebbe essere anche quello che chiude i ticket degli utenti. Tale procedura potrebbe includere l'utente "hey, abbiamo risolto il problema. Potresti fornirci una risposta entro la prossima settimana?", E quando l'utente non risponde più, il ticket viene chiuso.

Ovviamente questo è diverso quando il ticket proviene direttamente dal tester: quando a un tester viene indicato "il problema è risolto", è in genere una sua responsabilità assicurarsi che sia davvero corretto, e quindi dovrebbe essere lui a chiudere il biglietto.