Ottima spiegazione – con esempi – del perché i principi lean (e iterativi) riducono costi e rischi: The Small Batches Principle, di Thomas Limoncelli su CACM, 7/2016.
Archivi categoria: lean
Quanto costa ricevere feedback
Un concetto chiave della rivoluzione industriale è l’economia di scala: aumentando i volumi, riduco il costo della singola unità prodotta.
Ma quando l’obiettivo è di ottenere informazioni utili per migliorare i propri prodotti o servizi, l’economia di scala non serve – bisogna invece ridurre l’impegno necessario a ricevere il feedback, a imparare dall’esperienza.
Kent Beck (ideatore di eXtreme Programming, uno tra i principali processi agili) contrappone Economy of Scale a Economy of Scope, portando come esempio le pratiche di sperimentazione che Facebook usa per adattare e rendere più efficaci i servizi che offre.
Lean Startup
Lean Startup, di Eric Ries, è un libro sull’innovazione di prodotto, non (o almeno non solo, come farebbe pensare il titolo) sul lancio di nuove iniziative imprenditoriali.
Il successo di un prodotto, spiega Ries, nasce spesso dall’aver imparato le lezioni necessarie dal fallimento di precedenti tentativi. Per questo motivo, ogni tentativo di innovazione va condotto come un prototipo da controllare e misurare, ottenendo riscontri concreti e verificabili, rapidamente e con il minor costo possibile. Per poter poi aggiustare il tiro.
Lotto di lavorazione minimo
Uno dei principi basilari dell’approccio Lean: ridurre al minimo il Work in Progress, usando lotti di lavorazione minimi.
Il video mostra due modi diversi di imbustare dieci lettere. Nel primo, tutte le lettere vengono piegate, poi tutte imbustate, poi tutte le buste vengono incollate, infine tutte timbrate. Nel secondo modo, viene lavorata in modo completo una lettera-busta alla volta.
Sviluppo lean e gestione dei requisiti
Interessante numero di Software Engineering Radio con un dialogo – intervista tra Christof Ebert e Frances Paulisch su Lean (software) development: utile complemento al Lean tutorial pubblicato da IEEE Software qualche mese fa, soprattutto per quanto riguarda la gestione dei requisiti in ambito lean.
Lean tutorial
Il numero di September/October 2012 di IEEE Software ha come tema centrale lo sviluppo software Lean (in molti degli articoli della rivista Lean viene messo in relazione a Agile, per evidenziarne affinità e differenze).
L’articolo più interessante è Lean Software Development: a Tutorial di Mary Poppendieck e Michael Cusumano.
Poppendieck è l’autrice che ha pubblicato i testi probabilmente più interessanti sullo sviluppo Lean, come Lean Development Software: An Agile Toolkit for Software Development Managers e Implementing Lean Software Development: From Concept to Cash.
Michael Cusumano, del MIT, Massachussetts Institute of Technology, è da decenni uno degli osservatori più attenti dell’industria del software: il loro tutorial è probabilmente lo scritto più chiaro che sia stato pubblicato finora sull’approccio Lean allo sviluppo software.
Stop Using Story Points
Gli Story Points sono un metodo di stima dimensionale usato per misurare e tenere sotto controllo la produttività e la velocità di un gruppo di sviluppo software. Sono molto diffusi negli ambiti di sviluppo “agile“.
Una riflessione critica sull’uso degli story points in questo intervento di Joshua Kerievsky, che per certi versi testimonia un’evoluzione verso l’approccio “lean“.
Duraturo – adattabile
Il web è il più grande laboratorio mai esistito per studiare il comportamento umano, secondo Gerry McGovern:
“The Web facilitates continuous testing and improvement. Great web designs are responsive and flexible. They allow for rapid innovation based on feedback.”
Dal “Built-to-last” (fatto per durare) al “Built-to-change” (fatto per cambiare).
Sulla stessa linea, per approfondire, l’ottimo libro di Eric Ries, The Lean Startup.
Lean Primer
Una introduzione sintetica ed efficace al pensiero “lean”, di Craig Larman e Bas Vodde.
Agile and Toyota – Alistair Cockburn
due post il 31-12-2006 e 1-1-2007
Re: [APM] Management lineage of software processes
Interestingly, the Toyota Production System (TPS) was already doing most of what we now call agile, already back in the 1970s.
The west didn’t notice what they were doing and misinterpreted it. (most of) Those of us who wrote the agile manifesto in 2001 were not aware of TPS, and simply wrote what was on our minds. Since then, many of us have looked at TPS — and I for one, can’t see that we’ve added very much to what was already in TPS (test-first comes to mind as an exception).
Alistair
Re: [APM] Management lineage of software processes
Thanks, Boris. Well, I have three times visited a place in SLC(O.C.Tanner) where they are implementing TPS pretty strictly in their awards production, and I am unable to to suggest anything that they haven’t already been doing for over a year. I.e., TPS already leads them to everything I know.
Personally, I think it’s pretty nifty that we in software managed to reinvent our own localization of the ideas of TPS without knowing first about TPS. It doesn’t bother me if Toyota got there first (over a 60-year period). I think the ideas are there to be found by multiple groups of people … the math adds up, reflection and inspection lead there.
But the only reason I brought this all up was that someone asked about the sequencing of ideas and influences. AFAIK, we software people were not particularly influenced by Deming or TPS in coming up with the agile manifesto (I can speak for myself — my information came strictly from staring at my interview results and management attempts in the early/mid 1990s … I suspect the same was true for at least most of the people at the Snowbird meeting). And still, looking at time sequencing, it is clear that lean manufacturing got there first. I still don’t know about Deming’sstuff.