Questo articolo fa parte di una serie di mie riflessioni sull’innovazione technology-driven, cominciata qui.
Secondo wikipedia, il termine Metodologie Agili fu coniato nel 2001 quando venne formulato l’Agile Manifesto.
“Le singole pratiche applicabili all’interno di una metodologia leggera sono decine e dipendono essenzialmente dalle necessità dell’azienda e dall’approccio del project manager. Nella scelta però bisogna tenere conto delle caratteristiche di ogni pratica per i benefici che apporta e le conseguenze che comporta. Ad esempio, in Extreme Programming, si supplisce alla mancanza assoluta di qualsiasi forma di progettazione e documentazione con lo strettissimo coinvolgimento del cliente nello sviluppo e con la progettazione in coppia. Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie: Automazione; Comunicazione stretta; Coinvolgimento del cliente; Progettazione e documentazione; …”.
Pur essendo partite in ambito dello sviluppo software, le metodologie Agile si stanno affermando come metodologie indicate anche per progetti di altra natura. Scrum, ad esempio, è una metodologia Agile particolarmente indicata per progetti complessi e innovativi. Il metodo è molto semplice
- Un product owner crea una lista dei desiderata, in priorità (product backlog)
- Il team progettuale effettua una sessione di pianificazione (sprint planning) e seleziona un piccolo insieme di desiderata in cima alla lista (sprint backlog) e decide di implementarlo
- Il team ha un ammontare finito di tempo (lo sprint dura di solito da 2 a 4 settimane) per completare il lavoro, ma si incontra ogni giorno per verificare il progresso (daily scrum)
- Uno ScrumMaster si assicura che il team resti focalizzato sull’obiettivo
- Alla fine dello sprint, il lavoro dovrebbe essere rilasciabile: pronto per essere utilizzato dal cliente, messo su uno scaffale, presentato ad un azionista
- Lo sprint termina con una valutazione retrospettiva
- Successivamente si ripete lo sprint planning e comincia un nuovo ciclo
- Il ciclo si ripete fino a quando abbastanza elementi del product backlog sono stati completati, o il budget è finito, o arriva una deadline
- Quali di questi eventi determina la fine del lavoro è specifico di ogni progetto
- Qualunque sia il motivo ed il momento in cui termina il progetto, il metodo Scrum assicura che il lavoro di maggiore valore sia stato completato
Questa è una rappresentazione grafica della metodologia SCRUM, con evidenza degli attori coinvolti (fonte: https://www.cprime.com/). Come vedete, anche in questo caso esiste una fase, detta Preparation, che corrisponde grosso modo allo studio di fattibilità.
Qui vedete un dettaglio del meeting giornaliero, in cui i team members descrivono cosa hanno fatto, qual è il prossimo passo e soprattutto mettono sul tavolo, per avere un feedback immediato, i problemi che stanno incontrando. Il meeting è necessariamente molto breve, per non sottrarre tempo eccessivo alle attività progettuali.
Fondamentali sono i ruoli definiti nella metodologia:
Lo ScrumMaster è l’owner del processo ed ha la responsabilità di renderlo fluido, rimuovere gli ostacoli che impattano sulla produttività ed organizzare e facilitare le riunioni critiche. In particolare:
- Rimuove le barriere fra il product owner ed il team di sviluppo, in modo che il product owner lo guidi direttamente.
- Migliora il clima di lavoro del team agevolando la creatività e l’empowerment personale, le capacità di decision-making e problem solving.
- Agisce sui vincoli alla produttività.
- Migliora gli strumenti e le pratiche ingegneristiche, in modo che ogni incremento di funzionalità sia potenzialmente rilasciabile.
- Mantiene aggiornate e visibili a tutti le informazioni sui progressi del team.
In termini pratici, lo scrum master:
- Deve comprendere la metodologia SCRUM ed il contenuto del progetto sufficientemente bene da poter fare da mentore e formare tutti gli altri ruoli sul progetto, compresi gli stakeholder.
- Deve essere sufficientemente flessibile per intercettare i problemi emergenti e risolverli, anche con metodi non tradizionali.
- Deve proteggere il team dagli elementi di disturbi esterni.
Lo ScrumMaster non assegna compiti ai membri del team, poiché questa è una responsabilità del team stesso.
Il Product Owner è il responsabile dei requisiti, l’unica “fonte di verità” per il team riguardo i requisiti e il loro ordine temporale di realizzazione:
- Alimenta il team con le richieste di funzionalità e bug-fixing che possono arrivare da molte fonti e lavora a stretto contatto con il team per definire i requisiti tecnici, documentarli e stabilire l’ordine di esecuzione.
- Gestisce il product backlog mantenendolo aggiornato ed al livello di dettaglio e qualità richiesto dal team.
- Definisce i tempi per il rilascio del lavoro completato e stabilisce se le implementazioni hanno il livello funzionale e la qualità necessarie per il rilascio.
In pratica il Product Owner è l’interfaccia fra il business, i clienti, i loro requisiti sul prodotto ed il Team.
Il Team è un gruppo di persone cross-funzionale ed auto-organizzato, che fa il lavoro di sviluppo e test delle funzionalità.
Poiché il Team è responsabile della produzione, deve avere l’autorità di prendere decisioni su come realizzare il lavoro. Il Team quindi decide come spezzettare il lavoro in attività ed allocare le attività alle risorse, durante lo sprint.
La dimensione del Team dovrebbe essere fra i 5 e i 9 individui. Un numero maggiore rende difficoltose le comunicazioni, un numero minore comporta bassa produttività e fragilità.
I benefici di un metodo come lo Scrum sono molteplici:
- Per il Business: velocità di esecuzione e rispetto delle priorità.
- Per l’IT: minore dispersione di risorse, migliore customer satisfaction e relazione con gli utenti.
- Per il Team: visibilità sull’efficacia del lavoro svolto ed empowerment.
- Per il Demand Manager: allineamento più semplice con il business e opportunità più frequenti di rivedere le priorità per massimizzare il risultato.
- Per il Project Manager: la pianificazione ed il monitoraggio sono più semplici e più concreti, con la possibilità di indirizzare immediatamente i problemi.
- Per il Top Management: grande visibilità sullo stato complessivo del progetto, su base giornaliera, con maggiori informazioni per correggere, eventualmente, le linee strategiche.
luigiatauro.com 