> ## Content Index
> Fetch the complete content index at: https://bitstales.eu/llms.txt
> Use this file to discover other available public pages before exploring further.

# Agile, spiegato con un termostato: il cliente non sa cosa vuole, ma paga (e ha sempre ragione)
- URL: https://bitstales.eu/it/metodologia-agile/
- Published: 2025-09-08T07:36:00.000Z
- Updated: 2025-09-08T07:36:00.000Z
- Description: Anello aperto contro anello chiuso, una simulazione del cliente che cambia idea e un dizionario Agile–Italiano: perché si lavora a sprint, e su cosa il cliente ha davvero sempre ragione.
- Author: Vittorio
- Tags: Software Engineering, Agile, #it

Lunedì, 9:36\. Il daily stand-up da quindici minuti è appena finito, dopo quarantacinque. Il momento perfetto per parlare di **Agile**, la metodologia che parte da un'ammissione onesta e un po' scomoda: *il cliente non sa cosa vuole*. E subito dopo ne aggiunge un'altra: *però paga, e quindi ha sempre ragione*.

Sembra una contraddizione. Non lo è, ed è la cosa più ingegneristica di tutto Agile. Prima la spieghiamo con la teoria del controllo, poi traduciamo il gergo con un piccolo dizionario Agile–Italiano, e infine vediamo su che cosa il cliente ha davvero sempre ragione (e su che cosa no).

## Agile in una frase di teoria del controllo

Ogni ingegnere che ha studiato i controlli automatici conosce la differenza tra **anello aperto** e **anello chiuso**. Un tostapane ad anello aperto scalda per due minuti, qualunque cosa succeda al pane. Un termostato ad anello chiuso misura la temperatura, la confronta con quella desiderata e corregge. Il primo funziona finché il mondo è esattamente come previsto. Il secondo funziona anche quando il mondo cambia.

Il modello *waterfall* è un sistema ad anello aperto: si scrivono le specifiche all'inizio, si calcola tutto il percorso e si esegue senza misurare niente fino alla consegna. Agile è un anello chiuso: si costruisce un pezzo, lo si mostra (il **sensore** è la demo), si misura lo scarto tra ciò che il cliente voleva e ciò che ha visto, e si corregge. Lo sprint è il **periodo di campionamento**.

Il punto chiave è che il "valore desiderato" non è fisso: il cliente cambia idea perché il mercato cambia, perché i concorrenti fanno qualcosa, e soprattutto perché *vedere il software gli fa capire cosa vuole davvero*. È un riferimento che si sposta. Ecco una piccola simulazione: il desiderio del cliente si muove un po' a caso ogni giorno, per un anno, e confrontiamo strategie diverse.

```python
import random

def progetto(sprint, guadagno=0.7, mesi=12, seme=42):
    rnd = random.Random(seme)
    desiderio = prodotto = 0.0
    errore = 0.0
    giorni = mesi * 20                          # giorni lavorativi
    for g in range(1, giorni + 1):
        desiderio += rnd.gauss(0, 1)            # il cliente cambia idea, un po' ogni giorno
        if sprint and g % sprint == 0:          # demo: misuriamo lo scarto e correggiamo
            prodotto += guadagno * (desiderio - prodotto)
        errore += abs(desiderio - prodotto)
    return errore / giorni

# waterfall (specifiche congelate)                scarto medio:   10.9
# sprint di 2 settimane                           scarto medio:    1.5
# sprint di 1 settimana                           scarto medio:    1.0
# ogni giorno, assecondando ogni capriccio        scarto medio:  235371809.3
```

Con altri semi casuali il waterfall oscilla tra 4 e 11, mentre gli sprint restano stabilmente intorno a 1–2\. L'ultima riga è la più istruttiva. Il team che corregge ogni giorno con un **guadagno** eccessivo (qui 2,1, cioè correggendo più del doppio dello scarto misurato) non converge: **diverge**. È il team che fa esattamente quello che dice l'ultima persona che ha parlato in riunione, e ogni giorno sposta il prodotto più di quanto si fosse spostato il desiderio. In teoria del controllo si chiama instabilità. In azienda si chiama "abbiamo cambiato priorità di nuovo".

Da qui due lezioni che valgono più di qualsiasi certificazione:

1. Se il ciclo di feedback è più lungo del tempo che il cliente impiega a cambiare idea, state facendo waterfall, comunque lo chiamiate.
2. Ascoltare il cliente non significa amplificare ogni suo segnale. Un buon controllore filtra il rumore.

