Capstone: presentazione e retrospettiva

In parole semplici

L’ultima sessione del capstone (e del corso) chiude il cerchio: presenti il caso, ricevi review, scrivi la retrospettiva. Sono i sessanta minuti che trasformano “ho risolto un bug” in “ho un metodo che posso applicare di nuovo”.

Cosa impari (rivedere applicare)

• Modulo 6.1: chiedere/dare feedback strutturato.
• Modulo 6.4: review canonica.
• Modulo 6.5: retrospettiva blameless.
• Modulo 9.5: postmortem.

Sessione finale: scaletta 60 minuti

0–10 min: preparazione della presentazione

Prepara una demo di 10 minuti strutturata in cinque blocchi:

1. Il bug (1 min): segnalazione originale, perché era difficile.
2. L’indagine (3 min): ipotesi, prove, scoperte chiave.
3. La causa radice (1 min): cosa abbiamo trovato e perché.
4. Il fix (3 min): le modifiche minime applicate, test.
5. Verifica e lezioni (2 min): cosa funziona ora, cosa ho imparato.

Non slide. Sufficiente: taccuino aperto, codice in editor, PR in browser.

10–25 min: presentazione

Al compagno (o docente). Mentre presenti:

• Vai dal segnalato al fix in 10 minuti.
• Non difenderti: spiega cosa è andato bene e cosa male.
• Cita prove, non opinioni.
• Mostra il taccuino, mostra il diff, mostra i test che passano.

Al pubblico:

• Non interrompere durante la presentazione.
• Prendi appunti.
• Domande a fine presentazione.

25–40 min: review e domande

Domande tipiche (e utili) della review:

• “Quali ipotesi avevi escluso e perché?”
• “Hai considerato un’altra causa?”
• “Il test E2E copre anche [caso vicino]?”
• “Hai pensato al rollback in caso di problemi in produzione?”
• “Come si potrebbe automatizzare la rilevazione di bug simili in futuro?”

Le rispondi a voce. Le note vanno nel taccuino.

40–55 min: postmortem

Scrivi il postmortem usando il template del modulo 6.5 / 9.5:

# Capstone Postmortem: Checkout duplicati e scomparsi

## Sintesi
Tre cause composte (UI senza disable, server senza idempotency,
race POST/GET) producevano ordini duplicati o "scomparsi"
nelle ore di punta.

## Timeline
- 09:15 — Segnalazione ricevuta da Customer Success.
- 09:30 — Bug report compilato. Caso minimo identificato (doppio click rapido).
- 10:15 — Indagine: ipotesi 1 (doppio submit) confermata.
- 11:00 — Ipotesi 2 (idempotency server) confermata.
- 11:30 — Ipotesi 3 (race POST/GET) confermata parzialmente.
- 14:00 — Fix client + server applicati.
- 15:30 — Test e matrice manuale OK.
- 16:00 — PR aperta per review.

## Impatto
Simulato. In produzione: stimato impatto su ~X% degli ordini in ora di punta.

## Causa diretta
Doppio submit + assenza di idempotency-key lato server.

## Causa radice
- Mancanza di linea guida interna su submission UI (no disable durante in-flight request).
- Header `Idempotency-Key` non documentato come obbligatorio nella API spec.
- Test E2E non copriva interazioni rapide.

## Cosa è andato bene
- Caso minimo identificato in 15 minuti.
- Ciclo ipotesi/prova/esito ha portato a tre cause in 90 minuti.
- Test pre-fix scritti prima del fix.

## Cosa è andato male
- Race condition POST/GET resta da indagare a fondo (#C-002).
- La documentazione API non menzionava l'idempotenza richiesta.

## Azioni correttive
- [ ] ADR-008 "Idempotency negli endpoint di scrittura" — owner: me, scadenza +7 gg.
- [ ] Linea guida UI "submit con disable + AbortController" — owner: me, +7 gg.
- [ ] Test E2E "doppio click" su tutti i form di scrittura — owner: me, +14 gg.
- [ ] Indagare race POST/GET (#C-002) — owner: me, +21 gg.

## Lezione condivisa
Gli endpoint di scrittura DEVONO supportare Idempotency-Key.
Tutti i submit UI DEVONO disabilitare il pulsante durante la richiesta.

55–60 min: chiusura del corso

• Aggiorna il taccuino con la retrospettiva finale.
• Salva tutto nella tua “biblioteca personale di debug”.
• Decidi: quale dei 9 moduli vuoi rivisitare nel prossimo mese?

Cosa porti via dal corso

Dopo 79 ore (63 + 16 di Modulo 0 + capstone) hai:

• Un metodo: riproduci, leggi, osserva, isola, correggi, collabora, racconta.
• Un taccuino vivo con casi reali documentati.
• Una checklist mentale per ogni fase.
• Strumenti pratici: DevTools, breakpoint, git bisect, AbortController, source map, OpenTelemetry.
• Un postmortem template riutilizzabile.

Come continuare

• Applica il metodo ad ogni bug che incontri nella tua attività.
• Tieni il taccuino aggiornato per almeno un mese: serve a interiorizzare.
• Rivisita un modulo per settimana per stabilizzare.
• Insegna ad altri: spiegare consolida ciò che sai.

Errori frequenti nell’ultima sessione

• Tono difensivo durante la presentazione. Il capstone non è un esame: è una sessione di apprendimento.
• Saltare il postmortem perché “tanto era simulato”. Il postmortem è esercizio, non burocrazia.
• Non aggiornare il taccuino con le scoperte della review. Le domande del pubblico sono spesso le più informative.
• Trattare il corso come “finito”. È iniziato.

Grazie. Buon debug.