La metodologia di sviluppo Scrum

Nonostante l'azienda per cui lavoro si avvii a contare circa duecento impiegati, essa, per il contesto in cui si trova, continua ad essere considerata una start up.
Questa premessa è importante per comprendere la metodologia di sviluppo che vige nel team frontend. Le funzionalità (o feature) del prodotto vengono sviluppate in maniera incrementale, con diverse iterazioni prima di raggiungere la versione finale, seppur parlare di versione finale non abbia molto senso.
In un ambiente di questo genere spesso arrivano richieste da clienti molto grandi i quali, per concludere un contratto, richiedono caratteristiche non ancora presenti oppure il miglioramento di alcune di esse. È importante rispondere reattivamente a queste condizioni se si vuole dimostrare il valore di quello che offriamo. Per riuscire a sottostare a tutto ciò, continuando ad avere una pianificazione nel breve e nel medio periodo, da qualche mese abbiamo adottato la metodologia di sviluppo Scrum.

📌 Overview su Scrum

Scrum è una metodologia agile, nell'ingegneria del software tale espressione si riferisce ad un insieme di metodi di sviluppo emersi a partire dai primi anni 2000 e fondati su un insieme di principi comuni, direttamente o indirettamente derivati dai principi del Manifesto per lo sviluppo agile del software (Manifesto for Agile Software Development) pubblicato nel 2001 da Kent Beck, Robert C. Martin, Martin Fowler e altri.

I metodi agili si contrappongono al modello a cascata (waterfall model) e ad altri modelli di sviluppo tradizionali, proponendo un approccio meno strutturato e focalizzato sull'obiettivo di consegnare al cliente, in tempi brevi e frequentemente, un software funzionante e di qualità (early delivery - frequent delivery).

Fra le pratiche promosse dai metodi agili ci sono la formazione di team di sviluppo piccoli, poli-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva, e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.

La metodologia Scrum fu ideata da Ken Schwaber e Jeff Sutherland e permette la gestione del ciclo di sviluppo di un software attraverso una serie di procedure e ruoli capaci di ottimizzare i tempi ed i risultati. Grazie alla pianificazione, ai processi iterativi ed all’utilizzo costante di feedback, Scrum permette di raggiungere gli obiettivi in maniera rapida ed efficace.
Una metodologia come Scrum, per definirsi agile, deve rispettare i seguenti principi:

Priorità agli individui e alle interazioni più che ai processi e agli strumenti.
Software funzionante più che documentazione esaustiva.
Collaborazione col cliente più che negoziazione dei contratti.
Reagire al cambiamento più che seguire un piano.

L’idea è quella di stravolgere l’approccio classico e lineare di progettazione, puntando alla possibilità di realizzare un progetto per fasi, chiamate sprint.
Ad ogni sprint corrisponde una nuova funzionalità e viene verificata la soddisfazione del cliente, al quale viene mostrato il lavoro svolto sino a quel punto. È un sistema iterativo ed interattivo che consente di apportare facilmente modifiche al progetto, abbattere i costi di produzione, evitare sforzi inutili e fronteggiare un eventuale fallimento.

Possiamo paragonarla alla filosofia del Minimum Viable Product (o semplicemente MVP) attraverso la quale si può velocemente testare un prodotto o un servizio sul mercato, iniziando con una presentazione, una pubblicità o una landing page.
Anche qui si tratta di un processo iterativo durante il quale l’idea e la forma iniziale del progetto vengono modificati e adattati in base ai feedback ricevuti dagli utenti iniziali (early adopters), un processo che continua sinché non si raggiunge il prodotto desiderato dagli utilizzatori.
La durata media di uno sprint è di 2 o 4 settimane (da noi è di 2 settimane) ma una metodologia agile ha la peculiarità di essere adattabile secondo esigenze.

Avere un processo iterativo, con approccio incrementale, che ottimizza, passo dopo passo, la prevedibilità ed il controllo del rischio, ci permette di avere un controllo empirico dei processi: da un lato la conoscenza deriva dall’esperienza, dall’altro le decisioni si basano su ciò che si conosce.

Le componenti principali di Scrum si dividono in: ruoli, artefatti ed eventi.

👥 I ruoli all’interno di Scrum

