Sviluppo Agile – Chi paga il bug-fixing?
Proprio oggi stavo facendo una riflessione sui metodo agili e sul famoso dilemma della responsabilità del bug-fixing.
In un processo waterfall la responsabilità del bug fixing è (quasi) sempre a carico del fornitore (azienda che sviluppa software), spesso causando gravi disagi nei tempi di consegna e nel pagamento delle risorse.
In un processo agile, dove l’azienda fornitrice mette a disposizione un team full-time (o con effort concordato) sul singolo progetto di un cliente, chi paga il bug fixing?
Dal mio punto di vista ritengo che se un team adotta tutte le buone pratiche agili dovrebbe essere in grado di creare software esente da bug. Ovviamente questo non è sempre possibile.
I punti deboli della catena possono essere:
- scrittura di un test non completo;
- storie troppo poco granulari;
- poco feedback tra team e cliente;
Ok, ammettiamo che il bug è stato creato, quindi siamo caduti in uno dei tre punti precedenti. Tutti e tre i punti indicano che è stato tolto tempo all’implementazione di una storia, poichè:
- scrivere test completi richiede tempo;
- splittare storie significa più tempo di sviluppo;
- più feedback significa più tempo con il cliente
La mia domanda a questo punto è: “Che cosa ha fatto il team di questo tempo non utilizzato?”
Se c’è un rapporto di fiducia e trasparenza tra cliente e fornitore direi che il team se non ha speso il tempo per le attività viste sopra lo ha speso per continuare lo sviluppo dell’iterazione, quindi ha sempre venduto valore al cliente.
Con ciò direi che il bug-fixing rientra nella normale vendita di valore che il team fa nei confronti del cliente e che ogni bug, come ben spiegato in tutti i manuali agili, va trasformato in storia, stimato e pianificato nelle iterazioni successive.
Il team agile vende il maggiore valore al cliente nel minor tempo possibile, il cliente deve pagare tutto il valore che il team crea.
