Sviluppo software e metodologie Agile: come lavora un team moderno

Il daily dura venticinque minuti. Ognuno racconta cosa ha fatto il giorno prima, il project manager prende nota, nessuno dice che il rilascio è bloccato da due giorni per un problema di permessi sul database. La retro ha prodotto tre azioni, come sempre: la prima era la stessa del mese scorso, la seconda non ha un responsabile, la terza è "migliorare la comunicazione".

Il team fa tutto quello che c'è scritto nella guida. E non consegna. Il punto non è che Agile non funzioni: è che le metodologie sono il contorno, e il piatto — il software che arriva in produzione e si può correggere in fretta — dipende da poche scelte tecniche e organizzative che nessuna cerimonia sostituisce.

Prima di tutto: Agile è un insieme di valori, non un processo

Il Manifesto per lo sviluppo Agile del software è del febbraio 2001 e sta in una pagina. Diciassette persone che avevano lavorato su progetti falliti scrissero quattro preferenze: persone e interazioni rispetto a processi e strumenti, software funzionante rispetto a documentazione esaustiva, collaborazione con il cliente rispetto alla negoziazione contrattuale, risposta al cambiamento rispetto all'esecuzione di un piano.

"Preferire" non significa "abolire": la documentazione serve, il contratto serve, il piano serve. Significa che, in caso di conflitto, vince l'altro lato. La differenza con un approccio a cascata non sta nel numero di riunioni: sta in chi prende le decisioni e con quali informazioni.

Da quel testo sono nati framework e metodi diversi. Confonderli con Agile è l'errore che genera quasi tutti i fraintendimenti successivi.

Scrum 2020: cosa dice davvero il framework

Lo Scrum Guide nella versione del novembre 2020 è un documento di circa quindici pagine, scritto da Ken Schwaber e Jeff Sutherland, e definisce Scrum come un framework leggero che aiuta persone, team e organizzazioni a generare valore attraverso soluzioni adattive per problemi complessi. Poggia sull'empirismo: si decide in base a ciò che si osserva, non a ciò che si era previsto.

Tre pilastri — trasparenza, ispezione, adattamento — e cinque valori: impegno, concentrazione, apertura, rispetto, coraggio. Chi ha lavorato in team che li violavano tutti sa riconoscere la differenza meglio di qualsiasi definizione.

La struttura è essenziale:

• Tre responsabilità, non tre ruoli gerarchici: Developers, Product Owner, Scrum Master. Il Product Owner è una persona, non un comitato, ed è responsabile della gestione efficace del product backlog. Il team è tipicamente di dieci persone o meno.
• Cinque eventi dentro uno contenitore, lo Sprint (lungo al massimo un mese): sprint planning, daily scrum da quindici minuti, sprint review, retrospettiva.
• Tre artefatti con un impegno ciascuno: product backlog con il product goal, sprint backlog con lo sprint goal, increment con la definition of done.

Due frasi della guida valgono più di dieci slide. La prima: lo sprint review non va considerato un cancello al rilascio del valore — l'incremento può essere rilasciato prima della fine dello sprint. La seconda: implementare solo una parte di Scrum è possibile, ma il risultato non è Scrum. Molte organizzazioni hanno preso i quindici minuti del daily e lasciato a casa il resto, compresa la parte scomoda: la definition of done, il coraggio di dire che il lavoro non è finito.

Il test non è la cerimonia, è il flusso

Un team che fa tutti gli eventi e non riesce a mettere in produzione una modifica in una settimana non è un team agile: è un team con un calendario.

Le ricerche DORA, il programma di Google Cloud che studia le prestazioni di consegna del software, indicano da anni la stessa cosa: velocità e stabilità non sono in opposizione, e il modo per migliorare entrambe è ridurre la dimensione dei cambiamenti. Il documento sulle metriche di delivery lo dice esplicitamente: batch più piccoli sono più facili da ragionare, da far passare e da annullare quando qualcosa va storto.

"Batch piccolo" ha un significato operativo preciso: una modifica che tocca tre file e un test è piccola; una che tocca la base di dati, il frontend e il sistema di autenticazione è un progetto, non una modifica. La dimensione del batch è la variabile che un team controlla davvero, e quasi mai viene discussa in retrospettiva.

Sei pratiche che distinguono un team che consegna

Nessuna di queste è una cerimonia, tutte si possono verificare guardando il repository e la pipeline.

1. Storie verticali. Una storia che taglia tutti gli strati — interfaccia, logica, dato — si può rilasciare e mostrare. Una storia "facciamo le API" no. Il taglio verticale è più difficile da stimare e infinitamente più facile da verificare.

2. Definition of done reale. Se la DoD dice solo "codice scritto e testato", significa che non c'è. Una DoD utile elenca ciò che serve perché l'incremento sia usabile: test automatici che passano, revisione fatta, migrazione applicata, monitoraggio attivo, documentazione minima aggiornata.