I ruoli all’interno dello Scrum team, sono principalmente tre e lavorano in stretta connessione per assicurare un flusso di informazioni veloce e continuo.

1. Scrum Master 🎓

Il responsabile del processo, colui che deve garantire che la metodologia Scrum venga compresa ed eseguita con successo.
Egli, deve essere in grado di rimuovere gli ostacoli che si presentano, stabilire un ambiente in cui la squadra può essere efficace, affrontare le varie dinamiche che possono presentarsi all'interno del team, garantire una buona relazione tra quest'ultimo ed il Product Owner o altri al di fuori, proteggere la squadra da interruzioni e distrazioni esterne.

Inizialmente, il nome indicava solamente qualcuno esperto di Scrum in modo da poter divulgare la metodologia.
Scrum Master è anche usato impropriamente per riferirsi a persone che ricoprono un ruolo con responsabilità simili in team che non seguono esplicitamente Scrum. Altri termini usati raramente sono Iteration Manager, Agile Coach o Team Coach.

Mentre avere uno Scrum Master può fornire diversi vantaggi, ci sono anche diversi problemi che sorgono dall'applicazione impropria del ruolo.
Supponiamo di avere dei project manager abituati a guidare vari progetti, chiedere a qualcuno di loro di fare da Scrum Master senza avere alcuna esperienza pregressa in un ambiente agile può essere controproducente: egli potrebbe aspettarsi che il carico di lavoro assegnato ad un team piuttosto che ad un altro sia lo stesso, indipendentemente da quanto tempo il team abbia lavorato assieme in precedenza. Molto probabilmente invece, un team ben funzionante ha bisogno di molto meno coaching rispetto ad uno nuovo.
Non vi è un set di skill specifiche necessarie per ricoprire il ruolo e nella pratica possiamo osservare diverse interpretazioni dello stesso:

Scrum Master rotante: i membri fanno ruotare, di sprint in sprint, le responsabilità (principalmente amministrative) tra di loro
Scrum Master a tempo parziale: un individuo nel team assume le responsabilità di Scrum Master oltre a quelle solite.
Scrum Master a tempo pieno: le uniche responsabilità dell'individuo che ricopre tale ruolo sono quelle di essere uno Scrum Master. Questo modello è il più adatto per un team agile.
Scrum Master a tempo pieno con più di una squadra: come il modello precedente ma gestendo più di una squadra contemporaneamente.

2. Product Owner 👔

Colui che conosce tutti i requisiti del prodotto e porta avanti gli interessi di tutti gli stakeholder. L’interfaccia tra il business, i clienti e i requisiti del prodotto da un lato e il team dall’altro. Deve massimizzare il valore del prodotto e del lavoro svolto dal Team di Sviluppo.

Il Product Owner (in seguito chiamato anche PO) è in genere la figura principale con la quale interloquire, deve avere una visione d'insieme di ciò che si desidera costruire e trasmetterla al team. Questa è la chiave del successo per un qualsiasi progetto di sviluppo software agile.

Il PO è, in genere, un utente principale del sistema, qualcuno del marketing, della gestione del prodotto o chiunque abbia una solida conoscenza degli utenti, del mercato, della concorrenza e delle tendenze future per il dominio dell'applicativo o il tipo di sistema sviluppato.

Questo, ovviamente, varia a seconda del tipo di software che il team sviluppa: commerciale, per uso interno, hardware o altro, la chiave è che la persona nel ruolo di Product Owner abbia la visione di ciò che debba essere costruito. Sebbene il PO assegni le priorità ai task del Product Backlog, durante la riunione di pianificazione, il team seleziona la quantità di lavoro che crede di poter fare nello Sprint seguente e quanti Sprint saranno necessari per completare una determinata attività.

Il PO non dice (o non dovrebbe dire):

"Abbiamo ancora quattro sprint rimanenti, quindi devi fare un quarto del lavoro in questo sprint".

Il suo compito è invece quello di motivare la squadra con un obiettivo chiaro ed elevante. Chi, meglio dei membri del team stesso, conosce di cosa essi siano capaci e della quantità di lavoro in grado di svolgere? Sono loro stessi a selezionare le user story dalla parte superiore del backlog che a loro avviso possono consegnare durante lo sprint.

