Ormai i termini per indicare lo sviluppo software fatto secondo criteri di ottimizzazione e qualità si sprecano: “Agile”, “Scrum”, “Extreme Programming”, “Be Smart”, “CMMI” e sicuramente me ne sto dimenticando qualcuno.

In questo recente libretto di poco meno di 150 pagine si parla addirittura di “Lean”, ovvero “snello, asciutto, scattante”, proprio come l’aquilone che riporta in copertina.

Cosa ha di diverso rispetto agli altri?

Che significato simbolico ha – o cosa rappresenta – l’aquilone in copertina?

E soprattutto, perché uno sviluppatore (o manager, ecc.) dovrebbe leggere questo libro, tra l’altro piuttosto costoso nonostante la piccola dimensione?

Perché fa un bell’excursus dal 1970, epoca della metodologia “Waterfall” – a cui si devono tutti i problemi di software non funzionante – fino ai giorni nostri, dove l’approccio su iterazioni successive, in stile Scrum o XP va per la maggiore.

Perché spiega come l’arte dello sviluppo Lean sia nata nell’industria automobilistica (Toyota) giapponese, e sia poi stata applicata anche ad altri settori, sviluppo del software in particolar modo.

E poi perché è una piacevole lettura da weekend, costituita da brevi capitoli, sintetiche frasi e tanto pragmatismo.

In realtà tale libro può essere letto anche in una sola giornata, ma consiglio di lasciar sedimentare un po’ i concetti, e di non leggere più di un capitolo alla volta.

 

Le leggi “base” sono 5, e ad esse sono riservati 5 capitoli in mezzo al libro

Queste cinque regole, con tra parentesi le pagine ad esse dedicate, sono:

 

1)      Automated Testing

2)      Continuous Integration

3)      Less Code

4)      Short Iterations

5)      Customer Participation

 

Dico “in mezzo al libro” in quanto sono precedute da un capitolo zero e seguite da un capitolo finale e un appendice.

Il capitolo zero (abbastanza inconsueto di per se stesso) riporta i prerequisiti irrinunciabili per qualsiasi attività Agile o Lean che sia. Essi impongono la presenza di un sistema di gestione del codice sorgente, che potrebbe essere CVS o Subversion (Visual Source Safe, ad esempio, non viene nemmeno nominato) e l’utilizzo di script di codice per la realizzazione di compiti ripetitivi, quali potrebbero essere approntare un sistema di deploy automatizzato.

Personalmente sono d’accordissimo sul primo punto (non si può sviluppare senza un repository che mi storicizza il codice e che mi permetta di “ritornare indietro” in caso di errori), mentre sul secondo direi che la presenza di script dipende molto dal progetto in sé, dato che possono benissimo esserci situazioni in cui si vive e si procede benissimo senza.

 

Nell’ultimo capitolo (“What’s next?”) si traccia un breve e sintetico profili di altre metodologie, quali il Kanban, il CMMI, il SixSigma e il ToC.

 

Le pagine sono ariose, con tanto spazio bianco per prendere eventuali appunti; i paragrafi non sono mai lunghi e sono ben spaziati. Le frasi chiare e sintetiche.

Il font è particolarmente piccolo, ma tutto sommato molto leggibile.

Ho notato la mancanza, dato che spesso capita invece in altri testi simili, di piccoli box riportanti le esperienze dirette degli autori, sempre utili ed interessanti (credo che leggere esperienze di vita di altri professionisti sia molto istruttivo e formativo).

 

Nell’unica appendice finale (stranamente più volte indicata come “Appendice A” nel corso del testo) sono riportati i testi di approfondimento suddivisi per capitoli, e quindi anche per aree tematiche.

 

I capitoli hanno una lunghezza contenuta, il che li rende affrontabili riuscendo a chiuderne la lettura senza impegnarsi per delle ore: si passa dalle 6 pagine del capitolo ottavo (“Customer Partecipation”) alle 16 del capitolo 4 (“Automated Testing”). Questo è dovuto in parte anche alla piccolezza del font utilizzato (la lettura comunque non ne viene inficiata, anzi, lo trovo molto leggibile).

 

