Lean Thinking per sviluppatori software impegnati: la versione definitiva, ora anche su carta

La versione 3.0 di "Lean Thinking per sviluppatori software impegnati" rifà i capitoli 1-6 sui feedback dei lettori e porta l'AI agentica dentro tutto il testo, non solo nel capitolo che le è dedicato. E adesso c'è anche l'edizione cartacea, 6x9 pollici (15,24 x 22,86 cm), 316 pagine.

Il Lean nasce in fabbrica. Il software non è una fabbrica. È da questa frase che è partito il libro, ed è il motivo per cui la maggior parte dei testi Lean per developer finisce in un cassetto: applicano ricette del manifatturiero a un mestiere dove la materia prima sono requisiti ambigui, non bulloni standardizzati.

Oggi esce la versione che considero definitiva, e con lei l’edizione stampata. La carta era in programma da sempre, ma un libro si manda in tipografia quando è finito, non mentre lo stai ancora scrivendo. Adesso è finito, quindi eccolo su Amazon anche in cartaceo.

Quello che ho visto nei team a cui ho insegnato il Lean

Il libro nasce da lì, non da una lettura. Faccio consulenza e formazione su questi principi dentro aziende vere, e la velocità con cui un team rinasce quando smette di combattere contro il proprio processo continua a stupirmi. Gente che alla prima riunione non apriva bocca, due mesi dopo ti ferma in corridoio per dirti come andrebbe cambiata la board.

Poi arriva la parte scomoda. Quando il flusso di lavoro finisce sotto gli occhi di tutti, quasi sempre viene fuori che il collo di bottiglia non era il team. Erano le priorità riscritte ogni lunedì, le approvazioni ferme per giorni sulla scrivania di qualcuno, il lavoro iniziato tre volte e mai finito. Molto spesso è stato il management ad accorgersene per primo, e ad ammettere che il problema da sistemare era il suo. È lì che le cose hanno cominciato a muoversi sul serio.

Software House da incubo

Una delle analogie che uso più volentieri me l’ha regalata la televisione. Se non hai mai visto “Cucine da incubo”, il meccanismo è sempre lo stesso: un ristorante sta per chiudere, lo chef ci passa qualche giorno, guarda come lavorano davvero durante il servizio, ribalta il locale e se ne va lasciando una cucina che funziona. Nessuno parla mai di produzione o di processi, eppure quasi tutto quello che lo chef impone è Lean: taglia un menù con ottanta piatti e lo porta a dieci fatti bene, svuota le celle piene di roba comprata mesi prima, rimette in ordine la cucina perché i movimenti inutili si vedono a occhio, guarda il servizio dal vivo invece di ascoltare le versioni di chi ci lavora, e prima di andarsene ridà dignità a una brigata che si era rassegnata. Riduzione della varietà, scorte, sprechi di movimento, andare a vedere sul posto, rispetto per le persone. Sono gli stessi capitoli.

Ci si potrebbe fare “Software House da incubo” senza cambiare una virgola del metodo. Cambia l’artefatto, il piatto diventa una release, la cella frigorifera diventa un backlog di quattrocento ticket che nessuno aprirà mai, il servizio del sabato sera diventa il deploy del venerdì. I principi restano quelli.

Succede perché sono principi e non leggi, ed è una differenza che nel nostro mestiere ci sfugge di continuo. Il principio regge al cambio di contesto: “fai vedere il lavoro fermo” vale in una cucina, in un reparto e in un repository. La legge no, la legge va riscritta ogni volta che cambia il contesto, perché era stata tarata su quello di prima. E noi nel software siamo bravissimi a scrivere leggi, con i loro bravi numeri: due settimane di sprint, l'80% di coverage, il limite di WIP a cinque, quattro cerimonie a settimana. Poi cambia il team, cambia il prodotto, e la legge continua a valere per inerzia mentre il principio che l’aveva generata non se lo ricorda più nessuno.

Per questo il libro spiega ogni principio nel suo contesto originale, quello di Toyota, e poi lo re-inventa per il software invece di travasarlo. Se hai capito il principio, quando il contesto cambia la legge te la riscrivi da solo, che è poi l’unica cosa che serve davvero.

“Kitchen Nightmares” nasce come “Ramsay’s Kitchen Nightmares”, format creato e prodotto da Optomen Television per Channel 4 e distribuito nel mondo da All3Media International; Gordon Ramsay conduce le edizioni britannica e statunitense. “Cucine da incubo” è l’adattamento italiano condotto da Antonino Cannavacciuolo, oggi uno Sky Original prodotto da Endemol Shine Italy. Titoli, format e marchi appartengono ai rispettivi titolari: qui li cito solo per analogia, senza alcun rapporto con il programma o con i suoi produttori.

Cosa c’è dentro il libro

I capitoli 1-6 li ho riscritti sui feedback dei lettori: ragionamenti più discorsivi, e scenari presi dalla giornata vera di chi sviluppa invece che dalla catena di montaggio.

