Rilasciare il più spesso possibile: esempi e conclusioni

<< Informatica x digital Design = Business | Home | Eventi/Workshop Agili >>

Rilasciare il più spesso possibile: esempi e conclusioni

Dal quarto principo del Lean Software Development alcuni esempi che ho preso dal libro Lean Software Development:

Rilasciare il più spesso possibile

Quando nel mercato qualcuno riusce a ridurre i tempi di consegna i concorrenti si adeguano per recuperare il vantaggio competitivo oppure ...

Nel 1971 la Federal Express ha introdotto le consegne overnight dei pacchi. Anche la L.L.Bean si è adeguata e nel 1980 ha introdotto le consegne in giornata mentre la Sears Catalog non lo ha fatto ed è uscita dal mercato
Nel 1980 alle marche giapponesi di auto come Honda e Toyota bastavano 46 mesi per ideare e realizzare un nuovo modello mentre a quelle a americani come GM servivano 60 mesi e hanno rischiato di uscire dal mercato sino a quando non hanno colmato il gap
La Dell per ridurre i costi di obsolescenza dei computer già assemblati e in giacenza in magazzino ha cominciato a assemblare ogni computer solo dopo l'ordine e cosi riesce ad assemblarlo e consegnarlo entro una settimana

Proverbio popolare: "La gatta frettolosa fa i gattini ciechi"

Alcune "misure" che ho notato in team dove il rilascio viene fatto in modo continuato, spesso e bene :

run dei test e refactoring ogni 15min-1ora
1 check-in ogni 2-4 ore
1 integrazione ogni check-in o 2
rilascio ogni 1-2 settimane
planning (spike/crc/stime) ogni 1/2-2 settimane

raggiunte applicando le pratiche di coding agile

Tags : Team Work | Lean Agile | Leadership |

Print | posted @ lunedì 17 novembre 2008 23.07

Comments on this entry:

# re: Rilasciare il più spesso possibile: esempi e conclusioni

by Antonio Ganci at 18/11/2008 10.53

Per ottenere questo risultato è fondamentale curare il progetto affinché sia il più snello e veloce possibile.
Alcuni accorgimenti utili: Ridurre il numero di progetti all'interno di una solution al minimo necessario.
Usare una solution unica se possibile.
Preferire la dipendenza tra progetti piuttosto che tra assembly.

# Re: Rilasciare il più spesso possibile: esempi e conclusioni

by Roberto Messora at 18/11/2008 12.03

Luca posso farti una critica riguardo questa bellissima serie di "spigolature" (come le chiamerebbe la settimana enigmistica)?
Non trovi che ti stai troppo concentrando su "processes and tools" quando l'agilismo al primo principio mette davanti gli individui?
rilasciare il più spesso possibile è un cardine generale a mio avviso, ma mai mi sognerei di dare delle informazioni quantitative come citi alla fine del post.
anteporre il team in quanto composizione di individui e di interazioni fra questi significa anche che le policy di rilascio e quant'altro, che ricadono a mio avviso nell'area dei processi, devono essere commisurate in conseguenza alle dinamiche del team stesso, ed ogni team è fatto a modo suo con le proprie peculiarità.
Non so, non è che ti stai troppo tecnicizzando man mano che passa il tempo, o magari stai troppo guardando al tuo caso specifico e riporti dati validi per il tuo team ma che potrebbero non essere validi in generale?
senza polemica eh... il mio vuol essere uno spunto di discussione, anche perchè proprio in questi giorni sto approfondendo moltissimo le tematiche di gestione progettuale in senso agile come mai ho fatto nella mia vita di professionista.

saluti

# re: Rilasciare il più spesso possibile: esempi e conclusioni

by Luca Minudel at 18/11/2008 12.24

@Ganci

in base all'esperienza (per quanto personale e soggettiva) condivido al 100%

includo 2 link sul tema:
- http://matteo.vaccari.name/blog/archives/134
- www.google.com/.../...ssiENamespaceInAssembly.html

# re: Rilasciare il più spesso possibile: esempi e conclusioni

by Luca Minudel at 18/11/2008 16.13

@Roberto

ogni team e ogni progetto è in un contesto unico e specifico: hai evidenziato un buon punto

partendo da questo, la bravura di un agilista allora sta nel distinguere le difficoltà di cambiare e farsi altri skill (come i muscoli che fanno male dopo un buon allenamento) dagli ostacoli/difficoltà che nascono perché si stà rilasciando ancora troppo raramente (o troppo spesso) per quello specifico team/progetto/cliente (e quindi è un feedback che ci suggerisce di cambiare la frequenza)

i numeri che riporto sono indicativi di alcuni singoli casi specifici, e lo stesso possono essere utili:
- per un team nuovo all'agile che comincia possono essere presi come un primo termine di paragone con cui confrontarsi
(ad esempio quando un check-in dopo una settimana di codifica crea qualche problema, ci si può chiedere se provare a farlo più spesso visto che per altri la cosa ha funzionato)
- un team agile esperto può confrontare i propri numeri con quelli di altri team ed altre esperienze e dai confronti potranno emergere eventuali similarità e trend comuni (per esempio è una regola comune che cicli di feedback iù brevi sono più efficaci? o che si può spingere il ritmo di check-in sino alla metà di quello di test/refactoring/run-test ? )