Home

Progetto: Event Manager

Introduzione

Link al repository di GitHub per il calendario pubblico e la lista di eventi pubblici: https://github.com/marck283/Calendar.git

Membri

• Marco Lasagna: marck283 (numero di matricola: 209977)
• Guglielmo Zocca: GuglielmoZocca (numero di matricola: 209339)
• Enrico Fornasa: enrico-fornasa (numero di matricola: 209027)

Idea di progetto

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.

Link Apiary

Il seguente è il link alle API del progetto: https://app.apiary.io/eventmanager12/editor

Le modifiche citate di seguito sono state apportate nello Sprint #2.

Rispetto alla versione v1, sono state aggiunte le seguenti API:

• api/v2/authentications POST;
• api/v2/EventiPrivati/{idEvento}/Iscrizioni POST;
• api/v2/EventiPubblici/{idEvento}/Iscrizioni/{idIscrizione} DELETE;
• api/v2/EventiPrivati/{idEvento}/Iscrizioni/{idIscrizione} DELETE;
• api/v2/EventiPrivati POST;
• api/v2/EventiPubblici/{IDevento} PATCH;
• api/v2/EventiPersonali/{IDevento} PATCH;
• api/v2/EventiPrivati/{IDevento} PATCH;
• api/v2/EventiPrivati/{IDevento} GET;
• api/v2/Utenti/me/Iscrizioni GET;
• api/v2/Utenti/me/Inviti GET;
• api/v2/EventiPubblici/{IDevento}/inviti POST.

Rispetto alla versione v1, sono state modificate le seguenti "API":

• api/v2/EventiPubblici/{idEvento}/Iscrizioni POST
  • aggiunti ulteriori casi con codice di stato 403;
  • aggiunto codice di stato 404;
• api/v2/EventiPubblici POST
  • aggiunto codice di stato 403;
  • aggiunto codice di stato 400;
• api/v2/EventiPersonali POST
  • aggiunto codice di stato 403;
  • aggiunto codice di stato 400;
• api/v2/eventiCalendarioPubblico GET
  • aggiunti parametri da passare all'API
    • nomeAtt;
    • categoria;
    • durata;
    • indirizzo:
    • citta;
  • aggiunto codice di stato 400;
• api/v2/eventiCalendarioPersonale GET
  • aggiunti parametri da passare all'API
    • nomeAtt;
    • categoria;
    • durata;
    • indirizzo:
    • citta;
    • passato;
  • aggiunto codice di stato 400.

Rispetto alla versione v1, sono state aggiunte le seguenti "components":

• UtenteCercato;
• PrivateEvent;
• FormModificaPubblico;
• FormModificaPersonalePrivato;
• Iscrizione;
• Invito.

Rispetto alla versione v1, sono state rimosse le seguenti "components":

• FormEventoPubblico;
• FormEventoPersonale.

Rispetto alla versione v1, è stata modificata la "component" PersonalEvent.

Generale

Organizzazione repository

Cartelle:

• stati - 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;
• tests - contiene i file di estensione ".test.js" utilizzati per il testing del servizio.

File:

• oas3.yaml - documentazione dell'api;
• index.js - il file .js per il collegamento al database e l'avvio del nostro server (che pertanto si pone "in ascolto").

Strategia di branching

La strategia di branching utilizzata è la Feature Branch Workflow.

Product backlog

Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing

Il foglio di lavoro utilizzato per il product backlog è chiamato "Product Backlog".

Definizione di Done

I seguenti criteri saranno considerati perché si possa ritenere concluso un certo use case:

1. il codice dovrà essere funzionante (Node.js, html);
2. 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;
3. tutta la documentazione legata alla user stories dovrà essere completata;
4. La documentazione sulle API (Apiary) dovrà includere tutte le funzionalità fornite della parte di servizio che si vuole definire per la use story;
5. tutti i documenti e i codici riguardanti la use story dovranno essere presenti nel repository GitHub del gruppo;
6. tutti i membri del team dovranno avere eseguito il commit delle funzionalità da loro implementate sul branch master;
7. implementare tutte le funzionalità (task) che abbiamo definito per la user story, quindi nella project board tutti i task dovranno essere nella sezione “Done”;
8. La funzionalità che si implementa dovrà essere provata importandolo su un’ambiente di sviluppo;
9. Si dovrà unire tutte le funzionalità (dettate dalle user story) in unico software funzionante;
10. È necessario che ogni funzionalità associata ad una user story sia ben integrate con le altre legate ad essa.