In cambio dell'impegno del team a completare le user story selezionate, il Product Owner si impegna reciprocamente a non inserire nuovi requisiti durante lo sprint. I requisiti possono cambiare (e il cambiamento è una di quelle cose assolutamente incoraggiate nello sviluppo agile) ma solo al di fuori dello sprint. Una volta che la squadra inizia uno sprint, essa rimane maniacalmente concentrata sull'obiettivo di quello sprint.

Il ruolo del PO richiede solitamente un individuo con determinate skill e caratteristiche tra cui disponibilità, capacità di negoziazione, abilità comunicative e di analisi del business.

Innanzitutto, il Product Owner deve essere disponibile per il proprio team: i migliori PO dimostrano il loro impegno facendo tutto il necessario per costruire il miglior prodotto possibile, questo significa essere attivamente coinvolti con il team di sviluppo.

Avere capacità di business analysis è fondamentale, chi ricopre questo ruolo è anche colui che decide le caratteristiche che presenterà il prodotto, ciò significa che egli dovrebbe comprendere il mercato, il cliente e il business, al fine di prendere decisioni corrette.

Infine la comunicazione: questo ruolo richiede di lavorare a stretto contatto con i principali stakeholder di tutta l'organizzazione aziendale e, a volte, anche oltre; per cui il PO deve essere in grado di comunicare messaggi diversi a persone diverse in qualsiasi momento.

3. Team di Sviluppo 👩‍💻

Può essere formato da 3 a 9 persone le quali devono soddisfare le esigenze tecniche per sviluppare il prodotto o il servizio.
Sono guidati direttamente dallo Scrum Master, ma devono auto gestirsi, essere versatili e abbastanza responsabili da completare tutte le attività richieste.

Solitamente quando si forma una nuova squadra, ci vuole del tempo prima che si trovi la giusta affinità nel combinare le proprie conoscenze. Questo è del tutto normale, sarà lo Scrum Master, ogni giorno, ad aiutare ad affrontare la curva di apprendimento. Non è consigliabile cambiare spesso i componenti del team per evitare qualsiasi tipo di diminuzione della produttività.

Le principali responsabilità sono:

Creare e fornire prodotti o servizi.
Essere auto-organizzati ed autogestiti: i componenti devono essere in grado di determinare i propri compiti e in che modo li eseguiranno.
Multi-funzionale: i membri del team non hanno tutti le stesse skill ma esse sono eterogenee.
È consigliato si lavori in uno stesso ambiente di lavoro, nonostante noi rappresentiamo un'eccezione in questo senso (molti di noi lavorano da remoto).

Con l'acronimo SME (Subject Matter Expert) si indica qualcuno esperto in materia, con conoscenze molto specifiche nel suo ambito o skill particolari che sono necessarie al team. Il termine di solito si riferisce a quegli individui che sono al di fuori dello Scrum Team, ma non sempre.

📄 Gli artefatti

Gli artefatti sono 3, progettati per massimizzare la trasparenza delle informazioni chiave (sia per lo Scrum Team che per tutti gli stakeholder) e l’opportunità di ispezione e adattamento.

1. Product Backlog 📚

Nella sua definizione più semplice è un elenco di tutte le attività che devono essere svolte all'interno del progetto.
Sostituisce i tradizionali artefatti riguardanti le specifiche dei requisiti. Il Prodcut Owner è il responsabile dell'artefatto mentre lo Scrum Master, lo Scrum Team e gli altri stakeholder contribuiscono ad avere una To-Do list ampia e completa.

Il Product Backlog esiste, e si evolve, per tutta la durata del prodotto; è la sua tabella di marcia e vi sono molti servizi online nati per supportare questo tipo di attività dato che mantenerlo su carta, per prodotti relativamente grandi, diventa scomodo.
A Sysdig, quando eravamo più piccoli, Trello rappresentava una buona scelta, da qualche tempo siamo passati a Jira di Atlassian, una suite che unisce strumenti di management a strumenti di ingegneria del software quali bug tracking, feature request e così via.

In qualsiasi momento, il Product Backlog è l’unica vista di insieme capace di elencare tutto ciò che potrebbe essere sviluppato dal Team, in ordine di priorità.
Esiste un solo Product Backlog per prodotto, questo significa che il Product Owner è tenuto a prendere decisioni per assegnare le priorità a tutto spettro, rappresentando gli interessi di tutti i soggetti interessati.

