In questa seconda parte ti parlo di ciò che accade all’avvio del progetto Agile.

La prima cosa da fare, come avviene sempre anche nella metodologia classica, è la condivisione degli obiettivi del progetto.

Perché? Perché occorre giustificare il budget che viene investito all’avvio del progetto.

E’ in questa fase che vengono poste domande del tipo:

“Perché sono state allocate queste risorse per il progetto ?”

“Quali benefici sono attesi?”

“Quanto dura uno Sprint?”

“Come lavoreremo insieme?”

A tal proposito viene definito ciò che si chiama Working Agreement. E’ in questo working agreement che si definisce cosa significa il Done. Cioè quando una User Story (vedi PARTE PRIMA dell’articolo) è stata implementata ed il relativo deliverable è accettato da tutti.

Il Project Charter

Le domande poste trovano risposta nel Project Charter.

Tale documento è centrale anche nella metodologia classica (cui fa rifermento la certificazione PMP®), gli obiettivi principali di questo documento con riferimento alla PMP®, sono principalmente due:

• Dimostrare che il progetto porterà valore al committente ed il budget assegnato è giustificato.
• Dichiarare formalmente che il progetto esiste ed assegnare ll Project Manager.

Tale documento in PMP® non è pensato per essere continuamente modificato. Ma se parliamo di AGILE, con esplicito riferimento allo schema di certificazione PMI-ACP®, le cose cambiano.

Il Project Charter in AGILE è un documento che definisce sicuramente un agreement, ma che viene rivisto e può cambiare periodicamente.

Ti indico di seguito quali elementi vengono definiti nel Project Charter con riferimento ad AGILE e relativamente a quanto si conosce al momento della sua definizione. Per vedere nel suo insieme il Project Charter, puoi utilizzare le domande del tipo Who, What, Where, Why and How .

Who: chi sono gli stakeholder, come è composto il Team? Chi è il Committente?

What: cosa deve produrre il progetto affinché abbia successo? Questa definizione viene data con la consapevolezza che può cambiare nel tempo. In un mondo che cambia, i fattori di successo di riferimento, cambiano.

Where: sai bene che AGILE ha come punto di forza la trasparenza, la comunicazione aperta e continua (vedi articoli su manifesto agile). Ciò avviene quando il team è co-locato . Ma questa ipotesi non può essere sempre rispettata. A volte competenze specialistiche si trovano altrove (team distribuito) e va definito dove si trovano i componenti del team.

Why: perché il progetto viene svolto ? qual è il vantaggio che il committente ne deve trarre? Condividendo il why consente di avere per tutti gli attori una visione comune degli obiettivi finali.

How: qui definiamo quale approccio AGILE utilizziamo (SCRUM , XP, ..) oppure quale sarà la metodologia (anche mista) da utilizzare nel progetto. Quale sarà cioè il tailoring che applicherai.

Firma: così come il Project Charter nello standard PMBOK® Guide è firmato dal Project Sponsor anche qui è necessario che sia firmato e accettato, con l’indicazione della data. La data è importante, perché ? Perché quanto scritto nel Project Charter cambia nel tempo.

Il Team Charter

Il processo di Chartering che si svolge all’avvio del progetto, include la definizione del Team Charter, che regola ad esempio:

Il ritmo sostenibile e le ore giornaliere

Cosa significa il Done

Ground rules, che regolano i rapporti tra le persone

Group rules, che regolano come si svolgono i meeting.

Se il gruppo è collaudato e sa come lavorare insieme potrebbe essere inutile la definizione di un Team Charter. Ricordi? AGILE da priorità ai risultati e non alla documentazione (vedi articoli sul Manifesto AGILE, Parte prima e Parte seconda).

L’Iteration Zero

AGILE guardando ai risultati vuole vedere e condividere cosa è stato detto nel project charter. A tali fine viene svolto l’iteration zero.

