-
Notifications
You must be signed in to change notification settings - Fork 0
Sprint #1
Il goal del primo sprint è stato creare la struttura e le funzionalità di base delle API RestFul e del client Vue in modo da consegnare un’applicazione web funzionante anche se spartana.
Link allo sprint backlog: https://docs.google.com/spreadsheets/d/1OpbRwB_Z7LICdDP12J4CRnnvlK7oz8zuxENha4H4-Gk/edit?usp=sharing
Project board: https://github.com/Momofil31/HomeCheck/projects/1
Dopo un incontro con il professore a fine sprint ci siamo accorti di aver interpretato erroneamente il modo di compilare il documento dello sprint backlog. Durante lo sprint abbiamo infatti inserito erroneamente le ore di lavoro per ogni giorno invece che le ore residue. Inoltre la stima iniziale delle ore di lavoro è stata fatta per ciascuna user story invece che per ciascun task.
Come da accordo con il professore per questo sprint lasceremo così il documento. Per il secondo sprint procederemo nel modo corretto, segnando quindi le ore residue e compilando la stima iniziale per ogni singolo task.
Nel nostro gruppo abbiamo tutti orari differenti quindi il daily scrum si teneva nel primo pomeriggio per organizzare le attività dal pomeriggio fino alla mattina successiva.
Questa asincronicità era aiutata dalle notifiche sul gruppo telegram inviate da un bot appositamente configurato ogni volta che un commit veniva caricato sulla repository. Sotto il messaggio di commit venivano elencate eventuali note per le persone interessate, ad esempio una chiamata di backend modificata per il frontend. Inoltre grazie al documento contenente lo sprint backlog (“prenotazione” del task) e alla comunicazione su telegram, siamo riusciti a dividerci il lavoro in modo che nessuno “pestasse i piedi” a qualcun altro.
Abbiamo inoltre fatto largo uso di chiamate su google meet oltre che per il daily scrum anche per risolvere bug.
Un altro strumento molto importante nell’organizzazione del lavoro è stata la project board di Github che ci ha permesso di tenere sotto controllo lo stato di ciascuna user story durante tutto lo sviluppo del progetto.
Un altro strumento molto utilizzato è stato l’app Toggl Track per conteggiare con precisione le ore di lavoro sul progetto.
Sono stati sviluppati 21 test cases per un totale di 540 righe di codice. I 5 test più importanti sono:
- Products: POST create a product
- Categories: POST create a category
- Users: Creation of a new user should succeed
- Users: Login should succeed
- Groups: GetList should return list of groups
Durante lo sprint è stato necessario solamente modificare la priorità di alcune user stories. Abbiamo dovuto infatti dare priorità allo sviluppo delle user stories relative alle categorie in quanto necessarie poi per sviluppare quelle relative ai prodotti.
Il tutorial “How to demo” si trova al seguente link: https://github.com/Momofil31/HomeCheck/blob/master/README.md
Link Heroku:
Possiamo ritenerci abbastanza soddisfatti di come sia andato questo primo sprint. Lo sprint goal è stato raggiunto pienamente e possiamo dirci soddisfatti dalla qualità del codice prodotto. Tra ciò che ha funzionato bene possiamo includere la comunicazione all’interno del team e il pieno utilizzo degli strumenti di gestione del progetto a nostra disposizione.
Abbiamo notato tuttavia un lato negativo riguardo Scrum. Questa metodologia sembra molto più adatta un team di programmatori in un’azienda, piuttosto che a degli studenti che svolgono un progetto per un corso universitario. Avendo turni di lavoro ben definiti (Lunedì-Venerdì, 9-17) Scrum risulta molto pratico per l’organizzazione in azienda. Nel nostro caso invece avendo ognuno poco tempo a disposizione e soprattutto in orari frastagliati seguire precisamente la metodologia scrum è risultato poco pratico e, per usare un eufemismo, meno agile. In particolare è risultato pressoché impossibile tenere conto delle metriche standard di Scrum come velocity o WIP. Per quanto riguarda i ruoli di scrum, con un team così piccolo non risultano ben definiti. Per rispettare completamente le prescrizioni di Scrum sono mancate infatti le figure del product owner e dello scrum master.
Certamente però gli strumenti di pianificazione come il product backlog e lo sprint backlog, la definizione standardizzata delle User Story e l’utilizzo della project board sono stati degli elementi che ci hanno aiutato molto a mantenere la giusta rotta.
Dobbiamo aggiungere che, probabilmente a causa della poca esperienza, le stime dell’effort sono state molto grossolane e spesso molto lontane dal tempo impiegato realmente per ciascuna user story.