Eliminare il "Waste"
Uno dei principi Lean è eliminare il “Waste” (in italiano: spreco). Questo concetto fu coniato alla fine degli anni ’40 nell’industria manifatturiera da Toyota. All’epoca produrre veicoli era molto costoso e le aziende dovevano chiedere ai clienti prezzi molto elevati. L’unico modo per Toyota di abbassare i prezzi delle auto era ridurre i costi di produzione.
Cosa significa “Waste” nel Lean?
“Waste” o “spreco” è fondamentalmente l’opposto di “Value”, cioè “valore” (una capacità fornita al cliente dalla quale ottiene un vantaggio diretto o indiretto). Ad esempio, una riunione di team senza un motivo concreto è puro spreco di tempo.
Ecco i sette tipi di spreco identificati nel Toyota Production System (TPS) da Shigeo Shingo:
Scorte: prodotti non finiti (WIP: work in progress)
Sovrapproduzione: produrre più di quanto richieda la domanda
Lavorazione: passaggi aggiuntivi nel processo che non sono necessari
Trasporto: trasportare merci da un luogo all’altro
Tempi di attesa: pause tra le singole fasi di lavorazione
Movimenti: movimenti non necessari nel processo
Difetti: errori nei prodotti che compromettono le loro caratteristiche e funzioni
Quali sono i tipi di spreco nello sviluppo software?
Basandosi sui sette tipi di spreco nell’industria manifatturiera, Mary e Tom Poppendiek hanno definito i sette tipi di spreco nello sviluppo software:
Lavori incompleti: in ogni Sprint i membri del team sono responsabili di un numero stabilito di User Story. A volte però non riescono a completarle tutte. Devono quindi scoprire perché non ce l’hanno fatta, per poter ridurre questo tipo di spreco.
Funzionalità aggiuntive: all’inizio il Product Owner ha creato una visione e poi un Product Backlog con funzionalità prioritizzate che creano valore per il prodotto. Il principio di Pareto afferma però che spesso non è necessario sviluppare tutte le funzionalità, perché molte di esse sono inutili.
Apprendimento: in ogni Sprint si accumula sempre più conoscenza che può essere utilizzata per non reinventare continuamente la ruota.
Passaggio di consegne: qui il lavoro viene passato a un’altra persona una volta che la prima ha finito. Come si può contrastare? Il modo migliore è eliminare le dipendenze tra le User Story (e le funzionalità) oppure assegnare tutte le User Story con dipendenze a un unico team per mitigare il rischio.
Ritardi: tutto ciò che ritarda la consegna o l’avvio di un’attività che aggiunge valore. Come si può prevenire? Si devono eliminare i colli di bottiglia e riprogettare ogni processo lento per allinearli.
Cambio di attività: avviene quando il Product Owner cambia le priorità e i membri del team devono passare da una User Story all’altra senza poterla prima completare. La ragione principale è spesso che il Product Owner non ha una visione chiara del prodotto o che un concorrente ha lanciato un nuovo prodotto e si vuole adattare e lanciare il proprio il più rapidamente possibile.
Difetti: questo è uno dei problemi più grandi nello sviluppo software. Dopo un certo tempo si è accumulata un’enorme quantità di debito tecnico e da quel momento bisogna investire molto tempo e impegno per ridurlo Sprint dopo Sprint.
In conclusione posso dire che molte persone credono che Lean non sia un buon approccio per un team che lavora con Agile. Ma si sbagliano. In realtà ogni azienda dovrebbe prima applicare Lean e poi passare ad Agile!
Questo testo proviene dal blog di Mario Lucero ed è stato da noi tradotto in italiano.
Product Backlog Refinement
=> Ecco come si svolge un Backlog Refinement negli Scrum Team.
Come si svolge una Sprint Review nei team agili?
=> Qui scopri come può svolgersi una Sprint Review ideale.