Lavorare con il Product Backlog non significa che allo Scrum Team non sia concesso creare e utilizzare altri artefatti: risorse aggiuntive potrebbero essere un riepilogo dei vari ruoli utente, descrizioni del workflow, linee guida riguardanti l'interfaccia utente, storyboard o prototipi di UI. Tuttavia, questi artefatti non sostituiscono il Product Backlog ma lo completano.

Il Product Owner utilizza questo documento durante la riunione di pianificazione dello sprint per dettagliare le varie voci che lo compongono. Lo Scrum Team, determina quindi le attività che possono essere completate durante lo sprint in arrivo.

Il Product Backlog include una variegata tipologia di voci, soprattutto nuove funzionalità per il cliente ma anche i principali obiettivi di miglioramento all’ingegneria (ad esempio, "riscrivere il sistema da Ember a React") obiettivi di miglioramento generici (ad esempio, "diminuire il tempo della build") lavori di ricerca ("studiare soluzioni per accelerare il caricamento delle dashboard") e malfunzionamenti noti se questi sono un numero limitato, altrimenti si usa un sistema di tracciamento dedicato.

Contrariamente a malintesi comuni, il Product Backlog non contiene solo varie user story, contiene semplicemente voci; tali voci possono essere espresse in storie, casi d'uso o altri approcci che il gruppo ritiene migliori. Qualunque sia la scelta, gli item devono aggiungere qualche tipo di valore per il cliente, se questo non avviene, si tratta di rifiuti (nemmeno riciclabili 😬) e non dovrebbero essere presenti. Se le attività non aggiungono direttamente valore ad una funzionalità ma aumentano la qualità del lavoro o riducono la possibilità di errori a lungo termine, allora sono legittimate ad essere presenti.

Un buon Product Backlog è DEEP (Detailed Estimated Emergent Prioritized):

Detailed - Dettagliato in modo appropriato: le varie attività da svolgere hanno livello di dettaglio diverso, solo quelle da implementare negli sprint prossimi posseggono una descrizione più minuziosa mentre tutto il resto è riportato a grandi linee. Non avrebbe senso investire del tempo su delle specifiche che probabilmente rimarranno incomplete o cambiaranno.
Estimated - Tutti gli item all'interno del Backlog devono essere stimati in base alla definizione che il team ha concordato (solo per questo, sarebbe possibile scrivere un altro articolo, non è detto che non lo faccia in futuro, noi usiamo la tecnica degli Story Points che trovo molto interessante ma il team è libero di scegliere quella che più ritiene adatta alle persone che lo formano, per esempio anche solo semplicemente ore stimate). Questa misura può quindi essere utilizzata per assegnare la priorità alle voci nel Product Backlog e pianificare le versioni. Teoricamente, dopo ogni sprint, essi andrebbero ri-stimati in quanto si dovrebbe conoscere più contesto.
Emergent - Questo documento viene continuamente modificato/affinato; se necessario, vengono aggiunti nuovi requisiti e quelli esistenti possono essere modificati, ridefiniti con maggiore dettaglio o addirittura eliminati. Le specifiche non sono "bloccate" e sono sviluppate in modo iterativo insieme al software risultante per riflettere i cambiamenti delle esigenze del cliente, nuove idee o intuizioni, mosse della concorrenza, ostacoli tecnici che si presentano e così via. Un approccio diverso rispetto l'analisi dei requisiti tradizionale che consente di massimizzare il valore portato al cliente e ridurre al minimo lo sforzo per lo sviluppo.
Prioritized - Tutte le voci hanno una priorità ed il Product Backlog è ordinato seguendo tale graduatoria. Il Product Owner, con l'aiuto dello Scrum Team, decide la priorità: valore aggiunto, costi e rischi sono i fattori più comuni per la valutazione della sua assegnazione. Grazie a tale graduatoria, il Product Owner può decidere cosa dovrebbe essere fatto prima e cosa dopo.
In generale, gli elementi a più alta priorità devono fornire il maggior vantaggio economico: un’alta redditività (valore di business) a basso costo. Un'altra motivazione per aumentare la priorità di un elemento è quello di affrontare presto i rischi elevati, prima che questi si manifestino.

