Il gruppo ha adottato una metodologia Agile per la gestione e lo sviluppo del progetto.
In particolare, è stato scelto il metodo Scrum, apprezzato per la sua flessibilità e capacità di adattarsi alle esigenze del team e del progetto, consentendo di produrre, a ogni iterazione, nuove funzionalità o miglioramenti delle esistenti.
Per la coordinazione del team e la gestione del progetto sono stati utilizzati i seguenti strumenti:
Il team è stato organizzato nel seguente modo:
La suddivisione dei task è stata gestita in modo collaborativo durante le riunioni di pianificazione degli sprint, consentendo a tutti i membri del gruppo di partecipare attivamente alla definizione delle attività da svolgere.
Nel primo incontro (Sprint Planning) sono stati individuati i task principali e ne sono state assegnate le priorità in base alla rilevanza delle funzionalità, costituendo così il Product Backlog. In questa fase è stata inoltre definita la Definition of Done, secondo la quale una funzionalità si considera completata solo quando:
Durante le successive pianificazioni degli sprint, i task sono stati ulteriormente scomposti in attività più piccole (Sprint Backlog), favorendo un’equa distribuzione del lavoro e una gestione più agevole delle attività operative.
Al termine di ogni sprint, vengono inoltre redatti una Sprint Review e una Sprint Retrospective, volte rispettivamente a:
In una prima fase di analisi e progettazione, il gruppo ha svolto un meeting iniziale finalizzato alla definizione dell’architettura generale del progetto, durante il quale sono stati stabiliti anche la durata degli sprint e le modalità delle iterazioni successive.
Il team ha deciso di adottare sprint settimanali/bisettimanali in base alle disponibilità del team.
La scelta di organizzare sprint di lunghezza moderata è stata motivata dall’obiettivo di sviluppare funzionalità in tempi ridotti e ottenere feedback frequenti dallo stakeholder, mantenendo un equilibrio tra la qualità del prodotto e la velocità di sviluppo.
La revisione del lavoro è stata gestita tramite un meccanismo basato sulle pull request.
Ogni funzionalità è stata sviluppata in un branch dedicato e successivamente integrata nel branch develop, consentendo ai membri del team di lavorare in parallelo senza interferire con il flusso principale.
Al termine di ciascuno sprint, le modifiche consolidate in develop sono state unite nel branch main mediante pull request. Per essere approvata, ogni pull request su develop ha dovuto ricevere l’approvazione di tutti i membri del gruppo. Questo approccio ha garantito un aggiornamento costante tra i membri e un ulteriore livello di controllo e validazione del codice prima della sua integrazione definitiva.
Per il testing automatico è stato scelto ScalaTest, strumento noto e facilmente integrabile con l’ambiente di sviluppo.
Come build tool è stato adottato sbt, pensato specificamente per progetti Scala.
Per mantenere una formattazione coerente del codice è stato impiegato scalafmt, che assicura uno stile uniforme all’interno del team.
Per corregge possibili errori di stile e sintassi è stato integrato scalafix, che segnala come warning al programmatore problemi di sintassi, miglioramenti nella sicurezza del codice, cleanup del codice non utilizzato.
L’intero progetto e la relativa relazione sono stati gestiti tramite GitHub.
Per automatizzare i processi di test e controllo qualità, è stata configurata una pipeline di Continuous Integration mediante GitHub Actions, la quale si attiva automaticamente a ogni nuova pull request sul branch di sviluppo.
I workflow configurati eseguono le seguenti azioni:
scalafmtCheckAll, per mantenere una codebase coerente e leggibile.