Categoria: Agile

Pubblicato il

Stime Agili: si parte dalla dimensione del progetto

Nel mondo waterfall la data di rilascio di un progetto – quando non è fissata da contratto – è il risultato di una pianificazione iniziale.
Con l’ausilio di un Gannt vengono messe in sequenza le varie attività da completare in base all’ordine logico di implementazione (concept, progettazione, sviluppo, test, ecc.).

Sulla base del Documento di Requisiti si fa la “lista della spesa” delle attività da realizzare, se ne evidenziano le dipendenze, si assegnano le risorse e mediando tra tempi, costi e ambito si tenta di contenere il più possibile la durata del progetto.

In questo caso le persone che prendono direttamente o indirettamente parte al progetto (gli sviluppatori in prima persona, ma anche i responsabili d’area o eventuali esperti di settore) forniscono una stima temporale delle singole attività.
La somma delle singole durate insieme alla sequenza delle stesse determina la data di rilascio finale.

Quando si utilizzano invece le metodologie Agili il primo passo per stimare la durata di un progetto consiste nel valutarne il size, ovvero la dimensione.
La domanda che si pone lo Scrum Team è:
“Quanto è grande il progetto?”

Per valutarne la dimensione il gruppo di lavoro deve avere un’idea condivisa  di cosa è necessario realizzare.
Una volta comprese le finalità del progetto nel suo complesso e tradotte le componenti chiave in user stories si procedere a valutarne il size mediante story points o in giornate di lavoro ideali.

Entrambe queste tecniche consentono di esprimere con un sufficiente grado di confidenza la dimensione di una user story, vale a dire l’effort necessario per realizzare la funzionalità in tutte le sue componenti.
Il team in questa fase di analisi deve porre attenzione al fatto che il peso relativo delle storie sia consistente piuttosto che alla precisione della singola stima.

Solo quando tutte le user stories del progetto sono state stimate – anche ad alto livello – si deriva una durata complessiva.
Per farlo è sufficiente dividere la somma degli story points per la velocity del team, ovvero la misura della progressione che è in grado di portare a termine in un singolo sprint.

Facciamo un esempio per chiarire: il team ha valutato che il nuovo progetto cuba in tutto 150 story points. In passato il medesimo team ha avuto una velocity media pari a 25 story points per singola iterazione. Il nuovo progetto durerà quindi 6 sprint.
A questo punto siamo in grado di prendere in mano il calendario e comunicare una data di rilascio: 6 sprint di 2 settimane significano 3 mesi di lavoro.

Ho volutamente portato l’esempio più semplice per far capire come avviene il calcolo della durata. Ci sono tuttavia occasioni in cui il team è totalmente nuovo e lavora per la prima volta assieme, oppure i confini del progetto non sono del tutto chiari in partenza.
E’ utile tener presente che le stime Agili possono esserci d’aiuto anche in questi frangenti, ma le casistiche sono variegate e meritano un approfondimento successivo.

Ricapitolando…
Quando utilizziamo metodologie agili per la stima evitiamo di correre subito alle conclusioni assegnando ad ogni singolo task una durata prevista.
Partiamo sempre dalle funzionalità che rilasceremo al cliente finale (perché solo queste hanno reale valore) e seguiamo 3 step:

  1. stimiamo la dimensione di ogni user story e le sommiamo assieme
  2. dividiamo la somma degli story points per la velocità media del team (solo in questa fase iniziamo a parlare della variabile tempo!)
  3. il numero di sprint risultante ci consente di dire, a calendario, quando finiremo

Perché tanta enfasi sulle dimensioni?
Perché solo separando le due variabili di dimensione e durata possiamo garantire massima flessibilità al nostro piano di rilascio… e il Product Owner ed il Team saranno messi nelle condizioni migliori per valutare come procedere al termine di ogni sprint.

Pubblicato il

Minimum Viable Product o del valore in una fetta di torta

MVP e Release di prodotto

Nella pianificazione di una release ci si trova spesso a valutare a che punto sarà disponibile il prodotto per l’utente finale. Ma se adottate l’idea del Minimum Viable Product potreste decidere di rilasciare una “early beta” del prodotto per testare le vostre assunzioni in termini di ipotesi di valore e ricevere feedback dagli utenti quando lo sviluppo è ancora in corso.

La strategia dell’MVP presenta indubbiamente molti vantaggi: rilasciamo un prodotto (o una funzionalità) ad uno stato essenziale, totalmente “no frills”, perché desideriamo capire ciò che i clienti vogliono veramente, non ciò che dicono di volere o ciò che pensiamo vorrebbero.

Per anticipare il più possibile questo tipo di apprendimento potreste decidere di dare in mano ad una cerchia ristretta di utenti poco più che una presentazione o un wireframe.
Se non è questo il vostro caso, come spesso non lo è per me, rilascerete software funzionante ma dovrete identificare il set minimo di funzionalità in grado di comunicare il valore del vostro prodotto.

Cosa inserire in un MVP

Non è un’operazione così banale come può sembrare a prima vista…
Dovrete far comprendere a chi sviluppa qual è il valore del prodotto dal punto di vista dell’utente finale, un valore che sta nella soluzione di un problema, nella “slice” – la più piccola fetta compiuta – e non in un layer.

Questo approccio dal punto di vista di chi sviluppa è solitamente molto più oneroso perché significa aggredire più sistemi contemporaneamente invece che lavorare “a strati”.
Comporta molto più effort ma, allo stesso tempo, abbatte decisamente il rischio. Insomma, avrete la vostra bella negoziazione da fare con il tech team ma ne vale la pena.

