In questo articolo ti parlo degli elementi fondamentali dell’approccio AGILE e di come questi contribuiscono alla metodologia nel suo insieme.

In questa prima parte faccio chiarezza sui Temi, Epiche e User Story. In rete infatti si leggono molte definizioni, in alcuni casi contrastanti, ma con un po’ con l’aiuto dei concetti di insiemistica riusciremo a definire bene questi elementi.

Cosa si intende per Tema?

Un Tema può essere definito come un insieme di User Story che hanno attributi in comune, condividono uno stesso argomento.

Tra le user story che appartengono allo stesso tema ci sono quindi delle affinità, delle correlazioni inequivocabili e spesso un obiettivo comune.

Ad esempio, l’inizio della definizione di un tema potrebbe essere:

“Nell’eCommerce che stiamo sviluppando è necessario poter acquistare gli articoli mostrati.”

Potresti iniziare a definire il lavoro da fare sull’eCommerce in base a questa definizione?

No, direi proprio di no, perché troppo generica. E’ necessario pertanto introdurre un ulteriore elemento di dettaglio.

Cosa si intende per Epica?

Un’ Epica è una storia che è troppo generica per essere implementata. Descrive un insieme di funzioni collegate o un insieme di sotto-funzioni che realizzano un singola funzione complessa.

Potremmo dire anche che un’epica è una storia più grande delle User Story e che quindi non può essere completata in una singola iterazione.

Qual è la differenza tra un’Epica ed un Tema ? La figura seguente né da una spiegazione insiemistica.

Con riferimento all’esempio di Tema fatto prima, nella figura le user story 2 e 3 faranno sicuramente riferimento allo stesso contesto ed avranno attributi in comune. In pratica, ogni scenario avrà in comune la caratteristica: “contribuire ad implementare l’eCommerce nel sito web”.

Se lo scenario è descritto in modo molto astratto, siamo in presenza di un’Epica, ovvero una storia più grande delle altre da esplicitare poi in User Story – che sono il formato Agile delle specifiche dei requisiti e devono spiegare come il sistema si deve comportare rispetto ad una singola caratteristica o funzione – con un adeguato livello di dettaglio (in figura User Story 1 e 2).

Le User Story a loro volta saranno implementate o tradotte in task veri e propri da svolgere in una singola iterazione o Sprint.

Rapporto tra User Story e Sprint

Siamo arrivati ad un punto fondamentale.

Le User Story devono poter essere implementate in uno Sprint.

Perché?

Se rivediamo i due articoli precedenti sul manifesto AGILE (li trovi qui: articolo 1 e articolo 2) notiamo che uno dei principi fondamentali è:

Principio 3: consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.

E’ proprio questo il punto.

Per rilasciare software funzionante, è necessario avere User Story da tradurre in attività tali da poter essere implementate in uno Sprint, cioè in due settimane o al massimo (ma non è pratica comune) in un paio di mesi.

E’ questa la ragione per la quale se la User Story è troppo generica ma anche troppo vasta va tradotta in storie più “piccole”, perché devono essere scomposte in uno Sprint.

Come scegliere le User Story da implementare in uno Sprint: il Product Backlog

Tutta la metodologia Agile segue una logica ben precisa che parte dal manifesto, che abbiamo visto nei due articoli che ti ho citato prima.

Il punto è: ma quale User Story implemento in uno Sprint?

Qui ci viene in aiuto il Product Backlog.

In questo log sono inserite le User Story da implementare. C’e’ una figura professionale ben precisa in AGILE che si occupa del Product Backlog : il Product Owner.

Il Product Owner conosce quali User Story devono essere implementate per prima. Ma non lo fa a sua discrezione, lo fa tenendo in mente il primo principio enunciato nel manifesto:

Principio 1: La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

Quindi le priorità che assegna il Product Owner alle User Story del Product Backlog rispettano il primo principio: vengono assegnate in base al valore del Cliente.

Il punto di vista che guida è quello del Cliente.

Niente male, molti termini AGILE che interagiscono tra di loro e ci aiutano a comprendere la metodologia.

Una volta che sono attribuite le priorità delle User Story inserite nel Product Backlog si procede alla creazione dello Sprint Backlog.

Lo Sprint Backlog è costituito dagli item del Product Backlog che vengono scelti per essere implementati nell’iterazione.

In base a quali criteri vengono scelti questi item?

In modo sequenziale? Non sempre.

Come migliorare il throughput selezionando le User Story dal Product Backlog in modo non sequenziale

Il Team qui entra in gioco e fa sentire tutto il suo peso.

Definiamo una misura: le User Story point.

Ho la possibilità di assegnare un dimensionamento ad una User Story.

Ad esempio, supponiamo di avere 4 User Story nel Product Backlog che misurano i seguenti User Story point (usp):

• User Story 1: 6 usp
• User Story 2: 5 usp
• User Story 3: 4 usp
• User Story 4: 5 usp

Supponiamo inoltre che sia stato stimato, osservando più di tre iterazioni, che in uno Sprint il Team ha una velocità di 10 User Story point.

Per quanto supposto, non posso procedere in modo sequenziale altrimenti avrei bisogno di 3 iterazioni: una di 6, una di 5 ed una da 9 User Story Point. Questo significherebbe avere un throughput non ottimale e introdurre un ritardo nel progetto.

L’idea è quindi selezionare le User Story con l’obiettivo di ottimizzare il throughput, senza necessariamente rispettare la sequenzialità.

Ad esempio, con rifermento al caso sopra esposto, se scegliessi la prima e la terza potrei implementarle in uno Sprint da 10 usp, a seguire ovviamente selezionerò la seconda e la quarta sempre in un unico Sprint da 10 usp. In questo modo avrò in totale due iterazioni invece che tre.

Il PM Agile come servant leader

Abbiamo migliorato il throughput scegliendo secondo la velocità del Team le User Story ed avendo ben chiaro che una User Story non può essere implementata parzialmente, deve essere finita nello Sprint.

Questo limita anche il Work In Progress o WIP un principio molto caro a KanBan, ma ne parleremo ancora in un altro articolo.

Poi consideriamo anche che il Team che è self organized, deciderà le soluzioni migliori e come implementare le User Story.

Ma allora verrebbe da chiedersi il PM Agile che ruolo ha?

E’ il coach. E’ un servant leader.

Non è un leader autoritario ma è al servizio del Team e del Product Owner. Si assicura che seguano la metodologia nel migliore dei modi. E’ attento affinché tutto contribuisca al successo del progetto senza ostacoli.

Un esempio che trovo molto esplicativo è il seguente: se è necessario svolgere del lavoro amministrativo per favorire la consegna del Done, cioè dei deliverable in uno Sprint, può succedere che il PM Agile svolga tale lavoro per fare in modo che il Team non abbia ostacoli.

Questo esempio da molto l’idea del Servant Leader che contribuisce fluidificando il lavoro e l’uso della metodologia, che serve al gruppo per essere di successo.

Concludo con l’osservazione che questi concetti sono sempre più all’attenzione, anche del nostro Project Management Institute (PMI).

Alla prossima.