Questo è il terzo libro sulle metodologie agili che ho letto negli ultimi anni. Due – compreso questo – dalla Pragmatic Bookshelf, e l’altro della O’Reilly, una casa editrice che si mostra molto attenta ed attiva su questi argomenti un po’ al confine tra il tecnico e il manageriale.
Ormai è da un po’ che se ne parla, quindi eviterei di soffermarmi sul cosa siano e a cosa servano le metodologie agili, soprattutto nel mondo dello sviluppo software. Personalmente, come ho riportato anche nelle altre due recensioni, ho avuto la fortuna di provarla direttamente sulla mia pelle nella mia penultima esperienza lavorativa in una banca francese, dove il management illuminato ha avuto l’idea di formare noi sviluppatori sulle metodologie agili, in particolare sullo Scrum, una delle due grandi divisioni di queste tecniche (l’altra è l’Extreme Programming).
Questo libro, a cura di due consulenti donna, una londinese e l’altra neo zelandese, è indirizzato in particolare a chi voglia diventare “Coach”, ovvero la persona, all’interno del team, che ha il compito di guidare e formare secondo i dettami “agili” gli sviluppatori componenti il team stesso.
L’altro testo della Pragmatic che avevo letto, ovvero “Practices of an Agile Developer”, era più dedicato allo sviluppatore facente parte del team, ergendosi come vero e proprio coach in carta e inchiostro.

Il libro è suddiviso in 4 parti, che coprono le 4 macro aree in cui si esplica la gestione “agile” del team di sviluppo. La prima parte – “Coaching Basics” – ha lo scopo di introdurre, in maniera graduale ed approfondita, il lettore sulle metodologie agili nell’ambito dello sviluppo del software. Vengono trattati argomenti quali la collaborazione, l’utilità dei meeting mattutini, le relazioni tra i componenti del team e la gestione del progetto software. La seconda parte – “Planning as a Team” – è più tecnica, e spiega come organizzare materialmente l’ambiente. Questa può risultare la parte più interessante, dato che contiene un maggior numero di immagini, grafici, fotografie altro materiale utile per fissare le idee.
La terza parte – “Caring about Quality” – prosegue sul discorso tecnico iniziato nei precedenti capitoli per parlare di unit test, continuos integration, incremental design e pair programming.
Infine con la quarta parte – “IV Listening to Feedback” – si chiude il ciclo di vita del software spiegando come organizzare al meglio i deploy e le demo, oltra a raccogliere i feedback del cliente.

Inoltre, dopo aver dedicato 13 capitoli sul come migliorare il proprio team e i propri colleghi, le autrici dedicano l’ultimo capitolo al lettore in quanto singolo individuo, fornendogli consigli e suggerimenti per migliorarne la propria cultura, formazione ed attitudine al lavoro (in campo informatico, ovviamente).
Chiude il libro una completa e ragionata bibliografia di 3 pagine. Mi sorprende un po’ però non ritrovarvi il libro di cui parlavo all’inizio della recensione. Credo rappresenti una più che valida aggiunta, e far sapere al lettore della sua esistenza lo avrei apprezzato particolarmente.

Ogni capitolo termina con due interessanti sezioni: “Hurdles” – ovvero “ostacoli” – che mette in guardia il lettore dai possibili impedimenti e difficoltà che potrebbero sorgere nella messa in pratica dei concetti esposti nel capitolo, e una sezione riepilogativa “Checklist” (dal nome inequivocabile) che altro non è che un sommario schematico per punti. Volendo accelerare la lettura del libro, basterebbe leggere le prefazioni e queste due ultime sezioni, lasciando gli approfondimenti e i racconti delle esperienze dirette per una seconda posticipata lettura.
Lettura che viene facilitata e resa più attraente dai numerosi box sparsi qua e là che raccolgono le esperienze dirette delle autrici, e sono utili per capire cosa fare e come comportarsi in situazioni simili.
Bisogna però sottolineare come la prosa utilizzi un inglese piuttosto colloquiale e non facile da leggere per chi non conosca più che bene questa lingua. Anche io, pur essendo ormai abituato a leggere libri in lingua anglosassone, praticamente in ogni pagina sono incappato in parole sconosciute.
L’altro libro di cui parlavo prima (“Practice of an agile developer”), dato che contiene meno parti scritte e con un linguaggio più semplice, lo troverei più indicato per un lettore italiano.

L’aspetto fisico di questo libro, invece, è quanto di meglio si possa desiderare. La rilegatura è flessibile e resistente nello stesso tempo. La carta è liscia ma non lucida, sottile ma non velina. Sfogliarlo al tatto è davvero un piacere.
Tutti i libri di informatica (ma non solo) dovrebbero essere fatti così.
Notare inoltre come il libro si mantenga entro le 200 pagine, aspetto non secondario per libri che vogliano parlare di “agilità”. E come anche riporti una piantina nell’immagine di copertina. Farla crescere e germogliare riflette il percorso di crescita delle persone.
Una nota per finire: consiglierei di non leggere più di un capitolo alla volta. Meglio leggere le 15/20 pagine di ogni capitolo, lasciarle sedimentare nella mente e riflettere sul proprio modo di lavorare e capire cosa c’è di diverso rispetto a quanto esposto dalle autrici, prima di passare al capitolo successivo. È il modo migliore per assimilare i concetti.

