[10 years] Pianificazione e priorita (prima parte)

10 years: L'attività peggiore: la pianificazione

Pianificare è un'attività difficile, nonostante il planning game sia di per sè una pratica che rasenta il banale. In estremo sunto: 

• gli sviluppatori stimano le attività da fare dal punto di vista tecnico
• il business sceglie sulla base delle priorità di business

Quello che tutti scoprono dopo pochissimo tempo sono delle sacrosante verità: 

• gli sviluppatori sottostimano le attività
• l'errore di stima è solitamente significativo (circa un 30 % quando va bene)
• il business non considera tutto l'insieme delle attività da fare, ma solo le piu recenti

La mia sorpresa è che a fronte di queste banalità non ci sono tecniche di stima vagamente scientifiche che ho visto applicare. 

Un falso mito: i punti complessità

Stimare in punti complessità è un errore. Questa tecnica è (forse) utile quando stai valutando un nuovo progetto, e, in caso parta, nella prima iterazione. Dalla prima iterazione in poi è assolutamente da evitare l'uso di questa tecnica.

Mentalmente le persone scoprono rapidamente una proporzione tra 1 punto di complessità e il tempo ideale corrispondente.

Quando per stimare il tuo pensiero è: "penso ci vogliano 2 giorni/ coppia, 1 punto di complessità vale circa mezzo giorno coppia, quindi dico agli altri 4 punti complessità" è chiaro che il beneficio delle tecnica è svanito.

Anche quando cominci a stimare le attività 3,25 punti complessità il beneficio delle tecnica viene a mancare.

Infine, se hai un pizzico di bravura nel partizionare le funzionalità del tuo sistema, difficilmente dovrai stimare un gran numero di attività 4/5 volte piu complesse di un'altra. Il consiglio in tal caso è di migliorare la capacità di fare split. Guarda qua: http://www.agileforall.com/splitting-user-stories/ 

Un esperimento per stimare meglio: verso la scientificità?

Quando stimi una attività devo considerare un paio di aspetti: 

• quanto sei competente in materia? Se l'attività che devo stimare riguarda un ambito di competenza dove non sono preparato, ci metterò di piu! 

Si potrebbe compilare una matrice di competenza: sulle righe i nomi dei membri del team e sulle colonne le competenze necessarie per lavorare sul progetto. Nella intersezione un voto, ricavato o da autovalutazione o da metodi piu strutturati. 

• quanto è complessa l'attività richiesta? Sicuramente un aspetto di complessità è il numero di 'layer tecnologici' che devi attraversare. Ad esempio: se mi basta cambiare il codice è un conto, se devo cambiare una funzione javascript, il codice, un sottosistema esterno, un database etc. l'attività è molto probabilmente piu rischiosa quindi piu costosa.

Basterebbe moltiplicare con un fattore crescente la stima iniziale a seconda del numero di sottosistemi coinvolti. Il web, il database, il file system, il tuo codice, un servizio esterno, una coda di messaggi, sono tutti esempi di 'sottosistema'

I due errori piu comuni quando si stima

1: La naturale propensione di uno sviluppatore è di pensare solo all'happy path: il minimo necessario affinchè si possa considerare chiusa l'attività.

Per analizzare con più precisione è allora utile considere gli imprevisti - previsti, ovvero tutti i casi di fallimento più comuni che, nel proprio contesto, si sono presentati in passato. Ad esempio: cosa succede se il servizio esterno su cui ci si basa non risponde o se l'utente chiude il browser nel mezzo di una sessione. 

2: Un altro errore è considerare solo le modifiche al codice sorgente necessarie. 

Ci si dimentica di tempi per evenutali test manuali, o tempi di comunicazione con altri team di lavoro, tempi necessari per il deploy, per la configurazione..

Per ovviare a questo problema uso il concetto di tassa: quando devo modificare una virgola nel mio sistema software, quanto tempo è necessario affinchè quella minima modifica vada in produzione ? Questa tassa è relativamente facile da calcolare, e va aggiunta alla stima di ogni attività. 

Sarà poi compito del team cercare di abbassare la tassa il più possibile.

Conclusione

Ho visto troppi team combattere contro i mulini a vento dell'errore di stima. Si vuole diminuire l'errore di stima per essere piu predicibili verso le date di consegna. 

Penso che sia più proficuo usare un'altra strategia: migliorare l'abilità di dividere le grosse funzionalità in più funzionalità piccole tutte piu o meno stimabili in tre macro categorie: 1/2 giornata di lavoro , 1 giornata o 3 giornate. 

