Per quanto si possa eccellere nella scrittura di codice, esiste una triste verità: nessun programma sarà mai privo di bug! Questo porta a riflettere sul come gestire i bug durante una Iterazione, evitando che il team ecceda la normale capacity prevista e risponda in maniera strutturata ad essi.
Per affrontare la questione, è necessario definire cosa si intende per bug:
un bug è un funzionamento anomalo che si verifica durante il normale utilizzo del software.
Ora questo porta ad alcune considerazioni fondamentali:
- Se i test di unità e funzionali evidenziano un problema durate l’iterazione di sviluppo del Product Backlog Item, non si tratta di un bug, ma di un’azione di “correzione” intrinseca all’attività di sviluppo stessa
- Se il nostro Product Backlog Item è stato validato da Product Owner (e dal key stakeholder), una successiva richiesta di modifica è una “change request” non un bug, e per accoglierla deve essere creato un regolare Product Backlog Item da prioritizzare nel backlog
- I bug hanno sempre alta priorità di risoluzione, in modo da costruire e mantenere una main-line di sviluppo di qualità, ridurre il costo di risoluzione relativo, e poter ottenere una build affidabile in ogni istante (second way di DevOps)
Fatte queste precisazioni, è utile, in fase di Iteration Planning, tenere sempre presente dell’andamento medio dei bug (tre/quattro iterazioni possono essere sufficienti) in modo da riservare una parte della capacity del team proprio per la loro risoluzione. Chiaro che se non si ha un trend decrescente del numero di bug, è necessario individuare un’opportuna azione di riduzione del debito tecnico e approfondire la tematica della Built-In Quality in retrospettiva, decidendo con il Product Owner un opportuno bilanciamento tra nuove funzionalità e aumento della qualità.
A tal proposito, Martin Fowler raccomanda il mantra del “Refactoring forever”, ovvero risolvere immediatamente i bug (critici) intervenendo in modo strutturato per pulire il codice (clean code), senza dimenticarsi di aggiungere gli opportuni test di unità e funzionali (ma non solo) necessari a irrobustire il codice e supportare adeguatamente la pipeline di deploy a partire dalla Continuous Integration.
La cosa importante è quella di non ricadere nella trappola del Team di Supporto (Support Team): non bisogna istituire un team che si occupa esclusivamente di bug a cui si demandano le relative responsabilità di risoluzione. Ciò ha alcune implicazioni molto evidenti, soprattutto dal punto di vista della Cultura Agile:
- Il Support Team si sentirà presto un team di serie-B, perché non coinvolto nelle nuove attività ed iniziative
- Il costo di risoluzione è decisamente più alto visto che il problema non sarà risolto dal team che lo ha (involontariamente) generato
- Il know-how relativo ai problemi scoperti e risolti dovrà essere condiviso con il team originale che ha sviluppato la funzionalità specifica, causando un ping-pong di informazioni e ulteriori perdite di tempo
Il consiglio è quello di prevedere sempre, per ogni team, una gestione in stile Kanban dei bug, riservando una opportuna capacity dello stesso (la regola 80-20 è un buon punto di partenza se non si hanno dati storici del team)) per gestire i bug e occuparsi del refactoring e irrobustimento del codice: Do it your self!
Stay tuned J
