Archivi tag: user stories

Come gestire user stories tecniche

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 affrontarle?

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…

Non solo user stories nel product backlog

Il backlog racconta il nostro prodotto da diverse prospettive.
Sappiamo che finché esiste il prodotto esiste un backlog e che questo è principalmente costituito da user stories, ma non tutto ciò che è contenuto nel backlog deve necessariamente essere una storia.
Lo scopo di questo artefatto è condividere cos’è il prodotto che stiamo realizzando con chi lo deve implementare, validare, utilizzare e – in generale – con tutti coloro che ne sono interessati.
In quest’ottica le user stories potrebbero non essere esaustive.

Come descrivo un’interazione complessa? E l’esperienza utente? Dove condivido i dettagli delle interfacce? Come posso dettagliare gli aspetti di performance e scalabilità del software?
Le user stories a volte non bastano. In generale tutto ciò che può aiutare ad aumentare la comprensione del prodotto e a descriverne l’utilizzo da parte dell’utente finale è un elemento utile.

Nella mia esperienza un buon backlog finisce per contenere tutti questi elementi:
user stories
interazioni
visual design
requisiti non funzionali

Non mi soffermo sulle user stories, di cui abbiamo già parlato a lungo, e che hanno lo scopo di descrivere le funzionalità del prodotto.

Interazioni

A volte le funzionalità che vogliamo realizzare comportano un’interazione complessa.
Sono i casi in cui l’utente deve ad esempio compiere più step per portare a termine un’operazione o casi in cui una singola azione provoca più effetti in diversi punti del sistema.
Pensiamo alle esperienze di acquisto, alle registrazioni mediante social, alla gestione delle proprie mail nella casella di posta.
In questo caso oltre alle user stories sulle singole funzionalità è necessario dettagliare il percorso che dovrà seguire l’utente.
A questo scopo ci vengono in aiuto i diagrammi di flusso, gli scenari e le storyboard.
Mediante questi strumenti possiamo descrivere visivamente i singoli passaggi attraverso cui transita l’utente, verificare di non avere omesso degli step fondamentali e calarci nel suo percorso per verificarne la logica ancora prima di aver dettagliato l’interfaccia.
Con l’interaction design rispondiamo alle domande: come si muoverà l’utente? che cosa potrà fare nel nostro servizio?

Visual Design

Il design è un componente essenziale del successo di un prodotto ed un aspetto sempre più rilevante nei criteri di scelta da parte dell’utente finale.
Nel mondo digitale ci sono aziende di successo che hanno fatto di questa caratteristica il proprio elemento distintivo (pensate a Apple!).
Per comunicare questo tipo di caratteristiche possiamo utilizzare svariati tool: mock-up, sketch e wireframes che emulano la navigazione e le principali interazioni dell’utente finale.
Il ventaglio delle possibilità è ampio, si va dal semplicissimo disegno dell’interfaccia a matita su un foglio di carta al .psd dell’art director definito al pixel (anche se questo livello di dettaglio è eccessivo e controproducente).
Con il visual design rispondiamo alla domanda: cosa vedrà l’utente in ogni singolo step?

Requisiti non funzionali

Definiscono le proprietà e i vincoli di un sistema.
Sono gli aspetti che riguardano – ad esempio – l’usabilità, la scalabilità, le performance di un prodotto, i tempi di risposta.
Sono spesso elementi essenziali per la soddisfazione degli utenti, a volte poco tangibili ma trasversali all’intero servizio e critici per il suo corretto funzionamento.
Sono di solito problemi non indirizzati a livello di MVP (minimum viabile product)  ed anche i primi aspetti che “saltano” quando il time to market è fondamentale nella strategia di prodotto.
Pur essendo così bistrattati sono tuttavia quelle caratteristiche che rendono solido e flessibile un prodotto nel tempo.
Ecco perché prima o poi vi ritroverete a fare i conti con i requisiti non funzionali.
Possono richiedere tempi di implementazione più lunghi rispetto alle funzionalità del servizio ed è opportuno definirli il prima possibile nel corso dello sviluppo in modo tale compiere scelte tecniche e di prodotto in linea con i vincoli che caratterizzeranno il sistema.
Solitamente i requisiti non funzionali non vengono espressi mediante la formula classica delle storie (attore, funzionalità, beneficio), bensì mediante enunciati.
Qualche esempio:
– l’acquisto dei prodotti mediante carrello deve essere disponibile anche  su browser Opera
– il caricamento della pagina di risultati di ricerca deve essere inferiore a 1,5 secondi
– l’area personale deve essere consultabile in mobilità da device Android vers. 4 e superiori
Con i requisiti non funzionali rispondiamo alla domanda: di quali vincoli deve tenere conto lo sviluppo del nostro prodotto?

