Non assegnare bug a un utente specifico

The idea is that the team will create a Task work item which will be assigned to an individual and the Task will link to the Bug.

Quindi ci sarà un individuo assegnato al bug e quindi l'unica domanda è se quell'informazione è inserita nel sistema di tracciamento dei bug o meno.

Sei nella situazione in cui hai diversi sistemi che gestiscono le cose correlate e ti chiedi dove mettere le cose che potrebbero essere impostate in diversi. Avere informazioni ridondanti è male (ha la tendenza a desincronizzarsi, specialmente se il collegamento è manuale), ma non avere le informazioni necessarie dove è necessario è spesso peggio.

La domanda riguarda ora gli scopi di un sistema di tracciamento dei bug. Per il team, è un modo per gestire i bug. Ma spesso è anche un modo per comunicare con il richiedente e se lo si sta usando in questo modo, non riempire i campi nel sistema di tracciamento dei bug (lascia che sia assegnatario, pianificazione delle informazioni, suggerimenti sul lavoro o altro) interromperà la comunicazione e lascerà l'impressione che il bug sia ignorato, specialmente se l'informazione è ora disponibile solo in un sistema che non è accessibile dal richiedente. E se il sistema di bug viene utilizzato per tracciare chi ha il diritto di accedere ai dati dei clienti sotto NDA relativi al bug, dovrai riempirlo.

TLDR: ciò dipenderà da cosa stai usando il tuo sistema di tracciamento dei bug, nei flussi che conosco, non sarebbe saggio.

Se ci sono più membri del team che sono in grado di lavorare in ciascuna area del software, un vantaggio di non assegnare problemi ai singoli sviluppatori è che non devi pensare esplicitamente alla possibilità che alcuni sviluppatori vengano sovraccaricati con problemi, perché sono la scelta naturale per la maggior parte di loro. Invece, il carico di lavoro tende a essere distribuito in modo più uniforme su tutta la squadra, perché ognuno raccoglie ciò che pensa di poter gestire.

Per mantenere gli strumenti di reporting più utili, ti consiglio di non creare elementi di lavoro Task separati. Invece, quando uno sviluppatore inizia a lavorare su un Bug, deve assegnare l'Bug a se stesso per chiarire che sta lavorando su quell'oggetto.

Una volta che un membro del team decide di assumere l'incarico di correggere il bug, ognuno dovrebbe saperlo. Altrimenti, potresti finire con più sviluppatori che risolvono lo stesso problema. Se succede qualcosa, sii fuori dal compito.

La gestione deve acquistare l'idea indipendentemente dal rapporto. Se la squadra A si trova a proprio agio con lo sviluppatore X che non risolve mai bug, va bene purché non cambino direzione e incolpi le scarse prestazioni della squadra su questo fatto.

La filosofia è buona e buona, ma deve esserci un controllo sulla gestione. Questo è importante quando c'è un certo bug che nessuno vuole correggere (codice legacy troppo complicato, o uno di quei bug "a volte".). O richiedere i volontari o assegnarlo.

L'obiettivo è quello di fare le cose. Non puoi usare "siamo agili" come motivo di fallimento.

Cerco di non pensare all'assegnazione di User Story o Bug come assegnazione di responsabilità esclusiva a uno sviluppatore. Prova a pensarlo come se assegnassi a qualcuno il compito di guidare lo sforzo richiesto per risolverlo. Chiunque può essere richiamato come necessario e potrebbe essere potenzialmente assegnato un compito per catturare tale sforzo.

Per le squadre più grandi che utilizzano percorsi di area guidati da sottogruppi, è possibile lasciare un bug o una User Story non assegnati ma collegati a un percorso di area basato sul team.