Segnalazione di difetti in Agile

Penso che ci sia un problema fondamentale con la definizione di "fatto" nel tuo esempio.

Se un "difetto" è identificato in uno sprint, direi che non esiste alcun difetto. L'oggetto non è semplicemente "fatto" e dovrebbe essere rielaborato fino a quando non lo è. Vorrei modificare la definizione di fatto per includere il requisito che gli elementi non abbiano difetti noti (se non è già incluso).

Per i difetti identificati dopo lo sprint, è sufficiente creare un nuovo oggetto per correggere il difetto.

Per quanto riguarda il rapporto che stai creando, ho difficoltà a comprenderne il valore.

Penso che il posto per uno sviluppatore per capire che il loro lavoro può essere inferiore alla pari è durante lo sprint o alla retrospettiva, dal loro gruppo di pari. Non da un rapporto.

Inoltre, se la tua definizione di fatto è chiaramente enunciata, non è necessario che gli altri team sappiano che gli articoli hanno difetti e quindi non dovrebbero essere considerati "fatti". Gli articoli sono "fatti" o "non fatti" alla fine di uno sprint, indipendentemente dal fatto che i difetti si presentino più tardi.

Qualcosa sembra sbagliato: Sembra che il tester (tu) non faccia parte del team ma sia una sorta di assistente esterno, che riporta errori.

Se pensi che registrare errori tutti aiuti la qualità, perché fermarti ai bug che trovi come tester? Perché nessun bug registrato che il compilatore trova? Perché non registrare una parentesi ineguagliata o variabili non inizializzate, di cui parla il compilatore?

Tre regole pratiche e un flusso di lavoro:

1. All'interno di uno Sprint, non perdi tempo a registrare i bug: li risolvi.

2. Non consegnate il lavoro con errori noti perché non è "fatto". Non hai bisogno di archiviare bug su workitem N, perché il programmatore non è 'fatto' con il workitem N. È solo 'fatto' quando tutti sono d'accordo che è fatto, è conforme alla definizione di fatto, e non ci sono errori in esso (non che ho appena detto la stessa cosa in 3 modi diversi). Solo allora il programmatore passa al prossimo elemento di lavoro. Quindi non c'è bisogno di registrare l'errore.

3. Quando si ha a che fare con un errore, specialmente da altri Sprint o Teams, segui questo flusso di lavoro:

   • il programmatore può aggiustarlo in < 4 ore? Se SÌ, aggiustalo. Fatto
   • In caso contrario, la squadra può adattarla allo Sprint attuale? Se SÌ, quindi mettilo sullo Scrumboard e aggiustalo. Fatto.
   • In caso contrario, portalo con il proprietario del prodotto. L'errore non può essere corretto nello Sprint corrente. È possibile inserire l'errore come articolo del Product Backlog sul Product Backlog da correggere in seguito? Se SÌ, inseriscilo nel PB.
   • Opzione ultima e meno desiderabile: se non può essere riparata insieme allo Sprint corrente e non può essere posticipata, il PO può interrompere lo Sprint corrente. Il team geme e quindi corregge l'errore.

Nel rapporto delle statistiche sul numero di difetti devi distinguere tra diversi tipi di difetti:

• Difetti su storie che sono stati consegnati in precedenti sprint. A meno che i team non lavorino costantemente su parti separate dell'applicazione (vale a dire un front-end e una squadra di back-end), non c'è davvero un punto nel separare questi difetti per squadra.
• Difetti sulle storie nello sprint corrente che sono stati trovati e completamente risolti.
• Difetti sulle storie nello sprint corrente che sono aperti alla fine dello sprint. Non importa qui se i problemi sono stati chiusi e riaperti durante lo sprint. È pertinente solo lo stato al momento della demo.

Le prime due categorie possono quindi essere ulteriormente suddivise in base alla risoluzione del problema (fisse, duplicate, rifiutate).

In questo modo, c'è una chiara distinzione tra il numero di problemi relativi al lavoro corrente e il numero di problemi relativi al lavoro passato.

Quando si ha a che fare con le statistiche sui difetti, ci sono due cose da fare attenzione:

1. Difetti multipli in un rapporto.
2. Difetti di morphing: dopo aver corretto il difetto originale, lo stesso biglietto viene riutilizzato per segnalare un altro problema.

Entrambi sono un fastidio quando si risolvono / verificano problemi, ma sono un vero e proprio incubo per le statistiche. In entrambi i casi, dovrebbe essere segnalato come più, distinti, problemi.

Per sapere se le storie sono fatte se ci sono dei difetti aperti su di loro: Generalmente, una storia dovrebbe non essere considerata come fatta se ha difetti aperti associati ad essa, ma dovresti anche permettere al Prodotto Il proprietario accetta comunque una storia se, a giudizio del PO, i difetti non sono abbastanza importanti da bloccare la storia.
Ci possono essere motivi commerciali per accettare problemi minori con un prodotto, ma tale chiamata può essere effettuata solo dal rappresentante del cliente (cioè il proprietario del prodotto).

1. I reported few defects in Sprint-2 for the functionality developed by Team-B in previous sprint. Do I have to consider this as observation or defect and report to Team-A?

Questo dipende dal fatto che una storia utente in Sprint-2 sia passata o meno. Se si tratta di una storia utente fallita in sprint-2, segnala l'errore e menzioni che pensi che la causa sia nel codice di Team-B e lasci che gli sviluppatori lo capiscano e faccia passare questo test. Oppure, se il test della storia utente di Sprint-2 è stato superato ma hai notato che non è stato eseguito un altro tentativo, crea un nuovo elemento di segnalazione bug in modo che possa essere corretto nel prossimo sprint.

1. I reported 5 defects of Sprint-2 for the functionality developed by team-A. All the defects are fixed and closed by me in the same sprint. Before the end of sprint I observed 2 defects got reopened for some reason. Now the defect count should be 5 or 7(5+2) should be considered for this sprint?

Questo è puramente per il tuo team / azienda sulle loro regole per il conteggio dei difetti e come vengono interpretati. Se qualcuno vuole un conteggio di difetti bassi per ingraziarsi il favore o evitare la punizione, alcuni potrebbero voler avere regole che incoraggiano "in caso di dubbio, inserire un fallimento) o se qualcuno sta giocando il sistema e vuole avere un bell'aspetto perché hanno trovato / riparato un sacco di fallimenti, le regole possono essere in tal modo "in caso di dubbio, non creare conteggi di insuccesso aggiuntivi". Se le conseguenze troppo gravi o le ricompense dipendono da questi errori, indipendentemente dalla direzione, le persone tendono a distorcere i valori e gioca il sistema.

Le linee di codice, ad esempio, possono essere una misura migliore della dimensione / complessità di un'app se calcolate quando un intero progetto è completato e confrontato a se stesso (più controllo dello stile di codifica, delle lingue e dei framework usati, ecc.) durante le diverse versioni / rilascia senza la preoccupazione di coloro che scrivono il codice che possono tentare di influenzare i numeri in un modo o nell'altro.