In sintesi il mio consiglio è questo: non forzate all’interno di user stories qualsiasi tipo di dettaglio di prodotto.
Se avete difficoltà a descrivere una caratteristica mediante la formula who/what/why provate a chiedervi se non avete forse a che fare con requisiti non funzionali, interazioni o aspetti di visual design.
Tutti questi sono elementi determinanti della user experience finale e hanno la dignità di trovare posto nel product backlog.
Più in generale non esitate ad avvalervi di qualsiasi strumento possa generare maggiore chiarezza.
Sperimentate e divertitevi a farlo!

4 livelli per requisiti agili

Recentemente ho avuto occasione di seguire un workshop di Sally Elatta dal titolo “4 levels of Agile Requirements”.
L’idea centrale della relatrice – fondatrice di Agile Transformation e Agile coach – è che sia fondamentale approcciare i requisiti agili secondo diversi gradi di astrazione.

Questo modus operandi non è una novità.
Abbiamo già parlato di come l’introduzione di una gerarchia nel Product Backlog possa essere d’aiuto sia per il team sia nei rapporti con gli stakeholder di progetto.

Sally Elatta ripropone questa idea sottolineando l’importanza di avere punti di vista sul progetto che vanno dal generale al particolare, ovvero:
epiche
funzionalità
user stories
– singole attività (task)

Considerare i requisiti secondo questi 4 livelli di astrazione consente di legare le singole attività implementative con la “big picture” del progetto e dare così valore alle scelte che dovremo effettuare nel corso dello sviluppo.

Livelli di progetto

La continuità tra i vari livelli è ben rappresentata nell’immagine.
In relazione al Backlog ci interessa concentrare l’attenzione sui 3 livelli centrali.

USER STORIES

Le user story rappresentano il secondo livello dal basso, quello in cui propriamente avviene l’azione o interazione.
Descrivono brevemente ciò che il sistema può fare per risolvere un problema specifico di un utente ben definito.
La caratteristica principale delle storie è essere focalizzate sul valore che producono per il soggetto, a differenza dei singoli task che sono invece una segmentazione delle attività ai fini della lavorazione da parte del team.

 

FUNZIONALITA’

Ad un livello superiore di astrazione rispetto alle user stories troviamo le funzionalità (features), che costituiscono una descrizione più tradizionale del comportamento del sistema.
Sono il livello intermedio tra i bisogni dell’utente e la soluzione progettuale complessiva.
Il concetto di funzionalità ha dal mio punto di vista un enorme pregio: collega le singole attività portate avanti dal Team Scrum con una terminologia utilizzata abitualmente da figure professionali quali Program Manager, Product Manager e manager in generale.
Mediante un elenco di funzionalità siamo in grado di descrivere il nostro progetto con un discreto grado di approfondimento e di spiegarlo anche ad interlocutori non avvezzi alle metodologie agili.

In alcune realtà aziendali di dimensioni medio-grandi anche i team di sviluppatori potrebbero essere organizzati intorno a queste feature.

 

EPICHE

Infine le epiche rappresentano il livello più alto di espressione del bisogno di un utente.
Sono i pilastri della big picture, le caratteristiche costituenti.

Le epiche sono i primi elementi che emergono dal concept di progetto. Si tratta di storie di grandi o grandissime dimensioni che
permettono di comunicare il perimetro di progetto in poche battute ma non consentono di effettuare una stima iniziale dato l’elevato livello di astrazione.

Il collegamento tra questi 3 livelli – storie, funzionalità ed epiche – ci consente di avere maggiore controllo sullo stato di avanzamento del progetto ed offre una chiave di lettura di immediata comprensione agli interlocutori.

Per questo motivo può essere molto utile verificare la consistenza del backlog salendo e scendendo attraverso questi 3 livelli.

Facciamo qualche esempio di “prova del 9“:

  • Possiamo ricondurre tutte le user stories ad un’epica corrispondente?
    Se non è così probabilmente potremmo avere “lavoro sommerso” e sprint goal poco definiti.
  • Ci sono epiche a cui sono collegate pochissime user stories?Verifichiamo di aver compreso bene le aspettative degli stakeholder. Potremmo aver perso qualcosa per strada o non aver spacchettato correttamente il lavoro.
  • Siamo in grado di tradurre il backlog della release in una lista di funzionalità? Possiamo sintetizzare con una percentuale di avanzamento a che punto sono queste feature ?

Potreste accorgervi – come nel mio caso – che non state utilizzando coerentemente o con continuità tutti e 3 i livelli.
Non resta che ispezionare e adattare il backlog, in perfetto spirito agile…