## Il dizionario Agile–Italiano

**Waterfall** — *Definizione ironica:* il modo in cui si lavorava prima e di cui si parla male a ogni conferenza. *Davvero:* il nome viene, per ironia della sorte, da un articolo del 1970 di Winston Royce che il modello a cascata lo descriveva per **criticarlo**. Royce scriveva che quell'approccio *«is risky and invites failure»* e raccomandava di iterare, anzi di «fare tutto due volte». Per anni il settore ha citato la figura senza leggere il testo.

**Manifesto Agile** — *Ironica:* un documento firmato da diciassette persone in una località sciistica. *Davvero:* è proprio così. A febbraio 2001, a Snowbird, nello Utah, diciassette sviluppatori scrivono quattro valori e dodici principi. Il secondo principio è quello che spiega tutto: *«Welcome changing requirements, even late in development.»* I cambiamenti non sono un incidente da evitare: sono il motivo per cui il processo esiste.

**Scrum** — *Ironica:* una mischia di rugby in cui la palla è il backlog. *Davvero:* il nome viene proprio dal rugby, attraverso un articolo di Takeuchi e Nonaka su Harvard Business Review (1986) sui team di prodotto giapponesi. Schwaber e Sutherland lo formalizzano a OOPSLA nel 1995.

**Sprint** — *Ironica:* una maratona divisa in tanti pezzi da due settimane, tutti corsi alla velocità dei 100 metri. *Davvero:* un intervallo di tempo fisso alla fine del quale c'è qualcosa di funzionante da mostrare. È il periodo di campionamento dell'anello di controllo: abbastanza lungo da produrre qualcosa di misurabile, abbastanza corto da correggere la rotta prima che sia tardi.

**Backlog** — *Ironica:* il cimitero delle idee del cliente, ordinato per priorità. *Davvero:* la lista ordinata di tutto ciò che *potrebbe* essere fatto. La parola importante è "ordinata": un backlog senza priorità è solo una lista dei desideri.

**User story** — *Ironica:* «Come utente voglio un pulsante, così che ci sia un pulsante.» *Davvero:* il formato «Come <ruolo> voglio <cosa> per <perché>» serve soprattutto per il **perché**, che è proprio la parte che resta vuota più spesso. Senza il perché non si può proporre una soluzione migliore di quella che il cliente ha immaginato.

**Story point** — *Ironica:* un'unità di misura che non misura niente, ma che tutti vogliono convertire in giorni. *Davvero:* una stima relativa della complessità, nata proprio per evitare la conversione in ore. Ron Jeffries, uno dei firmatari del Manifesto, nel 2019 ha scritto: *«I may have invented story points, and if I did, I'm sorry now.»*

**Velocity** — *Ironica:* il numero che il management confronta tra team diversi per capire chi lavora di più. *Davvero:* uno strumento interno a un team per fare previsioni. Appena diventa un obiettivo, entra in gioco la *legge di Goodhart*: quando una misura diventa un obiettivo, smette di essere una buona misura. Le stime gonfiano, la velocity sale, il prodotto no.

**Daily stand-up** — *Ironica:* quindici minuti in piedi che durano quarantacinque, alla fine dei quali tutti si siedono stanchi. *Davvero:* un punto di sincronizzazione rapido per scoprire chi è bloccato. Non è un rapporto di avanzamento per il capo. Se lo diventa, diventa anche lungo.

**Sprint review (demo)** — *Ironica:* il momento in cui il cliente vede il software e dice «sì, ma io intendevo un'altra cosa». *Davvero:* è **esattamente** lo scopo della demo. Quella frase non è un fallimento: è il sensore che funziona. Scoprirlo dopo due settimane costa poco. Scoprirlo dopo diciotto mesi, al collaudo, costa un progetto intero.

**Retrospettiva** — *Ironica:* la riunione in cui si scrivono su post-it gli stessi problemi della volta precedente. *Davvero:* il secondo anello di controllo, quello sul *processo* invece che sul prodotto. Se le azioni decise non vengono mai fatte, l'anello è aperto anche qui.

**Definition of Done** — *Ironica:* «Funziona sulla mia macchina.» *Davvero:* la lista esplicita di ciò che deve essere vero perché qualcosa si possa dire finito: test, revisione, documentazione, rilascio in produzione. Senza questa lista, "fatto" significa cose diverse per persone diverse, e la velocity misura quanto lavoro è stato lasciato a metà.

