Ma come si scala la gestione dei bug?
Sviluppare e fixare potrà andar bene (semmai!) ma solo agli inizi; con la crescita della complessità del prodotto e del numero degli user ciò non sarà più sufficiente.
La chiarezza al primo posto.
Tutti devono avere chiaro cosa è bug e cosa non lo è. Un esempio pratico? Finita e inviata la compilazione di un form la finestra si chiude senza un’ulteriore risposta: perché? Ha salvato i miei dati e quindi non è un bug ma una scelta del sistema o il sistema non ha salvato i miei dati e quindi è un bug? Quando l’utente non capisce bene cosa stia succedendo pensa a un malfunzionamento e quindi indirettamente a un bug.
Ogni cosa ha il suo corso, anche il bug.
I bug devono quindi essere gestiti con veri e propri stati di avanzamento. Inseriti in un ticket e passare dal backlog. Dopo aver distinto i bug in base alla loro gravità, un’importante cosa da fare è misurare quanto tempo il team ci mette a fixare il bug. Questa attività viene chiamata ABA, ovvero average bug age.
Risolvere i bug richiede un intervento strutturato. Il codice va pulito (clean code) e testato ma senza cadere in una cattiva tentazione: il Team di Supporto. Istituire un team solo per la risoluzione dei bug non è una buona mossa, oltre che va contro i principi della cultura agile.
Il Team di Supporto si sentirà infatti messo in panchina e chiamato a giocare la partita solo per la risoluzione dei bug. Ma non solo. I costi di risoluzioni aumenteranno coinvolgendo più professionisti e il know-how si disperderebbe. È giusto che chi ha scritto il codice, seppur sbagliando, capisca l’errore e lo sappia risolvere.
Il product manager quindi aprirà uno o più ticket e farà risolvere al team di sviluppo il bug o i più bug. Ciò permetterà al PM e all’intero team di sviluppo di non cadere in confusione ma di prendere atto che un problema esiste, che va gestito e risolto. Il PM inserirà e affiderà la priorità ai vari bug, portandoli poi in Sprint Backlog.
“Test” a “Test” contro i bug.
Quando si parla di software e di scrittura di codice i bug sono la normalità, o quasi. È possibile però controllarli e vincerli applicando alla struttura organizzativa il testing. Prima di andare in produzione testare diventa un’attività fondamentale, un salvavita anzi salvaprodotto. E prima ancora di tutto questo... dividi gli ambienti!
Lavorare in un unico ambiente ti renderà la vita impossibile, dividendo l’ambiente di test invece potrai testare, testare e ritestare. Non avere fretta, prenditi tutto il tempo necessario: identifica su quali device e sistemi operativi testare, il bug fixing è l’unica via che ti condurrà a un prodotto funzionale, funzionante e di qualità.
Ognuno ha le sue priorità, anche i Bug.
Il PM, come abbiamo già anticipato, deve prioritizzare i bug da fixare. Ma come? Analizzando lo stesso bug sotto due punti di vista: l’impatto che il bug ha e la probabilità che questo si verifichi. È possibile che il bug si verifichi ad esempio solo su un device con vecchio aggiornamento oppure che si verifichi in molti più contesti e quindi abbia maggiore urgenza di risoluzione.
Nel tuo Sprint Backlog dedica il 20% al bug fixing: ciò ti permetterà di affrontare con la testa e con il tempo i bug più piccoli ma avere un margine anche per quelli più difficili da risolvere.
Un’altra metodologia adottata è quella di gestire i bug affidandone il fixing allo sviluppatore che ha scritto il codice errato. Fixandolo quindi subito. Ciò porterà lo sviluppatore a tu per tu con il suo bug e a migliorare.
Prova la gestione migliore per te e per il tuo prodotto. Sperimenta, testa, sbaglia, migliora. Solo sul campo, potrai costruire la tua esperienza.