Home
Il servizio proposto permette all’utente di ottenere suggerimenti di ricette basandosi su ingredienti posseduti. La Webapp è strutturata in modo tale da analizzare gli ingredienti posseduti da un utente e, se richiesto dall’utente, consigliare nuove ricette. L’utente dovrà provvedere all’inserimento degli ingredienti acquistati e disponibili nella cosiddetta “dispensa virtuale”. Da qui il nome del servizio “La Dispensa”.
La dispensa verrà aggiornata in seguito all’acquisto di nuovi prodotti ed al loro utilizzo. Sarà possibile consultare la lista degli ingredienti disponibili in qualunque momento della giornata.
La WebApp sarà, inoltre, in grado di verificare la fattibilità di una ricetta: nel momento in cui l’utente vorrà cucinare un determinato piatto, potrà verificare se gli ingredienti disponibili sono sufficienti per cucinare quella pietanza o meno. Verranno, quindi, specificati i prodotti da acquistare.
I servizi descritti finora sono pubblici: non necessitano di alcuna registrazione. Servizi aggiuntivi, quali monitoraggio soldi spesi, tracciamento apporto quotidiano di micro e macro nutrienti, esportazione dati personali ed inserimento nuove ricette sono disponibili solo con un’area personale.
| Nome e Cognome | Matricola | Github | |
|---|---|---|---|
| Paolo Aliprandi | paolo.aliprandi@studenti.unitn.it | 209404 | iPaoloTM |
| Letizia Girardi | letizia.girardi@studenti.unitn.it | 213934 | letiziagirardi |
| Michele Lamon | michele.lamon@studenti.unitn.it | 209396 | gelsounitn |
| Andrea Tomasoni | andrea.tomasoni-1@studenti.unitn.it | 209443 | andreaunitn |
- Wiki: Repository Wiki
- Documentazione apiary: Documentazione apiary
- Deploy Heroku Dispensa CD
- Backlog e sprint backlog: Google Sheets
- Sprint 1: Backlog e planning #1
- Sprint 1: Project Board #1
- Sprint 1: Testing #1
- Sprint 2: Backlog e planning #2
- Sprint 2: Project Board #2
- Sprint 2: Testing #2
In questa repository del nostro progetto si trova il codice backend e frontend. Il codice del frontend (HTML) si trova all'interno della cartella "frontend" mentre il codice delle api (nodejs + mongoose + express, inclusa la documentazione Swagger) si trova nella cartella "backend". La cartella frontend contiene i file html, che sono stati separati dai file javascript e CSS per implementare il principio di separazione degli interessi (SoC principle). Vi è anche una cartella "documentation" contenente i file per la documentazione Swagger + Apiary. Durante il secondo sprint, è stata aggiunta anche la cartella "test", contenente i file necessari per il testing con jest.
root
├── Procfile
├── README.md
├── backend
│ ├── authentication.js
│ ├── db.js
│ ├── home.js
│ ├── ingredienti.js
│ ├── insert_ingredients.js
│ ├── insert_recipes.js
│ ├── package.json
│ ├── ricette.js
│ ├── schemas.js
│ ├── tokenChecker.js
│ └── users.js
├── coverage
│ └──[...]
├── documentation
│ ├── apiary.apib
│ ├── swagger-def.js
│ └── swagger.json
├── frontend
│ ├── acquisti.html
│ ├── dispensa.html
│ ├── error.html
│ ├── header.html
│ ├── home.html
│ ├── login.html
│ ├── myProfile.html
│ ├── register.html
│ ├── script
│ │ ├── auth_script.js
│ │ └── script.js
│ └── style
│ ├── auth_style.css
│ └── style.css
├── index.js
├── node_modules
│ └── [...]
├── package-lock.json
├── package.json
├── spazzatura.txt
└── test
├── api_test.js
├── authentication.test.js
├── dbconnection.test.js
├── inserimento_ricette.test.js
├── pagina_inesistente.test.js
├── ricerca_ricette.test.js
├── users.test.js
└── visualizza_ingredienti.test.js
Ogni membro del team ha pubblicato, condiviso, esaminato ed eseguito modifiche al codice tramite rami Git condivisi con gli altri partecipanti. Adottando un’adeguata strategia di branching, abbiamo collaborato efficacemente dedicando più tempo possibile allo sviluppo del codice.
Sono stati utilizzati principalmente i seguenti modelli di workflow:
- il modello più utilizzato durante questo primo Sprint è il modello “Centralized Workflow”. Questo modello utilizza una repository centrale, detta master branch, la quale funge da unico punto di ingresso per nuove modifiche al progetto. Ogni membro del gruppo, quando intende apportare delle modifiche, clona la repository centrale e nelle proprie copie locali del progetto, modifica i file e con il comando push carica il lavoro sul branch corrente. Così facendo si ottiene una storia lineare senza necessità di comandi merge.
- un secondo modello utilizzato è il modello “Git-Feature Branch Workflow”. Questa strategia prevede la creazione di branch dedicati a specifiche feature. Una volta che la feature è conclusa, il branch viene chiuso e si aggiorna il branch master tramite un comando merge. Si è rivelato molto utile nella divisione del lavoro tra i membri del gruppo. Questa tecnica è stata adottata in modo da evitare la “Master only strategy”, ovvero quella tecnica che prevede di lavorare sempre su un solo branch: il branch master.
Esempio branching secondo il modello “Git-Feature Branch Workflow" - in tale branch é stata implementata la funzione cercaRicette. La funzione permette di cercare una determinata ricetta inserita manualmente dall’utente. Affinché la pagina possa essere accessibile tramite un identificatore globale (URL), é stata implementata l’architettura strutturale REST.
Il Product Backlog consiste in un elenco di attività (Product Backlog Item) ordinato per priorità. Già nella fase precedente del progetto (Milestone #4) è stata compilata una bozza di tale documento.
Durante questa prima iterazione, come previsto, abbiamo aggiornato la priorità di alcune attività. Il Product Backlog, infatti, deve essere costantemente rivisto e riordinato in base alle necessità degli utenti, del mercato o in base a suggerimenti da parte del team. Durante l’implementazione della WebApp ci siamo accorti che alcune user stories dovevano avere la priorità su altre, abbiamo quindi dato precedenza alla loro implementazione ed aggiornato il documento.
Il nuovo documento si trova al seguente link: product backlog. Possiamo notare che vi è stato un cambiamento di priorità nelle prime attività. Di preciso abbiamo preferito dare precedenza all’inserimento di prodotti acquistati dall’utente e all’eliminazione dei prodotti utilizzati, rispetto alla diversificazione delle ricette. La verifica dei prodotti mancanti per una determinata ricetta ha ottenuto più importanza in quanto è un servizio che la WebApp da anche all’utente non loggato. Spiegato, quindi, il motivo della minore importanza per l’area personale.
La nostra definizione di "Done" prevede che:
- Il codice relativo alla funzionalità in questione è stato implementato
- Il codice sia stato testato da chi lo ha fatto e sia funzionante
- la correzione di precedenti bug/errori conosciuti sia stata dimostrata al team
- Il codice sia stato letto ed approvato da almeno un altro membro del team
- La documentazione sia stata letta ed approvata da almeno altri due membri del team
- Il database sia stato progettato e integrato per supportare la funzionalità in questione
Il goal del nostro primo Sprint è di realizzare un prodotto software funzionante, coerente e utile. Vogliamo sviluppare una WebApp che possa risolvere un problema concreto, reale, che abbia motivo di essere realizzata. Siamo consci del fatto che con solo uno Sprint non possiamo sviluppare un prodotto software con un alto livello di complessità, rifinitura, dettaglio e correttezza del funzionamento, ciononostante non vogliamo produrre un software incompleto, “beta”. Vogliamo sviluppare un software, seppur ristretto rispetto alla nostra idea finale, che sia concreto, coerente nel suo insieme, e che sia utile per l’utente finale, anche in questa prima versione.
Il nostro goal per questo sprint è stato:
- consigliare ricette
- verificare fattibilità di una ricetta
- inserire ingredienti acquistati
- modificare lista ingredienti acquistati
- visualizzazione degli ingredienti posseduti
- sviluppo UI
- progettazione database
- implementazione metodi REST
- documentazione Swagger e Apiary
Dal meeting, abbiamo convenuto nel implementare le funzionalità relative alle user stories in ordine crescente di importance stimate. Detto questo, siamo passati alla divisione degli incarichi: ognuno dei membri del team ha competenze e conoscenze diverse; c’è chi conosce molto bene Git, chi è più esperto nella gestione di database, e chi è più ferrato nella programmazione frontend. Ma ciò non ci ha influenzato nella divisione dei compiti. Abbiamo voluto evitare la strada facile, preferendo una distribuzione equa e che garantisse a tutti noi di imparare cose nuove e confrontarsi con sfide mai viste prima, piuttosto che una ripartizione basata sulle conoscenze pregresse dei singoli.
Ogni membro del team è stato quindi invitato a partecipare attivamente al progetto, sviluppando come preferiva la propria funzione, documentandola e testandola. Agli altri membri del team è stato permesso discutere, per incentivare la comprensione, ed eventualmente poi modificare le altre parti di codice, in modo da favorire la più totale collaborazione.
Nel corso dello Sprint ognuno ha rispettato bene i ruoli assegnati, nonostante sia capitato che qualche membro del team chiedesse un consiglio a un altro membro del team. Noi crediamo che, nonostante sia giusto avere dei ruoli assegnati, sia da favorire anche la collaborazione tra il team, a patto che non leda la divisione degli incarichi.
Per i meeting e daily scrum di gruppo abbiamo preferito la piattaforma Discord, in quanto si è sempre rivelata perfetta per il team working, anche in altri corsi.
Nella pagina “testing” del documento “Sprint backlog” sono stati indicati alcuni test cases eseguibili con l’attuale versione delle nostre API. Questi si concentrano principalmente sulla ricerca di ricette tramite apposito url “./api/v1/ricette” con aggiunta di parametri come “ingredienti”, “titolo” e “id”. Con l’ampliarsi delle API nel prossimo Sprint, si aggiungeranno nuovi test cases relativi a login, registrazione e aggiunta ricette. Prevediamo di riuscire a provarli tutti e correggere le criticità.
Alla fine dello sprint, abbiamo partecipato al meeting per la sprint review. Inizialmente, eravamo molto titubanti sull’implementazione della nostra idea: approcciarsi con un database non relazionale è stato abbastanza complesso e macchinoso. Essendo sempre stati abituati a database relazionali, abbiamo faticato nel comprendere il funzionamento. Ma successivamente, abbiamo riscontrato una maggiore naturalezza nella modellazione degli oggetti e nella scrittura delle query. Similmente, l’intero processo di sviluppo delle API è iniziato lentamente e faticosamente. La confusione era molta: non era chiaro quali metodi permettere, quali risultati dare e come gestire gli errori. Solo lavorandoci più e più volte siamo riusciti a soddisfare i nostri obiettivi. Infine, le funzioni javascript client-side sono risultate più immediate e siamo riusciti a lavorare con maggiore facilità, dato il background generale del team. Nonostante questo, non ci siamo risparmiati molto tempo di debug. Forse ci siamo sopravvalutati dove sapevamo di più, e ci siamo sottovalutati di fronte alle nuove cose da imparare. Il nostro prodotto software, per essere il primo Sprint, è completo e ne siamo soddisfatti. Siamo comunque consapevoli dell’esistenza di alcune criticità e bug ancora presenti. Prevediamo di risolvere questi errori sparsi nel codice nei primi passi del prossimo Sprint.
Dal meeting, abbiamo deciso di procedere seguendo l’ordine crescente delle importance e abbiamo inizialmente discusso e infine concordato nell’assegnazione degli story points a ciascuna task. Successivamente, però, ci siamo dovuti ricredere e modificare alcuni story points, in particolare quelli relativi alle prime user stories sono stati incrementati. Nel corso di questo Sprint, ci siamo anche resi conto che il product backlog precedente non rispecchia correttamente la nostra percezione del prodotto software: man mano che le funzioni venivano implementate e testate, ci siamo chiesti quale sarebbe stato il naturale prossimo step. La risposta a questa domanda non sempre era ben riflessa dalla scala delle importance del backlog precedente. Abbiamo quindi modificato alcune importance, per adattarle alla nostra maturata idea della WebApp.
Dall’ultimo meeting, emerge la generale soddisfazione del nostro lavoro di squadra. Nonostante abbiamo avuto poche occasioni di collaborare in presenza, abbiamo recuperato con la piattaforma online Discord. Siamo sempre riusciti a proporre le nostre idee, confrontarle e risolvere eventuali disaccordi e perplessità. Siamo riusciti a implementare le funzionalità che ci eravamo prefissati. Ci siamo sottovalutati, infatti siamo riusciti ad implementarne altre. Abbiamo quindi modificato le funzionalità previste nel prossimo Sprint. Nel prossimo sprint terremo conto della nostra nuovamente stimata capacità produttiva. Ognuno di noi ha ampliato le proprie conoscenze in Javascript e abbiamo anche avuto modo di imparare cose nuove, ovvero l’utilizzo di nuovi strumenti per lo sviluppo software di cui ora non possiamo più fare a meno. Ci riteniamo compiaciuti in particolare della divisione dei compiti: siamo riusciti a lavorare in parallelo su diversi task, per poi unire i diversi artefatti in un prodotto finale complessivamente soddisfacente.
Il nostro team ha fissato come goal di questo secondo sprint la naturale evoluzione della nostra webapp. Tenendo ben presente il framework dello sviluppo di un earliest testable product, il nostro team ha deciso di proseguire ad implementare le funzioni che avrebbero reso coerente e utile, per l’utente finale, il nostro prodotto software. Innanzitutto, abbiamo deciso di fixare e perfezionare quegli errori e quelle sbavature che erano ancora presenti dal primo Sprint: pur ritenendo di aver realizzato un prodotto completo e funzionante, ben diverso da un mockup, ci siamo resi conto della presenza di bug e incoerenze logiche ma, per essere un primo Sprint, abbiamo convenuto che fosse normale avere modi per migliorare la nostra applicazione. Abbiamo poi deciso di implementare una componente molto importante per l’utente: l’area personale, così da rendere disponibile una zona in cui mantenere salvate le informazioni personali e i dati relativi alla webapp; il che ha reso necessario l’implementazione di un metodo per l’autenticazione: l’uso di JWT. Infine, il nostro team si è dedicato al perfezionamento del servizio di Continuous Delivery and Deployment Heroku e all’implementazione del servizio di Continuous Integration grazie alle Github Actions, con l’integrazione dei testing eseguiti col framework javascript consigliato a lezione: jest. Abbiamo quindi completato la pipeline.
Il nostro goal per questo sprint è quindi stato:
- verificare prodotti mancanti per una ricetta
- permettere l'inserimento di ricette nuove
- fixare e rivedere errori e bug
- implementare l’area personale (sign-in/log-in/log-out)
- rendere non device-dependent la possibilità di accedere e modificare la lista dei propri ingredienti nella dispensa virtuale testare le API con jest
Prima di iniziare lo sprint, il nostro team ha ritenuto utile svolgere una nuova stima della nostra capacity per questo sprint: abbiamo preso questa decisione poiché le nostre competenze riguardo ai nuovi strumenti come Node.js, Github e le pratiche del framework SCRUM erano aumentate.
Una volta stimato il nuovo carico di lavoro che avremmo poi consegnato, siamo passati alla distribuzione dei task per ogni membro del team. In conformità con quanto avvenuto nel primo Sprint, abbiamo diviso i compiti col criterio dell’apprendimento di nuove tecnologie e tecniche, e non per capacità e conoscenze già acquisite. Abbiamo però notato una tendenza, caratteristica per ognuno di noi, a “specializzarsi” nelle mansioni svolte maggiormente nel primo Sprint: riteniamo questa sia una vittoria, poiché siamo riusciti a confrontarci con nuove sfide (sprint #1) e abbiamo sviluppato passione e curiosità per le medesime (sprint #2).
In seguito, grazie a una maggiore familiarità col framework SCRUM e le metodologie Agili, abbiamo realizzato il secondo Sprint backlog con cui siamo riusciti a rimanere ben coerenti.
Pensiamo sia giusto sottolineare un acquisita maggiore sicurezza durante i meeting giornalieri: ogni componente del team ha sempre svolto un rapporto dettagliato del proprio lavoro agli altri membri del team, esponendo in modo chiaro e con riferimenti precisi (condividendo lo schermo agli altri) le nuove modifiche apportate al progetto. In particolare, nell’eventualità di una sottostima in story points per un certo task, i membri del team sono sempre stati d'accordo e dare priorità alla nuova criticità emersa in modo da essere coerenti con lo sprint backlog. Si è quindi dissipata l’iniziale lieve incertezza su cosa fare nei prossimi passi, ogni volta che una user story veniva completata o un problema si presentava.
Come nel primo Sprint, abbiamo svolto gli incontri sul nostro canale Discord. Questo strumento si è dimostrato estremamente utile: organizzare video-riunioni è stato sempre semplice e immediato; inoltre, ci ha permesso di essere sempre in contatto via messaggi istantanei e di incentivare la collaborazione reciproca grazie alla condivisione dello schermo.
Durante il secondo Sprint, abbiamo dato molta più rilevanza a questa fase rispetto a quanto fatto nel primo Sprint. A lezione abbiamo capito quanto sia importante verificare che la nostra webapp faccia ciò che ci aspettiamo e non faccia ciò che non deve fare Abbiamo optato per un mix tra approccio Black box e White box, dedicando però maggior tempo al secondo per via di un uso intensivo di Human testing.
Black box:
Seguendo questo approccio più randomico, abbiamo inizialmente testato le criticità emerse dal primo Sprint. Ci siamo chiesti: “questo risultato è davvero quello che ci aspettiamo? è logicamente corretto? Può portare a vulnerabilità?”. In caso affermativo, siamo contenti. In caso negativo, ci siamo adoperati per correggere laddove necessario.
White box e Human testing:
Con questo metodo, abbiamo condotto un testing con maggior criterio. Le fasi di testing non sono state guidate da chi avuto più a che fare con le API, bensì da chi non aveva troppa familiarità con esse, che ha comunque potuto apprendere velocemente grazie al documento presente su Apiary. Preferendo un team di tester principalmente composto da membri del team diversi rispetto a coloro che hanno implementato le API, siamo sicuri di aver svolto un testing privo di assunzioni e molto più scrupoloso di quanto avrebbe potuto fare lo sviluppatore dell’API stessa: quest’ultimo ha ben in mente come ha scritto le funzioni e il codice, ha perciò ormai delle assunzioni e bias difficilmente ignorabili. Riteniamo che la fase di Human testing sia stata molto più utile ed efficace rispetto a un approccio puramente Computer-based, che ha maggiormente scoperto errori “sintomi” di altro. Ecco perché abbiamo dedicato molto tempo a questa fase di analisi semantica e di ricerca di problemi, diversa dalla ricerca di soluzioni che è stata svolta successivamente. Effettivamente, grazie a questo metodo, siamo riusciti a pulire e perfezionare il nostro codice in punti di cui non ci saremmo mai accorti senza un’analisi approfondita svolta dai tester umani. Siamo quindi soddisfatti della qualità delle nostre API, tutte esposte secondo il metodo REST.
I successivi test sono stati svolti grazie all’utilizzo del framework Javascript jest, il tutto reso molto più comprensibile grazie all’integrazione del modulo coverage. Ispirati da come quest'ultimo ci mostrava i test, abbiamo realizzato una tabella di testing: Ogni riga rappresenta un caso di test e nelle colonne vi troviamo sezioni utili alla comprensione del caso di test come la sua descrizione, l’endpoint testato, eventuali pre-condizioni e, molto importante, il valore atteso e l’effettivo valore ritornato.
In generale, abbiamo cercato di evitare la restituzione di errori 500, preferendo codici di stato conformi al documento RFC 2616 dall’IETF accompagnati da risposte che aiutino la comprensione dell’errore.
Questa fase ha per noi grande valore, poiché il nostro goal è di sviluppare un prodotto utile e coerente ma allo stesso tempo anche robusto e che garantisca un’elevata affidabilità.
Durante questo meeting svolto al termine della seconda iterazione, ci siamo concentrati sullo svolgimento di una demo della Webapp “La Dispensa” che permettesse la collezione di pareri e feedback. In generale, il nostro team si definisce molto soddisfatto del prodotto software realizzato.
Siamo contenti delle user stories che siamo riusciti ad implementare. Pur avendo a disposizione solo due iterazioni, pensiamo di aver sviluppato una web app completa, che presenta una logica di funzionamento ben strutturata e che possa risultare utile nella vita quotidiana dei nostri utenti ideali primari e secondari (studenti fuorisede e persone comuni). Siamo consapevoli di non aver implementato tutte le user stories previste nel product backlog iniziale. Abbiamo però deciso di non eliminarle, poiché saranno protagoniste nelle prossime iterazioni. Riteniamo che al momento il nostro prodotto sia comunque completo, coerente nel suo insieme e non manchi di nessuna funzione principale.
Parlando dell’aspetto grafico, il team ha espresso parere positivo anche per la rivalutazione della GUI, inizialmente ritenuta secondaria. Abbiamo pensato di rendere lo stile grafico omogeneo, semplice e minimale. Con l’uso di colori simili per funzioni simili e viceversa, siamo sicuri di aver reso la nostra interfaccia grafica intuitiva ed esplicativa anche per un utente non esperto.
Per migliorare l’usabilità della piattaforma, abbiamo anche aggiunto una pagina d’errore in modo che l’utente possa sempre tornare alla home e non si trovi mai faccia a faccia con un freddo e scarno ‘’’ {error: not found} ‘’’. Sempre a proposito di usabilità, il team concorda nella scelta della gestione degli errori restituiti all’utente dalle API: ogni errore è accompagnato da un messaggio esplicativo della causa, così da evitare di confondere l’utente.
Infine, abbiamo ritenuto importante implementare anche una funzione non necessariamente riconducibile ad una user stories: Availability. La nostra webapp mantiene in memoria le informazioni, come gli ingredienti di un utente, così che siano sempre disponibili indipendentemente dal dispositivo d’uso. Pensiamo che ciò renda il prodotto più competitivo e coerente, poiché non è solo un semplice progetto locale, ma una web app funzionante e raggiungibile da chiunque grazie al deploy Heroku.
Infine, il nostro team ha svolto un meeting per raccogliere le considerazioni di ciascuno per quanto riguarda lo svolgimento del secondo sprint, in modo da cogliere spunti di miglioramento per future iterazioni.
Cosa ha funzionato:
-
Siamo davvero soddisfatti di come abbiamo collaborato in squadra. Nonostante l’interazione di persona sia stata rara, abbiamo lavorato insieme e separatamente: ognuno ha lavorato svolgendo diligentemente le proprie mansioni e, ad ogni merge, i singoli diversi file si tramutavano nella loro versione finale e soprattutto funzionante. In questo modo, abbiamo ridotto al minimo il numero di merge conflict.
-
Ad ogni SCRUM meeting, riportare il proprio lavoro verso gli altri membri del team ha reso la collaborazione più trasparente, migliorando il clima generale, e soprattutto ha fatto sì che ognuno fosse a conoscenza dei compiti svolti dagli altri. Questo ci ha permesso ad ognuno di avere sempre una visione generale dello stato corrente del progetto, senza intaccare la produttività dei singoli. Ognuno di noi aveva il proprio ruolo, ed era fondamentale che lo portasse avanti nel rispetto di tutti. è capitato che qualche giorno qualcuno rimanesse indietro per impegni personali o mancanza di progresso, ma ciò di cui siamo orgogliosi è che il clima di fiducia creatosi ha sempre invogliato a fare di più per portarsi al passo con gli altri.
-
L’adozione delle metodologie Agile, come l’utilizzo dei fogli Google condivisi e l’implementazione, come nel primo Sprint, delle Github Board, ha permesso il buon sviluppo del progetto e ha evitato che cambiamenti di programma o imprevisti rappresentassero un problema, grazie appunto alla comunicazione veloce e agile tra tutti i membri del gruppo.
-
Grazie alla maggior familiarità con i nuovi strumenti quali Git e i diversi framework Javascript, il team si ritiene soddisfatto della migliorata capacità di stimare i task e di essere coerenti con quanto riportato nello Sprint backlog. Ciò è visibile dal Burndown chart dove è mostrato che il total effort approssima molto meglio l’effort ideale, rispetto a quanto accaduto nel primo Sprint
Cosa non ha funzionato:
-
A volte i punti di forza hanno rappresentato anche delle debolezze: purtroppo è capitato che alcuni branch venissero lasciati troppo indietro rispetto ad altri, il che ha causato alcuni merge conflict e ha quindi portato via del tempo prezioso. Per far fronte a ciò, abbiamo ritenuto necessario fare il merge del Main branch nel ramo in questione, per ottenere le ultime modifiche strutturali e continuare a sviluppare le nuove features.
-
L’implementazione della Continuous Integration con le Github Actions ha rappresentato un’enorme soddisfazione per la nostra squadra, ma arrivarci è stato tortuoso: inizialmente avevamo sottovalutato l’importanza delle variabili d’ambiente contenute nel file .env, perciò quando è venuto il momento di caricarle per renderle disponibili al deploy heroku, abbiamo incontrato non pochi problemi. Riportiamo però che alla fine tutto si è risolto al meglio grazie alla determinazione al lavoro di squadra.
Prossime Iterazioni:
-
Da queste due iterazioni, riteniamo di aver imparato molto: per una migliore collaborazione, ci proponiamo di aumentare gli incontri in presenza; ciò non è sempre stato possibile data la diversa provenienza geografica dei membri del team. Abbiamo ben collaborato anche attraverso le piattaforme Discord e Telegram, per messaggi più veloci e meno formali, ma pensiamo di poter migliorare molto la qualità del nostro prodotto e soprattutto l'efficienza del nostro team.
-
Inoltre, per le future iterazioni, riteniamo utile dedicare tempo all’analisi di prodotti simili al nostro già esistenti, per studiare i loro punti di forza e di debolezza. Puntiamo poi a realizzare una seconda versione delle nostre API per una maggiore uniformità tra i dati in ingresso e in uscita e la contemporanea aggiunta di nuove funzioni quali la modifica di email e password dell'utente
