I fondamenti dell’Agilità e…i temi di wordpress.com

[iterazione 2 (27/9)]

Come già il buon FRANK ha notato, ultimamente il blog ha subito mutazioni di look giornaliere e da far girare la testa…

Tutto nasce dal post sul TDD e gli Unit Test che con il tema vecchio di wordpress, veniva visualizzato in modo poco chiaro. Da lì è cominciata la ricerca del tema, che per ostinazione somigliava più a quella del Santo Graal che ad un semplice cambio di look del sito. Sono infatti caduto nel problema del “Best is the enemy of Good“(TM), cambiando di giorno in giorno il tema senza mai esserne soddisfatto, al punto che il mio amico Simone è arrivato a dirmi “l’agile enri disagilizzato da un tema!”… Di seguito la mia breve autodifesa:

Innanzitutto wordpress non permette di far vedere un’anteprima della scelta del tema, quindi vi siete dovuti puppare tutte le mie prove…

In secondo luogo questi erano i miei requisiti:

1. il tema deve avere una larghezza flessibile così gli amici svizzeri possono sfruttare appieno la sboronità dei loro 21” 16/9
2. i post con del codice devono risultare chiari e leggibili
3. il layout deve essere chiaro e non stancare
4. il design deve essere semplice e pulito e per questo motivo d’impatto

Purtroppo nessuno dei temi di wordpress rispetta tutti i requisiti. Ovviamente prima che me ne rendessi conto li ho dovuti provare uno dopo l’altro.

Un approccio Agile al problema avrebbe previsto una soluzione per raffinamenti successivi, dando una priorità ai requisiti e procedendo quindi iterazione dopo iterazione alla loro implementazione. Qui (forse) viene la parte interessante di tutta la questione.

Per quale motivo non è stato possibile procedere per raffinamenti successivi intraprendendo la strada del miglioramento continuo? E quali sono i requisiti che gli strumenti di sviluppo devono rispettare per implementare un processo Agile?

Innanzitutto i temi di wordpress sono molto poco configurabili, al massimo (alcuni) permettono di cambiare l’immagine della barra superiore, o poco più. Questo significa che lo strumento è caratterizzato da pochi gradi di libertà. Avere un numero sufficiente di gradi di libertà permette di mantenere aperte un numero di strade ed opzioni (multiple options) quando ancora non è chiaro quale strada scegliere, e quindi permette di effettuare la scelta quando gli esperimenti intrapresi hanno permesso di imparare (amplify learning). Ma dal momento che wordpress.com ormai permette di cambiare i css solo con un plugin a pagamento, non è possibile lasciare aperte più strade per costruire conoscenza.

In altre parole il grado di ordine del sistema è eccessivo. Ciò non permette di essere pronti al cambiamento: essere sulla cresta della montagna dell’informazione, tra caos e ordine è la strategia per non avere un atteggiamento antipicatorio, ma adattativo ed un sistema troppo ordinato è chiaramente troppo rigido.

Ora…tutte queste caratteristiche non sono forse le stesse che desideriamo quando utilizziamo un linguaggio di programmazione, un framework o un qualsiasi tool? La mancanza di queste caratteristiche (che possiamo tradure con la parola flessibilità) non ci spinge ad abbandonare lo strumento, a buttare via la soluzione o a non essere contenti del risultato? Si pensi ad esempio a quei framework che imbrigliano troppo lo sviluppatore nelle scelte possibili imponendo un solo modo di risolvere un problema. Spesso l’alta velocità di realizzazione della soluzione (un click per i temi di wordpress), si scontra fortemente con l’incapacità della soluzione stessa di sopravvivere anche a distanza di brevissimo tempo (Enri che cambia due volte al giorno il tema).

A tutto questo aggiungo una frase di Simone assolutamente ragionevole che ha spinto alla ricerca di una soluzione pseudo-ottima: “La scelta del lookandfeel dovrebbe essere stabile, così da creare una sorta di brand del sito”.

Tutti questi aspetti portano a rendere quella che dovrebbe essere solo una decisione iniziale, una decisione definitiva e senza possibilità di miglioramenti. Ed il carattere di immobilità delle decisioni, porta a procrastinarle per “loop-speculativo” o per paura delle conseguenze nel migliore dei casi, a non prenderle affatto nei peggiori (vedi il ping-pong dei temi). Robertson ritiene questo uno dei peggiori nemici all’adozione dell’Agilità all’interno delle aziende: spesso nelle organizzazioni “classiche” l’errore viene percepito come qualcosa da punire, inibendo e limitando le spinte più creative o le idee più innovative ma ancora grezze.

Ok, lo so, tirare in ballo i fondamenti dell’agilità ed il Toyota Production System è un po’ troppo per giustificare la mia indecisione, ma ognuno si difende con le armi che ha!

Ritornando ai temi…penso che passerò ad un hosting con accesso ai server.