Per lo sviluppo del progetto, il gruppo ha deciso di adottare una strategia agile. Nello specifico, anche come riportato nel paragrafo P8 delle regole di esame, è stata scelta una metodologia SCRUM-inspired, dove i componenti del gruppo, oltre a essere tre sviluppatori, hanno anche assunto i ruoli di committente e product owner. Per lo sviluppo del progetto, il gruppo ha utilizzato i seguenti strumenti:
I task sono stati suddivisi in base alle priorità assegnate a ognuno di essi. Infatti, i task aventi una priorità maggiore sono stati assegnati durante i meeting con tutti i componenti del gruppo mentre, i task con priorità inferiore sono stati svolti dal membro il quale avesse già completato i task prioritari assegnati. Per essere considerato completato, un task deve soddisfare i seguenti requisiti:
A inizio progetto, il gruppo ha partecipato a un meeting iniziale dove venivano presentati l’analisi del dominio e una possibile modellazione dell’architettura. In più, sono stati pianificati anche il numero e la durata degli sprint. Per quanto riguarda quest’ultimi, il team ha deciso di organizzarsi in sprint settimanali con l’obiettivo di avere una giusta quantità di tempo per realizzare i goal prefissati dallo sprint. In ogni sprint, l’ultimo giorno della settimana veniva utilizzato per organizzare il meeting di fine sprint nel quale venivano discussi due principali argomenti:
Avere meeting corposi ha permesso al gruppo di avere aggiornamenti continui sullo sviluppo del progetto, aspetto di fondamentale importanza.
La revisione di ogni task è stata svolta grazie a uno strumento di GitHub: la pull request. Infatti, avendo seguito la classica struttura di Git flow, il processo è stato il seguente:
Questo metodo di lavoro ha permesso al team di rimanere sempre aggiornato sulle modifiche al progetto indotte da nuove implementazioni.
Il testing automatico del progetto è stato eseguito utilizzando come strumento Scalatest essendo una tecnologia semplice e facile da integrare. Per la fase di building, il gruppo ha preferito utilizzare sbt e non Gradle in quanto era più facile da utilizzare con il linguaggio Scala. Infine, la continuous integration della relazione è garantita dall’uso di GitHub Pages il quale produce un nuovo deploy a ogni modifica di essa.