Come gestire user stories tecniche

Tre approcci ai requisiti tecnici

Capita a tutti di dover inserire tra le attività del team task di tipo prettamente tecnico.
In questo articolo vi porto l’esempio di 3 modi differenti di gestire questo tipo di richieste.
Innanzi tutto ha senso parlare di user stories tecniche?
Mhhh, dipende…
Se siamo in grado di individuare nella richiesta un soggetto, un oggetto e un beneficio esplicito è utile definirla attraverso il format della user story.
Se non è così e ci si spacca la testa per far rientrare una richiesta in un modello che non le appartiene in alcun modo meglio evitare del tutto. Non l’ha prescritto il medico che tutto ciò che entra nel backlog sia esclusivamente una user story!
Ci può essere molto altro, ad esempio task di bug fixing, attività architetturali, prototipi, spike e via così.

Ha senso tracciare queste attività tecniche?
Assolutamente sì! Il team spende del tempo su questi task così come sull’implementazione di nuove funzionalità ed è importante tenerne traccia per monitorarle e pianificare il modo migliore di gestirle nel tempo.

Come affrontare user stories tecniche

Sprint funzionali e sprint tecnici

Quando nel corso del tempo non c’è stata un’attenzione continuativa alla qualità e al refactoring possono presentarsi casi in cui il codice legacy ha raggiunto livelli decisamente problematici.
In alcuni di questi casi mi è capitato di vedere i team di sviluppo alternare sprint in cui venivano implementate nuove funzionalità e sprint tecnici dedicati soprattutto al refactoring e alla “messa in sicurezza”.
Ad esempio a 3 sprint funzionali seguiva uno sprint tecnico.
Dico subito che non sono una fan di questa soluzione perché per la mia esperienza produce più svantaggi che vantaggi.

Svantaggi
E’ di difficile “digestione” da parte del business che fatica a comprendere uno stop forzato ogni mese e mezzo; è spesso difficile individuare un chiaro obiettivo dello sprint tecnico; il product owner ha difficoltà a misurare il valore di questo tipo di interventi (che peraltro poco si prestano a demo); richiede una maturità di gestione se possibile ancora più elevata da parte del team.
Infine spesso e volentieri questo sforzo non porta comunque un miglioramento effettivo in tempi brevi del codice legacy.

Vantaggi
Il team è fortemente focalizzato sulla risoluzione degli aspetti tecnici, li gestisce in totale autonomia e non subisce interruzioni.

User stories funzionali e tecniche nel medesimo sprint

Questa modalità di gestione è piuttosto frequente.
Il tempo disponibile dello sprint è suddiviso tra sviluppi funzionali e attività di tipo tecnico. Diciamo che il team concorda con il product owner di dedicare ad esempio l’80% del tempo ai primi ed il restante 20% ai secondi.
E’ il classico esempio di “un colpo al cerchio e uno alla botte”…

Svantaggi
Il team fa contest switching all’interno dello sprint (si tratta spesso di attività a sé stanti rispetto al resto); è difficile individuare un unico sprint goal.
Richiede comunque tempi lunghi per vedere effettivi benefici a livello di legacy.

Vantaggi
E’ un compromesso più che accettabile per il business perché non richiede periodicamente uno stop delle attività; questa modalità di gestione può essere adottata in ogni sprint; al termine di ogni iterazione consente di avere workable software da mostrare durante le demo.

Aspetti funzionali e tecnici nella medesima user story

Questa è un’altra possibilità e devo dire che tra tutte è quella dalla quale sento di aver tratto maggior beneficio.
In sostanza in ogni storia il team stima una quota parte di refactoring del codice e/o dei test. Questo si traduce in prima battuta in user stories che vengono valutate con un peso maggiore (e quindi in una diminuzione iniziale della velocity del team), ma in un tempo relativamente breve la situazione torna alla normalità e – addirittura – a migliorare.
E’ importante notare che richiede grande maturità tecnica ai membri del team e la capacità di fare solo ciò che è opportuno e nulla di più (no virtuosismi se non sono necessari).

Svantaggi
Il refactoring viene effettuato sulle sole storie funzionali lavorate nel corso dello sprint; iniziale diminuzione della velocity.

Vantaggi
Non ha effetti collaterali sugli stakeholder; questa modalità di gestione può essere adottata continuativamente; aumenta da subito la qualità del software e l’attenzione del team a questo aspetto; nel tempo porta grande confidenza ai dev sulle parti che hanno toccato e maggiore velocità di sviluppo.

E voi quale tipo di approccio adottate?
Quale ritenete più utile per il vostro caso? Avete esplorato altre possibilità?
Ci sono casi in cui per risolvere problemi di legacy avete dovuto adottare approcci più radicali?
Sono curiosa di sentire le vostre esperienze…