-
Notifications
You must be signed in to change notification settings - Fork 0
Home
- Marco Xausa
- Mattia Meneghin
- Riccardo Gilli
L’idea del nostro progetto è realizzare un sito web che permetta la visualizzazione delle statistiche di un torneo amatoriale di calcetto. Attraverso la piattaforma, l’organizzatore (MAF) potrà creare un torneo e gestire le iscrizioni delle squadre e la candidatura degli arbitri. Sarà disponibile una sezione notizie nella quale arbitri e giocatori potranno inserire informazioni e news. Oltre a questa funzione, ogni arbitro può accedere alla piattaforma per poter inserire i referti delle partite che ha arbitrato, con conseguente aggiornamento delle statistiche. L’utente che visualizza il sito senza essere loggato potrà semplicemente vedere le classifiche dei gironi, il tabellone finale e la classifica marcatori. Inoltre potrà procedere a candidarsi come arbitro o iscrivere una squadra se quest'ultime sono ancora possibili.
- github: https://github.com/MrcXausa/IngegneriaDelSoftware.git
- apiary: https://mrcxausa.docs.apiary.io/
- UI Repo: https://github.com/Mattiamene1/WebAppTorneo.git
- Heroku: https://ids-frontend.herokuapp.com/
La repository, oltre alla root principale, ha tre cartelle: controllers, middlewares e models. Queste rispettivamente contengono gli l'implementazione degli endpoints, i middlewares necessari(ad esempio per il check del token di login) e gli schema per il database mongodb. Nella root sono presenti il file server.js (il principale) e il file routers.js che contiene tutte le routespossibili implementate. Sono presenti diversi file funzionali cone .gitignore e .env.sample. Nella cartella di progetto locale sono presenti alcuni file non caricati su github in quanto setup di servizi esterni contenenti credenziali d'accesso a servizi di autenticazione terzi (firebase-key.json)
feature branching
link (primo foglio): https://docs.google.com/spreadsheets/d/1hJ5QkSRzjCNn2n8TOQD_BdcpN8CLl_1aP63Df5y8LuA/edit?usp=sharing
- il codice è stato adeguatamente commentato
- il codice è stato testato
- è stata scritta la documentazione
- il codice è stato committato e mergiato nella repository remota
Il goal per questo sprint è implementare le funzioni primarie della piattaforma, ossia la registrazione e login del maf e la creazione del torneo.
La programmazione dello sprint è stata tranquilla. La discussione riguardante quali user stories aggiungere allo sprint backlog è stata abbastanza condivisa da tutti, vista la capacity iniziale. La stima degli effort ha visto spesso da parte dei tre membri stime diverse, dovute anche alla diversa esperienza dei componenti.
Durante lo sprint review ci siamo trovati assieme per fare delle prove aggiuntive sul codice. Ci siamo inoltre confrontati sulla documentazione per vedere qualora vi fossero problemi.
Dopo aver discusso insieme e aver valutato i vari aspetti dell'implementazione dell'applicazione abbiamo deciso di suddividere la user story "visualizzazione Dati" in più userstory:
- visualizzazione dati gironi
- visualizzazione dati tabellone
- visualizzazione classifica marcatori
- visualizzazione partite programmate e disputate
- visualizzazione albo d'oro rivedendo così l'importance di diverse user stories oltre a queste
Lo sviluppo delle api è cominciato un po' a rilento, dovuto anche alla necessità di prendere confidenza con la nuova piattaforma. Le prime due user stories hanno richiesto più tempo rispetto alle seconde due. In generale tutto il gruppo è d'accordo che come primo sprint il carico di lavoro inserito nello sprint backlog sia stato adeguato, in quanto siamo riusciti a portare a termine per tempo le api richieste (anche se con un frontend "basico" e magari non sempre "esaustivo" nei controlli). L'iterazione degli elementi del gruppo è stata decisamente migliore rispetto a quella avuta durante la prima parte del corso e i momenti di condivisione di idee e opinioni sono decisamente aumentati. Un membro del gruppo ha avuto maggiori difficoltà ed impegni durante questo primo sprint. Visto però il suo importante contributo nella prima parte del corso è stato comunque aiutato dal resto del gruppo. Un'aspetto condiviso su cui lavorare per il prossimo sprint è la miglior gestione del tempo da parte dei membri del team, riuscendo a dilazionare meglio durante la settimana i momenti di sviluppo di codice e lavoro sulle task, mantenendo un maggiore impegno a rispettare anche i daily scrum meeting.
Il goal per questo sprint è implementare le funzioni principali (subito seconde a quelle del primo sprint) della piattaforma, ossia log in Arbitro, l'avvio torneo, programmazione partite, la candidatura della squadre, l'approvazione delle squadre, la visualizzazione delle partite e l'inserimento dei referti.
La programmazione dello sprint è stata eseguita correttamente, anche se non è stato considerato il tempo necessario per l'implementazione dei test finali. La discussione riguardante quali user stories aggiungere allo sprint backlog è stata abbastanza condivisa da tutti, vista la capacity iniziale. La stima degli effort ha evidenziato nuovamente stime diverse. Sprint backlog e burndown chart link: https://docs.google.com/spreadsheets/d/1hJ5QkSRzjCNn2n8TOQD_BdcpN8CLl_1aP63Df5y8LuA/edit?usp=sharing
link: https://docs.google.com/spreadsheets/d/10BRcD4pxxC2xOm4vqWm0oPN-0ZCNahQYA83wal3I98w/edit?usp=sharing
Durante lo sprint review ci siamo trovati assieme per testare il codice. Ci siamo inoltre confrontati sulla documentazione per vedere qualora vi fossero problemi. Ci siamo inoltre aiutati in situazioni di blocco, ove spesso, l'aiuto di un componente ha velocizzato la risoluzione.
Rispetto lo sprint precedente sono state riviste alcune importance, ed in generale sono state rimappate tutte in multipli di 10
Lo sprint è cominciato in maniera più sciolta del primo. La user story inserimento referti è risultata essere più impegnativa del previsto. E' emerso che la mole di lavoro del secondo sprint inserito nello sprint backlog sia stato eccessivo, poiché è stato un po' sottovalutato l'impegno per i test automatici. In generale nella stima del tempo dei singoli task è stata fatta una diffusa sottostima minima. Nonostante ciò, le user stories sono state terminate tutte. Il membro del gruppo che ha avuto difficoltà nel primo sprint ha implementato due userstories.
Il deploy finale prevede un frontend deployato su heroku tramite github actions, con un backend anch'esso su heroku che ci ha permesso di gestire la parte ci continuos integration e continuous deployment e un database remoto gestito da un cluster mongodb. link frontend: https://ids-frontend.herokuapp.com/