PRO

Dopo la lettura dei 14 capitoli di questo libro è ben difficile che il lettore non abbia imparato come portare il proprio team verso le metodologie agili. Molto carine ed interessanti le storie personali riportate dalle autrici. Impaginazione e rilegatura eccellenti.

 

CONTRO

I “Contro” sono fondamentalmente due: innanzitutto il linguaggio utilizzato è (credo) comprensibile appieno dai lettori madrelingua inglese, o perlomeno da chi conosce l’inglese in maniera più che ottima. Poi esiste una certa carenza di immagini/diagrammi/disegni che, soprattutto per un argomento come questo, risultano fondamentali per la comprensione. Quelle poche fotografie già presenti, tra l’altro, sono molto scure.

 

 

Voto complessivo: 8.5/10

 

Lettore: Tutti

 

Table of Contents

Foreward

Introduction

Generic Agile              

The Aim of this Book            

How to Read This Book           

Acknowledgements

I Coaching Basics

1 Starting the Journey

19 - 1.1 What does an Agile Coach do?       

21 - 1.2 Developing a Coaching Attitude     

23 - 1.3 Getting Ready To Coach         

27 - 1.4 How To Start Coaching         

30 - 1.5 Maintaining the Pace          

33 - 1.6 Hurdles              

34 - 1.7 Checklist           

2 Working with People

36 - 2.1 Listening           

40 - 2.2 Giving Feedback           

42 - 2.3 Resolving Conflicts          

44 - 2.4 Building Agreement          

46 - 2.5 Checklist             

3 Leading Change

47 - 3.1 Introducing Change          

51 - 3.2 Asking Questions           

56 - 3.3 Encourage Learning       

58 - 3.4 Facilitating Meetings      

59 - 3.5 Hurdles              

60 - 3.6 Checklist           

4 Building an Agile Team

62 - 4.1 Helping Your Team Jell         

65 - 4.2 Creating a Team Space         

67 - 4.3 Balancing Roles           

68 - 4.4 Energizing the Team    

71 - 4.5 Hurdles             

73 - 4.6 Checklist           

II Planning as a Team

5 Daily Standup

76 - 5.1 Standing Up            

77 - 5.2 For the Team by the Team        

81 - 5.3 Handling Issues           

83 - 5.4 Setting the Time          

84 - 5.5 When To Coach          

85 - 5.6 Hurdles              

89 - 5.7 Checklist           

6 Understanding What To Build

90 - 6.1 Life-cycle of a User Story         

91 - 6.2 Encouraging Conversations      

92 - 6.3 Working with Cards          

95 - 6.4 Confirming the Details      

99 - 6.5 Hurdles             

101 - 6.6 Checklist             

7 Planning Ahead

102 - 7.1 Preparing for Planning         

103 - 7.2 Understanding Priorities         

104 - 7.3 Sizing the Work           

109 - 7.4 Review and Commit         

112 - 7.5 Keeping Track            

114 - 7.6 Hurdles              

117 - 7.7 Checklist             

8 Keeping it Visible

119 - 8.1 The Team Board           

125 - 8.2 Big Visible Charts          

129 - 8.3 Maintaining The Team Board       

130 - 8.4 Hurdles             

131 - 8.5 Checklist             

III Caring about Quality

9 Getting to Done

133 - 9.1 Who Does the Testing?         

134 - 9.2 Define What Done Means     

136 - 9.3 Plan Testing In            

137 - 9.4 Managing Bugs           

142 - 9.5 Getting Feedback Early         

143 - 9.6 Recovering from Not Getting Done     

145 - 9.7 Hurdles              

146 - 9.8 Checklist             

10 Driving Development with Tests

147 - 10.1 Introducing Test-Driven Development     

153 - 10.2 Continuous Integration         

157 - 10.3 Sustaining Test-Driven Development     

160 - 10.4 Hurdles              

161 - 10.5 Checklist             

11 Clean Code

163 - 11.1 Incremental Design          

168 - 11.2 Collective Code Ownership        

173 - 11.3 Pair Programming          

176 - 11.4 Hurdles             

178 - 11.5 Checklist             

IV Listening to Feedback

12 Demonstrating Results

180 - 12.1 Preparing for the Demo         

184 - 12.2 Everyone Plays A Part         

188 - 12.3 Releasing the Software         

188 - 12.4 Hurdles              

190 - 12.5 Checklist             

13 Driving Change with Retrospectives

192 - 13.1 Facilitating a Retrospective       

201 - 13.2 Designing a Retrospective        

203 - 13.3 Broader Retrospectives         

205 - 13.4 Hurdles              

206 - 13.5 Checklist             

14 Growing You

207 - 14.1 Ways to Grow What You Know       

210 - 14.2 Have a Plan            

211 - 14.3 Building Your Network         

213 - 14.4 Personal Reflections           

215 - 14.5 Getting Comfortable          

218 - 14.6 Checklist             

A Bibliography

222 - Index