La Metodologia È il Livello Superiore

Le pratiche di delivery del software formano uno stack con tre livelli, e la maggior parte dei team cerca di adottarli nell'ordine sbagliato.

Livello 1: Fondamentali. Controllo del codice sorgente, tracciamento del lavoro, comunicazione dell'intento, abitudini di stima e tracciabilità. Queste sono le pratiche che questo corso copre. Sono indipendenti dalla metodologia — un team Scrum e un team Kanban ne hanno entrambi bisogno, e appaiono quasi identiche in entrambi i contesti.

Livello 2: Metodologia. Scrum, Kanban, XP o un ibrido. Qui è dove scegli una cadenza (sprint o flusso continuo), definisci ruoli (o scegli esplicitamente di non farlo) e adotti cerimonie (standup, retrospettive, sessioni di pianificazione). La metodologia dà a un team ritmo e struttura — ma presuppone che i fondamentali siano già in atto.

Livello 3: Scaling. /learn/safe/foundations/why-safe, LeSS, Lean Portfolio Management o pattern di coordinamento fatti in casa. Questo livello conta solo quando più team devono coordinare la delivery. Presuppone che sia i fondamentali che la metodologia funzionino a livello di team.

Lo stack conta perché ogni livello dipende da quello sotto. Un team che esegue Scrum senza un solido tracciamento del lavoro passerà metà di ogni riunione di pianificazione dello sprint a riscoprire cosa è in corso. Un'organizzazione che adotta SAFe senza retrospettive funzionanti a livello di team scalerà la disfunzione, non la delivery.

La maggior parte delle "trasformazioni agile" fallisce perché inizia dal Livello 2 o 3. Comprano uno strumento, assumono un coach, rinominano le riunioni — e poi si chiedono perché la velocity non migliora. La risposta è quasi sempre la stessa: i fondamentali non c'erano.

Ogni metodologia presuppone che tu abbia già le basi. Scrum presuppone che tu possa tracciare il lavoro in un backlog, fare commit del codice in un repository condiviso e stimare lo sforzo con sufficiente consistenza per pianificare uno sprint. Kanban presuppone che tu possa visualizzare gli elementi di lavoro, misurare il cycle time e tracciare un ticket dalla richiesta alla delivery. XP presuppone che tu possa scrivere test, revisionare codice e fare deploy frequentemente.

Nessuno di questi presupposti è dichiarato nelle guide metodologiche, perché gli autori li consideravano ovvi. Ma per molti team, non sono ovvi — sono aspirazionali. E quando un team adotta una metodologia senza i fondamentali, la metodologia diventa teatro: le cerimonie avvengono, gli artefatti esistono, ma i risultati non cambiano.

L'hai visto. Il team che esegue la pianificazione dello sprint ma non può rispondere "a cosa ci siamo impegnati nello sprint scorso?" perché i ticket non sono stati aggiornati. Il team che fa standup giornalieri ma non può condividere i progressi perché metà del lavoro non è tracciato. Il team che tiene retrospettive ma non può agire sugli insight perché non c'è un sistema per assegnare e seguire gli action item.

La soluzione non è abbandonare la metodologia. La soluzione è sistemare prima i fondamentali, poi stratificare la metodologia sopra. Questo è l'ordine che questo corso segue: i Moduli 2–4 coprono i fondamentali (controllo del codice sorgente, ticket, stima), e il Modulo 5 ti aiuta a scegliere quale metodologia — se ce n'è una — adottare una volta che le fondamenta sono solide.