2. Sprint Backlog 📓

Lo Sprint Backlog è un elenco di attività identificate dal team di sviluppo da portare a termine per lo sprint.
Durante la riunione di pianificazione dello sprint, il team seleziona un certo numero di elementi dal Product Backlog, in genere sotto forma di user story, e identifica le attività necessarie per completarle.
Lo Sprint Backlog può essere mantenuto come un semplice foglio di calcolo, si può utilizzare un sistema di bug-activity tracking o qualsiasi altro software progettato per questo tipo di gestione.
Durante lo sprint i membri del team sono tenuti ad aggiornare lo Sprint Backlog non appena sono disponibili nuove informazioni o, in genere, almeno una volta al giorno.
Gli sviluppatori fanno del loro meglio per annotare la giusta quantità di lavoro necessaria per lo sprint ma può succedere che la pianificazione sia imprecisa. In quel caso, il team deve aggiungere o rimuovere attività.

Determinata una storia, viene presa dal Product Backlog e discussa con il team tecnico al fine di poterla dividere in diverse attività più semplici. Raggiunto un accordo, le varie attività vengono messe nella To do list: la lista di attività da implementare.
Quando si inizia a sviluppare un’attività, viene spostata nella In progress list, in questo modo ogni qual volta che si guarda ad essa si può conoscere che cosa è in development in quel preciso istante.
Le attività completate vengono rimosse dalla lista in progress e riportate nella parte To be verified, che contiene tutte le attività che devono essere verificate. Perché è necessario questo passaggio?
Perché lo Scrum Team dovrà effettivamente essere certo che la parte implementata fa quello che richiedono i requisiti e che sia priva di errori. Qualora essi non fossero soddisfatti, l’attività viene rimessa nella lista in sviluppo (in progress list), se invece la verifica va a buon fine, si sposta nella Done list, la lista di attività completate.
Dopo aver raggiunto un certo numero di attività completate, una versione del prodotto con le ultime modifiche verrà rilasciata e tutte le attività verranno spostate nella In production list, la lista di tutte le cose in produzione.

Il processo che porta una storia ad essere differenti task prima, reale parte di codice in seguito

3. Incremento ➕

Uno dei concetti fondamentali di Scrum è quello di fornire un miglioramento del prodotto, potenzialmente consegnabile al cliente, al termine di ogni sprint. Le ultime modifiche devono essere integrate con tutto quello già presente precedentemente. Questo rappresenta un cambio di mentalità radicale per chiunque sia abituato a lavorare con il modello Waterfall.
In che modo un progetto riesce a partorire un prodotto potenzialmente consegnabile al cliente in uno sprint di due o quattro settimane?

Nota: potenzialmente consegnabile non significa che il prodotto deve includere tutte le caratteristiche necessarie per il rilascio finale (se mai vi sarà), l'incremento consente al team di rilasciare nuove versioni frequentemente.
Potenzialmente consegnabile significa che il cliente può usare il prodotto e farlo funzionare come se fosse stato rilasciato, non ci sono prototipi intermedi. Ciò, offre al customer l'opportunità di evidenziare le parti che non funzionano come previsto e di dare nuovi spunti per migliorarle.

Il Product Increment o semplicemente Increment in inglese, rappresenta la somma di tutti gli elementi del Product Backlog completati durante lo sprint attuale più tutti quelli precedenti. L'idea di incremento è propizia per tutti gli stakeholder: consente di avere feedback su ciò a cui il team sta lavorando effettivamente, non si perde tempo in code freeze o cicli di correzione bug da parte del QA team: tale processo avviene alla fine di ogni sprint, al termine del quale saranno state implementate varie storie utente che contengono piccole aggiunte in termini di funzionalità.

L'incremento è la somma di tutte le voci del Product Backlog completate durante lo sprint corrente più tutte quelle degli sprint precedenti.

Ogni incremento è additivo a tutti quelli precedenti ed alla fine di ogni sprint il tutto è completamente testato, assicurando che le nuove parti siano integrate per bene.

Il flow mostrato in figura è piuttosto semplice e serve per riassumere l’intero processo in relazione agli artefatti. Il Product Backlog contiene una serie di elementi ordinati per priorità. Quelli candidati ad essere sviluppati nello sprint vengono presi uno ad uno, suddivisi in attività più piccole e messi nello Sprint Backlog. È importante sottolineare che gli elementi nel Product Backlog non contengono un linguaggio tecnico e non hanno riferimenti al codice. Quando un elemento del Product Backlog viene suddiviso in più piccole attività, quest’ultime sono fortemente legate al codice e contengono prettamente un linguaggio tecnico. Alla fine dello sprint alcuni elementi del Product Backlog saranno stati sviluppati e si potrà rilasciare un incremento del prodotto.

Al completamento di uno sprint, ogni feature all'interno dell'incremento deve soddisfare la definizione di Fatto (in inglese Done), il cui significato deve essere condiviso da chi esegue il lavoro e da chi deve accettarlo. È una combinazione di requisiti che devono essere soddisfatti al termine dello sviluppo di una user story più l'esecuzione dei processi necessari al rilascio del codice. Senza la definizione di Fatto non vi sarebbe modo di accertare che il lavoro effettuato possa essere inserito nell'incremento.
Il team utilizza i criteri del Fatto durante lo sviluppo per segnalare quando un'attività è terminata.
La definizione di Fatto viene utilizzata dal Product Manager per decidere quando il lavoro completato deve essere accettato e quindi incluso nell'incremento.
Se tale definizione pare non funzionare, può essere modificata per lo sprint successivo. Ogni caratteristica deve quindi essere considerata fatta prima che possa essere riportata nell'incremento, ciò garantisce che tutte le best-practice quali unit test, regression run, integration test e documentazione vengano eseguite e siano completate prima che il cliente possa utilizzare la nuova versione. Essendo probabilmente rilasciati come nuova versione, gli incrementi devono essere accuratamente testati, ben progettati, scritti con codice di alta qualità ed accompagnati da una buona documentazione delle nuove funzionalità fornite.

🖇️ Gli eventi all’interno di Scrum

Sono 4 gli eventi formali utilizzati in Scrum (con durata prefissata) per creare regolarità, sincronizzare le attività e ridurre al minimo la necessità di incontri non definiti. L’obiettivo di questi eventi è consentire trasparenza critica ed ispezione sull’andamento del progetto.

1. Sprint Planning 👨‍🏫

Lo Scrum Team al completo collabora durante questa riunione: il Product Owner condivide i suoi pensieri riguardanti gli obbiettivi da raggiungere nello Sprint, presenta il Product Backlog ordinato secondo priorità e risponde a tutte le domande che il team potrebbe avere.
Il team di sviluppo si impegna a determinare la mole di lavoro che questi può prende in carico per avere una pianificazione realistica.
Lo Scrum Master, in qualità di coach dello Scrum Team, osserva in che modo si svolge la pianificazione, pone domande probanti e s'adopera nella rimozione d'ostacoli per il raggiungimento di un risultato positivo.

Qualsiasi task che deve essere svolto durante lo Sprint si decide con lo Sprint Planning, ha una durata massima di otto ore per la pianificazione di uno Sprint da un mese oppure quattro ore per uno di due settimane.
È responsabilità dello Scrum Master assicurarsi che l'evento abbia luogo, che ne sia rispettata la tempistica e che i partecipanti comprendano il motivo di tale riunione.

Alla fine dell'incontro si dovrà avere:

Lo Sprint backlog, composto dalle storie che il team ha preso in carico. In uno scenario ottimale, queste storie avranno criteri di accettazione.
Gli obiettivi dello Sprint.
Un accordo da parte del team di fare il possibile per raggiungere gli obiettivi prefissati.

Per definire un goal realmente raggiungibile ed organizzare il lavoro, il team incaricato di svolgere un'attività si basa su parametri quali complessità, dimensioni e dipendenze della storia assegnatagli rispetto ad altre ad essa collegate. Si cerca sempre di avere attività per quanto possibile isolate da tutto il resto, che si possano svolgere in piena autonomia senza dover dipendere da altri fattori ma la realtà è un po' diversa ed è comune poter avere dipendenze verso altri team.

Il Product Owner dovrebbe presentarsi con degli appunti pronti riguardanti gli obbiettivi che vorrebbe fossero raggiunti nello Sprint che si sta per pianificare.
In caso vi siano più Product Owner, è importante che quello partecipante sia aggiornato riguardo il lavoro degli altri: è molto frustrante per i membri del team quando un Product Owner chiede cosa sia o non sia possibile svolgere a causa di dipendenze.

