Dopo aver visto fonti e risorse adatte a chi vuole affrontare lo studio di Scrum, con questo articolo entriamo nel concreto iniziando con questa puntata della serie, ad entrare dentro i concetti base di Scrum. Questo mese proponiamo una rapida panoramica dei concetti fondamentali in modo da preparare il terreno ai vari approfondimenti che seguiranno nei prossimi mesi.
Introduzione al framework scrum
Scrum è una “infrastruttura” agile per lo sviluppo del software: è iterativo e incrementale, ed è stato messo a punto per gestire progetti e prodotti software. Gli “inventori” di Scrum sono Ken Schwaber e Jeff Sutherland. Gli autori affermano [1] che: “Scrum è un framework di processo utilizzato dai primi anni 1990 per gestire lo sviluppo di prodotti complessi. Scrum non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l’efficacia relativa del tuo product management e delle pratiche di sviluppo usate in modo da poterle migliorare.”
Anche se Scrum può apparire semplice da implementare, in realtà è necessario mettere in pratica un profondo processo di trasformazione sia della mentalità che del modo di agire. Per chi è abituato a lavorare con le metodologie classiche, waterfall o RUP, sicuramente il passaggio alle metodologie agili come Scrum richiede un duplice sforzo: da un lato è necessario sicuramente comprendere le pratiche e le tecniche necessarie per poter padroneggiare con successo la metodologia. Dall’altro è necessario un radicale cambiamento di mentalità per comprendere nel profondo i motivi di determinate scelte. Sicuramente un primo passo utile per procedere in questo percorso è la comprensione e condivisione dei valori su cui Scrum stesso si basa.
I valori di Scrum
Come detto, tecniche e pratiche che si fanno in Scrum devono avere un fondamento “teorico” e anche “etico”: ci sono dei princìpi e dei valori che saranno condivisi dal team di sviluppo. Senza questi valori, si rischia una implementazione meccanica, che porta poco lontano; va anche detto che il lavoro in squadra insito in Scrum contribuisce a rafforzare tali valori, che non appaiono quindi come imposti dall’alto, ma come princìpi condivisi e accettati mutualmente da tutto il personale coinvolto nello sviluppo.
I valori sono “concentrazione”, “coraggio”, “apertura”, “impegno” e “rispetto”. Vediamo in cosa consistono.
Concentrazione (focus)
Per lavorare bene, bisogna concentrarsi solo su poche cose alla volta. Lavorare in squadra, concentrandosi su pochi elementi, migliora anche i tempi di consegna.
Coraggio (courage)
Lavorare in squadra, e non da soli, presuppone il sostegno dei compagni: avere il supporto e riconoscere negli altri membri delle risorse dà il coraggio per affrontare compiti impegnativi.
Apertura (openness)
Lavorare in squadra presuppone che tutti si aprano agli altri membri del team, spiegando ciò che si sta facendo e gli eventuali problemi che si incontrano. Si comprende che, pur senza lamentarsi, è bene esprimere eventuali fondate preoccupazioni, in maniera tale che possano essere affrontate e risolte in gruppo.
Impegno (commitment)
Ciascuno è artefice del suo destino: per avere un controllo maggiore sulle nostre azioni e per raggiungere gli scopi prefissimi, è necessario un impegno, che è impegno verso la buona riuscita.
Rispetto (respect)
Occorre rispettarsi vicendevolmente, e aiutarsi tutti a essere sempre più “rispettabili”: lavorando insieme, si “vince” e si perde “insieme” e il rispetto è anche una conseguenza della presa di coscienza di questo fatto.
Il cambiamento è benvenuto
Rispetto alle metodologie tradizionali, una delle differenze più evidenti che troviamo in Scrum (ma anche in altre metodologie agili) risiede nel diverso approccio con cui si vuole gestire e pianificare un progetto o lo sviluppo di un prodotto. In un tipico approccio tradizionale, per esempio waterfall, la sequenza delle operazioni da compiere per poter arrivare al prodotto finito è già precisamente definita e normata: si analizza il dominio, si pianificano tempi e costi, si progetta, si implementa e si conclude. Questo approccio si basa sul presupposto che il processo di produzione in esame sia smontabile in sottoparti, e che la somma delle singole fasi, porterà al completamento del prodotto.
Domini semplici
Questo modo di concepire il lavoro, che potremmo definire deterministico, si adatta bene a contesti dove il livello di complessità è basso: secondo il modello Cynefin siamo nel primo quadrante (dominio semplice) o al massimo nel secondo (complicato), dove è plausibile tentare di definire un processo di lavorazione e applicarlo indefinitamente: il risultato ottenuto ad ogni applicazione di tale processo è paragonabile e di fatto costante.
Si pensi per esempio al processo di assemblaggio di un oggetto semplice (un pennarello, una bottiglia o altri oggetti simili), processo in cui si può immaginare di costruire una macchina che assembli il pezzo e progettare intorno a tale macchina un processo (dall’approvvigionamento dei pezzi alla consegna alla distribuzione) che sia sempre lo stesso.
In questo contesto (che potremmo definire di produzione industriale a catena o di massa) la realizzazione di n unità di prodotto è funzione del tempo (per produrre n pezzi impiego n * tempo di produzione di un pezzo). Viceversa posso sapere quanti pezzi posso realizzare in un determinato lasso di tempo.
Figura 1 – In un processo deterministico si può sempre calcolare quanto il sistema produrrà, in quali tempi e in che numero.
Per il management, in un processo di questo tipo, la qualità si misura solo in base ai pezzi prodotti: più se ne possono produrre, più se ne possono vendere. A conferma di ciò possiamo dire che siamo al massimo nel dominio del “complicato” dove, tutto sommato, le cose sono comunque comprensibili ed è possibile gestire e prevedere.
Teorie della complessità
Purtroppo, sviluppare software, come molte altre attività umane, è un tipo di produzione con un livello di complessità maggiore (si parla appunto di dominio complesso). In un ambito complesso, gli elementi in gioco sono tanti e tali per cui causa ed effetto non sono più direttamente ricavabili.
In un contesto di questo tipo, impiegare molto tempo in lunghe pianificazioni prima di procedere con la parte di produzione è molto meno utile, e questo per due semplici ragioni: a causa dell’elevato numero di variabili che possono condizionare il sistema, risulta all’atto pratico impossibile trovare la “formula” o più precisamente il modello che descriva il funzionamento del sistema e che consenta quindi di fare previsioni o anche semplicemente di regolarne il comportamento. Per esempio è piuttosto ovvio quanto possa essere difficile, se non impossibile, trovare la regola che determini l’umore di una persona in base agli eventi, a tutti gli eventi vissuti dalla persona in oggetto, direttamente e non, dalla nascita a un istante prima della previsione.
Il secondo motivo per cui è praticamente impossibile modellare un sistema di questo genere, è legato al fatto che il sistema cambia continuamente. Il sistema cambia sia per il mutare degli influssi delle innumerevoli variabili che vi insistono, ma cambia anche perche’ in genere un sistema complesso è cortocircuitato: gli effetti del suo comportamento vanno a influire sul sistema stesso, alterandone in modo retrodinamico il comportamento. Infine il fatto stesso che si provi a misurare un sistema complesso, influisce sul suo comportamento: per assurdo, se voglio sapere come si comporta, devo “sondarlo”, ma l’operazione di sondaggio ne cambia il corso, rendendo meno affidabile ogni dato precedentemente ricavato.
Il cambiamento ha un costo
Volendo per un momento lasciare gli studi sulla complessità, potremmo semplificare il ragionamento, considerando il diagramma di figura 2, il quale ci offre un punto di vista leggermente differente.
Figura 2 – Il cambiamento costa. In uno scenario complesso, più si cerca di prevedere il futuro lavorando di pianificazione, più il cambiamento avrà un impatto sui costi.
Si immagini infatti di partire dall’assunto che ogni cambiamento in corso d’opera nella realizzazione di un prodotto software sia costoso. Per questo si potrebbe essere portati a cercare di ridurre il rischio derivante dall’incertezza e quindi cercare di trovare una definizione quanto più precisa possibile del sistema; in altre parole spendere più tempo (= soldi) possibile per analizzare e pianificare prima di agire.
Passando alla fase implementativa, dato che il cambiamento arriva, ci si rende conto che il lavoro fatto in fase di analisi è in certi casi inutile o semplicemente ha dato risultati errati. Quindi, a maggior ragione, il cambiamento costa. Ma costa non in quanto tale, ma proprio per il lavoro di preparazione che diventa inutile. Secondo questa spiegazione, parrebbe che non vi sia scampo; nessun modello organizzativo può porsi contro il cambiamento. Nulla può prevedere e quindi gestire il cambiamento.
Adattarsi ai cambiamenti
In realtà qualcosa si può fare, e in certi casi con ottimi risultati: le metodologie agili si pongono esattamente questo obiettivo. Tramite un radicale cambiamento di mentalità, si cerca infatti di “entrare” direttamene dentro il sistema, lavorandoci da dentro, senza lunghe e dispendiose (e per come si è visto inutili) operazioni di pre-analisi.
Con Scrum per esempio si predilige l’approccio pragmatico: faccio un piccolo pezzo di lavoro ed eseguo quanto prima una verifica per capire se mi sto muovendo nella direzione corretta. Ogni errore o ogni cosa fatta nel modo giusto, servono per correggere la rotta o per confermare che la direzione è quella esatta.
Il tipo di approccio è quello raccontato in un articolo precedente [2], in cui si racconta la storia dello sciatore estremo che scende dalla montagna. Impossibile pianificare ogni passaggio su crinali inesplorati e pericolosi. Si conosce la posizione dell’obiettivo finale ma non si può sapere a priori cosa ci aspetta dopo una curva o un dosso di neve fresca. Si può fare soltanto una pianificazione di massima, ma solo adottando un approccio dinamico e aperto al cambiamento, si potrà modificare la rotta (nel caso di un progetto, l’insieme delle cose da fare) e arrivare sani e salvi alla meta.
Scrum una metodologia adattiva
Un buon punto di partenza per comprendere il funzionamento del framework Scrum è iniziare col vedere come si procede verso la realizzazione del prodotto finito. Prima di tutto il calendario e la cadenza: il lavoro del team viene suddiviso in iterazioni (dette sprint), le quali rappresentano un lasso temporale ben preciso, con un inizio e una fine fissati: la dimensione della iterazione e la sua cadenza, dovrebbero rimanere più costanti possibili.
Iterazioni
Normalmente, almeno nei paesi occidentali, ogni sprint è sincronizzato con il calendario o con le abitudini del team; spesso le iterazioni iniziano il lunedì e terminano di venerdi. Per quanto concerne la lunghezza del singolo sprint, si può variare da 1 settimana a un massimo di 4 (si sconsiglia, quasi si vieta, di superare le 4 settimane); nella maggior parte dei casi si utilizzano iterazioni di due settimane di calendario (10 gg lavorativi).
Incrementi
In Scrum il prodotto finale viene realizzato in modo incrementale, lavorando pezzo per pezzo alle varie funzionalità: queste sono quindi ordinate secondo la priorità con la quale si desidera che siano implementate.
Si utilizza per questo una struttura a pila o stack che prende il nome di Product Backlog: gli elementi che stanno in alto sono quelli che verranno prelevati e implementati per primi, e sono quindi caratterizzati dall’avere una dimensione (o grana) opportuna, in modo che il team possa implementarli prima della fine dello sprint.
In basso nella pila invece sono presenti elementi (funzionalità, pezzi di sistema, macrocomponenti) che sono più grossi e per i quali quindi è necessario un ulteriore processo di raffinamento prima che siano messi in lavorazione.
Il processo di lavorazione che punta a diminuire la grana degli elementi del backlog si chiama grooming o più semplicemente “raffinamento”. Rappresenta un passaggio molto importante che vedremo nel dettaglio quando affronteremo questo tema.
Figura 3 – Il Product Backlog (PB) è una pila di elementi che verranno implementati dal team. In alto elementi raffinati sono della dimensione giusta per permetterne la lavorazione. In basso invece elementi più grossi rappresentano funzionalità o parti del sistema a grana grossa [3].
Quando si decide che la lavorazione di un elemento è conclusa, si assume che tale elemento sia completo in tutte le sue parti, che sia finito e funzionante, privo di bug, pronto per essere potenzialmente messo in produzione. Questa è una delle poche regole su cui il processo Scrum si basa e su cui non si può prescindere. In gergo si dice che il pezzo è Done Done (“finito finito”).
Product Backlog e Task
Per semplificare la lavorazione, ogni elemento del PB potrà essere scomposto in sottoattività (in gergo, task); la lavorazione dell’elemento viene effettuata grazie alla sequenza dei task che lo compongono: questa suddivisione porta in alcun casi a qualcosa che può somigliare a una specie di “miniwaterfall”.
La decisione sul quanto fare e come fare delle varie attività di analisi o design o implementazione è comunque a carico del team. Per alcuni elementi del PB si potrebbe semplicemente limitarsi a definire due linee guida e passare alla implementazione. In altri casi potrebbero essere necessarie approfondite indagini col cliente o con un esperto di dominio, e dettagliati diagrammi UML, prima di passare alla fase di scrittura del codice.
In altri casi ancora i task corrispondono ad attività più o meno verticali: implementazione della parte di persistenza, definizione dello schema del DataBase e così via. Indipendentemente dal modo in cui il team decide di implementare le singole parti, è importante tenere bene a mente che si tratta di un processo empirico non deterministico, anche se, in alcuni passaggi, nel piccolo, può essere realizzato tramite un approccio deterministico.
Sprint Review
A questo punto, per essere certi che il lavoro fatto sia non solo funzionante, ma anche corrispondente alle esigenze del committente/utente, si esegue una vera e propria demo con il committente (o un suo rappresentante), il quale valuterà entrambi gli aspetti: se quanto fatto è quello che aveva chiesto e se funziona correttamente come ci si aspettava. Questa attività si chiama Sprint Review o Sprint Demo.
La demo viene fatta dal team al committente o meglio a un suo rappresentante. Scrum prevede un ruolo ben preciso per questa figura: il Product Owner (PO). Questa è una delle figure più importanti di Scrum, essendo il solo responsabile di quali cose debbano essere svolte e del funzionamento delle parti che il team implementa. Il team di sviluppo (DevTeam) non ha alcun potere sul cosa, ma ha totale controllo sul come tali parti debbano essere implementate.
Per poter quindi definire il set delle cose da fare il PO svolge un lavoro di preparazione prima che lo sprint abbia inizio, e presenta i suoi desiderata in una riunione che avviene in presenza di tutti i componenti del team di sviluppo (più lo Scrum Master, figura di cui non si è ancora parlato). Tale riunione avviene sempre all’inizio dello sprint e si chiama Sprint Planning: è probabilmente uno dei momenti più importanti e critici, visto che è legato a quello che il team farà (quante cose) e quindi di fatto è legato alla velocità di lavorazione del team.
Scrum per punti
Quindi, sebbene in modo estremamente rapido, abbiamo visto i concetti principali di Scrum, quelli che saranno oggetto, uno per uno, di approfondimenti specifici nei prossimi articoli di questa serie. Nell’elenco che segue, possiamo elencare in modo sintetico gli elementi e i ruoli presenti in Scrum.
Scomposizione e User Stories
In un progetto Scrum si lavora per la realizzazione di un prodotto tramite la scomposizione del prodotto complessivo in sottoparti. Tali parti verranno realizzate dal team in modo indipendente le une dalle altre. Il modo con cui è organizzato lo sviluppo di tali parti è lasciato alla discrezione del team. Nella maggior parte dei casi si utilizza il formato delle User Stories, perche’ si sposa bene con la filosofia incrementale di Scrum, ma si potrebbero usare gli Use Case o altri formati.
Product Backlog
La ToDo list delle cose da fare in Scrum è una pila ordinata detta Product Backlog (PB). Le componenti del PB sono dette Product Backlog Items (PBI). Il PB è ordinato in modo che le “cose” che stanno in alto saranno implementate prima di quelle che sono in basso. La dimensione degli item in alto è piccola in modo che il team possa prelevarle e implementarle in uno sprint.
Sprint
Il lavoro è organizzato in iterazioni o Sprint; in ogni Sprint il team di sviluppo esegue del lavoro implementando delle “cose” prelevate da un elenco delle cose da fare. Per massimizzare il numero di confronti fra il team e il committente e quindi avere la migliore percezione che il lavoro sia esattamente quello richiesto, gli sprint devono essere brevi.
Organizzazione delle iterazioni
Ogni iterazione comincia sempre con una pianificazione e termina con un controllo. Il check deve essere costante (nulla deve passare inosservato) e frequente. La durata degli sprint infatti deve essere commisurata alle esigenze del team, del progetto, del cliente. La sola regola che Scrum impone è che non si superino le 4 settimane di lavoro per Sprint; la lunghezza che mediamente si adotta (specialmente con team alle prime armi) è quella delle due settimane. Controlli costanti e frequenti e uso di iterazioni brevi sono i presupposti che consentono di portare a termine il progetto senza necessità di una lunga e dispendiosa fase di preanalisi e progettazione.
Retrospettiva
Accanto alla operazione di demo (Sprint Review), al termine di ogni iterazione il gruppo di sviluppo (normalmente senza il Product Owner, vedi sotto) esegue una attività di retroanalisi in modo da valutare errori nello svolgimento del lavoro effettuato. In questa fase, detta Sprint Retrospective, si effettua quindi non una valutazione del prodotto completato (la si fa nella Sprint Review), ma una valutazione retrospettiva del come si è lavorato, degli errori commessi e degli impedimenti incontrati: si compie, quindi, una valutazione del processo o, per essere ancor più precisi, del modo in cui il processo è stato implementato. È grazie a questo controllo costante e frequente che il team è in grado di migliorare il proprio lavoro e di diventare sempre più performante. Le tecniche di retrospettiva sono diverse a seconda del tipo di problemi incontrati o delle necessità del team. Quando affronteremo nel dettaglio questo tema, presenteremo le varie possibili tecniche adatte alle diverse situazioni.
Il framework prevede la definizione di tre ruoli precisi: il Product Owner, lo Scrum Master, il Dev Team.
Product Owner
Il PO è il rappresentante in tutto e per tutto del committente del progetto. Sa cosa deve essere fatto, quali funzionalità compongono il prodotto finale, conosce esigenze e desideri dell’utente. Il PO ha la responsabilità ultima di decidere cosa deve essere fatto, ma non come.
Dev team
Il development team è il gruppo di sviluppo che svolge il lavoro di implementazione. Lavora a stretto contatto con il PO (ma anche con tutti gli altri potenziali stakeholder) per comprendere al meglio i dettagli dell’implementazione. Decide come implementare (scelte tecniche, architettura, dettagli implementativi) ma non può in alcun modo interferire sul cosa debba essere realizzato (in carico al PO).
Scrum Master
Lo Scrum Master è una figura che non abbiamo ancora introdotto. Per il momento possiamo dire che lo SM ha il compito di fare in modo che tutti i partecipanti al progetto possano svolgere al meglio il loro lavoro. Il suo è un compito di “facilitatore” volto a eliminare ogni impedimento e a ridurre tempi morti o rallentamenti. Una definizione molto usata è quella di servant leader, anche se per certi versi questa può dare una visione distorta. Una recentissima nuova visione del SM lo definisce come l’ospite che organizza una festa a casa propria e che quindi si preoccupa che tutto sia al suo posto in modo che tutti gli invitati possano divertirsi. Sarà accogliente e amichevole ma al tempo stesso è colui che detta le regole se qualcuno dovesse uscire dai limiti imposti. In questo senso lo SM è l’owner del processo, ossia colui che verifica che si seguano le regole definite da Scrum.
Produttività attraverso l’adattamento
Per come è organizzato, il processo di lavorazione di Scrum risponde in pieno a uno dei requisiti tipici delle metodologie agili: evitare una lunga e dispendiosa fase di pre-analisi che non porterebbe alcun vantaggio evidente. Scrum invece spinge a iniziare la fase di produzione preceduta solo da una rapida pianificazione di massima.
Questo approccio è fondamentale per garantire la riduzione degli sprechi e massimizza invece la produttività e il valore atteso dal committente. In questo caso, per spreco, si intende sia il tempo perso in lunghe e poco attendibili attività di analisi, sia la realizzazione di pezzi di prodotto non rispondenti alle reali esigenze dell’utente.
Massimizzare il valore atteso invece vuol dire lavorare in modo estremamente focalizzato sulle reali esigenze di chi ci ha chiesto il lavoro, eliminando da una parte le cose non richieste o non necessarie, dall’altra riducendo al minimo i fraintendimenti che porterebbero alla realizzazione di cose non richieste.
Questi risultati si ottengono grazie a frequenti controlli degli stati di avanzamento: breve pianificazione prima dell’inizio degli Sprint e demo al completamento degli stessi, che sono per questo motivo sempre mantenuti piccoli. Il Product Backlog fa sì che, per ogni elemento, il DevTeam esegua quelle operazioni di analisi e implementazione necessarie per passare dalla definizione dei requisiti alla messa in produzione della funzionalità corrispondente.
Aggiustamenti di rotta grazie al Product Backlog
Potendo seguire un approccio incrementale, ad ogni step si effettua quindi un controllo sia del lavoro fatto, sia della correttezza delle scelte fatte. Se in un qualsiasi momento si dovesse verificare un cambio di rotta, il processo permette di assorbire il cambiamento in modo indolore. Se, per esempio, si scoprono nuove funzionalità non previste in origine, queste potranno essere aggiunte all’elenco delle funzionalità da implementare senza che questo sconvolga i piani del resto del progetto. Parimenti, se invece ci si dovesse rendere conto che alcune funzioni pianificate per una prossima iterazione non sono più necessarie, queste potranno essere rimosse dai PBI senza che questo sconvolga i piani del gruppo di lavoro.
Dato che il PB è sempre ordinato in modo prioritario, si ha la certezza che per ogni modifica (aggiunta o rimozione) il team lavorerà sempre prima sulle cose più importanti e necessarie, quelle che danno valore al prodotto dal punto di vista dell’utente.
Conclusione: valore per il cliente
Concludiamo con una considerazione importante: analizzando molti dei punti fin qui accennati, da quelli con cui si definisce l’ordine all’interno del backlog, alla scelta delle storie da implementare, al modo con cui viene eseguita una demo, si capisce che tutto in Scrum è finalizzato alla implementazione di “manufatti” (funzionalità rilasciate e funzionanti, documentazione, altre cose necessarie) che siano di valore per il cliente finale. Per questo ogni cosa non necessaria, non richiesta o non apprezzabile per il cliente, deve essere eliminata dall’elenco delle cose non fatte.
Nelle prossime puntate della serie avremo modo di vedere come questa filosofia viene implementata nella pratica, analizzando nei dettagli gli elementi di cui abbiamo parlato nel complesso in questo articolo.
Riferimenti
[1] Ken Schwaber – Jeff Sutherland, “La Guida a Scrum™”
[2] Giovanni Puliti, “Verso l’Agile – II parte: Miti, fatti e pianificazione”, MokaByte 189 – Novembre 2013
https://www.mokabyte.it/cms/article.run?articleId=S6J-QCM-7YV-4GY_7f000001_11231952_6cdbbe92
[3] Visual AGILExicon® Overview.
K. Rubin, autore del libro “Essential Scrum”, ha dato vita a un progetto che contiene un insieme di immagini utilizzate per la sua opera, e che consente il riutilizzo di tali immagini con una precisa licenza. Anche in questi articoli ci appoggeremo a tali repertori grafici, proprio per mantenere un linguaggio comune e conosciuto ai molti lettori del libro.