Quando tenere riunioni di triage di bug nel processo SCRUM?

Il processo di valutazione non è in genere eseguito come una riunione. I team lo fanno in modo diverso, a seconda del prodotto, ma nel nostro team, il proprietario del prodotto triages i problemi dei clienti e ruotiamo un altro membro del team come "triager del giorno" per i problemi riscontrati dai test.

Il lavoro del triager non dovrebbe essere il debug, ma rispondere alle seguenti domande nel modo più efficiente possibile:

• È un bug noto, un nuovo bug o un errore dell'utente?
• Se un nuovo bug, quale team del software dovrebbe essere responsabile della correzione?
• Quanto è grave l'impatto? C'è una soluzione alternativa, sta impedendo ulteriori test, ecc.
• Stima approssimativa del tempo da risolvere.

Se il triager ha bisogno dell'esperienza di qualcun altro, lo chiama. Se il triager sente che è abbastanza grave da mettere qualcos'altro in attesa, avrà una conversazione informale con il proprietario del prodotto. Altrimenti, entra nel nostro arretrato. La maggior parte delle volte, la risoluzione di un problema richiede circa 15 minuti e non richiede il coinvolgimento di nessun altro.

Dipende.

Diversi team agili hanno processi diversi perché hanno esigenze diverse. Se hai qualche dozzina di bug in arrivo ogni giorno, una riunione cubica informale probabilmente non la taglierà. Se la maggior parte dei bug viene immessa dall'utente, è necessario qualcuno che cerchi solo i duplicati e possa giudicare i problemi di usabilità. Se sei un piccolo gruppo, fermarsi dalla postazione del responsabile della squadra è positivo perché puoi discutere delle esigenze e degli scenari di riproduzione. Se sei qualche settimana prima della major release programmata (sì, a volte capita in modo agile), potresti aver bisogno di triage più spesso,

Quello che ho visto funziona meglio nei team di medie dimensioni (5-7 sviluppatori) su progetti di dimensioni medie (9-18 mesi) senza requisiti bizzarri (politica, supervisione governativa, progetto ad altissimo rischio, ecc.). triage meeting a fianco del tuo backlog grooming 1-2 giorni prima dello sprint start. Le persone possono venire guidate dal team con cose che ritengono più urgenti (problemi dei clienti di strong impatto, bug che bloccano un altro team, corruzione dei dati). Allora faranno una chiamata se il bug è abbastanza grave - o il reporter abbastanza affidabile - che non dovrebbe aspettare.

Sì, dovresti provare a non interrompere lo sprint, ma le persone lo faranno, quindi potrebbe anche spingerli a farlo nel modo meno dirompente.

La prima cosa da dire è che quasi tutto ciò su cui lavora un team Scrum dovrebbe essere discusso nelle solite riunioni di Sprint Planning. Se una storia è un bug risolviamo il nostro nuovo sviluppo di funzionalità, è a questo punto che il Product Owner dovrebbe metterlo al suo posto in uno Sprint prioritario.

In secondo luogo, si verificano interruzioni di Sprint - è solo una questione di frequenza. Se è una cosa occasionale, il team nel suo complesso, incluso il suo Product Owner, deve essere preparato affinché lo Sprint ne risenta, e l'OP dovrebbe essere a bordo prima che la gente inizi a lavorare su attività inaspettate.

La cosa principale che devi considerare è: Scrum è giusto per te? Potrebbe non essere. I PO novizi spesso passano attraverso una fase nei primi due mesi di tentativi di gioco del sistema, per ottenere in qualche modo più lavoro dal team. Ho visto nuovi proprietari di prodotti descrivono l'assenza di una funzione che hanno pensato sotto la doccia quella mattina come un bug urgente, nel tentativo di ottenere più cose nello Sprint che gli sviluppatori erano pronti a impegnarsi. Se questo è ciò che sta accadendo, stai male con Scrum e irrompi nella tua nuova PO come aggiungi delicatamente possibile. Ma se la natura del lavoro del team è che i bug inattesi, le domande dei clienti ecc. Devono essere affrontate praticamente ogni quindici giorni, suggerirei che Scrum non fa per te. Kanban è un sistema di Metodologia Agile che è molto più flessibile e genuinamente valori rispondendo al cambiamento seguendo un piano in modo che Scrum non lo faccia, in un tempo sufficientemente preciso. Se ti trovi costantemente a cercare di carpire le priorità emergenti in un sistema che non lo consente, prova un sistema diverso.