Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 597, comments - 1062, trackbacks - 81

My Links

News

Gian Maria Ricci
Mvp Logo
CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

Lean software development

Dopo avere letto un po di materiale su Kamban, sulla Teory of Constraint e sul Lean in generale mi convinco sempre di più che probabilmente è il modo corretto di lavorare. La limitazione del Work In Process infatti è probabilmente la procedura di controllo migliore che possiamo fare durante lo sviluppo software, perchè troppo spesso lavorare su mille cose in parallelo è fonte di bassissima qualità.

Il problema è che lavorare sempre in condizioni di “mancanza di tempo”, produce solitamente confusione ed un cattivo uso del poco tempo a disposizione, che essendo già poco dovrebbe essere invece usato nel migliore modo possibile. Purtroppo sembra che questo modo di procedere si sia oramai sedimentato e preso come assunto, per cui è oramai normale pensare di lavorare sempre in condizioni di scheduling assurdi ed agire di conseguenza.

Il sintomo di questo è arrivare a ridosso delle date di scadenza con “quasi tutto fatto”, ma senza avere bene specificato cosa significa “fatto”. Quello che accade è quindi deploy stile “bagno di sangue”, problemi di manutenzione e via dicendo, perchè in realtà fatto viene spesso tradotto con “lo sviluppatore ha scritto il codice e se va bene qualcuno ha fatto un giro nel software per verificare che non esploda”.

Sono quindi convinto che adottare dei processi iterativi, con limitazione stile Drum-Buffer-Rope, possa risolvere molti dei problemi, soprattutto perchè in questo caso nessuno nel team può produrre codice di bassa qualità con la scusa di “non avere tempo” o “scheduling impossibili”, dato che il quantitativo di Work In Process è limitato.

L’obiezione classica è che non si può dire al cliente che non faremo tutto, o che alla data di scadenza avremo solamente quello che siamo riusciti a fare, ma in realtà limitare il work in process non significa far lavorare il team più lentamente, significa razionalizzare il processo, affrontare i problemi un poco per volta e soprattutto piano piano “capire” quanto veloce può andare il team e magari fare pianificazioni future più aderenti alla realtà. Se il nostro team è in grado di realizzare diciamo 4 user stories ogni due settimane, non potrà mai implementarne 50 in due mesi, indipendentemente dal processo utilizzato, e dalle ore di overtime imposte al team.

Gian Maria.

Print | posted on martedì 10 gennaio 2012 10.03 |

Feedback

Gravatar

# re: Lean software development

Le persone non sono multi thread, se fanno più cose contemporaneamente ci mettono più tempo e il risultato è peggiore.
Pur essendo una considerazione ovvia, è difficile da applicare.
Probabilmente il mondo in cui viviamo del "tutto subito" ci ha forzato a questa distorsione mentale.
10/01/2012 10.44 | Roberto Cappelletti
Gravatar

# re: Lean software development

Non avendo mai avuto l'oppurtunità di applicare metodologie lean, non ho dati di prima persona, però mi convince l'idea di usare il tempo in maniera più "efficiente", focalizzandosi su un quantitativo massimo di cose da fare in un determinato tempo, ma che debbono però essere "finite".

Nel mondo industriale questa mentalità è oramai assodata e vincente, però si parla di processi oramai conosciuti e formalizzati, mentre per i software è ancora oggi tutto molto "evanescente :).
10/01/2012 14.36 | alkampfer@nablasoft.com
Gravatar

# re: Lean software development

Non "ancora oggi", semmai "oggi e sempre piu'": ai miei bei tempi l'ingegneria informatica e del software *era* una cosa seria.

Il limite principale di Lean (al punto tale che di fatto lo consiglierei giusto ai miei nemici piu' antipatici) e' che si tratta fondamentalmente di metodi di produzione di impronta statistica derivanti dall'esperienza della produzione manifatturiera su larga scala... Insomma, e' proprio l'esatto contrario della produzione di know-how che ci caratterizza. (Dove l'accento non e' tanto su "manifatturiera" quanto e ancora di piu' su "di impronta statistica".)

-LV
11/01/2012 19.46 | LudovicoVan
Comments have been closed on this topic.

Powered by: