Torniamo a dare uno sguardo dietro le quinte
Gli eventi e alcuni imprevisti hanno influenzato il nostro approccio agli Sprint e allo stesso tempo hanno confermato l'importanza delle retrospettive mensili nel nostro team.
The show must go on
The show must go on
Inside my heart is breaking
My makeup may be flaking
But my smile, still, stays on
Era il 15 Dicembre 2023, esattamente il numero 7 di questa newsletter (oggi siamo fieramente a 35, un sentito ringraziamento a chi ci segue), quando abbiamo dato uno sguardo dietro le quinte di Elly e vi abbiamo raccontato il modo in cui lavoriamo in Ellycode. Sembra passato poco tempo, ma in realtà in quei giorni c’era SMAU 2023 a cui poi è seguita la fine del periodo di beta il 29 Febbraio 2024 e successivamente il lancio commerciale di Elly ad AIWEEK 2024 lo scorso Aprile.
Questi eventi hanno stravolto il nostro modo di lavorare, mettendo un po’ in crisi le pianificazioni che avevamo fatto: il nostro lavoro era scandito dagli Sprint, un elemento del framework SCRUM, che definisce un periodo di tempo nel quale viene creato un incremento di prodotto pronto per essere rilasciato.
Nel nostro caso questo periodo di tempo era di due settimane, preceduto dalla cerimonia di Sprint planning, in cui viene pianificato il lavoro da svolgere, e seguito da una cerimonia di Sprint review, in cui il team presenta il lavoro completato. A monitorare il lavoro giornaliero c’è poi il Daily Scrum, delle brevi riunioni quotidiane per coordinare il lavoro e identificare gli ostacoli.
Con il lancio di Elly è diventato sempre più difficile per noi restare all’interno degli sprint e più di una volta abbiamo dovuto modificare la finestra temporale delle due settimane per poter avere un incremento di prodotto rilasciabile. Questo è stato il primo campanello di allarme che ci ha fatto pensare che qualcosa non stava funzionando a dovere, quindi, approfittando delle nostre retrospettive mensili, abbiamo chiesto ad Antonio, il nostro DevOps Engineer, di aiutarci a capire come affrontare il problema.
La retrospettiva è sempre stato per noi un momento importantissimo, è un appuntamento mensile in cui ci vediamo di persona e ci confrontiamo su come migliorare il processo e pianifichiamo gli aggiustamenti necessari. Nella storia d Elly è sempre stato un momento rivelatore e ci ha permesso di maturare sempre di più come team e come singoli. Durante quel particolare meeting di retrospettiva sono venute fuori principalmente tre difficoltà:
durante lo sprint le priorità hanno cominciato a cambiare troppo spesso
nonostante il tempo che dedicavamo alla stesura delle user story, l’analisi delle attività da svolgere risultava spesso incompleta o poco approfondita durante lo sviluppo, rendendo le stime poco accurate
abbiamo diverse linee di sviluppo con priorità mutevoli nel tempo, cosa che rende difficile la pianificazione.
Antonio ci ha quindi proposto di rimuovere, in via sperimentale, il vincolo temporale degli sprint, passando da SCRUM a Kanban, almeno in parte.
In Kanban non ci sono sprint, il lavoro procede in modo continuo senza interruzioni e il team decide le attività da svolgere in base alle priorità correnti e alla capacità disponibile. Il lavoro viene visualizzato su una bacheca con colonne che rappresentano gli stati di avanzamento ed è possibile spostare liberamente le attività tra le colonne, in modo che i cambiamenti possano avvenire senza interruzioni del flusso di lavoro.
Abbiamo quindi ristrutturato la nostra board introducendo degli stati di avanzamento nuovi, lungo i quali avviene il lavoro quotidiano.
Partendo dal Backlog, dove teniamo tutte le user stories organizzate in features, abbiamo diviso la colonna dei To Do in due colonne, Analysis e Ready, per risolvere il problema numero 2 della lista precedente. In questo modo infatti, quando una storia viene presa dal Backlog per essere lavorata, viene prima analizzata e solo quando è chiaro il lavoro da fare viene spostata in Ready. Questo ci ha permesso di suddividere il tempo di planning di tutte le attività dello sprint in tanti momenti di analisi delle singole attività, che di solito affrontiamo o in una call di scopo oppure, nei casi più complessi, trasformando l’attività in uno spike esplorativo allo scopo di chiarire i punti oscuri. Quando una user story è in Ready può essere spostata In progress e lavorata, seguendo l’ordine di priorità stabilito (le user stories più in alto sono prioritarie rispetto a quelle in basso).
Per il punto 3 della lista invece abbiamo introdotto le Swimlanes, una funzionalità che permette di raggruppare orizzontalmente le schede in base a determinati criteri. Nel nostro caso il criterio è stato un misto di linee di sviluppo e priorità, che ha portato alla seguente suddivisione:
Bug - in cui raggruppiamo tutti i bug segnalati dagli utenti o dal team stesso
Importatori - in cui raggruppiamo tutte le attività legate allo sviluppo degli imporatori dati
Default - in cui raggruppiamo le storie di avanzamento del prodotto
Operations - in cui raggruppiamo tutte le attività legate al processo, all’infrastruttura e alle automazioni
Utilizzando le board di Azure DevOps è possibile dare anche un po’ di colore, sia alle card che alle swimlanes, in modo da rendere evidenti gli aspetti salienti dello stato corrente all’osservatore.
In questo modo abbiamo avuto una maggiore efficienza nelle attività di lavoro e siamo riusciti a migliorare alcuni nostri punti deboli, ma ha anche introdotto un problema abbastanza evidente legato alla definizione di uno sprint:
quando avviene il rilascio del lavoro svolto?
Con gli sprint era abbastanza semplice rispondere a questa domanda: ogni due settimane di sviluppo si rilasciava l’avanzamento fatto. Adesso invece quando eseguiamo il rilascio?
Qui le possibilità possono essere diverse, ma le due più interessanti sono il rilascio continuo e il rilascio schedulato; con il rilascio continuo ogni attività finita viene immediatamente rilasciata, e sul lungo periodo questo sarà un bell’obiettivo da raggiungere; tuttavia per il momento abbiamo preferito percorrere la strada del rilascio schedulato: abbiamo fissato un giorno in cui avviene il rilascio di tutte il lavoro che si trova nello stato Done. Nel nostro caso è il martedì, in modo da avere il lunedi per fare delle verifiche manuali, ma avere una cadenza settimanale ci permette di scandire bene il lavoro nonostante la mancanza degli sprint.
Discorso a parte meritano gli Hotfix, cioè risoluzioni a malfunzionamenti in produzione segnalati dai nostri sistemi di monitoraggio o dai clienti: in quel caso l’intervento e il rilascio sono immediati.
È quindi da qualche settimana che ogni martedì i nostri clienti si ritrovano degli aggiornamenti di Elly - molto apprezzati, a dire la verità - ma la morale della storia non è il cambio di approccio, ma la necessità di adattamento alle varie fasi della vita del prodotto e della squadra: interrogarsi continuamente su come si sta lavorando e su come si sta portando valore ai propri clienti è la chiave del successo di un progetto software e di un team.
Speriamo che questo dietro le quinte vi sia piaciuto e se volete provare con mano Elly non dovete far altro che contattarci: saremo felici di mostrarvi il frutto della passione che mettiamo ogni giorno nel nostro lavoro. Se poi oggi - venerdì 28 giugno - siete a Catania e passate per Coderful, trovate al nostro banchetto Diego, Salvatore e Antonio pronti a rispondere a ogni vostra curiosità.