Sprint #1 - Pappol/UniBuk GitHub Wiki

Sprint goal

Il nostro obiettivo per questo sprint era principalmente prendere confidenza con le tecnologie da impiegare mediante l’implementazione delle funzionalità core del servizio. In particolare ci siamo prefissati di terminare lo sprint con un MVP che permettesse di inserire la gestione basilare degli utenti e dell’autenticazione, oltre che la visualizzazione delle varie risorse del servizio.

Sprint Planning

Sprint backlog

Il backlog del primo sprint s può trovare a questo link al Google sheets

Project Board

La project board si puo trovare a questo link

Sprint

Problemi branching strategy

Durante il corso dello sprint ci siamo accorti di aver create alcuni branch che sono successivamente risultati inutili, uno in particolare è stato quello di deploy in cui abbiamo inserito feature di continuous deployment del frontend e del backend. Ci siamo accorti che non c'era alcuna necessità di creare un branch separato per l'implementazione di questa feature, quindi dopo aver fatto il merge nel branch develop siamo andati a cancellare quello specifico branch per evitare di creare confusione (sempre seguendo sempre la self-explanatory naming convention discussa sopra). Altro problema relativo alla branch strategy riguarda sempre l'implementazione del Continuous Deployment, in cui il workflow react-deploy va a fare il build del frontend e a mettere i file generati nel branch gh-pages. Ci siamo accorti che questo branch è stato appunto inutile e lo abbiamo eliminato dato che abbiamo fatto il deploy sia del frontend che del backend su Heroku.

Abbiamo avuto dei problemi relativi a merge all'interno della repository durante alcuni giorni, in cui siamo andati a fare molteplici volte merge di commit tra api-developer e frontend-develop dato che stavamo apportando modifiche sostanziali alle api per poi appunto testare nel frontend. Questo è stato un problema abbastanza relativo, dato che abbiamo seguito sempre la regola prestabilita di non fare mai il merge tra i sottobranch (api e frontend), ma dato che ha un reso il network poco leggibile abbiamo deciso per il prossimo sprint di andare a cambiare branching strategy strettamente in feature based, in modo che frontend e backend siano uniti e sia possibile fare il testing in modo semplice.

Sprint Planning

Per quanto riguarda il Github Project, abbiamo innanzitutto predisposto una colonna “User stories”, dove abbiamo inserito tutte le user stories che abbiamo pensato durante la fase preliminare. Successivamente abbiamo creato una Issue per ciascuna delle 5 user stories che abbiamo deciso di realizzare in questo primo sprint, e all’interno di ciascuna di queste abbiamo inserito delle checkbox per monitorare lo stato di avanzamento della singola user stories; fatto ciò, abbiamo inserito queste issue in una colonna “In Progress” all’interno del progetto. Abbiamo infine predisposto un’ultima colonna, “Done”, in cui saremmo andati a inserire tutte le user stories completate. Il comportamento di queste colonne, fornito da Github, ci permette di trasferire delle issue (e quindi delle user stories) in Done semplicemente aggiungendo determinati tag nella pull request dei merge sul master, conseguendo un alto livello di automazione e agilità nella manutenzione del progetto stesso.

Team organization

Abbiamo fin dal principio deciso di non aggiornare il daily scrum meeting ogni giorno, bensì ogni tre, strategia ritenuta più compatibile con la nostra carriera da studenti universitari e non full time web developers. Nei daily scrum meeting non è mai emersa una personalità che avesse in tutto e per tutto i tratti di uno scrum master, abbiamo preferito lavorare come team vero e proprio e dare egual voce in capitolo e spazio per iniziativa a tutti e quattro i membri.

Ogni membro del gruppo, di volta in volta, si è fatto carico di lavorare su uno specifico punto di qualche user story, ma è stato estremamente frequente che una medesima funzionalità venisse rifinita progressivamente da più membri, o che si lavorasse insieme alla realizzazione della stessa. [Questo ha portato spesso a un’apparente confusione nel determinare chi fosse l’effettivo autore di una modifica e, per chi si dovesse trovare a osservare l’andamento del progetto da un punto di vista esterno, potrebbe sembrare che alcune funzionalità siano state implementate da una sola persona; non è invece così, in quei casi l’autore del cambiamento è solamente colui che ha inserito nel progetto delle modifiche realizzate a quattro (o anche più) mani. Per arginare questo problema, abbiamo iniziato a incentivare di più il lavoro individuale, e questo ha dato una svolta in positivo sia alla suddivisione progressiva dei compiti, sia alla composizione di un’efficace history dei cambiamenti.]

Testing

Per quanto riguarda il testing abbiamo utilizzato Jest, come spiegato a lezione, e l’abbiamo integrata con la CI di Travis. Abbiamo scritto principalmente test nella forma di unit testing per le singole funzionalità che di volta in volta ci trovavamo a testare; la maggior parte di questi sono relativi alle funzionalità del database, in quanto volevamo essere certi di non avere inconsistenze in una componente così fondamentale dell’applicazione. I dati che andiamo a utilizzare nei test sono valori boundaries, che abbiamo derivato da test precedenti, garantendoci quindi di avere controllo sui dati da ottenere.

