Skip to main content

Modalità di suddivisione in itinere dei task

Durante il processo di sviluppo, i task sono stati suddivisi in modo da facilitare la gestione e il monitoraggio del progresso. La suddivisione dei task è stata effettuata in base alla complessità e alla durata stimata, utilizzando un approccio Agile che consente una maggiore flessibilità e adattamento alle esigenze del progetto, sfruttando Trello come strumento di collaborazione e monitoraggio delle attività.

Trello

Per la gestione del progetto, è stato utilizzato Trello come strumento di collaborazione e monitoraggio delle attività. Trello ha permesso al team di visualizzare il progresso del progetto, assegnare compiti e tenere traccia delle scadenze in modo efficace.

  • Ad ogni Sprint Planning, il team ha selezionato gli elementi del backlog da completare durante lo sprint e li ha aggiunti a una colonna "Sprint Backlog" su Trello. Ogni item dello sprint backlog è decomposto in task specifici, che sono stati assegnati ai membri del team.
  • I task meno importanti non vengono assegnati a nessun membro del team, ma restano disponibili per essere presi in carico da chiunque abbia tempo libero durante lo sprint.
  • Durante i Daily Standup, i membri del team aggiornano lo stato dei loro task su Trello, spostandoli tra le colonne "Sprint Backlog", "In Progress" e "Done Sprint [end date]" a seconda del loro stato attuale.

Vengono utilizzate le label di Trello per categorizzare i task in base alla loro priorità e tipo di attività, facilitando la visualizzazione e la gestione del lavoro da svolgere, sono state definite le seguenti label:

  • High: Per i task che richiedono attenzione immediata e sono critici per il progresso dello sprint.
  • Medium: Per i task che sono importanti ma non urgenti, possono essere completati dopo i task ad alta priorità.
  • Low: Per i task che possono essere completati se c'è tempo disponibile, ma non sono essenziali per il completamento dello sprint.
  • Bug: Per i task che riguardano la correzione di errori o problemi riscontrati nel software.
  • C.I.: Per i task che riguardano lo sviluppo di nuove funzionalità o miglioramenti del prodotto.
  • Docs: Per i task che riguardano la scrittura o l'aggiornamento della documentazione del progetto.
  • Feature: Per i task che riguardano lo sviluppo di nuove funzionalità del prodotto.
  • Test: Per i task che riguardano test manuali e verifiche della qualità del software.
  • Research: Per i task che riguardano la ricerca e l'analisi di nuove tecnologie o metodologie da applicare al progetto.
  • Architecture: Per i task che riguardano la progettazione e l'architettura del software, inclusi miglioramenti strutturali o di design.

Inoltre, per la stima della durata dei task si è sfruttato il Power-Up "Activity Timer", che consente di tenere traccia del tempo impiegato per completare ciascun task. La stima della durata dei task è stata effettuata in modo collaborativo durante lo Sprint Planning, ogni membro del team ha espresso la propria opinione sulla durata stimata di ciascun task, e si è raggiunto un consenso su una stima finale. Questa stima è stata poi utilizzata per pianificare il lavoro dello sprint e monitorare i progressi. Le stime sono state effettuate in ore, scelgiendo un valore della successione di Fibonacci (0.5, 1, 2, 3, 5, 8, 13, ...) per rappresentare la complessità e la durata dei task. Questo approccio ha permesso al team di avere una visione chiara del carico di lavoro e di pianificare le attività in modo più efficace.

Nel caso in cui un task venga stimato di durata superiore a 13 ore, viene suddiviso in task più piccoli, in modo da facilitare la gestione e il monitoraggio del progresso.