Non solo il Product Owner, anche i membri del team dovrebbero essere preparati: potrebbe esser stato necessario svolgere alcune ricerche prima dello Sprint Planning per rispondere ad eventuali domande riguardo l'architettura del software o pareri sulle implementazioni future.

Scendendo più nello specifico, vi sono poi due approcci che si possono utilizzare:

Primo Approccio - Sprint planning unico

L'approccio più semplice è quello di avere una riunione unica in cui si interfogliano momenti in cui si seleziona un'attività dal Product Backlog con momenti in cui il team di sviluppo discute ed acquisisce consapevolezza nel poter svolgere un determinato task ed essere consegnato per tempo. Utilizzando questo approccio, il team di sviluppo inizia determinando la sua capacità per completare il lavoro. Successivamente si seleziona un'attività del backlog verificando che si possa inserire ragionevolmente nello sprint, dati gli altri elementi già inclusi. Questo ciclo viene ripetuto sin quando non si ha più capacità di lavoro libera. In questo tipo di pianificazione, tutti e tre i ruoli dello Scrum team sono presenti per l'intero meeting.

Secondo approccio - Sprint Planning diviso

Un approccio alternativo consiste nel dividere la pianificazione dello sprint in due parti.

Durante la parte 1, dove si definisce cosa fare, il team di sviluppo determina la sua capacità nel completare il lavoro e prevedere quali elementi del Product Backlog ritiene possano essere consegnati entro la fine dello sprint. Durante questa parte, tutti e tre i ruoli dello Scrum team sono presenti per tutto il tempo.

Durante la parte 2, si definisce come realizzare ciò che è stato selezionato nella parte 1 creando un piano.
È usuale crearlo spezzettando gli elementi scelti dal Product Backlog in una serie di attività ancora più piccole, stimando in ore l'effort richiesto per completarle. Il team confronta quindi la stima effettuata rispetto la sua capacità, per verificare che il suo impegno iniziale fosse realistico.

All'inizio della parte 2 il Product Owner abbandona la riunione, lasciando il team di sviluppo e lo Scrum Master più a proprio agio nello svolgere le attività intermedie di pianificazione, per poi tornare alla fine, in modo che il team di sviluppo possa confermare o negoziare l'impegno preso durante la prima parte.

2. Daily Scrum 🗣️

È un confronto quotidiano, fondamentale, di controllo e aiuto nel gestire il flusso di lavoro durante lo sprint e portare a termine tutti gli obbiettivi.
Consente ai membri del team di sviluppo di condividere tra loro impressioni generali su ciò a cui si sta lavorando, in modo che si possa capire collettivamente quanto lavorare su una determinata cosa piuttosto che un'altra, quali attività iniziare prima e come organizzarsi al meglio.

Tutti i membri del team di sviluppo devono essere presenti mentre lo Scrum Master dovrebbe vestire il ruolo di allenatore e facilitatore. Non è una riunione in cui in genere partecipa il Product Owner.

Altri stakeholder potrebbero partecipare ai daily scrum: il Q&A team o chiunque voglia capire meglio come la squadra sta progredendo verso gli obbiettivi dello sprint. Queste persone dovrebbero ricevere un invito per una delle riunioni quotidiane con la chiara consapevolezza che saranno lì ad osservare, piuttosto che a partecipare attivamente. Il fine del meeting è quello condividere informazioni fra i membri del team di sviluppo, non di preparare un rapporto sullo stato del lavoro.

Molti sostengono che qualora il Product Owner parteci a questo tipo di meeting, anch'egli dovrebbe farlo essenzialmente in "modalità silenziosa" poichè, in genere, non ha nulla da dire: il suo valore aggiunto nel partecipare è quello di capire meglio cosa stia accadendo durante lo sprint.
Tuttavia si possono fare delle eccezioni nel caso uno o più sviluppatori richiedano informazioni esplicitamente. Se poche parole coincise sono sufficienti a fugare ogni dubbio, il Product Owner può rompere il suo silenzio, altrimenti fornirà più dettagli al di fuori della riunione, magari anche in privato. In genere i daily scrum meeting sono molto veloci, noi dedichiamo una ventina di minuti in media ogni mattina.

