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. Affinché l’utente possa avere una grande varietà di piatti, la WebApp controllerà che una ricetta non venga riproposta nel breve periodo. Vi sarà un sistema di notifica per cibi in scadenza che permetterà di evitare sprechi. 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.
Team members:
| Nome e Cognome | Mail | 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
- Documentazione apiary
- Deploy Heroku
- Backlog e sprint backlog
- Sprint 1
- [Sprint 2]
- [Testing]
- Database: MongoDB
- Backend: API REST (NodeJS + Express + Mongoose) + [Testing ...]
- Frontend: Web App
- Documentazione: Swagger
- Continuous Deployment: Heroku
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 si chiude e si aggiorna il main branch tramite il comando merge. Si è rivelato molto utile nella divisione del lavoro tra i membri del gruppo. Questa tecnica è stata preferita in modo da evitare la “Master only
Noi definiamo "done" come:
- Il codice è stato testato da chi lo ha fatto ed è funzionante
- la correzione di precedenti bug/errori conosciuti è stata dimostrata al team
- Il codice è stato visto e approvato da almeno un altro membro del team
- La documentazione è stata vista e approvata da almeno altri due membri del team
- Il database è 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 una 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.
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.
In generale, siamo soddisfatti 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.