L’iteration zero viene eseguito per avere più informazioni e anche per accordarsi sul modo in cui sarà svolto il progetto. L’iteration zero non dura come gli altri Sprint, ma di meno, e viene utilizzato per :

• Chiarire i processi di produzione che saranno seguiti
• Chiarire i processi di gestione AGILE ed i vari ruoli e responsabilità
• Definire in pratica il DONE in modo da affermare la chiusura dello Sprint (ad esempio, una volta eseguito l’integration test, lo sprint è stato eseguito correttamente ed è accettato dal Cliente)

Durante l’iteration zero può avvenire anche il primo grooming del Product Backlog, in modo che abbiamo svolto tutto il lavoro per fare iniziare il primo Sprint.

Il Grooming del Product Backlog

Nella prima parte hai visto che nel Product Backlog risiedono le User Story. Il Product Owner ha dato la giusta priorità alle User Story in modo da produrre il massimo valore (il prima possibile) per il Cliente.

Ma hai anche visto che in AGILE il cambiamento è di casa e di conseguenza anche il Product Backlog cambia. Come ? Con il grooming del Product Backlog.

Letteralmente si scuote il Product Backlog. Si ridà priorità alle User Story, si aggiungono nuove User Story, si eliminano User Story non più utili, si rivede il dimensionamento che è stato dato ai diversi item.

Si accettano e gestiscono cioè tutti quei cambiamenti che partono dai requisiti ad arrivano a ciò che deve essere implementato nelle prossime iterazioni o Sprint.

Il grooming (o refinement) avviene durante tutto il progetto. Di solito dura 1 ora ed avviene una volta a settimana. Se dura di più di un’ora a settimana probabilmente significa che il Prouct Owner ed il Team non hanno la stessa base di comunicazione. Ad esempio Il Product Owner potrebbe avere una conoscenza troppo verticale sull’argomento, mentre il Team non ce l’ha.

Abbiamo svolto fin’ora tutte il lavoro propedeutico all’inizio dello Sprint, ma in verità manca qualcosa, il mapping.

Story Mapping e Impact Mapping

All’avvio del progetto non si hanno molte informazioni. Il compito del Project Manager AGILE è di aiutare il Product Owner ed il Team a definire una road map, utilizzando la definizione dei requisiti attraverso esempi (Specifications By Example) e tecniche come Impact Mapping e Story Mapping.

Story Mapping

Con questa tecnica costruisci una mappa utilizzando due assi.

Nell’asse orizzontale rappresenti le User Story per priorità o come le descriveresti per rappresentare la soluzione progettuale nel suo insieme. Sull’asse verticale rappresenti successivi gradi di dettaglio implementativo delle user story.

L’idea è che muovendoti lungo l’asse verticale ed aggiungendo dettagli implementativi ti accorgi se ci sono interdipendenze. E’ vero che il Product Backlog è organizzato in modo da fare implementare le User Story maggiormente di valore.

Ma potresti accorgerti con questa mappa che alcune non possono essere implementate se altre (a cui è stata data una priorità bassa) non sono già nello stato di “Done”.

Impact Mapping

Brevemente questa tecnica consente di partire dall’obiettivo e definire quali sono gli attori, come intervengono e cosa producono per raggiungere l’obiettivo prefissato.

Quindi gli elementi importanti sono:
Perché? (obiettivi) – Chi? (attori) – Come? – Cosa?

Percorrendo questa strada andiamo a vedere rispetto agli obiettivi cosa viene prodotto, cioè i deliverable.

Questo tipo di processo porta alla luce delle interdipendenze (analogamente a come avviene con lo Story Mapping) che ad un primo approccio non erano visibili.

Bene abbiamo veramente fatto di tutto per poter iniziare con l’elemento centrale della metodologia AGILE: lo Sprint e gli eventi che lo caratterizzano ma di questo ti parlo nel prossimo articolo.

Alla prossima!