[10 years] extreme programming (prima parte)

10 years: Il perchè di questi post

Sono passati circa 10 anni da quando ho iniziato a lavorare.

Nel 80 % di questo tempo ho lavorato in team che applicano quotidianamente eXtreme Programming.

Nel 20 % rimanente ho lavorato da solo o in team che non applicavano nessun metodo agile di sviluppo del software.

Questi post nascono per il desiderio di tener traccia delle principali lezioni imparate.  

Disclaimer

Queste sono solo considerazioni derivate dalla mia personale esperienza, non ho pretesa che siano vere per tutti. Lo sono per me.

Critiche a eXtreme Programming

eXtreme Programming è un metodo di lavoro molto criticato, fin dalla sua origine. Oggi qualcuno vocifera che è "main stream": a me non pare proprio, per lo meno in Italia. 

La mia prima considerazione è che pur essendo un metodo che può avere dei difetti, solitamente vince facile per mancanza di avversari. 

Negli ambienti di lavoro dove non c'è xp o un qualsivoglia altro metodo agile, non c'è un metodo. Ci sono project manager/team leader/sviluppatori che cercano di barcamenarsi senza una direzione. 

In particolar modo la pianificazione fa acqua da tutte le parti: solitamente c'è qualcuno che si inventa le priorità a "buon senso", senza considerare tutte quelle pianificate, e l'unica strategia è la last in first out: l'ultima cosa che mi viene in mente è senz'altro la piu importante. 

Un esempio di pianificazione...creativa

Ricordo un ambiente bancario dove non c'era gestione del processo. Ad un certo punto proposi di scrivere le attivita in un foglio excel condiviso. Chiesi al management di riempire la colonna 'priorità' per capire su cosa lavorare prima e dopo. Dopo parecchio tempo riempirono la colonna con tutte le seguenti parole: 

• priorità alta
• altissima
• critica
• bloccante
• importante
• uno

Io avrei desiderato una sequenza, essendo in quel perioda da solo. Lavoro prima sulla 1 , poi sulla 2 etc.

Team XP degenerati: i due estremi

Ho avuto modo di conoscere team xp che dopo un po di tempo si spostano verso uno dei due estremi:

• l'annacquamento delle pratiche. Ad esempio: non è necessario fare retrospective, se vedi un possibile miglioramento sei sempre libero di parlarne a tutti. "Sentiti libero" è lo slogan che sottende in verità a un immobilismo di cambiamento: puoi far tutto ciò che vuoi purchè stai nei confini imposti. Prima ti mettono in un pozzo e poi ti dicono che puoi muoverti come vuoi
• la estremizzazione delle pratiche. Ad esempio: il cliente che una volta dopo mesi e mesi di comportamento esemplare chiede al team di modificare una virgola e il team  risponde che bisogna pianificare l'attività, scrivere degli at, metterla nel backlog etc etc. Si ereditano delle programmazioni senza piu riflettere su ciò che si fa. Ha senso scrivere un test end to end per ogni funzionalità? Ha senso lo stand up mattutino? Ha senso la pianificazione per come è fatta attualmente? Magari la risposta è "si" ad ogni domanda, ma è importante riflettere spesso sulle proprie abitudini acquisite

Extreme Programmer: il rischio maggiore

Essere eXtreme Programmer vuol dire cercare l'eccellenza. Questo processo di continuo miglioramento può portare a sentirsi parte di una elite, e vedere il resto del mondo da un piedistallo. Spesso ho incontrato eXtreme Programmers che si sentivano migliori di manager, grafici, analisti per il solo fatto di aver studiato su molti libri. 

Io non sono esente da queste tentazioni, ed è un bel obiettivo concentrarsi sopratutto sul miglioramento di sè stessi. 

Un falso mito: tutti devono saper far tutto

Lavorare in un team agile vuol dire uscire dall'ambito della pura programmazione. Ti ritrovi a dover fare analisi, test, grafica, documentazione, meeting col cliente, facilitatore di discussioni, recluiting etc. Un gran numero di compiti che in contesti di aziende grandi richiedono figure professionali specifiche. 

E' un lavoro stupendo, perchè hai modo di esplorare tantissimi aspetti umani che richiedono conoscenze e impegni diversi dalla programmazione.

Penso che sia importante saper fare un po di tutto, ma con la chiara coscienza che lo si farà probabilmente meno bene di una persona che fa quello per lavoro. 

Spesso chi non è d'accordo con questa frase sta già affrontando il rischio maggiore sopra descritto. 

Gli elementi di un grande team

I team migliori in cui ho lavorato dimostravano questi punti salienti comuni:

• c'era una forte identità di team, nessuno si sentiva solo. Questo può portare ad un rischio di non sentirsi parte di qualcosa di più grande. Ma la forza di un team xp, in termini di qualità del lavoro, è travolgente. Ogni sera torni a casa avendo imparato qualcosa di nuovo, e di solito torni soddisfatto. 
• c'è un giusto mix tra libertà personale e disciplina. Un processo definisce delle regole che per forza di cose non accontenteranno tutti sempre. I team migliori riescono ad accogliere le particolarità di ogni persona, valorizzandola. Spesso si riesce a far questo dando spazio alle sperimentazioni.