Cos'è il lean software development e cosa non si trasferisce?
I principi della produzione snella portati sul software: si elimina l'attesa e il lavoro non finito, non le persone.
Il lean software development è l'applicazione allo sviluppo software dei principi nati nella produzione Toyota e resi noti da Womack e Jones con Lean Thinking (1996): definire il valore dal punto di vista di chi lo riceve, far scorrere il lavoro senza soste, tirarlo dalla domanda invece di spingerlo dalla previsione. La traduzione al software è di Mary e Tom Poppendieck, che in Lean Software Development (2003) riscrivono i sette sprechi della fabbrica e nel seguito, Implementing Lean Software Development (2006), ne fissano la versione oggi citata ovunque: il lavoro cominciato e non finito, le funzionalità in più che nessuno ha chiesto, il dover reimparare cose già sapute, i passaggi di consegne, il cambio di contesto, le attese e i difetti. Il primo di quella lista è il più caro e il meno visibile: il lavoro fermo a metà non compare in nessun bilancio, non fa rumore e continua a costare ogni settimana.
Cosa non si trasferisce, ed è la parte che si omette
Il Lean nasce dove le unità di produzione sono ripetibili e misurabili: un pezzo uguale al precedente, un tempo ciclo che ha senso confrontare. Il software è lavoro di progettazione, dove ogni unità è diversa dalla precedente per definizione, perché se fosse identica la si copierebbe invece di riscriverla. Il trasferimento ingenuo produce sempre lo stesso guasto: si misura la quantità di lavoro consegnato come se fossero pezzi prodotti, la misura diventa l'obiettivo, e da quel momento smette di dire qualcosa di vero. È il meccanismo della legge di Goodhart, e nel software si presenta quasi sempre travestito da cruscotto di produttività.
Un esempio concreto
Una software house segue quattro clienti con tre sviluppatori e ogni richiesta entra appena arriva. Nessuno è fermo, eppure niente esce: undici cose sono cominciate e nessuna è finita, e ogni cambio di cliente costa mezz'ora per rientrare nel problema. La correzione lean non è assumere: è smettere di cominciare. Si fissa un tetto a quanto può essere aperto insieme, e il lavoro nuovo entra solo quando qualcosa esce. Il tempo che passa fra la richiesta e la consegna si accorcia senza che nessuno lavori di più, perché quello che si è tolto è l'attesa, non lo sforzo.
Perché conta per chi decide
Chi ha vissuto il lean in fabbrica riconosce lo schema e commette lo stesso errore in due direzioni opposte. Da un lato applica gli strumenti alla lettera, e ottiene misure che non misurano. Dall'altro conclude che nel software non valga nulla, e butta via l'unica idea che si trasferisce integra: il collo di bottiglia non è quasi mai la velocità di chi esegue, è la quantità di lavoro aperto contemporaneamente. Quella si vede in un pomeriggio e si corregge senza comprare niente, ed è il territorio pratico di Kanban.
Domande frequenti
Termini correlati
- Kanban · Metodo di gestione del flusso di lavoro: si rende visibile quello che è aperto e si mette un tetto a quanto può esserlo.
- Agile · Organizzare lo sviluppo in cicli brevi ridecidendo le priorità: funziona se il contratto permette di cambiare il perimetro.
- Scrum · Framework di sviluppo a cicli di durata fissa, con tre responsabilità e cinque eventi: utile solo se il product owner decide davvero.
- Legge di Goodhart · Quando una metrica diventa l'obiettivo smette di misurare: il criterio di Goodhart applicato all'accettazione di un progetto AI.
- Debito tecnico · La metafora di Ward Cunningham: ogni scorciatoia nel codice è un prestito, e gli interessi si pagano a ogni modifica successiva.
Un termine che ti riguarda da vicino? Parliamone.
CONTATTAMI