I numeri sono lì per essere rifatti. La legge di Little nella forma che serve davvero, Lead Time = WIP / Throughput, e una tabella sul work in progress costruita su assunzioni dichiarate, un team di cinque persone e task da otto giorni-persona, così puoi verificare riga per riga cosa succede quando passi da tre lavori in parallelo a uno. Le citazioni risalgono tutte alla fonte primaria, e qualcuna riserva sorprese: la parola “Lean” non l’hanno coniata Womack e Jones nel 1990, è di John Krafcik, in un articolo del 1988 nato dalla sua ricerca al MIT.

Poi ci sono le pagine che uso io per prime: il cheat sheet finale, la tabella dei 7+1 muda con la colonna degli esempi concreti, la checklist della code review Lean.

I ventiquattro diagrammi servono a questo, a far vedere in una figura quello che in prosa richiede due pagine. Per esempio i tre pilastri su cui sta in piedi tutto il resto.

L’AI agentica non sta in un capitolo solo

Quando ho iniziato a scrivere, gli assistenti AI completavano righe di codice. Oggi aprono pull request.

Un capitolo dedicato c’è, ma relegare l’AI lì dentro sarebbe stato comodo e falso. Gli agenti spostano gli equilibri ovunque, quindi il discorso torna dove serve: nel flusso, nelle stime, nei limiti di WIP, nella code review, nel modo in cui si guarda la qualità. Dove l’AI non cambia niente non ne parlo, dove cambia qualcosa lo dico nel punto in cui il lettore se lo sta chiedendo.

C’è un’obiezione che sento spesso: se l’AI scrive il codice al posto mio, il Lean serve meno. È esattamente il contrario. Quando il costo di produrre codice crolla, tutto il resto resta dov’era: le attese per le approvazioni, i feedback loop lunghi settimane, il tempo in cui il lavoro è fermo in coda. Se prima scrivevi una feature in tre giorni e ne aspettavi sette per il deploy, lo squilibrio era tollerabile. Oggi che la scrivi in due ore, quei sette giorni diventano intollerabili e visibilissimi.

Questo è il diagramma che nel libro accompagna il capitolo sul flusso. Contale, le giornate: quasi tutte sono attesa, e nessuna di quelle caselle diventa più corta perché un agente scrive il codice al posto tuo.

Nel libro trovi tre sprechi che nel Toyota Production System non potevano esistere.

Il vibe coding: generare codice senza comprenderlo, accettandolo finché sembra funzionare. È il cargo cult tecnico in versione moderna, si adottano le forme esterne (il codice compila, le funzioni si chiamano) senza la sostanza. Ogni riga accettata senza capirla è debito tecnico che non vedi nel momento in cui lo firmi e paghi a ogni manutenzione.

Poi c’è la sovraccapacità generativa. La sovrapproduzione classica nasce da un developer che decide di costruire “mentre ci siamo”, qui invece è l’agente che costruisce mentre ci pensa: varianti che nessuno ha chiesto, casi limite inventati, gestione di errori per scenari che il sistema non contempla. Roba che qualcuno dovrà comunque mantenere.

L’ultimo è il verification overhead, cioè il costo di rileggere criticamente quello che l’agente produce. Non è zero e non compare in nessuna stima. L’agente non conosce le tue convenzioni architetturali, né le regole di business implicite che il team si è accumulato negli anni. Se quel tempo non lo conti, la velocità di generazione sembra produttività e non lo è.

Perché la carta

Perché me l’avete chiesta in tanti. C’è chi legge volentieri in digitale e chi con un testo da consultare preferisce la carta: il libro resta aperto accanto alla tastiera, si annota a margine, si ritrova la pagina che serve senza aprire niente. Sono gusti, e la 3.0 adesso li copre tutti e due.

L’edizione cartacea è 6x9 pollici, cioè 15,24 x 22,86 cm, 316 pagine, carta crema. I ventiquattro diagrammi li ho rifatti apposta per la stampa, così sulla pagina si leggono come si leggono a schermo.

Per chi è, e per chi no

Se il tuo team scrive codice più in fretta di quanto riesca a portarlo in produzione, il collo di bottiglia non è la tastiera. Questo libro serve a trovarlo e a toglierlo, con quello che avete già in casa: la board che guardate ogni mattina, i numeri del vostro flusso, la code review del venerdì pomeriggio. È scritto per developer senior, tech lead, architetti e CTO di PMI tecniche, cioè per chi il codice lo scrive davvero e non ha tempo da perdere con la teoria. Gli esempi sono in Python per leggibilità, ma i principi valgono in qualsiasi linguaggio.

Il libro non è per manager in cerca di slide motivazionali, né per consulenti in cerca di un framework da rivendere. E non è un libro sul Toyota Production System: Toyota è la premessa storica, non l’argomento.

Dove si trova

Edizione Kindle e cartacea sono su Amazon: 9,99 euro il Kindle, 19,90 il cartaceo. Su Leanpub resta la versione digitale, con gli aggiornamenti inclusi come sempre per chi l’ha già acquistata.

Il libro è scritto in italiano. Entro l’anno esce anche l’edizione inglese; spagnolo, portoghese brasiliano e tedesco dipendono da quante richieste arrivano, quindi se ti serve una di quelle lingue scrivimi a d.teti@bittime.it dicendomi quale.

Se il libro ti è servito, la cosa più utile che puoi fare è lasciare una recensione onesta. Per un libro tecnico italiano autopubblicato quelle poche righe pesano più di qualunque campagna.