Nasce con i team di software la metodologie di gestione dei progetti Agile per aumentare efficienza, collaborazione e capacità di rispondere alle esigenze del mercato.
Ma cos'è e come può aiutare un team di sviluppo software? Ecco tutto ciò che devi sapere per iniziare o perfezionare le tue pratiche Agile per la gestione dei progetti.
Storia
Il project management Agile è un approccio iterativo attuo alla gestione di progetti di sviluppo, più o meno complessi, software e non che si concentra su rilasci incrementali incorporando ad ognuno di essi il feedback dei clienti ad ogni iterazione.
Nati dal concetto di produzione snella di Toyota degli anni '40, i team di sviluppo hanno adottato le metodologie Agile per ridurre le inefficienze ed aumentare la trasparenza, rispondendo rapidamente alle continue evoluzioni di esigenze dei loro clienti.
Un netto cambiamento rispetto alla gestione del progetto a cascata dove tutto è concentrato sulle consegne programmate, mentre con Agile si aiutano i team di sviluppo a collaborare meglio ed innovare insieme più rapidamente e nella direzione del cliente.
La gestione dei progetti Agile può essere classificata in due framework: Scrum e Kanban.
Lo Scrum è focalizzato su iterazioni di progetti a lunghezza fissa, mentre Kanban è focalizzato su rilasci continui passando immediatamente al task successivo.
Organizzazione del Team
Team autoorganizzato
Il team è autoorganizzato e decide autonomamente quali strategie mettere in atto per completare il lavoro che ha preso in carico. Questo modello è stato concepito per massimizzare la produttività, la flessibilità e la creatività ed insieme ai rilasci continui e incrementali assicurano, potenzialmente, che una versione funzionante del prodotto sia sempre disponibile.
Team organizzato
Il team qui è leggermente più articolato del precedente. Infatti esistono delle figure che si occupano di determinati task, con ruoli ben delineati che rispondono alla domanda: chi fa chi?.
Questo approccio non oscura la creatività del team, infatti a secondo del gruppo una figura può effettivamente gestire diversi compiti all'occorrenza.
Product Owner
Il Product Owner ha la responsabilità di identificare le feature del prodotto, assegnandone le priorità. Come? Attraverso una corretta priorizzazione del Product Backlog, ovvero una lista di attività ordinate in base al valore attribuito dai Stakeholders e contengono una breve descrizione di ciascuna funzionalità del prodotto. Chi sono gli Stakeholders? In alcuni casi può essere lo stesso Product Owner, ciò è valido per esempio in progetti interni. In altri casi può essere un cliente per cui si gestisce lo sviluppo di un prodotto, oppure gli utenti finali.
Il Product Owner è diverso dal tradizionale Product Manager in quanto interagisce attivamente con il team, gestendo le priorità ed esaminando il lavoro insieme al team, piuttosto che delegare, curando nel frattempo il rapporto con gli Stakeholders. In ogni team Scrum di solito c’è una sola persona con il ruolo di Product Owner.
Development Team
Il Development Team, chiamato anche “Feature Team”, sviluppa il prodotto e le funzionalità stilate dal Product Owner. Ogni Team è cross funzionale ed include tutto l’insieme di skill che sono necessarie per lo sviluppo del progetto senza dover ricorrere a team esterni. Il team può essere anche auto organizzato con un buon livello di autonomia e di responsabilità.
All’inizio della cerimonia Sprint Planning, il Product Owner espone le priorità ed il team decide quali conseguirne, facendo il possibile per passare allo sprint successivo secondo la propria organizzazione interna. Il Team non ha solo il becero compito di sviluppare quello che gli è stato richiesto, infatti fornisce soprattutto dei feedback al Product Owner, al fine di migliorare il prodotto e renderlo sempre più funzionale.
In Scrum si ottengono i risultati migliori quando il team è dedicato al 100% sul progetto. Sarebbe meglio evitare, nel limite del possibile, il multitasking e persone allocate su diversi progetti. Team stabili sono spesso sinonimo di produttività alta.
Scrum Master
Lo Scrum Master ha invece il compito di aiutare il team ad essere efficace nel raggiungere gli obiettivi attraverso l'utilizzo di Scrum. Non è un Project Manager o il Product Development Team, ma una figura trascendentale che facilita il team a risolvere le problematiche interne e durante gli Sprint di difendere il team. Spesso viene definito un leader a servizio del proprio team.
Un buon Scrum Master educa e guida l’intero gruppo di lavoro all’uso di Scrum e lo fa in modo che chiunque, inclusi il Product Owner e il management dell’azienda, ne comprendano e ne seguano i principi e le pratiche. È importante che lo Scrum Master sia appassionato e che lavori energicamente alla risoluzione degli problemi che possono compromettere la riuscita di uno Sprint o dell'intero progetto.
Ogni team dovrebbe avere uno Scrum Master a tempo pieno, ma in realtà nei team più piccoli il ruolo può essere assunto da uno dei membri del team che magari dedica parte del suo tempo nell’attività. Il Product Owner non può essere allo stesso tempo lo Scrum Master, dato che a volte capita che lo Scrum Master debba tenere a bada un Product Owner troppo proattivo e perfezionista.
A differenza di un Project Manager, lo Scrum Master non assegna task ai membri del team e non dice loro che cosa devono fare ma facilita il processo aiutando il team ad auto gestirsi ed organizzarsi efficientemente.
Come funziona lo Scrum
Lo Scrum è un framework per la gestione di progetti Agile che utilizza le iterazioni di lavoro a lunghezza fissa, chiamate sprint e quattro cerimonie ad ogni sprint. Inoltre i sui pilastri sono; trasparenza, ispezione ed adattamento.
Le quattro cerimonie dello Scrum sono:
- Sprint Planning: Una riunione di pianificazione dei team dove si determinano quali attività bisogna completare nello sprint successivo. Le attività sono pescate dal product backlog, ovvero una lista di attività priorizzate dal Product Owner;
- Daily Standup: è un meeting giornaliero di 15 minuti per l'allineamento del team sullo stato dei backlog completati ed eventuali schedulazioni o aggiornamenti sulla loro pianificazione.
- Sprint Demo o Review: Una riunione di condivisione, di solito informale, in cui il team mostra cosa hanno completato in quello sprint.
- Retrospective Meeting: Una riunione per analizzare secondo i principi fondamentali (trasparenza, ispezione e adattamento) ciò che è andato bene e non, attraverso critiche costruttive ed azioni per migliorare i successivi sprint.
Le Scrum board possono aiutare per avere visibilità sulle informazioni dei flussi di lavoro. Infatti, le Scrum board sono dei componenti chiave per aumentare la trasparenza nella gestione Agile dei progetti e anche di tenere in mente gli obiettivi da e perseguiti, riducendo la complessità delle comunicazioni. Infatti vedere gli obiettivi in una board aumenta il loro focus per l'intero team.
Come funziona kanban
Kanban è un framework per la gestione dei progetti agile che abbina il lavoro alle capacità del team. Si concentra sul fare le cose il più velocemente possibile, dando ai team la possibilità di reagire ai cambiamenti molto più rapidamente rispetto allo Scrum.
A differenza dello scrum, kanban non ha arretrati (di solito) i backlog si trovano nella colonna Da fare. Ciò consente ai team kanban di concentrarsi sulle versioni continue, che possono essere eseguite in qualsiasi momento per migliorare il prodotto.
Tutto il lavoro è visibile, mirato e pronto per essere eseguito in modo che quando qualcosa è completato, il team passa immediatamente passare a quello successivo. La quantità di lavoro è abbinata alla capacità del team attraverso i limiti WIP, che è un limite predefinito di lavoro che può essere in una singola colonna alla volta.
Il framework kanban include i seguenti quattro componenti:
Elenco dei lavori (o storie): elenco di lavori o storie, sono definiti come i problemi o i compiti che devono essere eseguiti per avanzare l'iterazione.
Colonne e corsie: utilizzato su una scheda kanban serve a distinguere le attività dai diversi flussi di lavoro, utenti, progetti, ecc.
Limiti dei lavori in corso (WIP) : è una regola per limitare la quantità di lavoro da svolgere in base alla capacità del team per non opprimerlo.
Rilasci continui: il team lavora sulla quantità di storie entro il limite WIP e può rilasciare in qualsiasi momento.
Scheda kanban
Una scheda kanban viene utilizzata per visualizzare tutto il lavoro svolto. Viene anche utilizzato per la pianificazione delle risorse e consente ai project manager di vedere il lavoro e pianificare di conseguenza le tempistiche del progetto.
Una scheda kanban è strutturata in colonne e corsie che le storie attraversano nel loro cammino verso il completamento. Le storie rimangono nella colonna Da fare fino a quando il limite WIP non consente l'elaborazione dell'attività successiva. L'elenco dei lavori dovrebbe essere suddiviso in questioni relativamente piccole ed organizzato per priorità.
Stimare, riferire e pianificare
Qualunque framework Agile scelga per supportare lo sviluppo del tuo progetto, avrai bisogno di un modo per far vedere i progressi del tuo team. La stima del progetto Agile aiuta sia i team di scrum che quelli kanban a comprendere le loro capacità. I rapporti Agili mostrano i progressi del team nel tempo. Inoltre, il backlog grooming aiuta i project manager a tenere aggiornato l'elenco dello stato dei backlog, eseguiti, in lavorazione e da fare necessari per capire il punto del progetto.
Stima del progetto Agile
La stima del progetto è un aspetto estremamente importante della gestione dei progetti kanban e scrum. Per kanban, molti team hanno impostato il proprio WIP limite per ogni stato in base alle esperienze precedenti e alla dimensione del team. I team Scrum utilizzano la stima del progetto per identificare la quantità di lavoro che può essere eseguita in uno particolare sprint.
Molti team Agile adottano tecniche di stima particolari per la pianificazione come le carte del poker, la sequenza di Fibonacci o i punti della storia per determinare un valore numerico per l'attività da svolgere. Ciò fornisce ai team un punto di riferimento per l'impiego delle risorse e durante i retrospettive meeting, valutare i comportati dei loro team.
Rapporti agili
Le stime del progetto entrano in gioco all'inizio e alla fine di ogni sprint. Aiutano i team a determinare cosa possono pianificare all'inizio dello sprint ed al loro termine quanto fossero accurate. Rapporti agili, come i grafici di Burndown, mostrano quanti "punti della storia" sono stati completati durante lo sprint. Avere documentazione a supporto nei retrospettive meeting è un modo prezioso per migliorare il focus nei team Agile.
Gestione e cura degli arretrati
Come sappiamo stialata dal Product Owner, un backlog di prodotto è un elenco prioritario di lavoro per il team di sviluppo che deriva dalla roadmap del prodotto e dai suoi requisiti. Il team di sviluppo estrae il lavoro dal backlog del prodotto per ogni sprint.
Serve a mantenere il proprio arretrato ed aiuta i team a raggiungere i propri obiettivi a lungo termine aggiungendo e/o rimuovendo continuamente backlog in base alla loro capacità a lungo termine modificandone gli obiettivi aziendali.
Commenti
Posta un commento