Che cos’è un project e come si sceglie il layout
Un project è uno strumento di pianificazione flessibile che si appoggia agli issue e alle pull request già presenti nei repository: quando cambia qualcosa sull’elemento originale, l’informazione viene sincronizzata automaticamente nel project. A differenza degli strumenti di repository, un project può raccogliere elementi provenienti da repository diversi, e può contenere anche draft issue, cioè appunti che vivono solo dentro il project finché non vengono convertiti in issue veri.
Ogni view di un project ha un proprio layout, scelto dall’icona a ingranaggio View options accanto alla barra di ricerca. I layout disponibili sono tre.
Il layout Table è un foglio di calcolo denso: mostra molti elementi con i relativi metadati e serve quando devi leggere, ordinare, filtrare o modificare tanti campi in blocco, per esempio durante il grooming di un backlog.
Il layout Board distribuisce gli elementi in colonne come una kanban board. La colonna può essere pilotata dal campo Status, da un campo single select o da un campo iterazione: trascinando una scheda da una colonna all’altra il valore del campo si aggiorna da solo. È il layout del lavoro quotidiano di un team.
Il layout Roadmap posiziona gli elementi su una linea del tempo di durata configurabile, usando i campi data e i campi iterazione. Mostra anche marcatori verticali per date chiave e milestone, e permette di trascinare un elemento per cambiarne data di inizio o di arrivo. Serve alla vista d’insieme, non al dettaglio.
L’esame verifica proprio l’abbinamento fra scenario e layout: davanti a una domanda che parla di “visione temporale su più settimane” la risposta è Roadmap, davanti a “spostare il lavoro fra stati” è Board, davanti a “modificare in massa i metadati” è Table. Ricorda inoltre che il layout è una proprietà della singola view, non del project: lo stesso project può avere contemporaneamente una view Board e una view Roadmap sugli stessi dati.
Campi personalizzati, iterazioni e automazioni
Oltre ai campi integrati, puoi aggiungere campi personalizzati di tipo testo, numero, data e single select, utili per priorità, stima di complessità o data di rilascio prevista. Un project supporta fino a 50 campi complessivi, integrati e personalizzati.
Il campo iteration merita attenzione a parte: associa gli elementi a blocchi di tempo ricorrenti, cioè agli sprint. Alla creazione vengono generate tre iterazioni, la durata si esprime in giorni o settimane e puoi inserire break per segnalare le pause dal lavoro pianificato. Nei filtri sono disponibili i riferimenti speciali @current, @previous e @next, che restano validi senza doverli riscrivere a ogni sprint.
Le automazioni integrate si configurano dal menu con i tre puntini del project, alla voce Workflows. Fra i default workflows due sono attivi di serie: quando un issue o una pull request nel project viene chiuso lo Status diventa Done, e quando una pull request viene merged lo Status diventa Done. Altri workflow permettono di aggiungere automaticamente al project gli elementi di un repository che corrispondono a un filtro e di archiviare gli elementi che soddisfano un criterio. Per logiche più elaborate si passa a GitHub Actions o all’API GraphQL.
Label, milestone, assignee e saved replies
Qui si concentra la confusione tipica dell’esame. Label e milestone non sono funzionalità del project: sono strumenti del repository che il project si limita a mostrare, filtrare e raggruppare. Le label esistono nel singolo repository, ne vengono create dieci di default, servono a classificare issue, pull request e discussion; per crearle o modificarle serve il permesso write, mentre per applicarle e rimuoverle basta triage. Una milestone raggruppa issue e pull request di un repository verso un obiettivo, ha una data di scadenza e mostra la percentuale di completamento con il conteggio degli elementi aperti e chiusi. Se lo scenario richiede di seguire lavoro distribuito su più repository, la risposta è un project, non una milestone.
Sul fronte comunicazione, gli assignee dichiarano chi è responsabile: un issue o una pull request ne accetta fino a dieci, scelti fra te stesso, chi ha commentato, chi ha permesso write sul repository e i membri dell’organizzazione con permesso read. Le saved replies sono risposte riutilizzabili per i commenti ricorrenti; il punto da memorizzare è che appartengono al tuo account personale, quindi funzionano in tutti i repository e in tutte le organizzazioni ma non si condividono con il team, e se ne possono creare al massimo cento.
Insights: leggere l’andamento del lavoro
La sezione Insights genera grafici che usano come sorgente dati gli elementi del project. I current charts fotografano la situazione attuale, per esempio il carico distribuito per persona o per iterazione; gli historical charts seguono l’evoluzione nel tempo degli stati degli elementi, e il grafico storico predefinito è il burn up, che confronta il lavoro completato con quello ancora aperto per individuare tendenze e colli di bottiglia. Puoi creare grafici personalizzati e applicare filtri per restringere i dati. Attenzione a un dettaglio spesso chiesto: Insights non considera gli elementi archiviati o eliminati, quindi un’automazione di archiviazione troppo aggressiva rende i grafici poco rappresentativi.