Home
Progetto: Event Manager
Link al repository di GitHub per il calendario pubblico e la lista di eventi pubblici: https://github.com/marck283/Calendar.git
- Marco Lasagna: marck283 (numero di matricola: 209977)
- Guglielmo Zocca: GuglielmoZocca (numero di matricola: 209339)
- Enrico Fornasa: enrico-fornasa (numero di matricola: 209027)
Sistema rapido ed intuitivo per la gestione della quotidianità dell’utente. Offre la possibilità di organizzare ed iscriversi ad attività pubbliche (ad accesso libero) e private (ad accesso limitato), nonché l’organizzazione di eventi personali. Tutto ciò è accompagnato da un numero predefinito di “operazioni automatizzate” sui dati associati ad un’attività, che in quanto tali non richiedono alcun intervento attivo da parte del fruitore del servizio.
Il seguente è il link alle API del progetto: https://app.apiary.io/eventmanager12/editor
Cartelle:
-static: contiene la UI del nostro servizio, nello specifico i vari html utilizzati, gli script .js (nella sottocartella "scripts") e .css (nella sottocartella "styles") associati.
-app: contiene i codici .js (con la definizione dei vari router) per la gestione del back-end del nostro servizio, e come sottocartella si ha i .js delle collezioni Mongodb utilizzate nel nostro sevizio. Nello specifico il folder "events", contiene tutti .js che descrivono i router per la gestione delle chiamate che riguardano gli eventi (creazione,visualizzazione, etc.). Infine, nel file "app.js" è descritta la gestione dei vari middleware per i metodi RESTful.
File:
-oas3.yaml: documentazione dell'api.
-index.js: il file .js per il collegamento al db e l'avvio del nostro server (che pertanto si pone "in ascolto")
La strategia di branching utilizzata è la Feature Branch Workflow.
Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing
I seguenti criteri saranno considerati perché si possa ritenere concluso un certo use case:
- il codice dovrà essere funzionante (Node.js, html);
- tutti i test case che si definiranno per lo use case dovranno essere verificati e nel caso che un test case fallisca è necessario trovare una soluzione;
- tutta la documentazione legata alla user stories dovrà essere completata;
- La documentazione sulle API (Apiary) dovrà includere tutte le funzionalità fornite della parte di servizio che si vuole definire per la use story;
- tutti i documenti e i codici riguardanti la use story dovranno essere presenti nel repository GitHub del gruppo;
- tutti i membri del team dovranno avere eseguito il commit delle funzionalità da loro implementate sul branch master;
- implementare tutte le funzionalità (task) che abbiamo definito per la user story, quindi nella project board tutti i task dovranno essere nella sezione “Done”;
- La funzionalità che si implementa dovrà essere provata importandolo su un’ambiente di sviluppo;
- Si dovrà unire tutte le funzionalità (dettate dalle user story) in unico software funzionante;
- È necessario che ogni funzionalità associata ad una user story sia ben integrate con le altre legate ad essa.
Con questo primo sprint intendiamo fornire le principali funzionalità di base del servizio, quali: -creazione di un evento; -vista informazioni evento. Vorremmo inoltre sviluppare i meccanismi di login per accedere al sistema, oltre che una prima forma di interfaccia grafica.
Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing
Capacity del gruppo: 297
Velocity del gruppo: 208
Meeting sprint planning:
Durante il meeting ci siamo confrontati con il product backlog della Milestone #4. Abbiamo constato che certe user stories erano, secondo lo scopo del sistema da implementare e del tempo da dedicarci, più prioritarie di altre che potevano essere svolte in seguito. È stato quindi effettuato un processo di “Redefining priorities”. Abbiamo inoltre notato che certe use stories contenevano troppe funzionalità con priorità diverse quindi si è provveduto ad un processo di “Splitting stories”. Abbiamo stimato la capacity in funzione delle ore che potevano dedicare al massimo al primo sprint. Stabilita quindi una capacity di 297 ore, ne abbiamo preso il 70% per calcolare una velocity di 208 ore. Abbiamo poi impiegato come tecnica d’inserimento delle user story quella del “Commitment-driven iteration planning”. Finito ciò a seconda dei task che abbiamo ottenuto, abbiamo deciso il goal del nostro sprint. È stato concordato che gli "Sprint daily meeting" avvenissero di sera, e, infine, come giornata ddi completamento della demo indicativamente il 20/05/22.
Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing
In questo caso, il foglio di lavoro utilizzato per i test case è chiamato "Test Cases".
Raccolta feedback:
- l'applicazione manca di un'interfaccia intuitiva, che permetta all'utente di comprendere in che modo utilizzarla;
- dalla vista calendario, non è possibile capire quale evento è presente in quale giornata senza cliccare sopra la casella;
- i layout delle interfacce sviluppate finora sono oltremodo banali;
- è apprezzata la possibilità di visualizzare gli eventi sia in forma di calendario che in forma di elenco;
- sarebbe gradita la possibilità di non includere automaticamente l'organizzatore di un evento ai partecipanti;
- non è apprezzato il fatto che nel momento in cui un evento pubblico a cui ci si iscrive viene aggiunto al proprio calendario personale, nella pagina di informazioni rimane ancora attivo il tasto di iscrizione;
- è spesso ambiguo capire il risultato di un azione compiuta (e.g. non è chiaro il perché determinati eventi non vengano visualizzati nel calendario pubblico);
- non è chiaro all'utente cosa venga visualizzato nei diversi calendari;
- è apprezzato il fatto di poter visualizzare nel calendario pubblico i soli eventi a cui non ci si è iscritti;
- è apprezzata il metodo di programmazione di un nuovo evento, con i controlli sugli inserimenti (e.g. la data inserita non può precedere la data corrente);
- è poco chiaro quali controlli vengano effettuati tra le diverse funzionalità (e.g. sui dati inseriti nei form);
- è stata particolarmente apprezzata la distinzione tra calendario pubblico e personale, il che evita che si accavallino proposte (eventi pubblici) alla propria routine (eventi a cui si risulta iscritti).
In questo sprint non abbiamo terminato:
- storico eventi;
- visualizzazione biglietto. Li aggiungeremo quindi al prossimo: è stata presa questa scelta per via del fatto che la priorità era relativamente bassa e il tempo a nostra disposizione non era molto. Nello specifico, abbiamo deciso di tenere fra le prime stories del secondo sprint la user story "Visualizzione biglietto evento" in quanto è direttamente legata alla programmazione degli eventi.
Storico eventi: "importance" da 12 a 21 L'accesso alla funzionalità "Storico eventi" non è immediata, i.e. non è qualcosa a cui ci sia aspetta l'utente sia necessariamente interessato.
Invitare utente ad un evento: "importance" da 20 a 16 (al posto di "Programmare eventi privati"). Abbiamo ritenuto che fosse più importante occuparsi del meccanismo di inviti ad un evento piuttosto che la possibilità di organizzare eventi privati. In particolar modo, proprio gli eventi privati impongono l'invito di partecipanti scelti dall'utente, dunque poggiano su questa funzionalità.
Valutare eventi: "importance" da 18 a 20 (al posto di "Programmare eventi privati"). L'intenzione del gruppo è quella di occuparsi innanzitutto della realizzazione di tutte le tipologie di eventi (in numero 3 -> pubblico, privato e personale), a discapito della possibilità di valutare eventi che passa quindi in secondo piano.
Si è deciso di posizionare le user stories riguardanti la feature dell'"amicizia" più in basso nella scala, in quanto la loro realizzazione non è richiesta da altre user stories e, pertanto, l'assenza non rovinerebbe la user experience.
Ordinare eventi: "importance" da 26 a 22 (al posto di "Rifiutare l'amicizia"). Si ritiene meno importante la possibilità di rifiutare una richiesta d'amicizia della possibilità di ordinare la vista degli eventi.
Accettare invito ad un evento: "importance" da 27 a 19 (al posto di "Caricare dati aggiuntivi ad un evento"). Abbiamo convenuto che l'utente voglia poter sin da subito accettare inviti ad eventi, visto e considerato che si tratta della funzionalità complementare all'invito. Si osserva inoltre che gli eventi privati possono funzionare solo a fronte di un sistema ben realizzato di inviti ad utenti.
Accettare invito ad un evento: "importance" da 19 a 18 (al posto di "Programmare eventi privati").
Ricerca utente: "importance" da 28 a 21 (al posto di "Richiedere amicizia"). Per vai del fatto che il poter ricercare un utente migliorerebbe di molto l'esperienza nell'invito di persone ad eventi, riteniamo che sia più importante della possibilità di richiedere l'amicizia.
Sezione dedicata alle notifiche: "importance" da 32 a 24 (al posto di "Caricare contenuti multimediali ad un evento"). La bacheca delle notifiche è estremamente importante per l'utente finale in quanto gli permette di essere informato su inviti ad eventi ed annullamenti, oltre che di richieste di amicizia. Segue quindi che lo si ritenga pù importante della possibilità di Caricare contenuti multimediali ad un evento.
Annullamento evento: "importance" a 25.
Rifiutare amicizia: "importance" da 26 a 33 (al posto di "Visualizzare cancellazione evento").
Visualizzazione dati evento: "importance" a 33.
Riteniamo più importante la possibilità di espellere un partecipante da un evento organizzato rispetto alla condivisione del proprio calendario personale (una feature che passa in secondo piano rispetto alla gestione degli eventi).
Selezionare luogo evento map: "importance" da 37 a 28 (al posto di "Richiedere l'amicizia").
Selezionare data evento calendario: "importance" da 38 a 23 (al posto di "Visualizzare amici").
Invitare utente ad un evento: "importance" da 16 a 17.
Filtro utenti: "importance" da 17 a 18.
Accettare l'invito ad un evento: "importance" da 18 a 19.
Programmare eventi privati: "importance" da 19 a 20.
Valutare eventi: "importance" da 20 a 21.
Accettare amicizia: "importance" da 21 a 42. Come già indicato, il sistema di amicizia non è una feature principale del sistema: pertanto riteniamo sia giusto ridurne l'importanza.
Selezionare data evento da calendario: "importance" da 23 a 25 (al posto di "Anullamento evento"). Poter selezionare la data da un apposito calendario piuttosto che scriverla a mano è solamente una comodità: pertanto si è deciso di dare la precedenza alla possibilità di annullare eventi organizzati.
Operazioni automatizzate: "importance" da 35 a 39 (al posto di "Visualizzare espulsione").
Modifica operazione da eseguire dell'evento: "importance" a 39. L'importanza di modificare l'operazione automatizzata imposta su un certo evento è stata posta a 39, pari a l'importanza della user story "Operazioni automatizzate".
Modificare dati caricati su un evento: "importance" a 27. L'importanza di modificare i dait caricati su un certo evento è stata posta a 27, pari a l'importanza della user story "Caricare dati aggiuntivi ad un evento".
Per quanto riguarda lo sprint planning, abbiamo innanzitutto modificato sensibilmente il product backlog della Milestone #4, allo scopo di suddividere user stories complesse in più semplici. Abbiamo poi selezionato le user stories fondamentali a livello di importanza in questa prima fase.
Nel burndown chart abbiamo indicato una linea per:
- ogni task
- l'estimate totale reale di ogni task;
- l'estimate totale ideale di ogni task. L'estimate ideale viene calcolato su 9 giorni in base all'estimate della velocity stabilita nello Sprint Planning. L'estimate reale viene calcolato su 9 giorni in base ai ricalcoli degli estimate di ogni task: è risultato molto maggiore rispetto all'ideale, dunque ci prefiggiamo di eseguire dei calcoli più accurati nel prossimo sprint.
Una volta suddivise le stories scelte in task, ci siamo divisi il lavoro in "aree". Nello specifico:
- funzionalità legate alla programmazione degli eventi;
- funzionalità legate alla visualizzazione di informazioni specifiche (e.g. eventi pubblici/personali, oltre che profili utente);
- la gestione e la visualizzazione dell'intero insieme di eventi (e.g. in forma di calendario o elenco).
Durante lo sprint, sono inizialmente emerse problematiche riguardo la limitata conoscenza del linguaggio js e del framework Node, in particolar modo da parte di un membro: per coprire queste mancanze si è dovuto necessariamente collaborare più del previsto allo sviluppo di certi task, ma il ritmo della progressione è ritornato nella norma in poco tempo.
In generale, mentre i layout hanno subito relativamente pochi cambiamenti rispetto le forme iniziali, lo stesso non può essere detto degli script e moduli js, che abbiamo continuato a ritoccare fino all'ultimo giorno dello sprint: questo per via di falle mai notate o per sostituire frammenti di codice che, seppur funzionanti, non erano propriamente corretti.
In concordanza con la tecnica di branching adottata (i.e. Feature Branch Workflow), abbiamo realizzato un branch separato per ogni funzionalità da sviluppare. Prima del merge finale sul branch "master", abbiamo dedicato il branch "unione" alla raccolta di tutte le funzionalità per risolverne eventuali conflitti.
Nonostante gli innumerevoli meeting, le incomprensioni tra noi non sono purtroppo mancate, dalla banale posizione di un pulsante all'interno di una risorsa html alla logica di funzionamento di determinate feature: in ogni caso, ci siamo sempre dimostrati in grado di superare le varie problematiche.
Si osserva inoltre che l'estimate assegnato a molti task è risultato, a lavoro inoltrato, notevolmente sottostimato: è stato quindi necessario un ricalcolo degli estimate residui. Segue quindi che il valore della velocity è salito a 293, rispetto il calcolo iniziale di 207 effettuato nella fase di Sprint Planning.
La pratica agile dei meeting da noi adottata è risultata estremamente importante per:
- comprendere e porre rimedio a molte difficoltà (aiutandoci reciprocamente);
- determinare la "rotta" del progetto di volta in volta;
- stabilire il punto della situazione.
Teniamo a specificare che tutto lo sprint è stato svolto a distanza, pertanto non abbiamo avuto alcun ambiente di lavoro ben preciso: al di là delle difficolta date dalla connessione (spesso altilenante) di alcuni membri, il lavoro è stato svolto senza troppi intoppi e ci aspettiamo di mantenere l'approccio anche alla fase successiva. Fatta eccezione per determinate funzionalità, l'idea di fondo del progetto non è radicalmente cambiata in vista del prossimo sprint. Grazie al product backlog refinement abbiamo una più chiara idea dell'ordine di implementazione da seguire e ci preoccuperemo di sviluppare le feature rimanenti, oltre che migliorare l'interfaccia utente.
Rispondiamo di seguito ad alcuni feedback raccolti nella Sprint review (si veda l'enumerazione nella review):
- ci si aspetta di risolvere il problema aggiungendo una forma di "legenda delle operazioni" alle pagine che la richiedono;
- si potrebbe fare in modo che appaia una sferetta colorata sovrapposta ai giorni del calendario che contengono almeno un evento;
- possibilmente, ci preoccuperemo di migliorare sensibilmente il lato front-end, utilizzando, ad esempio, librerie come "bootstrap";
- faremo in modo di non includere automaticamente l'organizzatore di un evento ai partecipanti;
- faremo in modo di rimuovere il tasto di iscrizione dalle pagine di informazioni degli eventi a cui si risulta iscritti;
- renderemo visivamente più chiari gli effetti delle varie operazioni;
- ci si aspetta di risolvere il problema aggiungendo una forma di "legenda dei calendari" ai diversi calendari;
- ci si aspetta di risolvere il problema aggiungendo una forma di "legenda dei controlli".
Con questo secondo sprint intendiamo aggiungere altre funzionalità di base del servizio, dove alcune complementarie ad altre già sviluppate (e.g. disiscrizione/iscrizione):
- modificare evento;
- disiscriversi da un evento;
- invito ad un evento;
- programmare eventi privati.
Aggiungeremo inoltre funzionalità secondarie, come:
- visualizzare biglietto evento;
- storico degli eventi sul calendario pubblico;
- ricerca di un utente (per invitarlo).
Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing
Capacity del gruppo: 270
Velocity del gruppo: 265
Meeting sprint planning:
Durante il meeting ci siamo confrontati con il product backlog "refined" dello Sprint #1. Abbiamo in particolare covenuto che la User Story "Sezione dedicata alle notifiche", secondo il goal dello sprint e del tempo da dedicarci, ha priorità più alta di "Valutare eventi". Come lo scorso Sprint, è stato quindi effettuato un processo di "Redefining priorities". Abbiamo inoltre notato che "Sezione dedicata alle notifiche" conteneva troppe funzionalità con priorità diverse (alcune delle quali al di fuori dello scope del goal), quindi si è provveduto ad un processo di "Splitting stories" (analogamente allo Sprint #1). Ancora una volta, abbiamo stimato la capacity in funzione delle ore che potevano dedicare a questo secondo Sprint. La capacity calcolata nel primo Sprint è pari a 297 ore, mentre la velocity effettiva 293: segue quindi che il focus factor è all'incirca il 98%. Posto il focus factor pari a 98%, dalla capacity di 270 ore calcolata per questo secondo Sprint deriva una velocity stimata di 265 ore. Abbiamo mantenuto come tecnica d'inserimento delle user story nello sprint backlog quella del "Commitment-driven iteration planning". Si osserva che abbiamo riportato alcuni task già presenti nello Sprint Backlog #1: questo per via del fatto che risultavano incompleti. Lo stesso vale anche per le User Stories "Storico Eventi" e "Visualizzare biglietto evento". Abbiamo inoltre aggiunto dei nuovi task a certe User Stories in quanto assenti dallo Sprint precedente. È stato concordato che gli "Sprint daily meeting" avvenissero di sera, e, infine, come giornata di completamento della demo indicativamente il 05/06/22.