Stimare con più precisione non porta a nessun reale vantaggio. 

Il vero valore della fase di stima delle funzionalità è la condivisione nel team dell'analisi e degli obiettivi che ci si pone. 

[10 years] extreme programming (seconda parte)

Il coach: una figura ambigua

Nei 2/3 della mia esperienza agile ho lavorato in team dove era preponderante la figura del coach. 

Il coach in letteratura ha diversi compiti, ma nella realtà la sua figura ben si presta a contaminazioni con altre figure professionali. 

Essere un buon coach xp penso sia una sfida davvero difficile e ricca di soddisfazioni ! 

I coach da me incontrati provengono dal mondo della programmazione. 

La loro principale tentazione è quella di entrare in dettagli implementativi del codice per dare il loro contributo tecnico. Ma questo è spesso parziale! 

Se sei coach:

• devi fidarti del tuo team!  loro lavorano sul codice molto piu di te, e il loro parere in merito è probabilmente il più autorevole!
• ci sono momenti in cui non ti devi fidare! A volte il team piu o meno consciamente prende delle scorciatoie, il piu delle volte per pigrizia. Se il team decide che non ha piu senso fare la retrospective, che a mio parere è la pratica piu importante di tutte, devi fermarlo, uscire dal ruolo di facilitatore ed entrare nel ruolo di leader. Usa la tua possibilità di essere leader il meno possibile, ma fallo quando è necessario.
• connetti il tuo team con il mondo esterno. Vedo il coach come una figura che tiene traccia delle evoluzioni nel mondo, legge aggiornamenti, filtra informazioni, aiuta a preparare eventi. Il team spesso tra scadenze e obiettivi non riesce ad avere il sufficiente spazio per aggiornarsi spesso su ciò che avviene nelle varie comunità. 

Una pratica assai diffusa: la documentazione !?

In quasi tutti i team xp si è diffusa la pratica di documentare molto, in particolare l'attività svolta quotidianamente. Documentiamo anche le nostre pratiche, i dettagli del progetto, le specifiche, a volte gli acceptance test, gli account sui vari server , skype etc...

Paradossalmente in tutte le altre esperienze non agili non ho visto nessuna pratica di documentazione. Le persone lavorano non si sa su cosa, non ne tengono traccia, non aggiornano la documentazione. 

Questo è davvero un mistero di XP. 