Per rilasciare un MVP dovete concentrarvi sul COSA, su un piccolo pezzo, una singola funzionalità purché finita e funzionante. Fatela funzionare, fatela testare sul campo anche solo da un’unica tipologia dei vostri utenti e – intanto che analizzate i primi feedback – valuterete quali parti mancanti vale la pena di integrare e come.

Cos’è valore per il cliente?

Tenete presente che ciò che interessa all’utente è il servizio nel suo complesso, ma dovendo “fare a fette un elefante” nella mia esperienza ho trovato più utile un approccio verticale piuttosto che orizzontale.
In un servizio e-commerce, ad esempio, l’utente valuterà le diverse funzionalità: la navigazione nel catalogo dei prodotti, la ricerca, il carrello per l’acquisto, l’archivio degli ordini. Quale beneficio trarrebbe se il layer dei dati e quello applicativo fossero perfettamente compiuti ma non fosse possibile neanche consultare il catalogo dei prodotti?

E’ esattamente la differenza che passa tra una fetta di Sacher – per quanto piccola – ed uno strato di torta al cioccolato. Qual è più appetitosa in un uggioso pomeriggio di pioggia invernale? Cosa preferireste mangiare per merenda?
Io non ho dubbi!

P.S.: e non ditemi che non avete mai assaggiato la Sacher Torte perché se no avete ben altri problemi che individuare il vostro Minimum Viable Product …

Continuiamo così, facciamoci del male!  (… grazie Moretti!)

Pubblicato il

Le buone user stories sono INVEST

L’acronimo INVEST creato da Bill Wake nel 2003 è un trucco che i Product Owner possono utilizzare per ricordare le qualità di una buona user story.
Cosa significano le iniziali? Semplicissimo!

Indipendent – Indipendenti

Quando le user stories non sono indipendenti tra loro possono produrre stime non corrette, vincoli di implementazione e potenziali rigidità nella pianificazione dei rilasci.
L’ideale è segmentare le storie in modo tale che possano essere implementate secondo qualsiasi ordine (qui ho parlato dei criteri di suddivisione).

Quando ci troviamo di fronte a delle dipendenze possiamo provare alcune soluzioni alternative:

  • combinare insieme le storie interessate (purché si possano concludere in uno sprint)
  • suddividerle in una maniera differente
  • segmentarle in storie più piccole.

Quando proprio non è possibile scrivere user stories indipendenti è meglio definire un ordine di implementazione e fornire stime differenti per la prima storia e le successive (ad esempio 3 punti per la prima e 1 per le successive).

Negotiable – Negoziabili

Una delle qualità più apprezzabili delle user stories – dal mio punto di vista – sta nel fatto di non essere contratti scritti nella pietra una volta per sempre.
Le storie sono brevi descrizioni delle funzionalità desiderate. Catturano l’essenza di una richiesta, non le specifiche di dettaglio.

In Scrum la definizione dell’ambito di una storia (il cosidetto “scope”) non è come nel processo waterfall appannaggio esclusivo del project manager; i dettagli sono negoziabili e vengono negoziati perché emergono dai dialoghi tra il cliente, il product owner e il team.

La user story è un invito a conversazioni future.

Valuable – Di valore

In un mondo ideale tutte le storie sono di valore per l’utente finale; nella realtà non è sempre così, ma è utile tenere a mente questa aspirazione e interrogarsi sul vero beneficiario della user story (a volte può essere il cliente che paga lo sviluppo software, il committente interno, lo sponsor, il reparto vendite o altri tipi di stakeholder).

L’importante è evitare di perdere tempo (e soldi) in storie che non solo di valore per nessuno e provare a ricercare benefici “spendibili” anche nelle storie tecniche.

Estimable – Stimabili

Dal momento che Scrum prevede iterazioni time-boxed che siano autoconclusive, la stima di una storia e del tempo necessario per produrla è un’attività fondamentale nel team.
Quando la valutazione risulta difficile siamo solitamente di fronte ad uno di questi problemi:

  1. gli sviluppatori non conoscono perfettamente il dominio e non si sentono confidenti nel dare una stima iniziale
  2. hanno una conoscenza parziale della tecnologia da utilizzare
  3. oppure le storie risultano troppo grandi o poco chiare.

Nei primi due casi si può cominciare a programmare un’attività di analisi da parte del team (una spike) per arrivare a una stima sufficiente dell’ordine di grandezza delle attività; negli altri è il Product Owner che deve farsi carico di segmentare di più le storie e dettagliare maggiormente i criteri di accettazione.

Size appropriately or Small – Della giusta dimensione

La dimensione giusta è “quanto basta”… e come nelle ricette di cucina si migliora con la pratica, perché non è sempre evidente a cosa corrisponda il fatidico q.b.
Una cosa è certa: se le storie sono troppo piccole o troppo grandi ve ne accorgerete!
Il team non mancherà di farvelo notare già in fase di refinement, quando potrebbero sorgere problemi nella stima.
Anche in questo caso bisognerà dividere le storie tanto grosse da non poter entrare in uno sprint (di solito sono epiche nascoste!) o combinare più user stories affinchè l’effort complessivo comporti almeno una mezza giornata di lavoro.

Testable – Testabili

Al termine di ogni sprint vengono rilasciate delle funzionalità che sono “done” e dev’essere possibile dimostrare al cliente finale questo stato “finito”.
Ecco perché nella user stories non possono mancare criteri di accettazione effettivamente misurabili, ognuno dei quali possa poi essere misurato attraverso i test.
Quando i test passano (proviamo ad automatizzarne il più possibile) dimostriamo che le storie sono complete.

INVEST!

Ovvero user stories indipendenti, negoziabili, di valore, stimabili, della giusta dimensione (né troppo piccole né troppo grandi) e testabili.

L’articolo originale di Wax si intitola INVEST in Good Stories and SMART Tasks.

Proudly powered by WordPress