Guida a GitHub Projects per i docenti: gestire progetti di team con Scrum e monitorare il contributo di ogni studente

1. Perché un progetto di team ha bisogno di un sistema

Negli ITS e nell'ultimo biennio degli ITIS si lavora in gruppo su progetti veri: un'app, un sito, una rete, un servizio per un'azienda. Il problema del docente è sempre lo stesso: come si fa a sapere chi ha fatto che cosa, e a valutare un voto individuale su un lavoro collettivo.

GitHub Projects risolve la parte «tracciabilità»: ogni compito è un issue con un responsabile, una stima, uno stato e una scadenza (lo sprint). Il lavoro sul codice si lega ai task tramite le pull request. Il docente vede in un pannello chi sta lavorando a cosa e con quale esito.

Cosa ottieni:

• una metodologia reale (Scrum) usata nelle aziende, che gli studenti possono citare in un colloquio;
• un registro del lavoro individuale costruito mentre si lavora, non ricostruito a posteriori;
• la possibilità di intervenire presto (uno studente fermo, un compito bloccato) e non il giorno prima della consegna.

2. Scrum a scuola in una tabella

3. Cosa serve

• Un'organizzazione GitHub e una classe su GitHub Classroom, con assignment di gruppo: ogni team ottiene un repository condiviso.
• Un Project per team, nell'organizzazione, collegato al repository del team.
• Un account di prova per verificare cosa vedono gli studenti.
• Qualche ora di preparazione del backlog iniziale (nel kit ce n'è uno di esempio da 20 storie).

4. Passo 1 – Struttura di team e accessi

1. Forma i team di 3-5 studenti. Evita gruppi più grandi: oltre cinque persone il contributo individuale si disperde.
2. Crea l'assignment di gruppo su GitHub Classroom: ogni team riceve il suo repository, privato.
3. Crea un Project per team nell'organizzazione (Projects → New project) e collegalo al repository del team.
4. Assegna i permessi: gli studenti del team devono poter modificare il Project (ruolo di scrittura). Un team non deve vedere i Project degli altri.
5. Verifica con un account di prova: gli studenti di Classroom spesso sono collaboratori del repository e non membri dell'organizzazione, quindi controlla che possano aprire il Project e modificarlo. Se non possono, invitali come membri dell'organizzazione o raggruppali in un Team di GitHub.
6. Fai una copia: prepara un Project modello e duplicalo per ogni team con Make a copy, così tutti partono dagli stessi campi e dalle stesse viste.

5. Passo 2 – Configurare il Project

5.1 I campi personalizzati

Oltre ai campi predefiniti (assegnatario, etichette, pull request collegate) aggiungi questi:

5.2 Le viste

• Board per stato: colonne Backlog → Fatto, raggruppate per Stato.
• Backlog ordinato: lista ordinata per Priorità.
• Sprint corrente: filtro su Sprint = @current, per vedere solo l'iterazione in corso.
• Per persona: raggruppa per Assignee per vedere il carico di ognuno.

5.3 I workflow automatici

• Quando si apre una PR collegata, l'issue passa a In review.
• Quando la PR viene mergiata, l'issue passa a Fatto e si chiude se la PR contiene Closes #n.
• Aggiungi automaticamente al Project ogni nuovo issue del repository.

6. Passo 3 – Scrivere il backlog

Una storia utente ben scritta ha: titolo chiaro, descrizione con formato “Come [ruolo] voglio [obiettivo] così che [valore]”, criteri di accettazione testabili, stima in punti, priorità.

Nel kit trovi un backlog di esempio da 20 storie per un progetto gestione biblioteca, già con punti e priorità.

7. Passo 4 – Gli sprint

Lo sprint è un periodo di 2 settimane in cui il team si impegna a completare un insieme di task.

1. Sprint planning (30 min): il team sceglie dal backlog cosa fare nello sprint, assegna responsabili e stime.
2. Daily (10 min): cosa ho fatto ieri, cosa faccio oggi, blocchi.
3. Sprint review (15 min): dimostrazione del prodotto funzionante al docente.
4. Retrospettiva (20 min): cosa è andato bene, cosa migliorare.

Alla fine dello sprint, tag o release del repository con incremento funzionante.

8. Passo 5 – Collegare codice e task

Ogni task è un issue. Il lavoro sul codice avviene in branch separati e si chiude con pull request.

• Branch per issue: feature/12-login-utente (dove 12 è il numero dell'issue).
• Pull request con testo “Closes #12” per collegare e chiudere automaticamente l'issue al merge.
• Definition of Done nella PR: checklist di qualità (test, documentazione, review).
• Review tra pari: almeno un compagno approva la PR prima del merge.

9. Passo 6 – Monitorare il contributo di ogni studente

• Vista Per persona: quanti task per studente, stato, punti completati.
• Insights: grafici di burndown, completamento per sprint, attività per persona.
• Pulse / Contributors: chi ha fatto commit, quando, quanto.
• Pull requests: chi ha aperto PR, chi ha fatto review, quanti commenti.
• Report con script: il kit contiene report-contributi.py che genera report per studente e per sprint.

10. Valutare il singolo studente

10.1 Una rubrica a più fonti

La rubrica completa, con descrittori per ogni livello, è nel kit.

10.2 Il voto non è la somma dei punti

I punti dicono quanto e quando, non la qualità del lavoro. Un task da 3 punti fatto bene vale più di uno da 8 fatto male. Usa i dati per ragionare e fare domande, non come formula matematica.

10.3 La valutazione tra pari

A fine sprint ogni studente compila una scheda breve sui compagni (contributo, puntualità, aiuto). Serve a far emergere ciò che i dati non mostrano. Usala come segnale, non come unico criterio: le amicizie falsano.

11. Situazioni difficili

12. ITS e ITIS: cosa cambia

13. Privacy e correttezza

• Trasparenza: dillo agli studenti fin dal primo giorno: cosa misuri (task, PR, review, partecipazione) e come lo userai nella valutazione.
• Dati minimi: il Project mostra nomi utente, attività e date; non inserire dati personali non necessari nei task.
• Minorenni: verifica età minima e regole della scuola per gli account GitHub.
• Repository privati: ogni team deve poter vedere solo il proprio lavoro.
• Uso proporzionato: i dati servono a sostenere gli studenti e a valutare con elementi concreti, non a sorvegliarli minuto per minuto.
• Dati aziendali: per progetti con aziende partner concorda prima cosa può stare nel repository.

14. Problemi frequenti

15. Kit pronto all'uso (scaricabile)

• issue-templates/: tre modelli di issue (storia utente, bug, task tecnico) e il modello di pull request con la Definition of Done;
• backlog-esempio.csv: 20 storie per un progetto scolastico (gestione biblioteca), con punti, priorità e sprint;
• importa-backlog.py, bootstrap-project.sh e crea-etichette.sh: script per creare gli issue, il Project e le etichette con GitHub CLI;
• report-contributi.py: report del contributo per studente e per sprint;
• patto-di-team.md, definition-of-done.md, ruoli-scrum-scuola.md: documenti per il team;
• retrospettiva-template.md e scheda-valutazione-tra-pari.md;
• rubrica-valutazione-individuale.md e scheda-contributo-sprint.md: per il docente;
• calendario-sprint.md;
• LEGGIMI.md: istruzioni.

Come usarlo in 5 passi:

1. Crea il repository modello e copia le cartelle .github/ISSUE_TEMPLATE/ e il modello di pull request.
2. Crea il Project modello (a mano o con bootstrap-project.sh) e aggiungi il campo Sprint dall'interfaccia.
3. Importa il backlog di esempio o scrivine uno tuo.
4. Distribuisci a ogni team il patto di team e la Definition of Done.
5. A fine sprint esporta i dati e genera il report con lo script.

16. Checklist finale