Sprint #1

Goal

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.

Sprint planning

Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing

Il foglio di lavoro utilizzato per lo Sprint Backlog di questo primo sprint è chiamato "Sprint Backlog Sprint #1".

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.

Test cases

Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing

Il foglio di lavoro utilizzato per i test case è chiamato "Test Cases Sprint #1".

Sprint review

Raccolta feedback:

1. l'applicazione manca di un'interfaccia intuitiva, che permetta all'utente di comprendere in che modo utilizzarla;
2. dalla vista calendario, non è possibile capire quale evento è presente in quale giornata senza cliccare sopra la casella;
3. i layout delle interfacce sviluppate finora sono oltremodo banali;
4. è apprezzata la possibilità di visualizzare gli eventi sia in forma di calendario che in forma di elenco;
5. sarebbe gradita la possibilità di non includere automaticamente l'organizzatore di un evento ai partecipanti;
6. 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;
7. è spesso ambiguo capire il risultato di un azione compiuta (e.g. non è chiaro il perché determinati eventi non vengano visualizzati nel calendario pubblico);
8. non è chiaro all'utente cosa venga visualizzato nei diversi calendari;
9. è apprezzato il fatto di poter visualizzare nel calendario pubblico i soli eventi a cui non ci si è iscritti;
10. è 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);
11. è poco chiaro quali controlli vengano effettuati tra le diverse funzionalità (e.g. sui dati inseriti nei form);
12. è 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).

Product backlog refinement

In questo sprint non abbiamo terminato "Storico eventi" e "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".

Sprint retrospective

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):

1. ci si aspetta di risolvere il problema aggiungendo una forma di "legenda delle operazioni" alle pagine che la richiedono;
2. si potrebbe fare in modo che appaia una sferetta colorata sovrapposta ai giorni del calendario che contengono almeno un evento;
3. possibilmente, ci preoccuperemo di migliorare sensibilmente il lato front-end, utilizzando, ad esempio, librerie come "bootstrap";
4. faremo in modo di non includere automaticamente l'organizzatore di un evento ai partecipanti;
5. faremo in modo di rimuovere il tasto di iscrizione dalle pagine di informazioni degli eventi a cui si risulta iscritti;
6. renderemo visivamente più chiari gli effetti delle varie operazioni;
7. ci si aspetta di risolvere il problema aggiungendo una forma di "legenda dei calendari" ai diversi calendari;
8. ci si aspetta di risolvere il problema aggiungendo una forma di "legenda dei controlli".

Sprint #2

Goal

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).

Sprint planning

Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing

Il foglio di lavoro utilizzato per lo Sprint Backlog del secondo sprint è chiamato "Sprint Backlog Sprint #2".

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.

Test cases

Link allo spreadsheet: https://docs.google.com/spreadsheets/d/16fKkreM4VDILS75u_SeipSodk2pJjPfjnaDFebb5vZ0/edit?usp=sharing

Il foglio di lavoro utilizzato per i test case è chiamato "Test Cases Sprint #2".

Human Testing

In questo secondo sprint abbiamo applicato la tecnica dello Human Testing, dove ogni membro del gruppo si è occupato di "inspections" e "walkthroughs" del codice di un altro membro.
Nello specifico:

• Guglielmo Zocca si è occupato del codice di Enrico Fornasa;
• Enrico Fornasa si è occupato del codice di Marco Lasagna;
• Marco Lasagna si è occupato del codice di Guglielmo Zocca.

Guglielmo Zocca