3. Sprint Review 📈

È un meeting che serve a mostrare a tutti gli stakeholder ciò che è stato sviluppato sino ad allora. Fornisce in modo trasparente una visione della condizione del prodotto, comprese eventuali verità sconvenienti. È un'occasione per porre domande, formulare osservazioni, suggerimenti e discutere le soluzioni migliori per poter andare avanti dato lo stato dell'arte.

Quali figure dovrebbero partecipare a questa riunione?

Il Product Owner, lo Scrum Master e il team di sviluppo dovrebbero essere presenti in modo che tutti possano ascoltare lo stesso feedback ed essere in grado di rispondere alle domande riguardanti lo sprint e l'incremento del prodotto.

Gli imprenditori, i dirigenti e i manager dovrebbero vedere i progressi in prima persona in modo che possano suggerire fix o modifiche. Utenti interni, esperti in materia, responsabili operativi ed altre squadre interne, se presenti, sarebbe utile partecipassero.

Reparto vendite, marketing, supporto, legali e altri team (sia di sviluppo che non) potrebbero voler partecipare a questa riunione per fornire feedback specifici in base alla loro area di competenza o per sincronizzare il lavoro dei propri gruppi con lo Scrum team.

Eventualmente, anche parti esterne interessate quali clienti, utenti, partner e autorità, possono fornire un prezioso feedback allo Scrum team e agli altri partecipanti.

4. Sprint Retrospective 💬

Mentre lo Sprint Review rappresenta un momento di ispezione del prodotto, lo Sprint Retrospective è un'opportunità per analizzare e migliorare il processo. Durante questa riunione, i team sono liberi di esaminare cosa stia accadendo, il loro modo di lavorare, identificare alternative per migliorare e metter su le basi per la loro attuazione. Tutto quello che può influenzare il modo in cui il team sviluppa il prodotto è soggetto a controllo e discussione, inclusi processi, pratiche, comunicazione, ambiente, artefatti, strumenti, ecc.

L'intero Scrum team dovrebbe partecipare: i vari membri operano in aree molto varie fra loro ed hanno una serie di prospettive ricche e diversificate, essenziali per identificare i miglioramenti da più punti di vista.

Lo Scrum Master partecipa sia perché è parte integrante del processo, sia perché può indicare in quali occasioni il team non aderisce agli accordi presi ed essere anche una preziosa fonte di conoscenza e idee per la squadra.

Alcuni sostengono che il Product Owner non dovrebbe partecipare. Probabilmente, averlo all'interno di questo meeting potrebbe impedire al team di essere completamente sincero o rivelare i problemi più difficili da risolvere.
Tuttavia, sebbene possa essere un rischio, il Product Owner è parte integrante di Scrum e come tale dovrebbe farne parte. Se c'è una mancanza di fiducia tra quest'ultimo ed il team di sviluppo e parlare in modo libero delle difficoltà avute non è una cosa che il team fa in modo naturale, forse il Product Owner non dovrebbe partecipare finchè lo Scrum Master non avrà aiutato ad instaurare un clima disteso tra le varie parti.

Supponendo che fiducia e rispetto reciproco siano ragionevolmente in essere, un Product Owner efficace è fondamentale per un workflow rapido e flessibile, per cui averlo allo Sprint Retrospective sarebbe ottimale.
Quest'ultimo è il canale di comunicazione attraverso il quale i vari requisiti giungono al team.
Cosa succede se qualcosa non va in quel punto del processo?
Potrebbe essere che le varie voci del Product Backlog non siano ben preparate sion dall'inizio della pianificazione.
In tali casi, verrebbe difficile identificare/valutare potenziali miglioramenti al processo se il Product Owner fosse assente.

🏁 Conclusioni

Le metodologie agili hanno portato un nuovo modo di affrontare il processo di sviluppo. Sebbene non siano perfette, permettono di rilasciare frequentemente nuove versioni del prodotto ed avere contemporaneamente un discreto controllo sulla qualità dello stesso. In un mondo sempre più esigente di novità, questo rappresenta un must per stare al passo con i tempi. Scrum, che è una delle tante metodologie agili, prova a fornire delle linee guida per affrontare tale processo senza improvvisazione.