Per quanto riguarda i test white box, questi sono stati scritti in ottica di quelle che sono le funzionalità presenti nell’applicazione al momento del deployment da consegnare per questa milestone del 25 novembre. Tutti questi sono basati su azioni che un utente reale può compiere in un browser durante un normale utilizzo dell’applicazione (con le dovute eccezioni nel caso di funzionalità non ancora del tutto implementate) e vanno a verificare il corretto funzionamento e interazioni tra le business logic del backend e del frontend.

Il foglio di calcolo contenente i test cases è disponibile a questo link

Product backlog refinement (backlog grooming)

Product backlog

• Abbiamo mantenuto gli id uguali al report precedente, ma e abbiamo ordinate per grandezza mettendo all'inizio quelle più grosse (considerate come epics) e alla fine quelle più piccole (che impiegano meno tempo).
• La maggior parte delle user stories hanno impiegato da 1 a 3 giorni, mentre alcune (le epics) hanno dato le fondamenta al progetto e di conseguenza hanno impiegato più tempo.
• La nostra strategia utilizzata per il product backlog è stata di strutturare in 5 user story più grandi (considerate come epics) e 6 user story più piccole

Refinement

Ci siamo premurati di rimodulare le stime pensate inizialmente nella prima milestone, a nostro giudizio fin troppo conservative.

La più grande variazione che siamo stati costretti a fare rispetto allo sprint planning iniziale è stato l’aumento del tempo stimato per la realizzazione della UI, che risulta molto evidente anche solo guardando le varie burndown charts. La motivazione è da individuarsi nella curva di apprendimento della libreria ReactJS utilizzata per il frontend; prendere confidenza con questa tecnologia, infatti, si è rivelato essere molto più dispendioso del previsto in termini di tempo.

Inoltre, questo ci ha trattenuti dall’apporre ulteriori raffinamenti allo sprint plan: inizialmente, a fronte di una fase iniziale di progettazione DB e progettazione API piuttosto snella, ci siamo interrogati sulla possibilità di inserire altre user stories al piano, dietro il timore di essere stati troppo conservativi nella quantità di user stories da implementare in questo sprint. Fortunatamente abbiamo scelto di prendere tempo e, per i motivi di cui abbiamo parlato prima, abbiamo abbandonato l’idea e ci siamo concentrati sul perfezionamento delle funzionalità previste.

Sprint Demo #1

I link alla demo su Heroku sono stati forniti in cima alla pagina. Si può testare l'applicazione per esempio in /resources. Bisogna aspettare che carichi sia il frontend che il backend. Una volta caricato la pagina (frontend) bisogna aspettare altri 30 secondi che il backend parta, una volta passati 30 secondi ricaricare la pagina /resources.

Sprint retrospective

Una prima osservazione su cui tutto il gruppo concorda è che il nostro esperimento di aggiornare lo sprint backlog ogni tre giorni non ha portato i risultati che speravamo: la maggiore flessibilità è stata irrisoria rispetto alle maggiori difficoltà di gestione del tempo rimanente; inoltre, le variazioni degli estimates nelle burndown charts risulta poco indicativa del lavoro effettivamente svolto. Per tutti questi motivi, abbiamo stabilito che nel prossimo sprint ci atterremo a un’applicazione più rigorosa di scrum e tracceremo l’evoluzione degli estimates non più una volta ogni tre giorni, ma una volta al giorno.

Nella sezione del backlog grooming abbiamo spiegato come siamo stati costretti a ripensare gli estimate dello sviluppo UI per via del fatto che apprendere la tecnologia di ReactJS ha richiesto più tempo del previsto. Seppur il più notevole, non è stato un caso unico (sezione Architettura per lista completa). Sono stati numerose le giornate in cui ci siamo ritrovati interamente a fare commit con cambiamenti non relativi a qualche user story in particolare, ma bensì ad alcuni dettagli tecnici, come ad esempio l’apprendimento e l’implementazione delle tecnologie CI/CD con Travis, il testing con Jest, il deployment su Heroku, o il setup dell'ambiente Docker e Docker Compose. Tutto questo ha contribuito a rendere compilazione dello Sprint Backlog molto difficile da mantenere e forse poco indicativa del lavoro effettivamente svolto, poiché appunto tiene conto solo del lavoro svolto su delle specifiche User Stories, quando invece gran parte del lavoro che abbiamo svolto, a conti fatti, è stato legato all’apprendimento delle tecnologie da impiegare e all’implementazione di di dettagli tecnici come quelli sopra citati. Confidiamo nel fatto che questa disconnessione sia fortemente ridimensionata durante il secondo sprint, dal momento che abbiamo un livello di confidenza con le tecnologie impiegate sensibilmente superiore.

NOTA: Comportamenti anomali in Github Insights

Poco prima di finalizzare il materiale per la consegna abbiamo notato alcune anomalie nella sezione “Insights” del repository: il numero di righe aggiunte e cancellate, per alcuni dei collaboratori, sono assolutamente sproporzionate rispetto a quello che, ragionevolmente, sono quelle effettive. Inoltre, il numero di clones e views del repository appaiono sproporzionati allo stesso modo. Non abbiamo idea di quale sia il motivo di questo comportamento, ma nessun’altra funzionalità di Github appare compromessa; confidiamo che questo non causi difficoltà al Professore in sede di valutazione.