[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. 

[Script] Script for adding serialVersionUID to all java files which implements Serializable

According to Serializable java doc: "it is strongly recommended that all serializable classes explicitly declare serialVersionUID values" but sometimes it's easy to forget to add it. With this script you are able to add automatically a serial version uid generated with a random value.

#!/bin/bash  

files=$(find . -name '*.java' | xargs grep -i -l "Serializable"  | xargs grep "interface" -L | xargs grep "serialVersionUID" -L)

for f in  $files
do
 serial=$(jot -r 1 1000000000000 9999999999999)
 echo "Adding serialVersionUID $serial to $f"
        
sed -i '' "/implements Serializable/ a\  
    private static final long serialVersionUID =${serial}L;
" $f

done



* Tested on mac os x 10.8.5

[Agile] Elenco Pratiche

Ho provato a riepilogare un elenco di pratiche che svolgevo con gli ex colleghi del team Orione in XPeppers e con il team XPlayers di Quinary. Le scrivo senza un particolare ordine. 

• Stand up la mattina alle 9.30. Durata sui 15 minuti , seguito da caffe
• Planning su lavagna e uso di user story su cartoncini. 
• Pair Programming. Sempre. 
• Ogni user story ha un responsabile, che ci lavora dall'inizio alla fine. Durata massima prevista di ogni user story: 3 giorni. Durata media: 2 giorni. Se il team e' di 6 persone, al massimo si stanno lavorando 3 user story in parallelo
• Deploy in produzione settimanale. Non il venerdi
• Tutti sono in grado di fare deploy in tutti gli ambienti grazie a script automatici.
• Ogni sistema di pro viene monitorato per capire se ci sono situazioni anomale. (graphite, script che analizzano log etc) 
• Ogni deploy in produzione prevede un documento deploy plan + test plan che spiega i passi da eseguire. Oltre a lanciare gli script automatici, tiene traccia di eventuali operazioni manuali. Il test plan prevede test manuali delle funzionalita rilasciate nella corrente iterazione su ambiente di pre produzione
• 1 ora di studio quotidiano
• Sviluppo in tdd usando per lo piu test unitari
• (tentare di) mantenere la tempistica di tutta la suite dei test (unitari + acceptance + integrazione) minore ai 5 minuti, indipendentemente dalla dimensione del progetto e dalla sua crescita nel tempo.
• Sistema di continuos integration sempre attivo
• Nel codice: nessun todo, nessun metodo marcato come deprecato, nessun commento, o warning del compilatore, nessun test ignorato o codice "morto"
• Uso di pc aziendali uguali, stesso sistema operativo, ide, tastiere, organizzazione delle cartelle, programmi etc. Di conseguenza ogni pair puo sedersi davanti a un qualsiasi pc in ogni momento. Monitor grandi per permettere di far pair in comodita
• Ambiente di stage per uso e consumo dei soli sviluppatori. Ambiente di pre/produzione dove anche il cliente puo fare prove, allineato con produzione o con versione in preview di cosa andra rilasciato al prossimo deploy
• Retrospective con azioni e per ogni azione un campione. Evitiamo azioni del tipo: "tutti da domani faranno X" visto che "tutti" si trasforma spesso in "nessuno"
• Ritmo di lavoro cadenzato dal pomodoro. O comunque il team fa le pause nello stesso momento. Stesso orario lavorativo per tutti. 
• Straordinari rarissimi. 
• Ogni riunione (col cliente, retrospective etc) ha un moderatore, o un piano del giorno, e si stila un resoconto finale da mandare a tutti i partecipanti
• (talvolta) report di fine iterazione che presenta: elenco di funzionalita finite, eventuali metriche e feedback. 
• Ogni fine giornata, 5 o 10 minuti dedicati alla scrittura del journal, dove si prendono appunti sulla attivita svolta.
• Ogni comunicazione col cliente avviene tramite mailing list. Ovvero: no a comunicazioni peer to peer

[Business] Some business ideas I want to see in my future

Some time ago someone asked me "let's suppose you have all the resources you need. Which are the ideas you are going to build?"

It's not difficult to coming out with a great idea.
I follow two simple principles:

• Firstly, look at commons functionality not already binded to a specific area. 

For example, we well know the feedback system provided in form  of stars and comments like the one used in tripadvisor or ebay: 

I'd like to see the feedback system also associated to customers and software house. Is the software house a 4 star company with plenty of good comments ? Or is the customer the worst you can get because he never pays the check?

• Another principle is to enlarge the actual boundary of something. 

For example, some years ago there was a famous TV reality show called "The Big Brother" followed by lots of people.

The main idea is to follow the life of selected partecipants throughout the whole day.

Let's image a world where a person could send in streaming what he is hearing and seeing in real time (for example with google glass?) without the need to be selected or to be an actor. He could have followers that need to buy a ticket to see more hours.

Moreover the followers might comment your acts , and make  bids (with money)  in order to suggest some action to do instead of your usual behaviour.

All the needs of Voyeurism could be satisfied :)

[Agile] User story - what I have learned

Only one rule: clearness. 

It is not so important that a user story should be completed in few days as maximum, if this implies that it needs to become technical oriented.

An example
    We have a user story called 'multi currency' - actually our payment system manage only euro currency. This functionality is clear ; it is also big, so it is worth to think about some split, like 'multi currency only for protocol X'. A bad split is 'on database add a table named currencies'. Please don't do that.

[Life] 10 years have passed...

10 years have passed since I started my loved job (give or take)

My first team, called XPlayers, was one of the first eXtreme Programming team in Italy.

My second and current team's name is Orione. I had seen grow it from the scratch.

It has changed often in terms of seniority, number of members and experience.

I'm trying to summarize what i have learned so far.

