Metodo SCRUM, i ruoli e gli eventi
Nel blog post precedente abbiamo fatto un excursus su Agile e SCRUM, con la promessa di vedere nel dettaglio alcuni elementi come il product owner, la stand up ed alcune novità su queste tematiche, come i working agreement.
RUOLI SCRUM
Partiamo con i primi, i ruoli SCRUM. In SCRUM ci sono delle differenze nel rapporto tra le persone rispetto ad una gestione più verticale, compreso quello tra membri del team e responsabile del reparto e ci si impegna per dare la priorità al lavoro di squadra e alla trasparenza. Oltre a cambiare gli equilibri, cambiano in parte anche gli attori.
La figura più vicina al cliente è il product owner, che si occupa di gestire gli sviluppi di business in accordo con gli stakeholder. Il product owner fa sì che venga confezionato il prodotto migliore sulla base delle esigenze del cliente; gestisce e organizza il backlog, ovvero dà un ordine alla serie di task che devono essere realizzati per poter consegnare le release; aiuta il team a capire cosa deve essere sviluppato e perchè; ha la possibilità di accettare o meno quanto è stato prodotto a fine sprint. Infine, informa il cliente sullo stato di avanzamento del progetto.
Il tradizionale ruolo del project managerviene sostituito da quello dello scrum master, una figura più vicina al team che si occupa di far sì che il gruppo di developer sia in grado di auto organizzarsi migliorandosi gradualmente; rimuove gli ostacoli che possono rallentare il team di sviluppo e gestisce e facilita gli eventi SCRUM, routine che fanno parte degli sprint.
Anche il team di sviluppatori ha una collocazione e una consapevolezza diversaperché si interfaccia in misura maggiore con gli stakeholder. I developer si confrontano con il product owner e il cliente per raffinare i task, che devono essere chiari, piccoli e realizzabili in uno sprint. Sempre insieme al product owner, il gruppo contratta l’incremento di prodotto che è possibile consegnare. Dall’altro lato, cresce il livello di responsabilità: gli sviluppatori devono essere in grado di auto organizzarsi per decidere come consegnare l’incremento contrattato, di tracciare il proprio avanzamento giornaliero verso l’obiettivo dello sprint, di assicurare che il prodotto rimanga solido e che possa essere rifattorizzato facilmente. In sintesi in SCRUM Il team è il modo migliore per rispondere alla complessità di un progetto perché i suoi membri hanno obiettivi, valori e priorità comuni e sono in grado di lavorare in sinergia.
Tutti e tre i soggetti descritti sopra si interfacciano quotidianamente tra di loro e si rapportano direttamente con il cliente.
EVENTI SCRUM
Lo sprint è cadenzato dai cosiddetti eventi, momenti durante i quali il team si confronta, condivide necessità e pianifica. Ve ne sono quattro:
- Il planning
è il più importante perché è in questo momento che il team organizza, insieme allo scrum master e al product owner, il lavoro per l’intervallo di riferimento. Nella prima fase il product owner informa il gruppo su quali sono le user stories che si desidera includere nella pianificazione, spiegandole dal punto di vista funzionale.
Dopo aver fugato eventuali dubbi, il gruppo le scompone in task, analizza il backlog e decide quanti e quali task è in grado di portare a termine durante lo sprint e come farlo. L’obiettivo è assicurare un incremento di prodotto che sia di valore anche per il cliente. - Il daily SCRUM
anche chiamato stand up, è un incontro quotidiano, della durata di pochi minuti, durante il quale gli sviluppatori si confrontano sui task in carico. Ciascuno dei membri del team spiega brevemente di cosa si è occupato il giorno precedente, cosa farà per la giornata lavorativa in corso e chiarirà se ci sono eventuali issue che gli impediscono di concludere i task di cui si sta occupando. - Retrospettiva
La retrospettiva è un momento al quale partecipano tutti i componenti del team ed è dedicato al miglioramento del modo di lavorare. Durante la riunione tutti i membri, inclusi scrum master e product owner, sono chiamati ad esprimersi su cosa è andato bene nello sprint appena concluso, cosa è migliorabile e cosa è andato male. I temi affrontati nella retrospettiva possono essere diversi: si spazia dagli strumenti di lavoro, al team, alla produttività. - Review
La review è un incontro tecnico durante il quale vengono analizzate le feature sviluppate nell’ultimo sprint. Una per una, il gruppo affronta tutte le user stories incluse nello sprint backlog e dimostra al product owner quanto realizzato. Compito del product owner è verificare che il team abbia completato tutti i task che compongono le storie e, in caso di esito positivo, le valida.
Questa è, in sintesi, la teoria. L’applicazione pratica è più complessa: adottare il metodo SCRUM significa ristrutturare completamente il modo di lavorare del reparto sviluppo. Il framework è ideale per le start up e in generale le product company perché permette di andare in profondità, lavorando su un unico progetto in evoluzione; mentre nel caso di aziende che gestiscono più progetti in parallelo si rischia di frammentare il lavoro e di perdere di vista gli obiettivi.
Per questo motivo alcune imprese preferiscono utilizzare Kanban, che permette di organizzare un flusso di lavoro continuo. Dall’altro lato, però, questo metodo ha i suoi difetti: nonostante sia di più facile applicazione, con Kanban non è possibile misurare le performance del gruppo.
In conclusione, più semplice non è sinonimo di migliore. Il vantaggio di SCRUM è maggiore perché permette di procedere verso il miglioramento costante, di avere delle metriche sulla capacity aziendale e di evitare di sovraccaricare il singolo sviluppatore e il team. Inoltre gli eventi SCRUM come planning e retrospettiva aiutano i membri del gruppo ad tenere il punto della situazione, ad essere consapevoli dell'evoluzione di un progetto e dei possibili miglioramenti a livello di teamwork.
SCRUM richiede diverso tempo per poter essere applicato correttamente. Una soluzione possibile è quella di utilizzare solo alcuni elementi proposti dal framework oppure, come facciamo in Nephila, si possono utilizzare dei correttivi. Nel prossimo post vedremo nel dettaglio alcuni esperimenti Agile che abbiamo intrapreso in azienda, continuate a seguirci!