Durante la revisione del codice di Enrico Fornasa, mi sono soffermato in particolar modo sulla modifica degli eventi. Un problema emerso è stato, ad esempio, l'utilizzo improprio dell'operatore logico AND dove si sarebbe dovuto impiegare un OR, nei controlli sui campi inseriti in fase di modifica. Prima di risolvere il bug, l'omissione di anche solo un campo di testo provocava la generazione di un errore. Nella sezione di disiscrizione da un evento, invece, un errore sintattico imponeva di accedere ad un certo campo di una semplice variabile "non-oggetto", che in quanto tale non dispone di alcun campo.

Enrico Fornasa

Ispezionando il codice riguardante lo Storico Eventi, in uno switch il caso di default non definiva alcun return: ciò provocava un errore nel momento in cui non veniva imposto alcun valore al parametro "passato" dell'API. Nella sezione di Filtro Eventi è emerso invece un problema nell'utilizzo improprio dell'operatore logico AND dove si sarebbe dovuto impiegare un OR, nei controlli sui campi inseriti in fase di selezione filtro. Prima di risolvere il bug, l'omissione di anche solo un campo di testo provocava la generazione di un errore. Infine, nella Ricerca Utente una scelta implementativa causava la trasmissione in chiaro di tutte le credenziali dell'utente ricercato nel momento in cui non si specificava alcuna email per la ricerca. Per risolverlo si è fatto in modo di modificare il codice così da filtrare sempre tutte le informazioni utente inviate, non più sotto la condizione che esista o meno la mail.

Marco Lasagna

Ispezionando il codice riguardante la Visualizzazione delle Iscrizioni, l'errore riscontrato consisteva nell'utilizzo improprio della variabile "ListaBiglietti" (array biglietti dell'utente) al posto di "ListBigl" per l'operazione di push: ciò provocava un invio di informazioni non corrette al richiedente. Il tutto è stato risolto semplicemente scambiando le due variabili. Nella sezione di Programmazione Eventi Privati è stato aggiunto un controllo sul tipo del campo "durata": questo perché altrimenti ci sarebbero stati problemi con controlli futuri. Nell'implementazione di Inviti ad eventi pubblici è stato aggiunto un controllo sul parametro "email" passato all'API, allo scopo di prevenire eventuali problemi su controlli futuri. Infine, il codice di Iscrizione ad Evento Privato conteneva una duplice dichiarazione di una certa variabile che portava alle volte a conflitti. Il problema è stato risolto semplicemente rinominando le variabili in questione.

Testing

Abbiamo utilizzato sia le mock-functions (per virtualizzare il database) che un database di test presente nello stesso "cluster" del database proprio del progetto.

Revisione Test Cases

I test cases dello Sprint #1 non hanno subito variazioni radicali. Le modifiche sono principalmente state:

• di forma;
• l'aggiunta di codici di stato negli expected result.

In questo scondo sprint sono stati inoltre aggiunti gli actual result dei test effettuati.

Sprint review

Gli aspetti positivi e negativi emersi dai feedback ricevuti nello scorso sprint rimangono pressoché inalterati. Dunque, riportiamo di seguito i feedback "invariati":

1. dalla vista calendario, non è possibile capire quale evento è presente in quale giornata senza cliccare sopra la casella;
2. è apprezzata la possibilità di visualizzare gli eventi sia in forma di calendario che in forma di elenco;
3. sarebbe gradita la possibilità di non includere automaticamente l'organizzatore di un evento ai partecipanti;
4. 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;
5. è apprezzato il fatto di poter visualizzare nel calendario pubblico i soli eventi a cui non ci si è iscritti;
6. è 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);
7. è poco chiaro quali controlli vengano effettuati tra le diverse funzionalità (e.g. sui dati inseriti nei form);
8. è 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).

Per quanto riguarda le funzionalità introdotte nello sprint corrente, è invece emerso:

1. (9) non è gradito il fatto che ad ogni utente vengano mostrati tutti gli inviti ricevuti, compresi quelli ad eventi passati (i.e. a cui non è più possibile iscriversi);
2. (10) sarebbe stato più apprezzato se lo storico eventi fosse stato incluso nel calendario pubblico;
3. (11) è stata apprezzata la possibilità di filtrare eventi in entrambi i calendari pubblico e personale;
4. (12) non è gradito il fatto di poter invitare utenti ai propri eventi privati solamente in fase di creazione;
5. (13) è apprezzata la ricerca utente per mail, che non necessita dell'intero indirizzo ma anche solo di alcuni caratteri;
6. (14) sarebbe stato gradito se nel calendario pubblico venissero mostrati i soli eventi disponibili (vengono invece mostrati anche gli eventi passati, quindi non più disponibili).

Product backlog refinement

Confrontandoci, abbiamo convenuto che, rispetto allo scorso sprint, i cambiamenti del backlog refinement sarebbero stati pochi: questo perché, a parer nostro, il backlog prodotto dal refinement dello Sprint #1 è già di per sé molto vicino alle richieste dell'utente.

Segue quindi la lista delle modifiche apportate.

• "Valutare eventi": "importance" da 24 a 22 (al posto di "Ordinare eventi"). Siccome vorremmo poter ordinare gli eventi anche in base alle valutazioni, segue che "Valutare eventi" ha priorità su "Ordinare eventi".

• "Informazioni dati evento": "importance" da 33 a 27 (al pari di "Caricare contenuti multimediali ad un evento"). Riteniamo il caricamento e la visualizzazione dei dati sullo stesso piano, pertanto abbiamo deciso di assegnare alle User Stories qui sopra la stessa "importance".

• "Modificare dati caricati per un evento": "importance" da 27 a 33 (al posto di "Informazioni dati evento").

• "Richiedere amicizia" e "Sezione dedicata alle notifiche - richieste di amicizia": "importance" da 37 a 38 (al posto di "Visualizzare amici").

• "Visualizzare amici": "importance" da 37 a 39 (al posto di "Programmare operazioni automatizzate" e "Modificare operazione da eseguire dell'evento"). La gestione delle amicizie resta una delle feature meno importanti.

Sprint retrospective

L'approccio adottato in questo secondo sprint è rimasto pressoché invariato rispetto allo scorso. Per quanto riguarda lo sprint planning, non è stata apportata alcuna modifica al product backlog derivato dal refinement dello Sprint #1.

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 13 giorni in base all'estimate della velocity stabilita nello Sprint Planning. L'estimate reale viene calcolato su 13 giorni. Rispetto lo scorso sprint è stato sufficiente calcolare una sola volta la velocity in quanto siamo riusciti a rispettarla.

La pratica agile dei meeting giornalieri è nuovamente tornata utile in quanto ci ha permesso di aiutarci a vicenda e di stabilire di volta in volta la rotta dello sviluppo.

La comunicazione è rimasta per via telematica, il che ha permesso di abbattere le distanze e aumentare l'efficienza del gruppo.

Rispetto allo Sprint #1 l'attenzione del gruppo è stata quasi interamente rivolta al lato produttivo (oltre che revisioni di prodotti dello scorso sprint): ciò è dovuto al fatto che si è dedicato molto meno tempo allo studio degli strumenti di sviluppo.

La suddivisone del lavoro è stata più equa, non solo a livello di Task (Backlog) ma anche di Test e documentazione dell'API.

Analogamente allo scorso sprint, la tecnica di branching utilizzata è stata il "Feature Branch Workflow": a seconda della funzionalità da implementare (riportate nel Backlog), ognuno ha lavorato su un branch diverso.

Per quanto riguarda i test, abbiamo deciso invece di dedicare un branch per ogni membro del gruppo (in totale 3). Ognuno si è occupato del testing relativo ai Test Cases prodotti in precedenza.

Durante la Review di questo secondo sprint ci siamo concentrati sia su feedback del primo sprint che nuovi feedback.

Il product refinement è stato complessivamente più leggero rispetto lo sprint precedente, in quanto, come già indicato nella scorso sezione, il backlog prodotto dal refinement dello Sprint #1 è già di per sé molto vicino alle richieste dell'utente.

Nel prossimo sprint, l'obiettivo principale sarà quello di realizzare le funzionalità più particolari del servizio, come, ad esempio, la possibilità di selezionare una data da calendario in fase di creazione di un evento.