Briefly explained, the passage from novice to intermediate (I don't evaluate myself as a senior :) ) concern the capacity of embrace different  points of view.

When i was absolute beginner I assimilated all things, without filtering incoming informations.

So it comes the Lesson learned: Don't Trust!

And many others, I will write them  down in this blog in next weeks.  

[Agile] Retrospective di Retrospective

Con i miei colleghi abbiamo discusso a pranzo della tematica delle retrospective, tipica e fondamentale pratica di ogni metodo agile. 

Ho partecipato a numerose retrospective, sia nel mio team che in altri team.

Il concetto chiave della retrospective è riflettere a mente fredda su come si sta lavorando così da migliorarsi. 

Nella letteratura viene data una fondamentale importanza alle azioni: ogni retrospective che si rispetti deve avere come output un certo numero di azioni correttive. 

Non sono d'accordo su questo punto.

Penso che il valore della retrospective sia principalmente la condivisione di punti di vista sia razionali che emotivi legati al lavoro.
Le azioni quindi sono importanti per apporre un cambiamento, ma ciò che noto è:

• si dà poco tempo alla riflessione su quali azioni intraprendere.  In una retrospective di 1 ora ad esempio questa fase viene relegata agli ultimi dieci minuti. E' un peccato perchè la scelta dell'azione da compiere ha un immediato effetto sulla prossima iterazione, e uno sbaglio o una scelta non meditata può portare a parecchi fastidi.

• spesso le azioni scelte riguardano gli altri: chiediamo al pm/cliente di comportarsi differentemente. Non è un male a prescindere, ma il focus dovrebbe essere principalmente sul PROPRIO modo di lavorare, dove chiaramente si hanno piu leve! 

• la strategia di scelta delle azioni. Il piu delle volte ho notato che vale la democrazia: l'azione piu votata vince. Analizzando l'output di molte retrospective ho notato che vincono di solito le azioni che richiedono meno sforzo oppure il cui impegno non è personale. Penso che la strategia democratica della scelta delle azioni non sia sempre la migliore. Una alternativa potrebbe essere far scegliere a una sola persona l'azione da intraprendere, e ruotare la persona di volta in volta. 

• ammettiamolo: non sempre si propongono azioni risolutive per i problemi riscontrati. A volte pur di tirar fuori delle azioni si propongono idee poco efficaci. 

Esempi di azioni poco utili in generale sono: 

• cerchiamo di scandire meglio il ritmo del lavoro applicando con piu dedizione la tecnica del pomodoro
• iniziamo prima/dopo lo standup
• lo standup è troppo lungo, fissiamo un tempo massimo
• lo studio: facciamo così o cosà  
• dedichiamo x ore alla settimana al refactoring

Queste azioni portano dei benefici ma tendono a curare l'effetto non la causa. 

Lo standup è lungo e al posto di rispondere alle classiche domande si sbrodola in tematiche di analisi ? 

Il problema probabilmente è che non c'è un tempo dedicato all'analisi o alla risoluzione di problemi, e quindi le persone sfruttano (giustamente) l'unico momento in cui si condivide insieme. 

Concludendo, 

le retrospective hanno l'enorme vantaggio di portare allo scoperto pensieri emozioni e ragionamenti che altrimenti rimangono personali. 

E' importante dedicare il tempo necessario per riflettere bene su quali azioni efficaci si possono attuare! 

Probabilmente la fase di scelta delle azioni deve essere successiva alla retrospective e deve avere un momento dedicato.

[Design] Pattern observer

Un pattern assai famoso che abbiamo usato pesantemente nell'ultimo progetto

è l' OBSERVER

Abbiamo osservato tutti gli eventi significativi che succedono; tipicamente: 

• l'evento scatenante di ingresso che scatena un certo use case
• tutte le chiamate verso i sistemi esterni e le risposte ottenute
• la risposta dello use case invocato

Tale struttura è tornata utile per le seguenti implementazioni concrete: 

• 'database' observer, che a fronte degli eventi interessati esegue delle operazioni sul database, tipicamente l'aggiornamento di timestamp di una macchina a stati
• 'logger' observer, che stampa su log gli avvenimenti significativi del sistema.
• 'latency' observer, che calcola il tempo di esecuzione di uno use case
• 'statistic' observer, che memorizza in stutture dati l'andamento delle chiamatesecondo particolari regole di business (ad esempio quali e quanti use case sono statiscatenati in un intervallo di tempo) 
• 'audit' observer, per salvare su database quale utente sta eseguendo una operazione sensibile

Tutti questi observer sono richiamati da un observer list iniettato nell'oggetto che incapsula il flusso principale.

Ad esempio se vogliamo notificare l'evento di 'messaggio in ingresso' : 

 public void execute(IncomingMessage message) {

    observerList.notifyIncomingMessage(message);

    doSomething()...

 }

 dove observerList è una implementazione concreta dell'interfaccia CustomObserver : 

 public class ObserverList implements CustomObserver {

    private final List observers;

    public void notifyIncomingMessage(IncomingMessage message) {

  for (CustomObserver customObserver : observers) {

customObserver.notifyIncomingMessage(message);

}

  }

Grazie a questo pattern il codice principale è ignaro dei dettagli a contorno. 

Mi piace anche l'effetto teorico che puoi sfilare un certo observer in modo che il sistema

continui ad andare! 

Immagino una situazione estrema dove ad esempio si scopre che il 'logger' observer  per un qualche baco sta rallentando pesantemente la produzione. Nel frattempo che si indaga il baco si potrebbe rimuovere questo observer dalla ObserverList e tutto continuerebbe ad andare, senza causare disservizio.