Capita a tutti di dover inserire tra le attivit\u00e0 del team task di tipo prettamente tecnico. Ha senso tracciare queste attivit\u00e0 tecniche?<\/strong> Quando nel corso del tempo non c\u2019\u00e8 stata un\u2019attenzione continuativa alla qualit\u00e0 e al refactoring possono presentarsi casi in cui il codice legacy ha raggiunto livelli decisamente problematici. Svantaggi<\/strong> Vantaggi<\/strong> Questa modalit\u00e0 di gestione \u00e8 piuttosto frequente. Svantaggi<\/strong> Vantaggi<\/strong> Questa \u00e8 un\u2019altra possibilit\u00e0 e devo dire che tra tutte \u00e8 quella dalla quale sento di aver tratto maggior beneficio.
\nIn questo articolo vi porto l\u2019esempio di 3 modi differenti di gestire questo tipo di richieste<\/strong>.
\nInnanzi tutto ha senso parlare di user stories tecniche?
\nMhhh, dipende\u2026
\nSe siamo in grado di individuare nella richiesta un soggetto, un oggetto e un beneficio esplicito \u00e8 utile definirla attraverso il format della user story.
\nSe non \u00e8 cos\u00ec 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\u2019ha prescritto il medico che tutto ci\u00f2 che entra nel backlog sia esclusivamente una user story!
\nCi pu\u00f2\u00a0essere molto altro, ad esempio task di bug fixing, attivit\u00e0 architetturali, prototipi, spike e via cos\u00ec.<\/p>\n
\nAssolutamente s\u00ec! Il team spende del tempo su questi task cos\u00ec come sull\u2019implementazione di nuove funzionalit\u00e0 ed \u00e8 importante tenerne traccia per monitorarle e pianificare il modo migliore di gestirle nel tempo.<\/p>\nCome affrontare user stories tecniche<\/h2>\n
Sprint funzionali e sprint tecnici<\/h3>\n
\nIn alcuni di questi casi mi \u00e8 capitato di vedere i team di sviluppo alternare sprint in cui venivano implementate nuove funzionalit\u00e0 e sprint tecnici dedicati soprattutto al refactoring e alla \u201cmessa in sicurezza\u201d.
\nAd esempio a 3 sprint funzionali seguiva uno sprint tecnico.
\nDico subito che non sono una fan di questa soluzione perch\u00e9 per la mia esperienza produce pi\u00f9 svantaggi che vantaggi.<\/p>\n
\nE\u2019 di difficile \u201cdigestione\u201d da parte del business che fatica a comprendere uno stop forzato ogni mese e mezzo; \u00e8 spesso difficile individuare un chiaro obiettivo dello sprint tecnico; il product owner ha difficolt\u00e0 a misurare il valore di questo tipo di interventi (che peraltro poco si prestano a demo); richiede una maturit\u00e0 di gestione se possibile ancora pi\u00f9 elevata da parte del team.
\nInfine spesso e volentieri questo sforzo non porta comunque un miglioramento effettivo in tempi brevi del codice legacy.<\/p>\n
\nIl team \u00e8 fortemente focalizzato sulla risoluzione degli aspetti tecnici, li gestisce in totale autonomia e non subisce interruzioni.<\/p>\nUser stories funzionali e tecniche nel medesimo sprint<\/h3>\n
\nIl tempo disponibile dello sprint \u00e8 suddiviso tra sviluppi funzionali e attivit\u00e0 di tipo tecnico. Diciamo che il team concorda con il product owner di dedicare ad esempio l\u201980% del tempo ai primi ed il restante 20% ai secondi.
\nE\u2019 il classico esempio di \u201cun colpo al cerchio e uno alla botte\u201d\u2026<\/p>\n
\nIl team fa contest switching all\u2019interno dello sprint (si tratta spesso di attivit\u00e0 a s\u00e9 stanti rispetto al resto); \u00e8 difficile individuare un unico sprint goal.
\nRichiede comunque tempi lunghi per vedere effettivi benefici a livello di legacy.<\/p>\n
\nE\u2019 un compromesso pi\u00f9 che accettabile per il business perch\u00e9 non richiede periodicamente uno stop delle attivit\u00e0; questa modalit\u00e0 di gestione pu\u00f2 essere adottata in ogni sprint; al termine di ogni iterazione consente di avere workable software da mostrare durante le demo.<\/p>\nAspetti funzionali e tecnici nella medesima user story<\/h3>\n
\nIn 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\u00e0 e \u2013 addirittura \u2013 a migliorare.
\nE\u2019 importante notare che richiede grande maturit\u00e0 tecnica ai membri del team e la capacit\u00e0 di fare solo ci\u00f2 che \u00e8 opportuno e nulla di pi\u00f9 (no virtuosismi se non sono necessari).<\/p>\n