I progetti Agile utilizzano la segnalazione di difetti abbreviata? [chiuso]

Se incoraggiare le persone a interromperle frequentemente a causa della semplice pigrizia è considerato Agile, quindi devo ammettere che la mia comprensione di Agile è seriamente compromessa.

Una descrizione del problema sufficiente non è una documentazione del prodotto (potenzialmente superfluo), piuttosto è una raccolta distinta di tutti i fatti necessari per efficientemente riprodurre e risolvere il problema.

Se la descrizione in qualsiasi forma è sufficiente, va bene. In caso contrario, chiudilo come " Non riproducibile, riapri se nuove informazioni diventano disponibili " - con una sola eccezione: se senti la necessità di investigare a causa dei potenziali rischi scoperti dal problema, potrebbe prendere in considerazione di mordere il proiettile e il follow-up. Non vuoi (ad es.) Un problema di sicurezza lasciato non risolto solo a causa di una descrizione scadente.

"Agile" non significa che non hai regole e processi - solo che dovresti cercare di cavartela il meno possibile (ma non meno, parafrasare la citazione di Einstein). Il Manifesto Agile esprime questo come "Individui e interazioni su processi e strumenti".

Nel tuo caso ciò significa che dovresti discuterne con i tuoi colleghi. Spiega i vantaggi che vedi nell'avere rapporti sui bug più strutturati e cerca di trovare una soluzione con cui tutti possano lavorare.

Forse alcuni dei tuoi colleghi hanno buone ragioni per non voler richiedere rapporti più strutturati (ad esempio, non spaventare gli utenti che vogliono segnalare bug, o perché hanno scoperto che la struttura non ha mai avuto un senso) - o forse hanno solo mai pensato a questo. Lo scoprirai solo chiedendo: -).

È importante ricordare che Agile non è un insieme di regole rigide, ma piuttosto una mentalità di miglioramento dei processi. Come ha fatto notare Dave Thomas, agile è un aggettivo, non un sostantivo. Per definizione, non puoi fare agilità, puoi solo essere agile.

Quindi, il modo in cui un team agile gestisce le segnalazioni di bug dovrebbe essere basato sul modo più efficace che il team ha scoperto che aiuta a fornire un software funzionante. Questo potrebbe essere diverso per i diversi team a seconda del contesto in cui lavorano. Se il processo che stai utilizzando non funziona per te, cambialo. Se vedi che potrebbe essere migliore, cambialo. (Se non può essere modificato, non sei agile)

La cosa da fare sarebbe scoprire perché è così com'è. Altre risposte qui hanno proposto possibili spiegazioni. Parla con il tuo capo tecnico o con il tuo team e chiedi come sono arrivati al processo corrente. Dai suggerimenti su come migliorare il processo.

I rapporti sugli errori degli utenti sembrano sempre seguire questo modello:

I can't {action here} when I {another action here}

o

When I {action here} it doesn't work

Non c'è molto che puoi fare al riguardo. Tuttavia, indipendentemente dalla tua metodologia di sviluppo, ottenere questo tipo di segnalazioni di bug dai tester del QA è assolutamente inaccettabile . Quando QA invia una segnalazione di errore a modo mio con quelle poche informazioni, le tiro indietro dicendo loro di darmi dei passaggi per riprodurre e indicare chiaramente cosa è andato storto e cosa dovrebbe accadere.

Se il QA può solo fornirti una segnalazione di bug in uno dei formati precedenti, ciò significa che il tester QA potrebbe aver bisogno dell'aiuto di uno sviluppatore per sradicare il problema, o se il tester è nuovo al progetto e non ha familiarità con le regole aziendali. Questo è accettabile, ma non fino a dopo la dovuta diligenza dal tester .

Puoi incoraggiare gli utenti a fornirti resoconti sui bug più dettagliati, ma sappi che probabilmente riceverai poche informazioni. Quando ciò accade, chiedi a QA di controllare il bug per vedere se può essere riprodotto, o contatta il client e organizza una passeggiata.

Non ci sono regole in Agile che dicono che devi avere segnalazioni di bug abbreviate - il tipo di segnalazioni di bug è controllato da ciò che funziona meglio per la tua squadra o organizzazione. Se i report abbreviati funzionano per tutti, è agile. Se i report di bug complessi funzionano meglio, anche questo è agile.

Agile sta responsabilizzando il team a fare tutto ciò che gli consente di essere il più produttivo, senza essere obbligati ad aderire a un particolare insieme di regole stabilite da qualcuno al di fuori del team.

Entrambi i tuoi esempi potrebbero essere perfettamente agili. Tutto dipende dai tuoi bisogni, dalla tua gente e dalla fase attuale del ciclo di sviluppo. In generale, ho visto i team di controllo qualità utilizzare le schermate e registrare come strumento di supporto per integrare la segnalazione di bug. Perché? Secondo la gente del QA, ottenere buone catture e registrazioni dello schermo non è così facile come semplicemente digitando. Inoltre ci sono alcuni passaggi che sono meno inclini a essere rappresentati come una cattura dello schermo, come cambiare le configurazioni tramite la riga di comando; gli sviluppatori adoreranno il fatto che tu l'abbia digitato, in modo che possano semplicemente c & p; ti odieranno se hai solo allegato una cattura dello schermo:)