Quello che mi è piaciuto molto di questo libro è la sua brevità e la sua maneggevolezza; ammettiamolo, chi necessita di leggere un argomento come questo non ha moltissimo tempo da dedicarci. La maggior parte del tempo lo utilizza per scrivere codice, o al massimo per studiare “reali” manuali tecnici, non certo testi sull’arte dello sviluppo software. Questo aspetto spesso viene visto come acquisito dall’esperienza, oppure imposto dall’ambiente in cui si opera. È inutile – e forse anche controproducente – scrivere manuali su Scrum, XP o anche Lean Development eccessivamente lunghi e dettagliati. Pochissimi fanatici dell’argomento li leggeranno per intero. Meglio allora dare le (poche) dritte giuste in poco tempo. Poi con l’esperienza ci si migliora e si affina la tecnica e l’approccio. Al massimo si può riportare una lista di testi dove approfondire, cosa che gli autori di questo libretto appunto fanno nelle ultime pagine.

 

Il lettore ideale di questo libro è chi ha sentito parlare di “Lean” e “Agile” e vuole approfondire un attimo la loro conoscenza senza per questo doversi sorbire tomi da centinaia di pagine.

Ritengo sia altrettanto utile per manager – non necessariamente informatici – per comprendere che benefici tali approcci agili potrebbero portare nella loro attività professionale.

È meno adatto magari a sviluppatori che già possiedono le basi di questi argomenti e vorrebbero una guida esaustiva – con esempi di codice o altro – per approfondire e mettere in pratica queste metodologie.

L’inglese utilizzato è comprensibile, anche se non ai livelli di altri libri tecnici (qualche volta bisogna rileggere un attimo la frase o ricorrere al dizionario).

 

La pagina del sito O’Reilly dedicata al libro è questa. 

da qui è possibile scaricarsi l’intero capitolo 4 (“Practice 1: Automated Testing”).

Non c’è codice sorgente scaricabile, dato che gli esempi presenti nel libro sono veramente ridotti al minimo sindacale, e tutti tratti dalla documentazione ufficiale dei vari tool per lo unit testing.

 

Uno degli autori, Curt Hibbs, ha realizzato anche un podcast su questo libro, reperibile a questo link. 

 

PRO

Come rendere comprensibili a chiunque i concetti di “agilità” nello sviluppo del software, e non solo. Questo, in sostanza, il grande pregio di questo piccolo libro. È la miglior porta d’accesso a questi argomenti che mi è capitato di avere tra le mani recentemente. Rilegatura e impaginazioni eccellenti.

 

CONTRO

Nessun argomento viene approfondito nel dettaglio; non ci sono passi di esempio da seguire per mettere in pratica i consigli e i concetti esposti. Ma questo, più che un “contro”, è una caratteristica del libro, che non vuole essere una guida omnicomprensiva ma fornire un’idea base su cui poi proseguire con personali approfondimenti. Prezzo un po’ superiore alla media.

 

PROS

How to make comprehensible to anyone the concepts of "agility" in the development of software, and not only that. This, in essence, the great merit of this small book. It’s the best leads of access to these topics that I have to have between hands recently. Binding and excellent layout

 

CONS

No argument is thorough in detail; there are steps to put into practice advice and exposed concepts sample. But this one, more than a "hand", is a feature of the book, which does not want to be a guide all-inclusive but provide a basic idea on which then continue with personal insights. Price a bit higher than average.

 

 

Voto complessivo: 8/10

 

Lettore: Tutti

 

 

Table of Contents

Preface

1 – Cap. 1: Why Lean?

15 – Cap. 2: Applying Lean to Software Development

27 – Cap. 3: Practice 0: Source Code Management and Scripted Builds

37 – Cap. 4: Practice 1: Automated Testing

55 – Cap. 5: Practice 2: Continuous Integration

71 – Cap. 6: Practice 3: Less Code

83 – Cap. 7: Practice 4: Short Iterations

95 – Cap. 8: Practice 5: Customer Participation

103 – Cap. 9: What Next?

119 – Resources

123 – Index

 

Titolo:  The Art of Lean Software Development
Autori: Curt Hibbs, Steve Jewett, Mike Sullivan
Editore: O’Reilly
ISBN: 9780596517311
Pagine: 142
Prezzo: 34.99 $ (prezzo di copertina)
Data di uscita: Feb. 2009