3. Revisioni piccole e veloci. Una pull request da mille righe non viene revisionata, viene approvata. Se le revisioni restano aperte giorni, il collo di bottiglia è organizzativo, non tecnico.

4. Deploy ripetibile. Un rilascio che richiede una persona specifica e una procedura scritta a mano contiene già il suo incidente. L'infrastruttura descritta come codice — come in Terraform e Infrastructure as Code — e la configurazione gestita da strumenti come Ansible, che abbiamo raccontato in questo articolo, sono la premessa per rilasciare spesso.

5. Tracciabilità dei rilasci. Sapere quale versione gira, con quale configurazione e per quale modifica è ciò che rende possibile il rollback. È il terreno del GitOps: lo stato desiderato nel repository, la produzione che converge su di esso.

6. Retrospettive con azioni tracciate. Due azioni con un responsabile e una data battono dodici idee. Se alla retro successiva nessuno ricorda cosa era stato deciso, l'evento non serve a migliorare: serve a sentirsi migliori.

Come si misura un team senza rovinarlo

DORA ha fissato cinque metriche, divise tra throughput e instabilità. Attenzione: per anni sono state chiamate "le quattro chiavi", ma il modello è cambiato e oggi sono cinque.

• Change lead time: dal commit al rilascio in produzione.
• Deployment frequency: quanto spesso si rilascia.
• Failed deployment recovery time: quanto ci vuole a recuperare dopo un rilascio che richiede intervento immediato. Ha sostituito la vecchia MTTR.
• Change fail rate: la quota di rilasci che richiedono intervento immediato.
• Deployment rework rate: la quota di rilasci non pianificati causati da un incidente in produzione.

La parte più utile della guida DORA è però l'elenco delle trappole. Trasformare una metrica in un obiettivo — "entro dicembre ogni applicazione deve rilasciare tre volte al giorno" — è il modo più rapido per falsificarla. Un solo indicatore che domina su tutti produce comportamenti distorti. Confrontare applicazioni diverse non ha senso. E le metriche vanno lette insieme, da sviluppo e operations, altrimenti diventano un'arma tra reparti.

Nella pratica: una baseline, una conversazione sui vincoli, un miglioramento per volta. Le misure servono a capire dove sta il collo di bottiglia, non a classificare le persone.

Gli anti-pattern che si vedono più spesso

La stima diventa un impegno. Se lo story point diventa una promessa contrattuale, il team impara a stimare per difendersi e la stima perde ogni valore informativo.

Il Product Owner non decide. Se ogni priorità richiede l'approvazione di tre dirigenti, il backlog diventa un documento di negoziazione e il team lavora su ciò che è stato promesso a qualcun altro.

Lo Scrum Master fa il segretario. Il suo lavoro è l'efficacia del team, non le note della riunione.

La velocity diventa un obiettivo. Misurata come produttività individuale o come target da raggiungere, spinge a gonfiare le stime. È il caso di scuola della legge di Goodhart.

La demo non è il software. Una presentazione con slide al posto di un ambiente reale nasconde esattamente i problemi che la sprint review dovrebbe far emergere.

Agile imposto dall'alto. Un'organizzazione che obbliga i team a essere agili mantenendo approvazioni a cascata, budget annuali e piani a dodici mesi sta chiedendo un paradosso, e i team lo risolvono nel modo peggiore: fingendo.

Agile non è l'unica opzione, e va bene così

Scrum è un framework, non una religione. Un team di manutenzione con richieste continue e priorità che cambiano ogni giorno spesso lavora meglio con Kanban: flusso continuo, limiti su quanto lavoro è in corso, nessuno sprint. Un team di prodotto con una roadmap da esplorare trova in Scrum la cadenza che gli serve.

La domanda da porsi non è "quale metodologia", ma "quale ciclo di feedback possiamo sostenere". Se i rilasci richiedono un mese, nessuna retrospettiva vi dirà cosa non funziona, perché il feedback arriva troppo tardi per essere collegato alle decisioni.

Le competenze che servono

Un team moderno chiede due cose che raramente stanno nella stessa persona: competenza tecnica profonda — test, design del codice, pipeline, ambienti — e capacità di lavorare sulle decisioni, non solo sui task. Chi sa scrivere codice ma non sa dire di no a una richiesta fuori tempo è un collo di bottiglia; chi sa facilitare una retrospettiva ma non capisce perché un deploy è lento non può migliorarla.

Le certificazioni sul framework danno un vocabolario comune a chi arriva da contesti diversi, ma nessun attestato sostituisce la pratica. Se il team deve costruire questa base — sviluppo, test automatici, integrazione e rilascio continuo, con strumenti che si usano davvero — nel catalogo dei corsi Digital Lab trovate i percorsi su sviluppo software, DevOps e metodologie, con laboratori su progetti reali.