Come si può adattare Scrum per consentire gli obblighi di supporto?

Se il team di sviluppo è lo stesso gruppo che gestirà il supporto clienti, la prima cosa da fare sarebbe regolare la quantità di punti storia che il team porta nello sprint per tenere conto del tempo necessario. Ad esempio, se in origine si basavano i punti della storia in uno sprint di 350 ore uomo (5 persone in 2 settimane a 35 ore / settimana dedicate al progetto), se si ha bisogno di persone per svolgere il lavoro di assistenza clienti, è possibile avere solo 270 ore-uomo nello sprint rimanente. Se, con uno sprint di 350 ore all'uomo, avessi una velocità di 20 punti per ogni sprint, avrei ridotto la velocità pianificata a 15-16. Se un'entità separata gestisce le domande di assistenza clienti, non devi preoccuparti di questo tanto.

Successivamente, consenti ai bug report e alle richieste di miglioramento dei clienti di fluire nel backlog del prodotto. Il Product Owner lavorerebbe con il personale dell'assistenza clienti per comprendere la priorità che il cliente esterno ha posto sulla richiesta e per organizzarla con la visione del prodotto. Queste storie generate da entità esterne sarebbero gestite come qualsiasi altra storia - sarebbero ordinate per priorità, stimata dal team di sviluppo, e il numero appropriato di storie generate internamente ed esternamente verrebbe portato allo sprint.

Nel caso in cui si verifichi un problema critico durante uno sprint, il team può impiegare un breve periodo di tempo per stimarlo e lavorare con il Product Owner per determinare se è possibile affrontare nello sprint corrente e cosa dovrebbe essere scivolato dallo sprint attuale per farlo accadere o se sarebbe la prima storia tirata nel prossimo sprint. Il team dovrebbe prendere in considerazione la possibilità di mantenere lo sviluppo sostenibile, la qualità del prodotto e la soddisfazione del cliente al momento di decidere cosa fare con una storia, negoziare se necessario.

Supporto e Scrum non dovrebbero essere un problema in un ambiente sano e ben gestito.

Idealmente, il prodotto dovrebbe essere sviluppato e testato e mantenuto abbastanza bene che i bug vengano normalmente catturati prima di essere spediti ai clienti. Allo stesso modo, la piccola percentuale di bug che sfuggono deve essere documentata, assegnata la priorità e aggiunta al backlog per diventare parte del normale processo di scrum.

Tuttavia, di tanto in tanto, ci deve essere un evento "catastrofico" che non può essere gestito in questo modo, e una squadra di crisi viene rimossa dallo scrum sprint per affrontare questo problema, con l'azienda che accetta che gli impegni feccia possano scivolare di conseguenza.

Tuttavia, ciò che non dovrebbe accadere è che esiste un tale volume di richieste di supporto ad un'urgenza sufficientemente elevata da interrompere continuamente lo scrum sprint. In tal caso, le soluzioni potrebbero includere il miglioramento del testing e del QA prima della spedizione, una migliore formazione per il supporto per risolvere ulteriori problemi di supporto senza fare riferimento a "software" per una risposta, o forse come ultima risorsa persone con competenze di sviluppo nel team di supporto per gestire questi problemi di supporto.

La maggior parte delle squadre di mischia in cui lavoro hanno questi obblighi di supporto. Ci sono un paio di approcci diversi che prendono per gestirli.

Un modo è lasciare che sia un fattore nella tua velocità come interruzioni. In altre parole, potresti avere una velocità di 20 punti per iterazione anziché 30 a causa dei tuoi obblighi di supporto.

Un modo è creare una storia del buffer chiamata "Assistenza clienti" e assegnarle un numero appropriato di punti per la quantità di supporto che ci si aspetta di fornire per tale iterazione. Questo metodo è leggermente migliore del primo se la quantità di supporto varia nel tempo. Ad esempio, se fai un sacco di supporto subito dopo un'implementazione importante, non aspettarti quasi nulla per un anno.

Alcuni team separano il triage iniziale dal fixing effettivo. Creiamo una storia separata per correggere una causa sottostante che viene data la priorità alle altre storie, ma trovare soluzioni temporanee e problemi di configurazione viene subito risolta.