Rispondiamo di seguito ad alcuni feedback raccolti nella Sprint review (si veda l'enumerazione nella review):

1. (9) realizzeremo un controllo a livello di UI in modo tale da mostrare i soli inviti ad eventi disponibili (i.e. a cui l'utente può ancora iscriversi);
2. (10) ci preoccuperemo di estendere lo storico eventi al calendario pubblico nel prossimo sprint (esattamente come per il calendario personale);
3. (12) analogamente agli eventi pubblici, faremo in modo di permettere una modifica della lista di invitati dalla pagina di informazioni dell'evento;
4. (14) imporremo un controllo a livello di UI per mostrare i soli eventi disponibili.

Le nostre risposte ai feedback "irrisolti" dello scorso sprint restano invariate:

1. (2) si potrebbe fare in modo che appaia una sferetta colorata sovrapposta ai giorni del calendario che contengono almeno un evento;
2. (5) faremo in modo di non includere automaticamente l'organizzatore di un evento ai partecipanti;
3. (6) faremo in modo di rimuovere il tasto di iscrizione dalle pagine di informazioni degli eventi a cui si risulta iscritti;
4. (11) ci si aspetta di risolvere il problema aggiungendo una forma di "legenda dei controlli".

Conclusione

Diagramma infrastrutturale del deploy

Continuous Integration e Deployment

In questa sezione sono state utilizzate GitHub Actions con Workflow Node.JS CI. Il Job Workflow adottato è stato "Test", allo scopo di eseguire i diversi test nel momento in cui si intende effettuare un push sul branch master della repo. Per quanto riguarda il CD, non è stata indicata alcuna "Job Release", dato che si è utilizzata l'opzione di Heroku per effettuare deployment automatici al momento di push sul branch master della repo nell'istante in cui operazioni di CI (definite dal Job Workflow "Test") vengono eseguite con successo.

Non è stato adottato il "Job Workflow Release" a causa di un bug discusso nel link riportato di seguito. https://github.com/AkhileshNS/heroku-deploy/issues/84

Stack Tecnologico Utilizzato

Software impiegato:

• Node.JS - Framework JS utilizzato per realizzare il lato server del servizio;
• MongoDB - Database non-relazionale utilizzato per collezionare e gestire i dati del servizio;
• HTML - utilizzato per realizzare l'interfaccia del servizio;
• JS - utilizzato per fornire dinamicità all'interfaccia utente;
• Heroku - servizio cloud utilizzato per il deploy del servizio.

Moduli Node JS standard impiegati:

• mongoose - utilizzato per interagire con il database MongoDB;
• dotenv - utilizzato per accedere alle variabili di ambiente dal file ".env";
• supertest - utilizzato per la scrittura di codice di testing;
• jsonwebtoken - utilizzato per la generazione e verifica di token;
• express - utilizzato per la gestione di richieste rivolte al server;
• qrcode - utilizzato per la generazione di codici QR (in base64).

Conclusioni

È stato senza dubbio istruttivo utilizzare nuovi tool, tra cui GitHub ed APIary, per lo sviluppo di applicazioni web. L'impiego, poi, di un database non-SQL è stata un'esperienza nuova ed interessante. Complessivamente, la scrittura di codice in gruppo è una referenza importante soprattutto in ambito lavorativo, ma non per questo il progetto è stata un'esperienza priva di difficoltà: nello specifico, il dover integrare tra loro moli importanti di sorgenti e documentazioni scritti da persone diverse è risultata un'impresa più complicata del previsto. Rispetto gli anni precedenti, lo studio e l'applicazione della metodologia Agile ci ha permesso di scoprire un nuovo approccio alla cooperazione. Col senno di poi, abbiamo convenuto che sarebbe stato meglio utilizzare la strategia di branching "Gitflow Workflow" puttosto che "Feature Branch Workflow" in quanto la prima è più facilmente gestibile della seconda. Infine, abbiamo osservato che piuttosto che prediligere la quantità di feature, abbiamo favorito la qualità del prodotto.