**MVP (Minimum Viable Product)** — *Ironica:* la versione del prodotto con tutti i difetti e nessuna delle funzioni. *Davvero:* il prodotto più piccolo che permette di *imparare* qualcosa dal mercato (Eric Ries, *The Lean Startup*, 2011). Henrik Kniberg lo ha spiegato con un famoso disegno: se il cliente vuole un'auto, non si consegna prima una ruota, poi un telaio e poi la carrozzeria. Si consegna prima uno skateboard, poi un monopattino, poi una bicicletta. Ogni versione è usabile, e ognuna insegna qualcosa sulla successiva.

**Product Owner** — *Ironica:* la persona che traduce «il cliente ha sempre ragione» in «il cliente ha sempre ragione, ma una cosa alla volta». *Davvero:* è proprio questo il ruolo. Il Product Owner è il **filtro** dell'anello di controllo: raccoglie i segnali (cliente, utenti, mercato), elimina il rumore e decide l'ordine. Senza questo ruolo si torna dritti al guadagno di 2,1 della simulazione.

**Debito tecnico** — *Ironica:* quello che si accumula ogni volta che qualcuno dice «per ora facciamo così». *Davvero:* la metafora è di Ward Cunningham (1992): consegnare in fretta è come prendere un prestito, e va bene se poi lo si ripaga. Agile senza tempo per ripagare il debito è come pagare la carta di credito con un'altra carta di credito.

**Trasformazione Agile** — *Ironica:* un progetto waterfall di diciotto mesi per diventare agili, con un piano Gantt. *Davvero:* succede più spesso di quanto si pensi. Nel 2014 Dave Thomas, uno dei firmatari del Manifesto, ha scritto un articolo intitolato *"Agile is Dead (Long Live Agility)"*: la parola era diventata un prodotto da vendere, mentre l'idea, cioè *agilità*, l'aggettivo, è ancora valida.

## Il cliente ha sempre ragione. Su cosa, esattamente?

La frase viene dal commercio al dettaglio di inizio Novecento: la si attribuisce a Harry Gordon Selfridge e a Marshall Field, mentre César Ritz diceva *«le client n'a jamais tort»*. Non è nata per il software, ma nel software ha un significato preciso, se la si legge bene.

**Il cliente ha sempre ragione sul problema.** Sa cosa gli fa perdere tempo, cosa gli costa soldi, cosa vogliono i suoi clienti. Sa quanto vale una soluzione per lui: per questo paga, e per questo decide le priorità.

**Il cliente non ha necessariamente ragione sulla soluzione.** Quando dice «voglio un pulsante che esporta in Excel», spesso il problema reale è «devo mandare ogni lunedì un report al mio capo». Magari la soluzione migliore è un report automatico via email, e nessun pulsante. Il lavoro dell'ingegnere è risalire dalla soluzione chiesta al problema reale. Tra parentesi: la famosa frase di Henry Ford sui «cavalli più veloci» probabilmente Ford non l'ha mai detta. Non ci sono prove. Anche la citazione preferita da chi dice "il cliente non sa cosa vuole" è, in un certo senso, un requisito inventato.

**Il cliente paga, quindi i soldi sono il segnale più onesto.** Il settimo principio del Manifesto dice: *«Working software is the primary measure of progress.»* Non i documenti, non i diagrammi, non la velocity. Software che funziona e per cui qualcuno è disposto a pagare.

Il contratto, invece, è il punto in cui molte aziende tornano al waterfall senza accorgersene. Un contratto a prezzo fisso, tempi fissi e funzionalità fisse blocca tutti e tre i vertici del cosiddetto *triangolo di ferro*. Se il cliente cambia idea, e lo farà, qualcuno dovrà pagare la differenza, di solito il team con gli straordinari. Le alternative esistono: prezzo e tempi fissi con perimetro flessibile, oppure lo schema che Jeff Sutherland chiama *"Money for Nothing, Change for Free"*. Il cliente può cambiare le priorità senza costi purché scambi funzionalità di pari dimensione, e può chiudere il progetto in anticipo quando ha già il valore che gli serve.

## In sintesi

Agile non è un insieme di riunioni, ruoli e post-it. È una scelta ingegneristica precisa: quando il riferimento si muove, serve un anello chiuso con un periodo di campionamento breve e un filtro che non amplifichi il rumore. Il cliente non sa cosa vuole perché nessuno lo sa finché non lo vede. Paga, quindi decide le priorità. E ha sempre ragione, sul problema. Sulla soluzione, per fortuna, ci sono ancora gli ingegneri.

Alla prossima storia di bit. Stessa ora, stesso sprint. 🏃