Iterazioni e Qualità Integrata

Le iterazioni SAFe sono timebox di 2 settimane (occasionalmente 1 o 3 settimane, ma 2 è lo standard). Ogni iterazione segue un ciclo familiare:

Pianificazione dell'Iterazione (mezza giornata) — Il team rivede gli obiettivi dell'iterazione, preleva le storie dal backlog del team, le scompone in task e si impegna su ciò che consegnerà. In SAFe, gli obiettivi dell'iterazione dovrebbero allinearsi con gli obiettivi del PI stabiliti durante la Pianificazione del PI.

Esecuzione (la maggior parte dell'iterazione) — Il team lavora sulle storie, tiene gli standup giornalieri e si integra continuamente. Le storie si spostano attraverso gli stati: definita, in corso, completata. Il team traccia i progressi rispetto agli obiettivi dell'iterazione.

Revisione dell'Iterazione / Demo di Sistema (1-2 ore) — Il team dimostra il lavoro completato. In SAFe, questo alimenta la Demo di Sistema a livello di ART dove tutti i team mostrano il loro lavoro integrato agli stakeholder. La demo del singolo team è una preparazione per la demo di sistema.

Retrospettiva dell'Iterazione (1 ora) — Il team riflette su cosa è andato bene, cosa no e cosa migliorare. In SAFe, le intuizioni della retrospettiva possono anche alimentare l'evento Inspect & Adapt a livello di PI.

Cosa cambia rispetto allo Scrum autonomo: L'iterazione è sincronizzata tra tutti i team dell'ART. Tutti iniziano e finiscono nello stesso giorno. Questa cadenza condivisa crea punti di integrazione naturali e rende prevedibile il coordinamento tra team.

Ogni PI include un'Iterazione di Innovazione e Pianificazione (IP) alla fine. Questa è unica di SAFe e una delle sue innovazioni più preziose.

Cosa succede durante l'IP:

• Preparazione della Pianificazione del PI: Il Product Management prepara la visione e il backlog per il prossimo PI. I System Architect preparano la runway architetturale. I team analizzano le feature in arrivo.
• Evento di Pianificazione del PI: L'evento di pianificazione di 2 giorni faccia a faccia per il prossimo PI (questo è lo scopo principale dell'iterazione IP).
• Tempo di innovazione: I team usano il tempo rimanente per hackathon, esplorare nuove tecnologie, ripagare il debito tecnico, formazione o perseguire idee che non si adattano perfettamente a un backlog.
• Inspect & Adapt: La retrospettiva formale a livello di PI dove l'intero ART riflette su dati quantitativi (misura di prevedibilità) e osservazioni qualitative.

Perché l'IP è importante:

Senza tempo dedicato all'innovazione, il debito tecnico si accumula, le competenze ristagnano e i team diventano fabbriche di feature. L'iterazione IP è una garanzia strutturale che il miglioramento e l'esplorazione avvengano—non dipende dal "trovare tempo" che non si materializza mai.

L'iterazione IP fornisce anche un buffer naturale. Se i team incontrano complessità inaspettate durante il PI, l'iterazione IP assorbe l'eccedenza senza richiedere estensioni di calendario o tagli di scope nel mezzo di un'iterazione.

SAFe è intransigente sulla qualità: non puoi essere agile con codice scadente. La qualità integrata non è un optional—è un valore fondamentale e un prerequisito per un flusso sostenibile.

Pratiche di ingegneria del software:

• Test-Driven Development (TDD): Scrivi i test prima del codice. Questo produce design migliori e suite di test complete. Su scala, il TDD è ciò che rende praticabile l'integrazione continua.
• Integrazione Continua (CI): Integra il codice più volte al giorno. Costruisci e testa automaticamente. In SAFe, la CI si estende oltre i singoli team—il sistema deve integrarsi tra tutti i team dell'ART.
• Pair Programming / Code Review: Due paia di occhi su ogni modifica. Le coppie ruotano per diffondere la conoscenza. Le code review catturano problemi e condividono il contesto tra i membri del team.
• Ownership Collettivo: Qualsiasi sviluppatore può modificare qualsiasi parte del codebase. Nessun silo di conoscenza. Questo richiede CI e testing per essere sicuro.
• Refactoring: Migliora continuamente la struttura del codice senza cambiare il comportamento. Il debito tecnico si accumula più velocemente su scala perché più persone stanno cambiando più codice.

Pratiche architetturali:

• Architettura Intenzionale: Non lasciare che l'architettura emerga puramente dalle decisioni dei team. I System Architect guidano le preoccupazioni trasversali, assicurano che i team costruiscano su piattaforme condivise e mantengano la runway architetturale per le feature future.
• Runway Architetturale: Investi in anticipo in infrastruttura, framework ed enabler tecnici di cui le feature future avranno bisogno. Senza runway, ogni feature parte da zero.

Perché la qualità su scala conta di più:

Con un team, la scarsa qualità significa consegna lenta. Con dieci team, la scarsa qualità significa fallimenti di integrazione a cascata, scaricabarile e difetti a livello di sistema che nessuno possiede. Il costo dei problemi di qualità cresce in modo super-lineare con il numero di team.