Milestone #5
Deadline 23 Maggio
- Valeria Grotto - Matricola: 210401 - https://github.com/valegr8
- Davide Cavedon - Matricola: 209313 - https://github.com/Caved1ne
- Daniele Dall’Anese - Matricola: 194094 - https://github.com/Daniele-DallAnese-Unitn
- Stefano Modenese - Matricola: 209535 - https://github.com/stefanoModenese
La nostra idea di progetto è quella di sviluppare un servizio per agevolare la ricerca di appartamenti per studenti universitari: potrà permettere sia di cercare appartamenti, sia di inserire annunci, in modo da poter mettere in contatto studenti e locatori rapidamente.
- Github repository: api_project
- Apiary:
- Heroku: housemateproject
- app: codice riguardante il backend dell'applicazione, qui sono definite tutte le api RESTful
- app/models: qui abbiamo definito i modelli per le collezioni dati che verranno poi salvate in MongoDb
- public/images: static folder contenente le immagini che vengono visualizzate nel frontend dell'applicazione
- static: in questa cartella abbiamo inserito la UI e il frontend dell'applicazione
- utils: in questa cartella abbiamo deciso di mettere file utili per il progetto e per il backend dell'applicazione.
Nel progetto software abbiamo deciso di adottare una strategia di branching basata sulla funzionalità che dovevamo implementare, per esempio per la pagina di creazione nuovo annuncio abbiamo creato un nuovo branch. Inoltre abbiamo creato branch separati anche per la parte di bug fixing e abbiamo separato la UI dalla parte di backend, questa scelta è stata fatta perchè diversi membri del gruppo hanno lavorato contemporaneamente sia sulla parte di backend che sul frontend, quindi tenendo separate le parti abbiamo evitato conflitti. Quando una specifica funzionalità veniva implementata e testata abbiamo eseguito il merge sul branch master.
Per la milestone #5 abbiamo deciso di definire "Done" un task che dopo essere stato implementato è stata aggiunta la documentazione su apiary e di cui è stato fatto il merge del branch su "master". Dalla milestone #6 a questa definizione aggiungiamo anche che devono essere presenti i test per lo specifico task.
Il Goal di questo primo sprint è quello di implementare il servizio di HouseMate, concentrandoci sulle prime 6 user stories specificate nella Milestone #4, ovvero: visualizzazione lista annunci, visualizzazione dettagli, registrazione utente, login, logout e inserimento di un nuovo annuncio.
Durante il meeting di Sprint Planning, abbiamo discusso innanzitutto del goal da raggiungere in questo Sprint. Analizzando le user stories specificate nella milestone precedente, abbiamo determinato l’implementazione delle prime 6 storie, come obiettivo dello sviluppo: discutendo tra i vari membri, abbiamo scelto questo insieme di storie, in modo da non appesantire troppo il lavoro del primo Sprint (valutato con cautela inizialmente, in quanto sapevamo avremmo dovuto spendere inizialmente del tempo aggiuntivo per fare pratica con gli strumenti messi a disposizione per il progetto, come per esempio il WorkFlow di GitHub e l’impostazione del database MongoDB), e al contempo di non accumulare troppo lavoro nello Sprint successivo.
Inoltre, prima di iniziare il lavoro dello Sprint, abbiamo deciso riguardo la “definition of Done”: per poter definire il nostro prodotto come “potentially shippable”, abbiamo concordato con il seguire queste indicazioni:
- il codice deve essere commentato il più possibile, specialmente nelle funzioni più importanti, in modo da poter permettere di capire lo scopo della funzione prima ancora di leggere tutto il codice;
- il codice deve essere visionato dagli altri membri del team: così facendo, tutti abbiamo potuto concordare su una determinata modifica al codice, approvandola o mettendola in discussione in caso di pareri discordanti;
- la documentazione deve essere stata stilata: essa deve essere completa, includendo quindi tutte le funzionalità principale del servizio, e gli altri membri del team devono visionarla e approvarla
- il codice del progetto deve essere modificato e aggiornato seguendo le norme di “Versioning Control” di GitHub, in particolar modo creando nuovi branch per ogni nuova feature aggiunta, procedendo poi al suo merge al branch master in caso di assenza di conflitti.
Per concludere la fase di Sprint Planning, abbiamo stilato lo Sprint Backlog, contenente tutte le storie prese in considerazione per questo periodo di lavoro, suddiviso nei rispettivi task: dopo aver fatto ciò, a ciascun membro del team sono stati assegnati dei task, in modo da poter partire con il lavoro effettivo. Successivamente, mano a mano che il codice veniva sviluppato e le feature implementate, nuovi task sono stati occupati dai membri del team, consultandosi prima per evitare conflitti.
Abbiamo fatto una demo del software sviluppato fino a questo punto, come ci si aspettava abbiamo notato dei bug visto che il testing è rinviato allo sprint successivo, ma ci sono venute in mente alcune proposte di modifica. Ci riteniamo tutto sommato soddisfatti del lavoro che siamo riusciti a svolgere in questi dieci giorni e siamo fiduciosi per il secondo sprint.
Product backlog refinement (Commentare aspetti rilevanti del meeting e variazioni al product backlog):
Per quanto riguarda il Product Backlog Refinement, non abbiamo individuato modifiche da effettuare al Product Backlog indicato nella scorsa milestone: le 6 storie selezionate dal team non sono state fonti di particolari dubbi o ripensamenti, permettendoci quindi di mantenere il backlog iniziale, almeno per lo svolgimento di questo primo Sprint.
Sprint retrospective (Commentare conclusioni del meeting, cosa ha funzionato, cosa no, adozione di pratiche “agile”, dinamiche di gruppo, spunti per il prossimo sprint, etc.):
Come Retrospective dello Sprint #1, il lavoro è avanzato in modo discretamente fluido: dopo i primi giorni, in cui al tempo effettivo di sviluppo andava sommato il tempo per fare pratica con gli strumenti di Versioning e il DataBase, i progressi sono stati costanti: il WorkFlow su GitHub è stato fluido, ovvero non ci sono stati problemi di conflitti o modifiche importanti andate perse: questo è dovuto principalmente al metodo di WorkFlow adottato, che ha permesso al team di procedere con il lavoro di sviluppo in modo ordinato e corretto. Per quanto riguarda l'adozione di norme di sviluppo agile, abbiamo seguito molte delle prescrizioni dell'approccio Scrum, come la redazione del product backlog e dello sprint backlog nonché lo svolgimento di gran parte delle riunioni previste (Sprint planning, Sprint Review e Sprint Retrospective). Infine, in retrospettiva abbiamo sottostimato l'impegno neccessario per il completamento di parecchi task, nel secondo sprint useremo l'esperienza acquisita nel corso di questo sprint con lo scopo di fare stime migliori.