Extreme Programming Explained – Kent Beck
(in inglese) – Addison Wesley
(in inglese) – Addison Wesley
Una caratteristica dell’Extreme Programming che la differenzia da altre metodologie è quella di scegliere un set di best practice molto ‘decise’ nell’approccio, e non prive di pericoli e rischi.
Il ‘trucco’ di XP è quello di fare in modo che ogni svantaggio / rischio di una best practice sia bilanciato dalle caratteristiche di almeno un'altra pratica del set, in modo da avere un sistema che si ‘auto protegga’.
In questo approccio, è evidente, sta sia la forza che la debolezza di questa metodologia, che va adottata in toto, senza vie di mezzo, per non fallire.
Pregi del libro
Il libro si fa leggere molto bene, è discorsivo, chiaro e ben esposto. L’argomento è affascinante e le promesse sono alte.
Capitoli e paragrafi sono corti e scritti in linguaggio non troppo tecnico. Non sono presenti dettagli implementativi, codice sorgente o altri aspetti comprensibili solo dagli sviluppatori.
Praticamente è alla portata di chiunque mastichi un minimo di gestione dei progetti software.
Difetti del libro
I difetti emergono a distanza di tempo.
Il contenuto sembra invecchiare più velocemente di altri argomenti di software engineering. Leggendo oggi questo libro il tutto sembra troppo ottimista, ‘fattibilista’ e in generale poco applicabile.
Si nota anche una tendenza alla ripetizione, al calcare a distanza di diversi capitoli due o tre ‘mantra’ fondamentali che diventano pesanti e noiosi quando si conosce già Extreme Programming con tutti i suoi pregi e difetti.
Anche l’enfasi sui princìpi su cui si basa XP, che rubano troppo spazio alle pratiche, sembra diretto più alla presentazione di una filosofia che ad un approccio pragmatico diretto all’uso quotidiano.
In conclusione
Ai tempi in cui l’agile si scontrava con i metodi tradizionali Extreme Programming ha rappresentato un elemento di rottura e di conflitto che è servito ad attirare molta attenzione e discussioni su un nuovo modo di vedere lo sviluppo del software, e in generale la gestione dei progetti.
Oggi l’approccio è più ‘tranquillo’, le metodologie agili sono in qualche modo diventate mainstream e si sono integrate meglio con il project management.
Non so quanto XP sia adottata in questo momento. Sicuramente dopo qualche periodo di sperimentazione posso dire di averla abbandonata senza grossi rimpianti.
Alcuni team la applicano con successo ma non credo sia più in discussione l’uso di un metodo o di un altro.
Oggi diciamo che contano altri parametri, e questo libro, per quanto interessante da leggere, ha un impatto incredibilmente ridotto.
Dici bene: ora sono mainstream. Mi domando quanto durino in media però. Ora sembra il turno di Scrum.
RispondiEliminaQuanto all'XP, devo ammettere che alcune delle cose alla base mi piacciono: Pair programming, TDD, Refactoring, Continuous Integration, ...
A pensarci, forse è proprio per queste "feature", prese insieme, che i metodi agili si sono diffusi e continuano ad essere sulla cresta dell'onda.
JP
Scrum è molto adottata perché meno estrema e quindi vantaggiosa per un numero più alto di tipologie di progetti.
RispondiEliminaPratiche come il Refactoring continuo, il TDD e il Continuous Integration, se seguite bene, sono veramente ottime per la buona riuscita di un progetto software. E' vero anche che adottarle non significa necessariamente fare XP né avere un approccio 'agile'. Si possono usare anche in contesti diversi.
Come accennai in un precedente commento (o post), di solito cerco di vedere le pratiche come 'strumenti' e le metodologie come 'cassette degli attrezzi'. Le filosofie, per quanto posso, le lascio da parte .. che ne pensi ?
Penso che il ragionamento fili su tutta la linea, nel senso che anche io vedo una metodologia come una collezione di strumenti di supporto, applicati in un particolare modo se vogliamo.
RispondiEliminaIl resto sono solo flamewar fra i vari adepti di questa o quella metodologia... :P
JP