Sprint 1 retrospective

Sprint 1 retrospective

Analisi retrospettiva sull’organizzazione dello sprint 1

In questo file raccogliamo le valutazioni che abbiamo tratto sul nostro utilizzo della metodologia Scrum, le osservazioni su quali migliorie possiamo apportare per il prossimo sprint e le impressioni che questo periodo di lavoro ci ha lasciato.

Partiamo con il dire che alcuni di noi avevano già lavorato con la metodologia Scrum e questo ci è stato molto d’aiuto nel momento iniziale, quando ci siamo avvalsi dell’esperienza di alcuni di noi per partire con più decisione ed avere chiara fin da subito una visione del percorso del primo sprint.

Abbiamo impiegato molto tempo per stilare la documentazione dello Sprint planning e quindi per definire bene le user stories, i relativi task ed i punteggi di rilevanza. Riteniamo tutto il tempo speso in questa fase come ben investito, in quanto in seguito è stato molto più semplice lavorare senza continue interruzioni organizzative ma pensando praticamente solo a problemi tecnici ed implementativi.

Grazie all’accurata pianificazione preliminare, non abbiamo avuto la necessità di dover modificare il product backlog. Questo è dovuto principalmente al fatto che la nostra idea e la definizione delle user stories sono state molto riflettute e ponderate. Questa è la motivazione per cui non abbiamo avuto bisogno in seguito di effettuare la fase di grooming.

Abbiamo apprezzato molto il fatto che siano previsti meeting a scadenza regolare, questo è un mezzo che ci è stato utilissimo per avere dei feedback importanti dai nostri compagni di gruppo, il che ha aiutato soprattutto chi tra di noi aveva meno esperienza nell’ambito della programmazione web.

I nostri meeting si sono svolti molto regolarmente, all’incirca uno ogni due/tre giorni e ogni volta abbiamo ricavato beneficio dal discutere con i colleghi non solo dello sviluppo del codice individuale ma anche delle parti di unione del codice sviluppato da persone diverse e delle parti di revisione del codice altrui.

Sugli scrum meeting c’è anche una nota da fare, spesso sono durati più del tempo previsto dalla metodologia Scrum (40 minuti, a volte anche 1 ora, invece che 20 minuti), crediamo che questo sia dovuto un po’ alla nostra scarsa esperienza con questa metodologia ed un po’ anche al fatto che i meeting non erano a scadenza giornaliera ma un po’ più rari. In aggiunta abbiamo spesso approfittato degli scrum meeting per approfondire tematiche più complesse, per cui erano necessarie discussioni più prolungate.

In qualche occasione ci siamo ritrovati anche a lavorare in gruppo per affrontare errori complessi o merge di codice scritto da persone diverse. In particolare abbiamo seguito questo approccio nel periodo immediatamente precedente alla consegna, in cui ci siamo ritrovati a trarre le fila di tutte le user stories completate e ad unire tutte le varie funzionalità.

Non siamo riusciti a completare tutte le tasks che ci eravamo prefissati durante lo Sprint meeting perché abbiamo sopravvalutato la nostra velocità di esecuzione, ma non lo vediamo come un fattore negativo per due motivi:

• abbiamo pensato fin da subito di “alzare un minimo il tiro” per il primo sprint, in modo da avere la possibilità di verificare con precisione la nostra velocità di esecuzione a pieno ritmo;
• abbiamo impiegato una parte considerevole del tempo all’inizio dello sprint per studiare a fondo le tecnologie/i framework che abbiamo deciso di utilizzare come impalcatura per il nostro progetto.

Un’ultima nota su cui vorremmo soffermarci riguarda il fatto che abbiamo speso molto tempo per occuparci di compiti che non risultano né nello sprint backlog né nel project di GitHub ma che comunque hanno un peso fondamentale per lo sviluppo del progetto; questi sono principalmente compiti di impostazione dell’architettura e di integrazione di nuove componenti, come CI/CD o database remoti.