Master Universitario di II livello in Management, Innovazione e Ingegneria dei servizi – MAINS
Anno Accademico
2016/2017
SCRUM e le Metodologie Agile:
l’alternativa all’approccio
tradizionale di sviluppo Software
Autore
Dott.ssa DANIELA VITALE
Tutor Scientifico
Prof. MATTEO VIGNOLI
1
Indice
1. Introduzione
2. La disciplina del Project Management
2.1 Il PM e gli obiettivi S.M.A.R.T
3. Il Visual Management: cenni
4. L’avvento delle Metodologie Agile
4.1 La nascita dell’Agile
5. Scrum: bilanciare la qualità con il tempo
5.1 I Ruoli 5.2 Le Cerimonie 5.3 Gli Artefatti
6. Un processo Iterativo ed Incrementale
7. Alcuni dei vantaggi pratici di Scrum
7.1 Requisiti
7.2 Individuazione bug e Testing 7.3 Comunicazione
8. Osservazioni conclusive
2
I. Introduzione
Nell’attuale contesto di mercato, in particolare nel settore IT, sempre più effervescente e iper-concorrenziale, per ottenere un posizionamento strategico ed un vantaggio competitivo è ineludibile possedere e dimostrare capacità di evolversi e adattarsi rapidamente alle mutevoli situazioni che possono presentarsi.
Le aziende, grandi o piccole, potenze globalmente riconosciute o acerbe realtà che si affacciano ora sulla scena, hanno tutte davanti lo stesso scenario: un mondo, quello tecnologico ma non solo, in continua mutazione e soggetto a vorticosi sviluppi, progetti forse di più breve respiro, ma sempre più complessi e utenti maggiormente consapevoli del loro “potere” e quindi esigenti nelle richieste.
Allo stesso tempo, le realtà di business che si trovano in questo contesto, hanno anche il medesimo obiettivo di fondo: sopravvivere e non rimanere indietro, non lasciarsi travolgere dalla feroce competizione. In poche parole, continuare a produrre profitto.
Nell’era di Internet, il software development è diventato oggi parte integrante di ogni aspetto/prospettiva di Business.
Nel momento in cui i consumers domandano sempre più immediatezza e convenienza, le aziende sentono una forte pressione nell’introdurre servizi web-based alla base dell’offerta dei loro prodotti.
Allo stesso modo, un numero crescente di risorse vengono allocate verso lo sviluppo di software profittevoli tali da incontrare coerentemente i bisogni e i desideri dei clienti o utenti finali. Le aziende, come appena sottolineato, desiderano massimizzare i profitti e, di conseguenza, una allocazione efficiente di tali risorse risulta indispensabile per minimizzare i costi.
La strategia di massimizzare i profitti anche minimizzando i costi, può essere sviluppata implementando un process model capace di convertire al meglio le risorse a disposizione in prodotti ad alta qualità.
In base a questo scenario si è compiuto il processo di cambiamento nelle regole del project management, in particolare indirizzandosi allo scopo ultimo principale e ineludibile della riduzione dei rischi e dei costi di produzione: in tal modo si è fatto strada e si è imposto il
3 lavoro, non appena verrà fornito un quadro sintetico ma quanto più possibile esaustivo degli eventi anticipatori dell’avvento dell’Agile.
Il cambiamento sistematico come regola costitutiva mette in discussione gli stessi principi teorici su cui si basa il Project Managament, inteso quale processo di gestione integrata di un progetto dall’inizio alla fine, mediante l’allocazione, l’utilizzo e il monitoraggio di risorse (limitate) al fine di rispettare i requisiti (del progetto) in un arco di tempo predefinito.
Ciò in quanto obbliga le aziende ad operare in un contesto di mercato in cui i clienti si aspettano prodotti finiti sempre più veloci, economici ma allo stesso di elevata qualità e che, di conseguenza, richiedono una sistematica e continua ri-focalizzazione sugli obiettivi, una capacità costante di adeguarsi a cambiamenti spesso imprevedibili fino all’ultimo. Insomma, al mutare del contesto in cui si muovono le imprese IT, muta anche il concetto stesso di progetto e della sua gestione.
Nell’ultimo decennio, infatti, le metodologie tradizionali di Project management si sono rivelate spesso inefficaci nel garantire il successo, in termini di tempi e risorse, umane economiche e materiali, per un vasto numero di progetti, in particolare quelli che implicavano l’uso di nuove e complesse tecnologie.
Questa evidenza ha generato una spinta verso il cambiamento, volta a promuovere l’adozione e la diffusione, all’interno dell’azienda, di nuove tecniche e di nuove metodologie per lo sviluppo, l’amministrazione e la gestione non solo dei progetti, ma anche dei relativi team. Obiettivo di questo lavoro sarò proprio rivivere, nello spazio concesso, il cambiamento di rotta in atto nel Project Management, in particolar modo mostrando come le metodologie fino a pochi anni fa più perseguite e indiscusse, prima fra tutte la waterfall, stiano perdendo parte della loro efficacia e stiano lasciando il posto a metodologie diverse: le metodologie Agile.
Tutto il contenuto di questo elaborato avrà come punto di riferimento le realtà di business che operano in settori tecnologici e digitali; dunque, come vedremo, l’introduzione a specifiche metodologie assumerà un significato preciso e ben definito proprio in quanto applicate ad un particolare tipo di progetto, quello legato allo sviluppo software.
Tali metodologie - note appunto come Agile - hanno quale scopo comune incrementare la produttività, l’efficienza e la trasparenza del gruppo di lavoro, mediante l’introduzione di un notevole cambio di paradigma nella gestione delle risorse di progetto.
4 Dopo una prima parte teorica e contestuale, ci si calerà in un contesto più specifico, per vedere più nel concreto cosa vuol dire per una azienda di consulenza IT introdurre le metodologie agile all’interno dei suoi progetti, quali sono i tools più diffusi ed efficaci e quali le prime evidenze dei benefici ottenuti dopo un mutamento, talora radicale, del metodo di lavoro e di gestione dell’intero ciclo di vita del progetto.
L’intento non è proclamare le metodologie Agile panacea per tutti i problemi e le criticità cui è sottoposto il project manager di progetti IT e il suo team di sviluppo, arrivando a sostenere indiscriminatamente l’applicazione di queste a tutti i tipi di progetti, quanto piuttosto di comprendere meglio come questa nuova filosofia organizzativa e gestionale si concretizzi praticamente e come questo nuovo paradigma abbia poi effetti sulle strategie aziendali e sulla cultura stessa del business.
Certo è che, garantendo prontezza e rapida capacità di risposta, queste metodologia risulta calzare a pennello con le caratteristiche di un progetto di sviluppo software, per permettere alle aziende di governare nel miglior modo possibile l’alta variabile del rischio che predomina in questo e in tanti altri settori, sempre nella consapevolezza che il rischio di un progetto non potrà mai essere estirpato del tutto.
Si partirà da un accenno teorico alle pratiche di PM, qualche accenno storico e l’introduzione alle sue metodologie, in particolare la waterfall, ad oggi ancora tra le più utilizzate.
Nel proseguire, si passerà alle metodologie Agile, tentando di evidenziare perché il loro successo non accenna ad arrestarsi e quali sono le principali differenze con le prime.
5
II. La Disciplina del Project Management
Ogni organizzazione, di qualunque natura ed entità, lavora per portare a termine un progetto. Secondo la nota definizione contenuta nel testo PMBOK GUIDE1, un progetto si identifica come una “iniziativa temporanea intrapresa per creare un prodotto o un servizio univoco”. In sostanza, si tratta di uno sforzo complesso portato avanti da uno specifico gruppo di persone, non necessariamente appartenenti alla medesima organizzazione, che comporta il raggiungimento di determinati obiettivi tramite schedulazioni e budget ben definiti. Caratteristica importante, è che tutti gli attori coinvolti nella gestione e realizzazione del progetto hanno, o dovrebbero avere, il medesimo obiettivo, il quale deve essere sin dall’inizio chiaro e efficacemente comunicato/condiviso.
Come da definizione, il progetto è considerato “temporaneo” in quanto esso ha un inizio e una fine individuabili: la fine si raggiunge quando gli obiettivi vengono raggiunti, quando non è più possibile perseguirli o quando non sussiste più l’esigenza di realizzare il progetto. Ogni progetto termina al raggiungimento degli obiettivi preposti.
L’output finale del progetto è considerato unico poiché non possono coesistere due progetti atti a realizzare lo stesso identico prodotto o servizio. Ciascun progetto è unico sia dal punto di vista delle risorse necessarie ad attuarlo, sia delle circostanze e fattori esterni che inevitabilmente vanno ad impattare il suo naturale percorso.
Un progetto ha 3 vincoli fondamentali tra loro in competizione: - qualità/prestazioni; - tempo; - costo. Queste variabili determinano un qualsiasi progetto, indipendentemente dal settore e dall’organizzazione nel quale si radica e sviluppa, e rappresentano i vincoli del progetto. Un altro elemento che sicuramente hanno in comune tutti i tipi di progetto è costituito dalle fasi che ne costituiscono lo sviluppo: ideazione, pianificazione, realizzazione e chiusura.
Di fatto, tutti i progetti seguono un percorso più o meno strutturato in fasi distinte e successive che partono dall’idea iniziale in cui si concepisce il prodotto o servizio che si vuol realizzare, e che termina quindi con la sua effettiva realizzazione: il ciclo di vita del progetto. Lo svolgimento di ogni progetto avviene attraverso fasi definite anche e soprattutto per agevolarne l’impostazione, la gestione ed il controllo.
6 In breve, un progetto può essere visto come un processo caratterizzato da un suo ciclo di vita ben definito. Il ciclo di vita comprende due aspetti strettamente collegati tra loro, l’aspetto gestionale e l’aspetto tecnico. Mentre l’aspetto gestionale è costituito da fasi comuni a tutti i progetti, quello tecnico è specifico per ciascun settore di applicazione, dipendendo strettamente dalla tipologia di prodotto che si vuol realizzare e dalla natura delle tecnologie coinvolte. Il ciclo di vita di un progetto descrive l’insieme delle fasi che un progetto attraversa dallo stadio di analisi di fattibilità al delivery di quanto pianificato.
L’ideazione è la fase in cui si tracciano le caratteristiche principali del progetto: a partire da un’idea, si determinano gli obiettivi, i destinatari, il piano di lavoro, i prodotti, i risultati attesi, i partner, i tempi, i luoghi e le risorse. La fase di ideazione si conclude quando gli aspetti principali del progetto sono delineati e condivisi dal team di progetto. Questa fase parte da un’idea e si conclude con un documento, la scheda progetto, che riassume il contesto del progetto, i suoi elementi costitutivi e una prima stima delle risorse necessarie per realizzarlo. A questo punto si può procedere verso la fase di pianificazione. A partire dalla scheda di progetto è possibile dettagliare la struttura, la strategia, il processo e le risorse necessarie alla realizzazione del progetto. La pianificazione è la fase in cui l’idea del progetto viene analizzata in ogni suo aspetto per indicare il piano chiaro e definitivo delle attività, descrivere il suo svolgimento temporale, definire il team di progetto, stabilire il budget preventivo. Il risultato finale di questa fase è la descrizione in dettaglio del progetto che costituirà il punto di riferimento per la sua realizzazione.
La realizzazione segna il passaggio dalla definizione teorica del progetto alla sua attuazione pratica.
La realizzazione si configura come un processo di attività finalizzate a rispettare il piano previsto e a controllare che gli obiettivi del progetto vengano conseguiti. Durante questa fase, vengono compiute le attività previste dal progetto che avranno come scopo la realizzazione dei prodotti e dei servizi. Alcune di queste attività sono continue, altre ripetitive. Ad esempio, le attività di gestione, comunicazione, monitoraggio e valutazione di un progetto partono contemporaneamente al suo avvio e si estendono per tutta la sua durata. Queste sono attività comuni a tutti i progetti indipendentemente dai loro contenuti. Altre invece, si sviluppano solamente per una porzione del progetto e sono parte costituente della sua specificità e della sua originalità.
7 La chiusura: si possono distinguere due chiusure, la consegna dei prodotti, servizi realizzati e la chiusura amministrativa del progetto. Quest’ultima fase spesso viene trascurata o osservata solo per obblighi contrattuali. Invece, la verifica finale riveste un ruolo cruciale e rappresenta una vera e propria ricapitolazione dell’intero percorso fatto. In base ai risultati della verifica finale, si potrà stabilire se il progetto abbia raggiunto i risultati auspicati, cosa si dovrebbe eventualmente modificare per meglio adeguare il progetto alla realtà o per estenderlo ad altri contesti. È la fase in cui si capitalizza il lavoro svolto per il futuro. Si potrebbe dire che una chiusura ben gestita del progetto è un’ottima apertura per nuovi progetti. In questo modo si chiude il ciclo di un progetto, passando dalla chiusura di un progetto all’ideazione di un altro. In qualsiasi specifico progetto, per ragioni di dimensioni, complessità, livello di rischio e vincoli di flusso di cassa, le fasi possono essere ulteriormente suddivise in sottofasi.
Definire il ciclo di vita del progetto può aiutare il responsabile di progetto a chiarire se sia opportuno considerare lo studio di fattibilità la prima fase del progetto o un progetto distinto e autonomo, analogo discorso vale per le altre fasi del progetto.
Possiamo affermare che esistono diverse tipologie di ciclo di vita di un progetto, le quali dipendono sicuramente dal prodotto/servizio da realizzare oltre che dalla stessa cultura aziendale.
Una delle più diffuse è sicuramente quella conosciuta come “waterfall”, a cascata. Così come descritto anche nel PMBOK, l’approccio waterfall individua uno sviluppo sequenziale di fasi che descrivono da un lato il ciclo di vita di un progetto, dall’altro il ciclo del project management che ne governa lo sviluppo. Ci si soffermerà brevemente su questa tipologia perché, oltre ad essere universalmente nota e una delle più utilizzate da sempre, è anche la metodologia che spesso viene contrapposta alle metodologie più recenti oggetto del presente lavoro, quelle Agile.
8 Il modello Waterfall possiede l’indubbio vantaggio di essere concettualmente semplice grazie alla sequenzialità con cui si procede alla pianificazione del progetto, quindi alla sua attuazione e al suo controllo. L’elemento della sequenzialità caratterizza l’intero approccio dal momento in cui ciascuna fase in cui è stato suddiviso il progetto può cominciare solo se quella precedente si è conclusa, quindi quando sono state raggiunte e verificate le deliverables pianificate. In generale, si può serenamente affermare, che tale approccio sequenziale privilegia la prevenzione dei cambiamenti nell’ambito del progetto e considera la stima dei costi e dei tempi come una conseguenza delle specifiche dei deliverables. Se nella realtà fosse tutto prevedibile e privo di fattori inaspettati, questo approccio potrebbe essere applicato a ciascuna tipologia di progetto, a prescindere dalla natura del prodotto e dal settore in cui opera l’azienda. Tuttavia, le cose stanno diversamente: a causa della urgenza che incombe su ogni iniziativa, capita sovente di passare ad una fase prima del previsto, di saltarne temporaneamente una o semplicemente di modificare i piani del progetto così come si erano inizialmente accuratamente organizzati.
Si è parlato di progetto, del suo ciclo di vita e del modello Waterfall nella gestione dei progetti. Naturalmente, il quadro non può considerarsi esaurito senza aver introdotto e specificato l’attività alla base del funzionamento di un progetto: il Project Management.
Il Project Management è “l’applicazione di conoscenze, abilità, strumenti e tecniche alle attività di progetto al fine di soddisfarne i requisiti”. La persona incaricata del raggiungimento degli obiettivi di progetto nei tempi e nei costi giusti è il Project Manager. La gestione di progetto include le seguenti attività: - identificare i requisiti; - fissare obiettivi chiari e raggiungibili; - individuare il giusto equilibrio tra le esigenze di qualità, ambito, tempo e costi, che sono in competenza tra di loro; -adattare specifiche di prodotto, piani e approccio alle diverse aree di interesse e alle diverse aspettative dei vari stakeholder.
Molti dei processi del Project Management sono “iterativi” a causa dell’esistenza e della necessità dell’elaborazione progressiva in un progetto per l’intera durata del suo ciclo di vita: mano a mano che un project team approfondisce la conoscenza del progetto è anche in grado di gestirlo ad un maggiore livello di dettaglio.
9 Come si è accennato prima, nella gestione dei progetti spesso si parla di “triplo vincolo”, ossia di prestazioni/qualità, tempi e costi (Kerzner, 2013)2. Lo sforzo costante che compie il Project Manager per bilanciare questi tre fattori impatta sulla qualità del progetto. I progetti di alta qualità consegnano il prodotto, il servizio o il risultato richiesti nell’ambito stabilito, entro il tempo fissato e restando entro i limiti del budget definito. La variazione anche di uno solo dei tre fattori del triplo vincolo implica che almeno un altro fattore ne risulta influenzato.
I project manager si occupano inoltre di gestire i progetti tenendo conto anche dei rischi connessi ad esso3, ossia eventi o condizioni incerte che, se si verificano, hanno un effetto negativo su almeno uno degli obiettivi di progetto o comunque sulla performance generale dello stesso. I rischi riconociuti come minacce possono essere accettati se opportunamente controbilanciati dalla ricompensa che deriva dal correre il rischio.
A volte si parla non di rischio-minaccia ma di rischio-opportunità, nel caso in cui le conseguenze associate al suo verificarsi potrebbero rivelarsi anche, ma non sicuramente, vantaggiose. Dal momento che non tutti i rischi prevedono una risposta pronta e definita, per essere presi in considerazione è opportuno esaminarli secondo priorità. In questo senso intervengono tue tipi di analisi, una quantitativa, l’altra qualitativa. Quest’ultima consiste nel stimare la probabilità che il rischio avvenga davvero e l’impatto che esso genererà sul progetto. L’impatto che si prova ad identificare avrà conseguenze sul budget, sulla qualità e sul tempo stesso in cui si è previsto di portare a termine il progetto.
L’analisi quantitativa invece prevede l’assegnazione di un valore numerico al rischio e alle componenti appena citate. Spesso si finisce per esprimere la probabilità in percentuale (valore atteso) e l’impatto attraverso una scala formata da valori numerici pieni.
Uno strumento molto utilizzato per assegnare le priorità ai rischi in base alla combinazione dei loro indici di probabilità e impatto è appunto la matrice di probabilità e impatto, con la quale è possibile assegnare ai rischi una priorità “bassa”, “media” o “alta”.
2Project Management: A Systems Approach to Planning, Scheduling, and Controlling , H. Kerzner, 2013
3 Secondo D. van Well-Stam, “Risk Management is a cyclical process that must be repeated regularly during the course of a project. Risk Management begins with an analysis of the risks. With the aid of risk analysis, insight into the risks within a project can be gained systematically and the (effects of the) measures used to approach these risks can be evaluated”. (Project Risk Management: An Essential Tool for Managing and Controlloing Projects)
10 In definitiva, un project management di successo può essere definito come il raggiungimento degli obiettivi del progetto al livello di prestazioni/qualità desiderate, mantenendosi nei tempi e nei costi previsti e utilizzando le risorse efficientemente ed efficacemente. La qualità, detto in altri termini, è il grado con cui il progetto ottempera alle aspettative dei committenti, o clienti.
II.I Il PM e gli obiettivi S.M.A.R.T
Una fase fondamentale è quella di identificare le aspettative che hanno gli stakeholder di progetto, ad un alto livello di granularità e di dettaglio. Come spesso accade, anche nel Project Management l’obiettivo per funzionare deve essere ben definito, tanto che, un progetto o un processo i cui obiettivi rimangono vaghi e imprecisi, risulta poco funzionale.
A tal proposito, risulta particolarmente diffuso il modello dello S.M.A.R.T Criteria tra le aziende. SMART è l’acronimo, semplice ma potente, di Specific, Measurable, Attainable, Relevant e Time-Bound. Dietro questo acronimo, che sintetizza il metodo di Peter Drucker4 nel
suo noto libro The Practice of Management (1954), c’è la convinzione che se un obiettivo
4 Peter Drucker (1909-2005) è stato un economista austriaco naturalizzato statunitense considerato come uno
11 manchi solo di una delle cinque qualità appena citate, allora diventa un concetto privo di sollecitazione all’azione.
Un obiettivo che ambisce ad essere qualcosa di concreto e intelligente deve formarsi di queste 5 importanti caratteristiche:
• Specifici, dunque comprensibili a tutti gli stakeholder. Il fine che ci proponiamo deve essere specifico, chiaro e non vago. È ampiamente diffusa la consapevolezza che una delle cause principali di ritardo o addirittura fallimento del progetto, anche nel mondo dell’IT, è proprio la carenza nella qualità della comunicazione. Se un obiettivo invece risulta troppo ampio, è bene ricondurlo ad una serie di obiettivi più piccoli e più facilmente gestibili.
• Misurabili, ovvero quantificabili. L'obiettivo deve essere misurabile al fine di permettere a tutti di capire se si sta raggiungendo il risultato atteso o meno ed eventualmente, se le cose non vanno nel verso desiderato, di accrescere la consapevolezza di quanto si è lontani dalla meta finale. Obiettivi misurabili sono importanti dal momento in cui diventano delle metriche importanti per la comprensione della performance di progetto mentre esso è in corso e nel momento in cui è terminato.
• Raggiungibili, obiettivi accessibili. L'obiettivo deve essere realizzabile tenendo a mente le risorse e le capacità che l’azienda o il team ha a disposizione. È importante essere ben consapevoli della propria capacità e di quello che si può “sfruttare” e mettere a disposizione per non fissare obiettivi al di fuori delle proprie competenze e il cui raggiungimento risulta possibile solo a danno della motivazione e della stimolazione delle persone che compongono il team. In questa fase è opportuno anche conoscere le abilità e la capacity di ciascun membro del team, in termini di skills e di quantità di tempo necessaria per eseguire determinati compiti.
• Realistici. Questa caratteristica è in parte connessa a quella della raggiungibilità. Un obiettivo deve essere sufficientemente stimolante, ma anche realisticamente raggiungibile, alla portata del team ed effettivamente completato entro i tempi prospettati. Se a volte fissare obiettivi sfidanti ed eccitanti ha i suoi indubbi lati positivi, in quanto incoraggia e stimola la creatività e l’impegno di chi vi lavora, altre volte
12 esagerare sotto questo punto di vista ha come lato negativo l’indebolimento della convinzione e motivazione di chi li deve portar a termine, perché considerati, appunto, poco realistici.
• Time-Bound o Time-Related. L'obiettivo deve essere fissato nei suoi limiti temporali, cioè occorre determinare il periodo di tempo entro il quale l'obiettivo deve essere realizzato, quindi il suo inizio e fine. Ciò serve a rendere misurabile l'obiettivo stesso e soprattutto ad evitare che, mancando un riferimento temporale, qualche attività venga considerato non urgente e di conseguenza non vengano concentrati abbastanza sforzi su di essa. Per la natura stessa del tempo di essere la risorsa scarsa per eccellenza, risulta di fondamentale importanza strategica un corretto e continuo monitoraggio di esso anche durante lo svolgimento di un progetto.
III. Il Visual Management: cenni
Prima di passare alla trattazione delle metodologie Agili e, se si vuole, per cominciare a preparare il terreno, seguirà un breve paragrafo dedicato al Visual Management. Infatti, come vedremo e come si intuirà nel prosieguo della trattazione sulle metodologie agile e in particolare su Scrum, un aspetto rilevante del “nuovo” modo di approcciare i progetti e gestirli, risulta proprio il ruolo importante ricoperto dalla componente visual, ovvero la visibilità dei processi man mano che essi vanno avanti e gli strumenti dedicati a supportare queste modalità di visualizzazione.
Tradizionalmente, la disciplina del PM ha sempre attribuito maggiore importanza al controllo e alle previsioni di lungo periodo piuttosto che ad una analisi e supervisione del lavoro in corso. Tuttavia, dal momento in cui la percentuale di progetti che stentano a raggiungere i loro obiettivi nei tempi previsti si è incrementata, si è imposta una crescente esigenza di visibilità real-time sugli avanzamenti dei tasks e delle attività in generale. Il Visual Project Management, di cui si parla sempre più, è un nuovo approccio disegnato per indirizzare sfide di questa portata. Nello specifico, le aziende che hanno introdotto nei propri modelli operativi questo nuovo approccio alla gestione di progetti, hanno anche registrato una performance superiore in termini
13
di velocità ed efficienza. Per dare una definizione di Visual Project Management, se ne riporta la definizione elaborata dal suo autore, Mark Woeppel:
“Visual Project Management is a process that uses visualization of the delivery process to drive team behaviors5.”
Il visual PM, in realtà, non è altro che una strategia di PM ideata per incrementare il successo e la performance tramite la visualizzazione di tutte le componenti che costituiscono un progetto e ne scandiscono il suo ciclo di vita: come tasks tecnici, tasks funzionali, dati, bugs, milestones etc.
Soprattutto nel mondo dell’IT, il Visual PM va risultando di grande aiuto ai team di sviluppo per rimanere sincronizzati e rispondere prontamente ai requirements di cambiamento.
Le caratteristiche di questo nuovo approccio sono comunemente associate, non a caso, alle metodologie agile di sviluppo software, in particolare ai metodi noti come Scrum e Kanban. Infatti, uno dei principi del metodo KANBAN è “to visualize workflow in order to better
understand what is going on and what can be improved”.
Tra gli strumenti che entrambe le metodologie appena citate hanno in comune e che rientrano a pieno titolo nella categoria di strumenti di Visual PM, ci sono:
• Real-time dashboards
• Timelines
• Graphic reports (Gantt, burndown, etc.)
• Boards (Kanban)
• Product Roadmap
Tra i benefici che derivano da un approccio visivo alla gestione di tasks e attività che compongono un progetto, ce ne sono alcuni indiscutibili e che valgono in ogni caso, a prescindere dall’entità e la natura del progetto. Una delle utilità è sicuramente semplificare il complesso, ovvero rendere disponibile ad una persona la comprensione a prima vista della struttura generale di un progetto, vale a dire i tasks attualmente in lavorazione, quelli da iniziare e quelli completati, risparmiando di conseguenza tempo prezioso.
5 Visual Project Management: Simplifying Project Execution to Deliver On Time and On Budget , M.J. Woeppel,
14
La comunicazione tra il team è un altro aspetto che può giovarsi particolarmente di un corretto approccio “visivo” alla gestione del progetto, eliminando o riducendo gli sprechi e permettendo una veicolazione più efficace delle informazioni.
In parte connesso a quest’ultimo, il visual task management incoraggia la collaborazione tra i membri del team proprio perché ognuno può sapere facilmente chi è lo sviluppatore incaricato della lavorazione di una specifica user story e dei suoi relativi tasks. Allo stesso modo, è molto più semplice e intuitivo venire a conoscenza per tempo di eventuali impediments e predisporre le opportune azioni quando si nota che uno o più task procedono con una certa lentezza. In ultimo, ma non per ordine di importanza, è stato anche provato che quando il team può visualizzare su una board tutte le attività che compongono il progetto su cui si sta lavorando, percepisce più facilmente il senso e l’obiettivo comune che deve e dovrebbe legare tutti i diversi task di cui ognuno è singolarmente responsabile con il goal ultimo che è quello della realizzazione del prodotto.
Targetprocess, uno dei software agile utilizzato nelle aziende per gestire progetti IT e di sviluppo software, supporta grazie alle sue caratteristiche intrinseche il Visual Management: “Targetprocess merges the information visualization and project management domains for a
visual approach to project and project portfolio management6”.
Attraverso le cosiddette View (o data mode), con Targetprocess è possibile vedere i progressi e cogliere interdipendenze tra i progetti e i programmi; osservare sotto diverse e rilevanti angolature i data generati dallo sviluppo dei progetti e dai cambiamenti; condividere i dati importanti; aumentare la collaborazione permettendo a tutti di prendere decisioni più smart grazie alla totale trasparenza fruibile a tutti dalla tipologia di data mode scelta e delle informazioni da essa deducibili.
15
IV. L’avvento delle metodologie Agile
Giunti a questo punto della trattazione, ci addentriamo nell’ambito delle metodologie agile per quel che riguarda la gestione di progetti di sviluppo software.
Un primo passo va nella direzione di provare ad identificare i passaggi principali del percorso evolutivo dei framework di Project Management nella creazione e progettazione di prodotti software. Percorso evolutivo che vede un altro interessante aspetto individuabile quale causa ma allo stesso tempo effetto dei nuovi trend di PM, ovvero la riqualifica della figura dell’utente all’interno dello stesso processo di sviluppo e quindi della progressiva integrazione della metodologia di progettazione incentrata sull’utente user-centered la quale, insieme ad un mercato in continua evoluzione e cambiamento, ha inspirato e incoraggiato questi cambiamenti. Per quanto concerne la metodologia waterfall, a cascata, cui si è già fatto cenno nella prima parte del lavoro, basterà aggiungere che il primo a parlare di ciclo di vita a cascata fu Winston Royce negli anni ’70, quando si cominciò ad accostare questo framework di sviluppo e PM al mondo dell’ICT. Da quel momento, la maggior parte dei progetti di sviluppo software cominciarono ad essere elaborati utilizzando il metodo a cascata, per il quale ciascuno di essi
16 veniva completato in fasi distinte e spostato da una fase all’altra verso il rilascio definitivo agli utilizzatori. I processi spesso si dimostravano lenti e macchinosi, e sovente non si concludevano con la creazione del prodotto effettivamente desiderato dalla committenza.
Dal 1970 ad oggi, tuttavia, la metodologia di sviluppo a cascata si è notevolmente evoluta a seguito di molte critiche avanzate, in particolare nei confronti della sua natura rigida e che non prevede cicli di test iterativi e continui. Il modello è stato progressivamente abbandonato dall’industria del software, pur rimanendo un importante riferimento teorico.
La critica principale che si muove a questa metodologia è che per avere un feedback dagli utenti, qualunque errore concettuale si faccia nelle fasi iniziali, ad esempio nell’analisi dei requisiti, è necessario attendere la fase di rilascio, ripercorrendo inevitabilmente tutto il ciclo per correggerlo. Questo metodo è inoltre troppo rigido per i linguaggi di programmazione che si sono affermati a partire dagli anni ‘80, con i quali non si tende più a sviluppare un’unica procedura che prevede dalla A alla Z tutte le funzioni, ma sistemi complessi di service providers e service users che dialogano sulla base di messaggi.
Per riassumere, sono passati ormai più di 50 anni dalla prima introduzione del termine Waterfall e le sue limitazioni nell’ambito dello sviluppo software sono evidenti e ben documentate:
1. Time To market elevato: il committente del progetto non riceve nulla se non in fondo al progetto che può durare mesi addirittura anni in alcuni casi, durante i quali non ha modo di godere del vantaggio competitivo sul business che si proponeva di ottenere dalla commessa stessa; un rischio troppo grande da correre, laddove lo spettro dell’obsolescenza determina il tempo brevissimo che deve intercorrere tra l’ideazione e la commercializzazione, ed i prodotti devono essere concepiti, testati e consegnati nelle mani degli utenti finali quanto più tempestivamente possibile.
2. Rigidità: il committente del progetto, anche a fronte di cambiamenti dello scenario del mercato e delle aspettative dei suoi clienti finali, ha difficoltà ad influire su quanto richiesto, perché la fase di progettazione è tutta all’inizio e non è previsto un suo coinvolgimento durante lo svolgimento delle attività;
3. Costi elevati notevoli: quello che appare come un processo lineare ed efficiente si tramuta spesso (nel caso del software) in una serie di cicli turbolenti e fallimentari che fanno perdere tempo e soldi. Questo perché le fasi sono legate tra loro da artefatti che
17 non sono definibili in modo rigoroso e questo scatena tutta una fase di cicli di revisione all’indietro che riducono drasticamente l’efficienza del metodo.
Con questo non si vuol affermare che il modello waterfall sia stato scartato in toto o che non risulti più di alcuna utilità, al contrario esso resta fondamentale per i progetti molto complessi, che coinvolgono numerose persone disperse geograficamente, dove di conseguenza è necessaria una comunicazione remota, la creazione di una precisa documentazione e il livello di controllo e burocrazia è piuttosto elevato.In una fase di transizione come quella che viviamo oggi, non occorre scegliere tra “Waterfall” e “Agile”, ma piuttosto bisogna saper convivere con entrambe le metodologie ed essere in grado di comprendere quando valga la pena adottarne una abbandonando i precetti e le regole dell’altra.
Quel che in questa sede interessa, è piuttosto capire come anche i mutamenti del mercato del software abbiano aiutato molto la nascita di metodologie agile e l’abbandono, a volte solo parziale e non totale, del modello a cascata: ciò a cui si mira sempre più non è solo la produzione del software di per sé, ma anche e soprattutto la soddisfazione totale del cliente e degli utenti finali.
Tre sembrano essere i macro aspetti da tenere a mente per comprendere l’evoluzione delle metodologie di PM verso forme più snelle e agili:
1. La crescente e sferzante competizione tra imprese.
2. L’abbattimento dei costi di distribuzione: la nascita degli store online, primi fra tutti l’Apple Store e Play Store, i quali permettono ai software di godere di continue release e quindi all’utente di aggiornare l’applicazione continuamente a costo zero. A partire dalla fine degli anni ’90, grazie alla diffusione globale di internet, i canali di distribuzione del software sono sensibilmente cambiati, passando dal canale fisico a quello digitale.
3. L’innalzamento sempre maggiore delle aspettative degli utenti. Aspetto questo connesso anche ai primi due, in quanto l’utente di oggi poco soddisfatto di una app, sa che col minimo sforzo e a costo zero può abbandonare un’applicazione e scaricarne un’altra che rispecchi di più le sue aspettative.
4. Riqualifica dell’utente all’interno dell’intero processo di sviluppo: progressiva integrazione della prospettica user-centered.
Viste queste e altre ragioni, col tempo si è giunti ad una riflessione profonda e limpida: il metodo ingegneristico applicato al software non è detto che funzioni in quanto lo sviluppo
18 software è una attività creativa e non produttiva, richiede l’apporto di knowledge worker e non di meri operatori, con una forte componente artigianale e di interazione umana.
Le metodologie agili quindi possono essere considerate la scelta più idonea per affrontare la gestione di un sistema complesso proprio perché non negano la complessità ma anzi la sfidano in modo chiaro e diretto, approcciando al tema "gestione del sistema" nella sua interezza. Accogliere a pieno questo framework vuol dire anche rivedere in parte i pilastri su cui si basa il “senso comune”, il quale ci ha insegnato ad affrontare lo svolgimento di una qualsiasi operazione prima procedendo ad una analisi completa delle cose da fare, poi realizzando una pianificazione dettagliata in tutti gli aspetti tecnici e non solo, infine svolgendo sequenzialmente ogni singola operazione fino al completamento e al raggiungimento degli obiettivi, rispettando quanto più possibile tempi e costi. È un approccio che, in determinate situazioni, ha le sue ragioni di esistere e si è dimostrato naturalmente funzionante. I problemi nascono quando si pretende di applicare tale paradigma ad attività complesse che rientrano all’interno di un sistema anch’esso complesso e in continua evoluzione. Le caratteristiche tipiche di un sistema complesso, infatti, suggeriscono un cambio di paradigma, un approccio che, forse solo inizialmente, sembra essere contro-intuitivo e sicuramente contro il nostro buon senso.
Ne consegue che pianificare una strategia prima di essere “entrati nel problema” potrebbe non essere di alcun aiuto; il fatto stesso di suddividere il lavoro in attività orizzontali potrebbe non avere alcun beneficio. La teoria della complessità ci suggerisce di “entrare” nel caso, vedere cosa succede, provare a risolvere qualche problema e capire se quello che stiamo facendo sia efficace o meno. Le metodologie agili, partendo da questi presupposti, si preoccupano di definire un metodo di lavoro che sia efficace nei contesti complessi, quali sono ad esempio quelli dello sviluppo e della produzione di software o quei settori dove domina la cosiddetta “economia della conoscenza7”. Concetti come lavoro e collaborazione di gruppo, iterazioni
piccole, eventi time-boxed, feedback continui, visualizzazione dei flussi e dei processi sono infatti key words per comprendere a pieno le metodologie agili.
7 L’«economia della conoscenza» (knowledge economics) è una nuova disciplina della teoria economica che si
occupa della conoscenza come bene economico e dei relativi effetti sia sul benessere individuale sia su quello collettivo
19
IV.I La nascita dell’Agile
Dall’11 al 13 febbraio 2001, nello ski resort “The Lodge at Snowbird” nello Utah, diciassette persone si sono incontrate per parlare, sciare e rilassarsi insieme. Tra gli obiettivi c’era anche trovare un’intesa comune riguardo a queste tematiche.
Da questo incontro è emerso il manifesto per lo sviluppo agile di software, talvolta abbreviato come “manifesto agile”, sottoscritto da tutti i diciassette convenuti.
Di seguito, si riportano i principi originali:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project 5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility 10. Simplicity- the art of maximining the amount of work not done- is essential
11. The best architectures, requirements, and designs emerge from self-organizing teams 12. At regular intervals, the team reflects on how to become more effective, then tunes and
20 I principi su cui si basa una metodologia che segua i punti indicati dall'Agile Manifesto, sono quattro (vedi figura sopra):
➢ Individui e reciproche interazioni: le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto;
➢ Distribuzione di software funzionante: bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile;
➢ Collaborazione del cliente: la collaborazione diretta offre risultati migliori dei rapporti contrattuali;
➢ Risposta al cambiamento: bisogna essere pronti a rispondere ai cambiamenti più che aderire al progetto, il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche al progetto in ogni momento.
Il manifesto agile sposta l’attenzione del monto IT sulla necessità di soddisfare il cliente e l’utente piuttosto che lo sviluppo di un software migliore. Le metodologie scorse limitavano il coinvolgimento del progetto.
I principi su cui si basano le metodologie Agile, così come descritti nel Manifesto, pongono quindi le persone e le interazioni che si sviluppano fra loro come elementi fondanti della filosofia Agile: Attenzione alle persone, scegliere le giuste risorse da coinvolgere nel progetto, che partecipino in maniera attiva alla creazione di valore, gestendo in autonomia problemi e criticità (problem solving). Stakeholder engagement: utenti, esperti e sponsor devono essere sempre presenti durante l’intera vita del progetto, sia nelle fasi iniziali, per fornire in maniera
21 dettagliata le specifiche da sviluppare, sia durante lo sviluppo del progetto, per i necessari chiarimenti e/o le eventuali modifiche alle stesse. L’owner, inoltre, non deve mai mancare nelle fasi finali, durante le quali verifica che quanto realizzato sia in linea con le specifiche fornite e, soprattutto, con le proprie aspettative. Comunicazione face-to-face: preferire sempre il confronto personale, aperto e interattivo, riducendo l’utilizzo dei canali tradizionali quali e-mail/telefono e promuovendo l’impiego di strumenti a carattere visuale come post-it, flip chart e white board da fissare alle pareti. La soluzione ottimale consiste nella collocazione, in un unico ambiente, del personale operativo e delle figure di business; tuttavia, nei casi in cui ciò non sia fattibile, le attuali tecnologie ed infrastrutture possono fungere da supporto per migliorare e facilitare lo scambio interattivo delle informazioni, preferendo quelle che consentono anche un’interazione visuale, per esempio la webcam. Focus sul valore: creare concretamente valore attraverso la riduzione dei cosiddetti “waste”, ovvero del superfluo e dei ricicli; limitare all’essenziale la documentazione, che non significa, però, non redigerla o attribuirle una scarsa considerazione.
V. SCRUM: bilanciare la qualità con il tempo
Tra i metodi previsti nell’Agile, Scrum è sicuramente uno dei più noti e apprezzati. Scrum nasce grazie alle intuizioni di due personalità di spicco nel mondo tecnologico: Jeff Sutherland, esperto di biometrica e innovatore tecnologico, e Ken Schwaber, sviluppatore software e project manager, i quali, più di 20 anni fa, diedero luce a questo nuovo modo più veloce, affidabile ed efficace di creare software per il settore tecnologico.
Il termine scrum deriva dal gergo del rugby, vuol dire “mischia”, e indica proprio la mischia che spinge la palla in una sola direzione. Il concetto alla base di Scrum è infatti assimilabile ad uno schema di gioco semplice e comprensibile, al cui centro vi è un leader-facilitatore o “guru-mediatore”, lo scrum master, che organizza e programma in cicli brevi il lavoro di un team di attori con ruoli diversi, e che tuttavia vanno tutti nella stessa direzione.
Per entrare subito nel merito della questione, si riporta la definizione di Scrum così come contenuta nella Scrum Guide (Scrum Alliance), il documento ufficiale costantemente aggiornato dai due co-creatori di Scrum, J. Sutherland e K. Schwaber:
22 “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”.
Scrum è descritto come un process framework piuttosto che un processo completo per sviluppare prodotti. Infatti, differenza fondamentale dagli altri framework più diffusi, è che Scrum si definisce intenzionalmente incompleto e non specifica al suo interno tutti gli step necessari per portare a termine la realizzazione di un prodotto. Si rivela essere un framework all’interno del quale possono essere impiegati un gran numero di processi e tecniche. Va da sé, naturalmente, che le core rules alla base del framework devono essere sempre rispettate: lo scrum team ha la possibilità di scegliere quali procedure e tecniche utilizzare durante gli sprint, comunicandole apertamente, ma non può eliminare alcuno delle componenti e ruoli principali di Scrum. Se così fosse, semplicemente non si parlerebbe più di Scrum, dal momento in cui esso esiste solo nella sua interezza e ciascuna parte deve rispettare lo specifico scopo per cui è stata prevista.
Proseguendo lungo la definizione, gli aggettivi “complex” e “adaptive” riferiti ai problemi, forniscono subito un’idea della tipologia di progetto che meglio si addice alla metodologia Agile.
Ma ancora prima, per cogliere appieno il significato e il perché della scelta di utilizzare questi due termini, occorre riferirsi al concetto di uno “spettro”, alle cui estremità si posizionano, da un lato, problemi statici, semplici e prevedibili, e dall’altro problemi complessi, poco o per nulla preventivabili e in continuo cambiamento.
I professionisti operanti nel mondo del project management, sono piuttosto confident sulle modalità di approccio al primo tipo di problemi: essendo statici e presumibili, si è in grado di creare un piano dettagliato in cui rappresentare tutte le attività da portare a termine, con i loro tempi e le loro dependencies e, soprattutto, senza bisogno di cambiar piano o di porre rimedio ad eventi inattesi. Questo è chiamato Defined Process Control.
Ma nel mondo reale accade realmente questo? Fatte le dovute eccezioni, saremmo miopi e sciocchi nel credere di non aver a che fare con un mondo molto più complesso e intricato, in cui i problemi non possono venire catturati e gestiti da un piano realizzato meticolosamente all’inizio di un progetto. Tuttavia, è bene sottolineare, come sia assolutamente errato associare l’uso di Scrum alla convinzione che pianificare e prevedere i rischi sia inutile. Anzi, come vedremo nel proseguo della trattazione, Scrum aiuta a fornire due tipi di pianificazione: una a
23 breve e brevissimo termine, con le cosiddette cerimonie che si svolgono tutti i giorni e altre ogni due settimane, e una a medio-lungo termine, con Visione e Roadmap di progetto.
Il defined process control non funziona più quando le cose diventano complicate. Come suggeriscono i due autori di un noto libro, Process dynamics, modeling, and control, Ogunnaik e W. Ray: “It is typical to adopt the defined approach when the underlying mechanisms by which a process operates are reasonably well understood. But, when the process is too complicated for the defined approach, the empirical approach is the appropriate choice”. La teoria alla base del controllo empirico dei processi (empirismo), dice che, da un lato, la conoscenza deriva in primo luogo dall’esperienza e, dall’altro, le decisioni si basano su ciò che si conosce e che si può controllare. Per questo motivo si prevede un processo iterativo con un approccio incrementale che ottimizza, sprint dopo sprint, la prevedibilità ed il controllo del rischio. Scrum è quindi vicino ai sistemi evolutivi, adattativi e che si correggono da sé, e lontano da meccanismi di progettazione top down e metodicamente prevedibili e prescrittivi.
Scrum è un metodo che poggia su alcuni pilastri fondamentali: trasparenza, ispezione,
adattamento, velocità, qualità.
La trasparenza è garantita nel momento in cui gli aspetti più rilevanti e significativi del processo, in particolare gli eventi e gli artefatti devono essere visibili a tutti i responsabili dell’outcome del progetto. È importante, di conseguenza, che tutti gli attori coinvolti condividano linguaggio di riferimento e standard comuni. Per esempio, deve esserci sintonia e
24 accordo della definizione di “done” tra coloro che effettuano le attività e coloro che verificano i risultati incrementali o, in altri termini, tra chi deve eseguire e chi deve accettare un task. L’ispezione va riferita alla circostanza per cui chi utilizza scrum effettua frequenti controlli sullo svolgimento dei lavori e sui progressi incrementali nel corso dello sprint per identificare eventuali varianti indesiderate e porvi rimedio in tempo.
L’adattamento è una caratteristica fondamentale delle metodologie agile, quindi dello scrum. I continui feedback e aggiornamenti in corso d’opera, permettono agli sviluppatori e al resto del team di rendersi conto di eventuali deviazioni e di rimediare; inoltre, le caratteristiche della metodologia permettono eventuali interventi di modifica dei requisiti, qualora il cliente lo ritenga necessario, nel minor tempo possibile, per non intaccare la qualità dell’outcome. Nel mondo IT, la complessità dei prodotti che arrivano sul mercato è sempre crescente. Basti pensare alla competizione più che mai agguerrita e serrata tra i prodotti ad alto contenuto tecnologico, al punto da costringere le imprese a gestire sì, problemi molto complessi, ma con un approccio adattivo (e da qui riferimento all’aggettivo “adaptive”) e rapido, necessario ad evitare una brusca frenata e a consentirgli di rimanere a galla.
Altro termine su cui fare luce è highest value: non basta accorciare il time to market, portando sul mercato prodotti nuovi e aggiornati, ma è necessario che questi prodotti portino con sé valore aggiunto per gli utenti (circoscrivendo il discorso al mondo dello sviluppo software). A mio parere, il valore aggiunto di un prodotto non può essere considerato qualcosa di preconfezionato e prevedibile in modo assoluto sin dalle prime fasi della sua ideazione. Molto spesso, infatti, le caratteristiche che al product owner sembrano essere le più significative per portare valore, si rilevano meno essenziali del previsto, o semplicemente vengono sostituite da altre che in base a successive analisi/ricerche si dimostrano quelle realmente ricercate e desiderate dagli utilizzatori.
Potremmo prendere in prestito quanto dice Patrick Charbonnier, insegnante Agile, il quale rappresenta questa caratteristica dell’agile attraverso un esempio semplice ed efficace: “è come quando ristrutturi una casa, vai dall'architetto e gli dici di mettere un angolo cottura affacciato sul salotto del terzo piano perché pensi che sia la soluzione più allegra per le serate con gli amici. Mentre i lavori sono in corso ti viene un'ernia o ti nasce un figlio e ti rendi conto che ha molto più senso avere una cucina abitabile al piano terra”.
25 Tuttavia, rimanendo in tema di valore, degno di sottolineatura è che lavorando con Scrum si attribuisce massima importanza al valore espresso dalle proprie risorse: l’elemento base dello sviluppo è la squadra composta da un numero ristretto di risorse (da 5 a 10), le quali agiscono come un’unità organizzativa autonoma, composta da skill e know how necessari per svolgere le attività di sviluppo in completa autonomia, facendo pieno uso delle metodologie Agile con frequenti rilasci software. Un gruppo di persone che mettono a fattor comune le proprie conoscenze, i tool utilizzati e le best practice. Le persone, con Scrum, sono protagoniste delle attività che svolgono e diventano esse stesse promotrici del cambiamento e dell’incremento di valore.
Lavorare in modo Agile significa operare in modo molto più veloce e più organico: si parte dall'obiettivo iniziale, anziché dal modo di raggiungerlo e, tralasciando l'infinita scrittura delle specifiche, lo si spezzetta in tanti piccoli obiettivi e lo si lavora in sprint che solitamente vanno dalle 2 alle 4 settimane, al fine di coordinare il processo di sviluppo del prodotto con le esigenze del committente/cliente.
Secondo la Scrum Alliance, tuttavia, le componenti di cui abbiamo appena trattato costituiscono piuttosto il sistema logico, il brain of scrum. Ciò che permette al sistema di funzionare bene nella pratica sono i 5 valori alla base di esso, che ne costituiscono l’heart. Infatti, alla base di questo framework, ci sono pur sempre le persone e le mille diverse sfaccettature che connotano le personalità di ciascuno. I 5 valori al cuore di Scrum sono:
1. Commitment, letteralmente “joined together”. Le persone che costituiscono lo scrum team sono personalmente coinvolte e impegnate insieme, per raggiungere lo scopo fissato.
26 2. Courage, letteralmente “from the heart”. I membri del team prendono decisioni anche
rischiose e inaspettate, quando si è di fronte a problemi complessi.
3. Focus, la cui etimologia deriva dalla parola latina focolaio, per cui si fa riferimento al fuoco al centro della casa e all’interno del quale si raggruppano le persone per cercare calore e riparo. Il focus è dunque quella cosa che unisce le persone. In scrum tutti lavorano intorno allo stesso obiettivo.
4. Openness, letteralmente esposto o evidente, definisce la volontà di tutti gli attori coinvolti in Scrum di essere aperti e trasparenti sulle attività da svolgere e sulle sfide da affrontare. Si ricorderà, che uno dei pilastri su cui si basa Scrum è proprio la trasparenza, aspetto in comune con i metodi empirici.
5. Respect, in scrum si traduce nel dare un secondo sguardo al lavoro dei membri del team, al fine di determinare e esporre loro sinceri apprezzamenti sulle loro capacità e sui loro contributi alla buona riuscita del progetto. È un modo per dimostrare che gli scrum members nutrono rispetto gli uni con gli altri per essere persone capaci e indipendenti, ancor prima di essere parte di un team.
Per garantire un corretto utilizzo e approccio a Scrum e alla filosofia sottostante, è necessario che la struttura logica e quella emozionale comunichino a vicenda e si alimentino l’una con i valori dell’altra.
È necessario ora passare agli artefatti le cerimonie e i ruoli che compongono la metodologia Agile, nello specifico Scrum.
V.I I ruoli
In Scrum, le persone che partecipano al progetto vengono inquadrate in ruoli a cui corrispondono specifiche responsabilità.
Esistono due macro categorie: i “Pig”, coloro che sono davvero coinvolti (committed), e i “Chicken”, coloro che possono ritenersi osservatori interessati (involved). Questa suddivisione deriva da una scenetta cartoon in cui è rappresentato un pollo che propone ad un maiale di aprire insieme un ristorante, da chiamare ham and eggs, e il maiale risponde che in questa circostanza lui sarebbe l’unico davvero committed e il pollo only involved. L’idea è semplice ed intuitiva:
27 in Scrum, i pigs sono il PO, il team e lo Scrum Master, i chicken tutti gli altri, gli stakeholder di progetto. I pigs sono coloro davvero committed al progetto e al lavoro, in quanto per avere la pancetta si presuppone il sacrificio del maiale, mentre le galline non sono parte del team e sono solo coinvolti, in quanto fare uova è un’attività naturale che non richiede impegno particolarmente oneroso. In Scrum tutte le persone devono essere committed e devono lavorare insieme come un unico gruppo verso il medesimo obiettivo.
Il Product Owner ha la responsabilità di far emergere il prodotto col più alto valore aggiunto possibile ed entro la data desiderata, oltre che di massimizzare il lavoro svolto dal team di sviluppo. Egli ha anche la quasi esclusiva responsabilità della gestione del Product Backlog del progetto. Per facilitare il lavoro del Product Owner in questa direzione, è necessario che gli items all’interno del product backlog siano chiari, trasparenti, compresi da tutti e ordinati in modo da raggiungere meglio gli obiettivi; il valore del lavoro svolto dall’intero team sia massimizzato e ottimizzato.
Certamente il Product Owner non può essere nel concreto l’unico responsabile dell’intero andamento del progetto. L’intero team che lavora con Scrum è responsabile a sua volta del livello di produttività, del miglioramento delle pratiche e del supporto al Product Owner stesso. Tuttavia, ciò che rende unica la funzione del PO è il fatto di essere la persona più vicina al versante business del progetto: dal PO ci si aspetta il massimo per soddisfare ed allineare le aspettative di tutti gli stakeholder. Infatti, nella sua persona risiede anche il potere decisionale riguardo a ciò che può essere ritardato ovvero anticipato, oltre che per le scelte tra l’estensione delle funzionalità e le tempistiche di realizzo.
28 Il Team di Sviluppo è composto da professionisti con diverse abilità, collettivamente responsabili del Potentially Shippable Increment, dal momento in cui lavorano per produrre un incremento di prodotto definito da rilasciare alla fine di ogni sprint. Il team è stabile almeno per tutto un intero sprint, si definisce auto-organizzante, normalmente è presente fisicamente nello stesso spazio di lavoro e include uno scrum Master che funge da coach. I membri del team sono gli unici che creano effettivamente l’incremento del prodotto. Tra le caratteristiche principali che connotano uno scrum team di sviluppo troviamo: l’auto-organizzazione e auto-gestione su come svolgere il lavoro dal punto di vista tecnico; la cross-funzionalità, essendo formato da individui con skills e capacità differenti; la non contemplazione di sotto-team dedicati a particolari domini come il testing; la condivisione della responsabilità finale del lavoro. Riguardo alla dimensione ottimale, in uno scrum team di sviluppo è abbastanza contenuta: dalle 3 a massimo 9 persone. Una dimensione del genere è necessaria per lavorare Agile e per coordinare in maniera massimamente efficace il lavoro, garantendo adattabilità e trasparenza. Lo Scrum Master è un leader che aiuta il resto del team a seguire l’intero processo Agile: deve avere una buona padronanza del framework Scrum e la capacità di istruire gli altri. Per rimanere all’interno della metafora da cui nasce il termine Scrum, è un buon allenatore che aiuta lo scrum team a lavorare insieme e lo supporta nel rimanere focalizzato, produttivo e in costante miglioramento, oltre a proteggere il team da interferenze esterne. Insomma il mediano di mischia, scrum half in inglese, nel rugby collega avanti e trequarti come lo scrum master fa in azienda, fungendo da raccordo tra i vari ruoli del progetto. Nel concreto, è come un servant leader che gestisce i servizi di coordinamento delle persone, aiuta a districare le problematiche, fissa gli orari e presiede alle cerimonie. Non è certamente una figura presente da tempo in azienda, ma, soprattutto nel mondo ict, negli ultimi anni risulta essere molto diffusa nel mondo aziendale soprattutto per la sua efficacia provata di “far funzionare le organizzazioni”.
V.II Le cerimonie
Pianificare, conoscere e prevedere sono aspetti chiave per l’abbassamento del rischio di fallimento di un progetto. Le cerimonie scrum, con la loro durata “time-boxed” e la loro regolarità, vanno proprio nella direzione di diminuire il livello di rischio associato ad un progetto di sviluppo software e di agire subito lì dove si verificano scostamenti e/o richieste inattese, senza compromettere la buona riuscita del progetto in generale e senza introdurre
29 sprechi di tempo e risorse durante il processo di pianificazione. Tutti gli eventi che vedremo, contribuiscono ad alimentare uno dei pilastri del framework, ovvero garantire la trasparenza tra tutti gli attori coinvolti, siano essi pigs o chicken8, e l’ispezione continua.
Le cerimonie caratterizzanti il framework scrum sono le segueni: • Sprint, il contenitore di tutti gli altri cerimoniali, o eventi • Sprint planning
• Daily scrum
• Sprint retrospective
Le iterazioni di un processo basato sul framework Scrum sono gli Sprint. Lo Sprint può considerarsi il cuore dello Scrum.
Generalmente, la sua durata varia da due settimane fino ad un mese, durante la quale viene creato un incremento di prodotto potenzialmente rilasciabile al cliente, definito come done. A tal proposito, è utile chiarire meglio cosa si intende per “definition of done” in relazione alla lavorazione di una user story: la lavorazione di una funzione che sviluppa una specifica user story non può essere considerata finita a meno che non soddisfi a pieno la definizione di done concordata dal team e dal PO. E’ importante che tale definizione sia il meno possibile vaga e il più possibile compresa e condivisa, così da rendere chiaro a tutti quando si può affermare che un’attività è conclusa definitivamente e quindi passare allo step successivo. Per riportare un esempio, una possibile definizione di Fatto può essere il completamento di una codifica della funzionalità richiesta; test funzionali scritti ed effettuati; funzionalità approvata definitivamente dal Product Owner.
30 All’inizio di un progetto e durante la sua pianificazione, viene stabilito il numero di Sprint in cui si dividerà il lavoro e, almeno idealmente, tale numero deve rimanere invariato e permettere al team di esaurire tutte le attività in quel lasso di tempo. Una caratteristica intrinseca degli sprint, oltre alla omogeneità della durata di ciascuno di essi, è la ciclicità: ogni sprint è avviato non appena quello precedente si è concluso.
Naturalmente, se ogni Sprint è avviato per realizzare qualcosa, è previsto anche un momento, prima dell’avvio di ciascun sprint, in cui si definisce ciò che andrà costruito, un piano flessibile che guiderà a questo scopo, il lavoro che si è svolto fino ad ora, l’esame di cosa non si è concluso, quindi il perché si è rimasti eventualmente indietro nella lavorazione di specifiche user story/feature9, e il prodotto che risulterà una volta terminato lo sprint, compresi gli avanzamenti dagli sprint precedenti.
In sostanza, ogni Sprint dovrebbe prevedere uno Sprint Goal, un obiettivo dichiarato, condiviso e non tecnico, stando che lo scopo del progetto (se consideriamo ogni sprint anche come un piccolo progetto a se stante) può essere rinegoziato e chiarito tra il product owner e il team di sviluppo, qualora dovessero emergere nuovi elementi da considerare o nuovi ostacoli da superare. In quest’ultimo caso, fondamentale è la figura dello Scrum Master, il quale, come si è detto prima, deve intervenire soprattutto a supporto del team quando sopraggiungono impediments che sembrano mettere a repentaglio il sereno svolgimenti del lavoro.
31 Nella loro impostazione originaria, è importante tener conto del fatto che durante lo svolgimento di ciascuno sprint non devono essere apportate modifiche che possano mettere a rischio il goal e degradare la qualità del lavoro.
L’obiettivo da raggiungere, lo sprint goal definito in attività di planning, deve essere rispettato il più possibile, e il team deve dimostrare capacità di concentrazione e coordinamento soprattutto in questa fase, in quanto richieste superflue e “out of the scope” possono essere avanzate da chi non è completamento coinvolto nel progetto, e si deve fare in modo di saper “ignorare” quelle richieste che non produrrebbero valore aggiunto e che portano via tempo o distolgono dal fine ultimo. Altro requisito fondamentale per il team affinché possa svolgere al meglio le attività, è la comunicazione limpida ed efficace: comunicare le attività che si stanno svolgendo, condividere dubbi e problemi eventuali, è indispensabile per non perdere di vista il raggiungimento del goal e rendersi conto il prima possibile di possibili rallentamenti.
Lo Sprint Planning è un incontro in cui il team pianifica il lavoro da svolgere lo Sprint che sta per avviarsi. Il risultato dello Sprint Planning è lo Sprint Backlog, ovvero l’elenco delle attività che il team di sviluppo ritiene di portare a termine alla conclusione dello sprint e, come appena visto, la definizione dello Sprint Goal. La durata del meeting può variare a seconda delle attività da includere nella pianificazione e in base allo stato dell’arte del progetto ma, generalmente, per uno Sprint di due settimane sono sufficienti dalle due alle quattro ore. In questa sede si entra nei dettagli di ogni singola attività da svolgere, non a livello di stima delle user story, bisogna dunque stabilire i cosiddetti story points, ovvero quante ore lavorative si prevede debbano essere impiegate. Compito dello Scrum Master è assicurarsi che l’evento abbia luogo nei tempi stabiliti e, soprattutto che i partecipanti ne comprendano le finalità. Sostanzialmente, alla base delle decisioni che vengono prese durante la cerimonia di planning, vi sono le seguenti domande:
• A che punto siamo rispetto alle nostre previsioni? Valutare dunque eventuali ritardi o impediments che hanno reso difficoltoso al team la conclusione dello sprint precedente; • Qual è lo Sprint Goal? Il quale in sede di planning può essere visto come aiuto per creare la coerenza e l’idea di lavoro concertato nel team di sviluppo che non si verificherebbe se ognuno interpretasse le proprie attività come a sé stanti e senza un obiettivo finale; • Cosa può essere consegnato al cliente come incremento di lavoro, come done? Quindi,
quali elementi che costituiscono il Product Backlog, vanno inseriti in quello sprint? Questo aspetto finale, può essere definito solo dal team di sviluppo, essendo l’unico in
32 grado di stimare davvero quanto tempo e quante risorse siano necessarie per portare a termine i tasks che costituiscono ciascuna user story; il team di sviluppo si autogestisce per chiarire il lavoro da fare in termini di effort al fine di convertire gli elementi del Product Backlog in Incremento di prodotto;
• Quali risorse sono necessarie per realizzare quanto previsto? A tal proposito, è utile avere una idea della capacità produttiva del team, soprattutto guardando alle performance registrate in passato, per definire la composizione del team.
Tuttavia, può capitare che durante lo Sprint l’entità del lavoro necessario sia diversa da quanto il Team di Sviluppo aveva pianificato o che il lavoro pianificato risulti in eccesso o in difetto. A fronte di casi tali, è possibile ed auspicabile che il team collabori col product owner per rivedere il piano e rinegoziare le voci selezionate dal Product Backlog, non perdendo mai di mira lo Sprint Goal.
Ogni giorno e durante ogni sprint, viene tenuto un cerimoniale dalla durata di circa 15 minuti in cui il team di sviluppo verifica, al fine di sincronizzare la attività, cosa si è appena fatto e prevede/pianifica le attività che si svolgeranno nelle 24 ore successive. Tale evento, che prende il nome di Daily stand-up o Daily Scrum, si svolge quotidianamente allo stesso orario e nello stesso luogo per ridurne la complessità.
Durante l’incontro ogni membro del Team di Sviluppo risponde alle seguenti, sottointese, domande:
