[10years] Studio

Lo studio: come cresce un team

In varie aziende in cui ho lavorato si dedicava un certo periodo di tempo allo studio. Era tempo impiegato fuori dalle tipiche attività di sviluppo del software.

Lavorare in un ambito informato implica la necessità di aggiornarsi e confrontarsi continuamente. Non molte aziende però valutano questa pratica importante rispetto agli usuali impegni lavorativi. Eppure senza un tempo dedicato all'esplorazione ci si tarpa le ali su tantissime possibili evoluzioni! 

Ho visto lo studio svolgersi secondo modalità assai differenti:

• tutto il team studia insieme uno stesso argomento. Ad esempio ci siamo ritrovati a studiare i design pattern piu noti descritti in  Design Patterns . Al termine dello studio ci siamo confrontati su punti oscuri, vantaggi e soprattutto possibili applicazioni reali nel codice quotidiano.

• ogni persona esplora un argomento che ha a cuore. Ad esempio chi è interessato al mondo javascript studia le librerie piu recenti e valuta i vantaggi di una loro introduzione, oppure alcuni si sono concentrati su aspetti meno tecnici e più rivolti al metodo, come ad esempio lo studio di altri metodi di sviluppo del software alternativi a eXtreme Programming, come Scrum e Kanban

Perpendicolarmente alla modalità di studio solitaria/ in gruppo, gli argomenti affrontati sono stati dei più disparati: 

• argomento libero: qualsiasi cosa tu voglia esplorare: chiaramente l'apertura mentale è avvantaggiata, a scapito forse di una concreta applicazione immediata. Ad esempio studiare un linguaggio di programmazione diverso da quello che quotidianamente usi può dare forti insight sulle tecniche di programmazione ma può essere un argomento contestato perchè non presente nell'azienda in cui lavori

• argomento legato a progetti correnti. Ad esempio ho studiato strumenti per tracciare le performance di un particolare caso d'uso. In quel momento del progetto non c'era una reale esigenza di analisi, ma affinare la conoscenza degli strumenti può tornare utile nel momento in cui si presenta un problema. 

E' difficile dire quale 'incrocio' sia il migliore, essenzialmente perchè ognuno ha i suoi pro e i suoi contro. Probabilmente la migliore soluzione che mi sentirei di proporre è di variare ogni 3/4 mesi la modalità di studio. 

Ma una invariante è necessaria ....

Vincolo: binary deliverable

Ogni studio per essere efficace deve avere uno scopo, una 'consegna' di quanto si è appreso. La piu tipica forma di condivisione della conoscenza è una presentazione al team. Ma ci possono essere molte altre forme valide: pubblicare il codice su un repository pubblico, scrivere un blog post, rispondere ad un forum etc.

Questi articoli sono appunto il mio binary delivarable per questa iterazione di studio :)  

[10years] Retrospective

Condizione necessaria e non sufficiente dei metodi agili

Per il principio già esposto che per dare importanza a un concetto bisogna dedicargli esplicitamente del tempo, i meeting di retrospettiva sono la pratica che si concentra sul miglioramento del processo di lavoro. 

Come fa un team a dirsi agile se non è guidato da uno spirito di miglioramento ? 

Un team non può professarsi 'agile' se non pratica la retrospettiva con regolarità. In alcuni team questa pratica non viene attuata con la scusa che si è sempre liberi di proporre miglioramenti o alzare una bandiera di soccorso quando ce n'è la necessità, ma in verità non ci vuole molto per capire che questo non può accadere spontaneamente. 

Problemi comuni

Nei vari anni ho trovato poche retrospettive davvero utili. Ma per quelle vale comunque la pena averne fatte tante poco efficaci ! In ogni team ci sono uno o due persone che prendono a cuore l'argomento, e tendono a parlare sempre, e uno o due persone che sono introverse o disinteressate.

E' compito di un buon facilitatore far sì che tutti abbiano il loro spazio. Il fulcro della retrospettiva è la comunicazione, principalmente verbale. Ma se non tutti hanno avuto modo di esprimere il loro parere non è stata una buona retrospettiva! 

Reputo la figura del moderatore fondamentale; probabilmente può venire a meno solo in team davvero esperti e affiatati (o forse nemmeno in quel caso?) 

Ciò che cerco sempre di evitare è l'effetto "gruppo di ascolto". Concentrandosi sui problemi, è facile che le discussioni vertino sulle mancate responsabilità di altri reparti, di altri collaboratori. 

Temi del tipo "il pm non sceglie con cura le priorità", "i sistemisti non rispondono ai ticket celermente", "gli analisti danno specifiche troppo incomplete" sono ricorrenti. Il piu delle volte sono inutili. 

Vale solo la domanda di cosa puoi fare tu e il tuo team per migliorare l'ambiente, ed eventualmente anche la comunicazione con questi reparti. 

Le azioni

E' diffuso il concetto che scopo delle retrospettive è generare azioni. 

Non sono d'accordo. 

Primo perchè le azioni dovrebbero essere meditate, e non inventante nel breve arco di tempo di una retrospettiva. Secondo perchè il valore di una retrospettiva è la comunicazione. Senza saggiare il parere di tutti su un argomento, senza una adeguata meditazione si rischia di proporre azioni deboli. E azioni deboli che non convincono verranno svolte poco impeto, risultando inefficaci. 

Se non ci sono azioni forti, risolutive, non fate nulla! 

L'iniziativa personale

La fase della retrospettiva in cui si generano azioni non deve essere la sola in cui attuare un cambiamento. Se una persona si prende a cuore un aspetto ed ha desiderio di migliorarlo, a mio avviso può e deve essere aiutato dal team in termini di tempo e supporto. Spesso mi è accaduto di ringraziare una persona per il lavoro personale che ha intrapreso spontaneamente. 

Le idee e le iniziative personali vanno incoraggiate, non soppresse!

Team agili...appesantiti

Spesso le azioni di una retrospective mirano ad aggiungere regole al processo. Dopo un po di retrospective le regole -sensate- che si sono aggiunte sono davvero tante...e il team diventa tutto tranne che agile. 

Le regole create sono da rivedere puntualmente e, a mio avviso, sono anche da limitare. 

Esempio di azioni sensate che un generico team agile propone: 

• verifichiamo le metriche prima di ogni commit
• facciamo code review ad ogni aggiornamento del codice
• al termine di una funzionalità implementata ci ritagliamo x ore per pulire / documentare
• prima di iniziare una carta scriviamo tutti gli acceptance test
• prima di iniziare una carta la dividiamo in task
• non si inizia una carta se ce ne sono altre in progess
• su ogni carta c'è un responsabile fisso e ogni giorno il resto del team ruota

[10years] on-site customer

On-site customer: le scomode verità

Non ho praticamente mai visto il cliente venire a lavorare nell'ufficio del team: la maggior parte del mio tempo lavorativo l'ho passato nella sua sede. Tale scelta veniva fatta in fase contrattuale senza coinvolgimento del team di sviluppo e anzi dando per scontato che fosse la scelta piu sensata per un team XP di lavorare a stretto contatto col cliente.

Dal punto di vista teorico lavorare dal cliente dovrebbe abbattere molte barriere di comunicazione.

Verità #1: Lavorare dal cliente non facilita la comunicazione! 

La spiegazione è semplice: l'abitudine ad avere il gruppo di lavoro vicino è un freno per dedicare al team momenti specifici, perchè, in fin dei conti, è sempre disponibile. 

Tuttavia non viene così rispettata una regola d'oro per lo sviluppo del software: 

Bisogna dedicare un tempo prestabilito ad ogni azione che si reputa importante

Il sapere che si è 'sempre' disponibili perchè si è fisicamente presenti equivale a dire 'mai'. 'sempre' e 'mai' sono due estremi che si toccano spesso.

Verità #2: Spesso i clienti offrono ambienti di lavoro inadeguati.

Ho spesso lavorato in ambienti sporchi, confusi, con regole di lavoro controintuitive. Postazioni di lavoro inadeguate, tecnologie e pc obsoleti. 

Poichè il lavoro di sviluppatore richiede ben pochi requisiti, mi ha sempre stupito questo fatto. Si ha necessità di un pc potente, un monitor grosso, un ambiente non troppo rumoroso e ben illuminato e il gioco è fatto ! Spesso è più facile ricreare l'ambiente ideale nella propria sede piuttosto che dal cliente.

Lavori presso il cliente? Ecco i rischi che ti stai accollando...

• fare formazione interna al team non è scontato. Il cliente può non capire l'importanza della formazione, e non ritenerla un'attività per cui ha pagato. Certo lo si può convincere che la crescita in un contesto che richiede aggiornamento va a suo beneficio nel lungo periodo...ma ne vale la pena? 

• in generale, qualsiasi attività che non è pura codifica è soggetta a critiche. Fai retrospective, sessioni di design, stand up meeting, call conference, formazione ? Perchè il cliente dovrebbe supportarti in queste attività? 

• il rischio dell'ingerenza del cliente nel processo di sviluppo è alto quando si lavora presso il cliente. Essendo lui il soggetto pagante, sarà sempre difficile per un team difendere il proprio processo di lavoro. Da un rapporto di collaborazione si passa facilmente a un rapporto di micro-management

• talvolta il cliente vuole gli sviluppatori nella sua sede per una scomoda verità: non si fida di loro! in questo caso si ha un grosso problema di partenza, perchè viene richiesto a professionisti di cui non ci si fida di risolvere una propria esigenza. E' vero che la fiducia si conquista sul campo, ma è anche vero che bisognerebbe partire per lo meno 'neutri' in un rapporto lavorativo. Partire presupponendo che il fornitore ti voglia rubar soldi è indice di un grave problema da risolvere prima ancora di scrivere la prima riga di codice! 

La soluzione..

Lavorate presso la vostra sede. Semplice. 

[10 years] Codice (seconda parte) leggibilità,framework, falsi miti

Passaggio di consegna: una metrica fondamentale!

Per valutare un buon codice sono state proposte un gran numero di metriche. Io ne ho trovata una che reputo saggia:

Se formare una nuova persona nel tuo progetto 

richiede poco tempo, 

il tuo codice è ottimo! 

In teoria sarebbe sufficiente una suite di test di non regressione e una certa leggibilità.

Talvolta i passaggi di consegna sono considerate attività che richiedono mesi. A me pare assurdo, soprattutto considerando la complessità media dei progetti su cui ho lavorato. Quando lavori su un ecommerce, il passaggio di consegna o la formazione di un nuovo membro di un team dovrebbe essere rapida, dell'ordine di qualche giorno. Infatti a parte specificità anomale del progetto il campo ecommerce ha un dominio estremamente semplice. Tutt'altra cosa sarebbe formare una persona su un simulatore di volo o su codice geometrico 3d. 

Perchè nella realtà, nella stra grande maggioranza dei progetti il tempo di inserimento di una nuova persona è lungo ? 

Ho identificato 3 motivi principali: 

• Ci sono troppe convenzioni orali. Per fare un task il team sa che deve rispettare delle regole, che però né sono scritte né sono automatizzate. Scoprirle tutte richiede tanto tempo e il rischio di infrangerle è grande.

• Non c'è una fonte di informazione chiara, o non si risce ad accedervi facilmente. Ad esempio potrebbe non aver senso documentare l'architettura di un sistema, se per sua natura cambia ogni pochi mesi. Ma senz'altro ha senso poter ridisegnarla in poco tempo. La documentazione non è importante di per sé, ma è importante definire un modo con cui un nuovo entrato può reperire le informazioni necessarie.

• Il codice è complesso. Ma il problema che risolve non lo è. Se fosse semplice la formazione sarebbe assai semplificata.

La Leggibilità: il sacro graal 

Fate fare un kata di programmazione a vari sviluppatori, ognuno valuterà l'esercizio altrui meno leggibile del proprio. 

Troppi refactoring inutili si sono fatti per il tema della leggibilità! 

Anche questa tematica secondo me distingue uno junior da un senior:

Il codice dev'essere leggibile come il sale: quanto basta.

E' invece importante costruire un dizionario comune all'interno del team. Quindi un termine o una tecnica che può apparire ostica ad un nuovo arrivato ha completamente senso all'interno del team consolidato. Poichè il team si allinea volente o nolente su uno stesso linguaggio è importante che esso stesso cresca (con confronti, esercizi etc) al fine di aumentare la sensibilità media. 

La mia opinione sui framework

Non amo i framework, perchè se li si usa cambia la natura del proprio lavoro che diventa da una attività creativa ad una attività organizzativa/burocratica.

Tuttavia sono andato più a fondo della pura motivazione del divertimento. La verità è che quando qualcuno decide di usare un framework per un progetto è perchè ha una scarsa concezione dei programmatori a sua disposizione. 

Scegli un framework se:

• il tuo team discute tanto di design e poi non combina nulla

• il tuo team mette troppi bachi in produzione

• ogni virgola richiesta al team richiede un tempo esagerato per essere implementata

• ci sono numerose regressioni

Il più delle volte i problemi risolti da un framework sono molto piu grandi e complessi di quanto serve davvero implementare, e il costo di imparare il framework nella mia opinione è maggiore del tempo di riscriversi un sistema custom piccolo e adatto alle proprie esigenze. 

Ho riscritto o visto riscrivere con poche righe di codice: 

• un rule engine in ruby
• un router in java
• una macchina a stati di media complessità
• un sistema di alerting di eventi asincrono estremamente scalabile

Il mio consiglio non vuole essere di usare o meno framework: non avrebbe senso. Reputo invece importante che sia il team a scegliere. 

Rimane un ultimo punto da chiarire: 

Come scegliere tra vari framework che risolvono lo stesso problema? 

Io reputo un framework valido se ha previsto un modo per essere testato o per testare. Ad esempio non sceglierei mai un framework per costruire applicazioni web che come *unico* strumento di test richiede Selenium.

[10 years] Codice (prima parte)

La regola delle regole del buon codice

E' simile a quella seguita nella vita day by day: ascolta tutti, ma scegli tu. 

E' importantissimo confrontarsi su buone pratiche di programmazione, sia con blog, libri e colleghi. Lo scambio di punti di vista su cosa sia un 'buon' codice è anche uno degli aspetti più divertenti del lavoro. Tuttavia tutte le regole possono essere infrante, purchè ci sia un ragionamento di base. 

Reputo questa considerazione uno dei punti che distinguono un programmatore junior da un senior. 

Un junior si appassiona a buone regole di programmazione, le applica e le considera di buon senso e funzionanti. Ma non riesce ad adattare strategie diverse a nuove situazioni. 

Un semplice esempio: in un codice scritto con paradigma ad oggetti è buona norma non esporre lo stato interno degli oggetti con metodi 'setter/getter'; tuttavia questi metodi sono molto utili nei test, non metterli implica il giocare su librerie di reflection per modificare a run time il codice compilato. La soluzione di mettere 'setter/getter', usati solo dai test, è senz'altro da preferire in un gran numero di occasioni, pur introducendo una convenzione di team di non usarli in codice di produzione. 

Le buone pratiche di programmazione

Tralascio quelle che si trovano comunemente diffuse, i vari principi SOLID, GRASP etc etc. 

Secondo molti il codice riflette il modo di pensare del programmatore. 

Se il programmatore pensa a lavorare in fretta per chiudere una funzionalità e migliorare il codice 'in futuro' non avrà problemi ad aggiungere commenti stile "TODO" nel codice. 

Ecco una breve lista di punti che reputo validi al fine di scrivere e leggere un buon codice: 

• No Todo e Fixme nel codice. 

• No warning del compilatore o dell'Ide. Avere un progetto con piu di una decina di warning vuol dire non usare questo strumento, quindi tanto meglio disabilitarlo. Oppure può valere la pena di configurare l'ide per valutare i warning considerati significativi, per poi correggerli.

• Nessun commento inutile. La maggior parte dei commenti è inutile. Ma non tutti. Da agilista junior ero abituato a cancellare ogni commento. A volte indicare il perchè di una scelta, un link a un'api o un articolo, può essere utile. Commenti utili sono quelli che specificano una data e il nome dell'autore, oltre al motivo.

• Il miglior oggetto ha un solo costruttore e un solo metodo. Sicuramente quell'oggetto sai come costruirlo e come usarlo :) certo, è una grossa semplificazione. Ma mi piace far tendere il codice verso oggetti di quel tipo. E' piu probabile che un oggetto con un solo metodo abbia una sola responsabilità. 

• I log dell'applicazione sono importanti. Non amo i log a debug, mentre mi piace loggare ciò che vorrei leggere durante una fase di analisi. Quindi benvenuto qualsiasi formato utile ai fini di grep dei log o per tracciare tutto il ciclo di vita di un task applicativo. Ad esempio, in un contesto di ecommerce, è importante dato un numero d'ordine o un identificativo utente, poter tracciare tutto l'iter di navigazione di un processo di checkout con semplici grep dei file di log.

• Spesso non è immediato dare responsabilità agli oggetti. Nel dubbio, meglio crearne uno nuovo, che sicuramente renderà più snelli gli altri. Il ciclo di vita di questo oggetto potrà poi essere breve, collassare o crescere in identità. 

• Se nel tuo codice c'è anche un solo if X instanceof poniti delle domande sulle tua abilità di programmazione

[10 years] Pianificazione e priorita (seconda parte)

Priorità: considerazioni

Errore diffuso di chi ha il compito di decidere le priorità è considerare le più recenti funzionalità come le più importanti (strategia LIFO= last in first out). 

Può anche essere corretto, purchè si analizzino le 'vecchie' funzionalità messe in backlog di cui magari non si ha più memoria.

Ma al di là di ciò che viene scelto, raramente ho visto lavorare per un obiettivo. 

Un progetto bancario prevedeva la riscrittura totale di un sistema di pagamento elettronico. L'obiettivo del primo rilascio era quello di dirottare i pagamenti del più semplice sistema di pagamento verso il nuovo sistema, mantenendo per tutti gli altri protocolli il vecchio sistema. L'obiettivo era chiaro, ed ha permesso a pm e team di non aggiungere funzionalità speculative che non avrebbero aiutato nel raggiungimento dell'obiettivo.

Tante volte le date di consegna non sono associate a reali esigenze. Se il prodotto deve essere pronto entro il primo marzo perchè in quel giorno ci saranno pubblicità in televisione che sicuramente traghetteranno traffico, la data di consegna ha un senso. 

Spesso si creano date di consegna fittizie, passate le quali non succede niente: 

Niente di più demoralizzante aver lavorato sodo per raggiungere una data in cui non c'è reale esigenza. 

Non è mia intenzione suggerire di non creare date di consegna; il suggerimento è di associare un obiettivo.

I metodi agili generano fastidio

Il planning game ha il compito di esplicitare i rischi e gli obiettivi di un rilascio. Con quanto budget si riesce a raggiungere un set di funzionalità con ragionevole certezza. 

Il problema è che tanti manager non accettano di vedere i vincoli. Cosi le date di rilascio diventano mandatorie, e l'unica strategia suggerita più o meno esplicitamente è di ribaltare il rischio di consegna sullo sviluppatore, chiedendogli di fare straordinari.

Io non baserei il successo del mio progetto su quest' unica opzione. 

User story - le considerazioni assodate

In quasi tutti i team in cui ho lavorato si identificano le funzionalità da implementare con l'ausilio di cartoncini fisici o elettronici chiamati 'user story' o anche 'carte'. 

Anche se ho notato una certa uniformità mi piace ribadire alcuni importanti concetti oramai assodati: 

• ogni carta necessita di un solo responsabile. Anche se il team lavora in pair programming il responsabile rimane sulla carta dall'inizio alla fine.
• potrebbe essere utile, se il team lo ritiene, indicare in quale attività si è consumato il tempo della carta: se una carta ha richiesto 30 pomodori/coppia (ovvero circa 15 ore/coppie), quanti di questi sono stati dedicati al codice, o alla documentazione, o al deploy e così via?
• è utile riportare a fine giornata quanto manca alla fine della carta, e notificare al resto del team se ogni sera il remaining è maggiore di quello della giornata precedente
• ogni carta quando chiusa necessita della firma del cliente, che si assume così la responsabilità di aver verificato, assieme al team, il suo funzionamento.  

Come si velocizza il completamento di una carta? 

Talvolta un cliente chiede di accelerare il completamento di una carta e raramente ho visto sviluppatori trovare opzioni per riuscire a farlo. Certo, non è sempre possibile nè facile, ma non è nemmeno sempre impossibile.

Il classico metodo di 'divide et impera' è una buona tecnica. 

Se si segnano su una todo list tutte le micro attività si impara a poterle dare in carico a qualcun altro. Mi piace lavorare tenendo in mente che se un mio collega si libera posso sempre 'usarlo' al fine di velocizzare la chiusura di una carta.

Quindi quando si chiede: "qualcuno ha un task che posso fare?" è un buon obiettivo di team rispondere con una pletora di "io, io!!" 

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

[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

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

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

[Agile] meglio un mal di testa ogni giorno o un cancro una volta nella vita?

I team agili, la trasparenza e la percezione della velocità.

Penso che i team agili a volte si tirano la zappa sui piedi.
Il fatto che si esplicita un piano di iterazione (consegneremo queste funzionalità entro una settimana da oggi), che si fa una review del piano (su questa funzionalità siamo arrivati in ritardo) e che spesso si esegue una dimostrazione e verifica col cliente di quanto consegnato è un fatto virtuoso.

E' un fatto che tendenzialmente le stime sono piu basse di quanto di solito ci vuole a completare davvero una funzionalità (lo dico per varie ragioni che potrei argomentare, raccolta numeri e confronto con vari team) quindi tendenzialmente un progetto avrà tanti piccoli ritardi, comunicati costantemente durante la pianificazione lavori.

Il cliente sentirà spesso ripetere che ci sono stati tanti piccoli ritardi e la sua tendenza sarà di percepire una lentezza del team 'agile' che ha virtuosamente collezionato e comunicato queste informazioni.

Altri team non agili non danno grande visibilità sui lavori, vivono in pace e lasciano vivere in pace il cliente fino ai dintorni della famosa 'data di consegna'; lì tutti si aspettano di rodersi il fegato perchè quel giorno diventa per forza di cose un momento di confronto tra aspettative e risultati.

E' vero però che il cliente sente di un grosso ritardo, somma di tanti piccoli, dopo un bel po' di tempo, e fino ad allora è vissuto bene.

Insomma, il dubbio è: l'eccesso di trasparenza aumenta la percezione che i team agili siano più 'lenti' rispetto ad un team non agile?

In altre parole, meglio un mal di testa ogni giorno o un cancro una volta nella vita?

[Agile] da noi non si può fare

Quando mi capita di confrontarmi con persone interessate alla tematica di introduzione di un metodo di lavoro sento spesso delle obiezioni abbastanza comuni.

E mi pare che negli anni le maggiori problematiche siano all'incirca le stesse.
Provo a riassumerle con degli slogan e una classifica. Al primo posto :

1) "Da noi non si può fare"

Spesso si pensa che la propria realtà lavorativa sia assolutamente straordinaria e unica per quanto riguarda colleghi, rapporti con il management, rapporti con il cliente. Io penso che sia abbastanza simile da tutte le parti, e si compone così:

• rapporto con i colleghi: di media buono con quelli dello stesso team. Probabilmente il fatto di lavorarci tutti i giorni incentiva l'impegno a creare relazioni piacevoli. Quello che noto è che quando ci sono team diversi si tende a parlare delle persone degli altri team 'disumanizzandoli', banalmente smettendo di chiamare per nome e cognome e sostituendo con un sostantivo generico. Ad esempio frasi del tipo: "Quando si lavora con gli *(indiani|cinesi|spagnoli|americani)* è sempre un disastro" "il team di *(analisi|test|dba|plm)* ci mette il bastone fra le ruote". E allora in questo senso vedo bene tutte quelle pratiche che portano a ripristinare i nomi e i cognomi, al fine di avere una comunicazione umana.
  

• rapporto con il management o con i commerciali: tendenzialmente ogni sviluppatore pensa di essere migliore del proprio manager o del proprio commerciale nei loro rispettivi lavori. Mi sbaglio? Mi chiedo quindi se è anche vero che ogni commerciale o manager pensa di essere migliore dei propri sviluppatori per quanto riguarda la codifica. Se così fosse sarebbe buffo! Ma in effetti a volte *forse* manager e commerciali ci azzeccano, quando ci chiedono delle funzionalità davvero banali tipo 'sposta questo link da destra a sinistra' e la cosa genera giorni di lavoro.

• rapporti con il cliente. E' mia convinzione che un buon cliente gioca sempre il ruolo dell'insoddisfatto ma continua a mantenerti come fornitore. Ovviamente questo non vuol dire si debba dormire sugli allora o lodarsi per sempre. Ma questo porta allo slogan numero due:

2) "Siamo lenti" oppure "il team XXX non è abbastanza produttivo"

Posto che non è possibile definire chiaramente la produttività, e qualsiasi metrica che viene _imposta_ per misurare la produttività verrà di certo raggirata, la risposta deve andare nella direzione della chiarezza. Non si è produttivi rispetto al passato? O non si è produttivi rispetto ad un altro team? La ricerca di una metrica è una scusa per cercare di sviscerare e oggettivare la percezione di lentezza di un team.

3) "Mi sembra che ci sia poca documentazione"
Sì, in certi ambienti si ama la carta. Ammetto di essere uno di quei sviluppatori che di base reputano la documentazione inutile perchè non porta valore. Ma so che in certi casi mi sbaglio. Quel che noto in verità è che quando lavoro in un team XP scrivo molta piu documentazione di quando lavoro da solo. Esempi:

1. documento tutti gli script
2. manutengo il file di istruzioni per il setup del progetto
3. scrivo un journal delle attività ogni fine giornata
4. scrivo un iteration report da consegnare al cliente ogni fine iterazione
5. scrivo un riassunto di ogni meeting che si effettua
   

Alla base di questa critica che viene fatta all'XP o Scrum o quel che sia pongo solo un principio: che non scrivo per principio ciò che non viene letto. Se scrivo qualcosa è perchè qualcuno davvero la legge e trova valore in quel che scrivo.

4) "Non posso migliorare il codice perchè non mi viene allocato del tempo per farlo"
E' virtuoso coinvolgere il cliente nel processo di sviluppo del suo prodotto, ma non è furbo farlo ad ogni livello, sopratutto scendendo troppo nel tecnico. L'importante è mantenere i RUOLI. eXtreme Programming e Scrum li identificano con grande precisione, cosa può o non può fare un cliente e uno sviluppatore. Non ha senso chiedere a un cliente se dopo che hai risolto un baco puoi scrivere un test per garantire che non accada più: lo fai e basta. Il cliente non ha alcun diritto di entrare in merito alla gestione di task tecnici.
Immedesimandomi in un cliente, non farei fare allo sviluppatore niente di cio che non capisco, tranne poi lamentarmi degli effetti.

Nella stessa direzione va la maggior critica che viene posta al "pair programming":

5) "Non possiamo fare pair programming perchè il management non vuole due persone lavorino sulla stessa cosa"

Ok. Mettiamola così, se la situazione lavorativa è buona e il management non si lamenta, va bene non fare pair programming. Altrimenti è giusto sperimentare, coinvolgere, ma come dicevo prima è fondamentale distinguere cosa si può fare in un certo ruolo.
Se il management forza i tentativi di miglioramento del team, ed ha il diritto (diritto, non il potere) di farlo, va bene purchè poi si assume le responsabilità della scelta, prendendo quindi su di sè eventuali critiche sulla 'produttività' del team. Patti chiari, amicizia lunga. Però per ragionare in questo modo ci vuole coraggio! Dimostriamo che davvero c'è miglioramento nell'applicazione di una tecnica!
L'invito è di provare, di valutare dopo un certo periodo di tempo e non scendere a compromessi se non dopo averla imparata con una certa disinvoltura.

In bocca al lupo!

[Xp] la domanda sbagliata

E' successo ancora.
La domanda sbagliata che uno sviluppatore fa al suo project manager: "ci sono priorità particolari tra queste funzionalità?"

La risposta è: "no, parti pure da dove vuoi, tanto le devi fare tutte".

Non è professionalmente corretto supporre che non ci siano priorità, la domanda giusta da porre è: "QUALI sono le priorità, qual è la prima funzionalità su cui inizio a lavorare?"

[Book] Agile coaching

I'm reading "Agile Coaching" ; until chapter 4 it's full of trivial suggestions. It looks like a priest when he recommends you to become more good for the near future.

Now i find some interesting advice. Noone of them is new, but it's always useful remember them.

Not Too Easy, Not Too Hard
The secret to great teams is they need reachable but challenging goals.
Everyone needs to be sufficiently challenged, neither bored nor anxious.
This is the optimum work zone where people enjoy it the most.
If work is too easy, developers will get bored and demotivated.

... and the solution...

Time for Innovation We’ve met developers on Agile projects who were burned out by working on a continuous stream of user stories. If they don’t get time to explore new technology or experiment with innovative product ideas, teams become demotivated. Make time in iteration plans for them to explore new ideas.

(like the Gold Card practice)

And always remember to...

Celebrate Success!!!
Find ways to celebrate the success of every release. Having a team
lunch or drinks celebrates success and increases team bonding.

[Life] productivity and overtime

How to be professional. What's the meaning of professionalism.
I cannot give a whole definition. I can say a clear example of fake professionalism: overtime.

Most of the times, if you need to work on sunday or saturday, it means you are not able to complete your work in a given time. The first thing to do is to acknowledge that this situation is the consequence of one or more failures.

Instead of working 24/7 to reach some goal you should try the opposite strategy: reserve some free time to think about the process and why you need to work hard.

I read this suggestion from this interesting article: Making Time Off Predictable - and Required

People can show their energies only in presence of limits.
I remember "The Legend of 1900" of Baricco:
"That keyboard is infinite... and if that keyboard is infinite, then on that keyboard there is no music you can play. You're sitting on the wrong bench... That is God's piano" and the conclusion:
"Take piano: keys begin, keys end. You know there are 88 of them. Nobody can tell you any different. They are not infinite. You're infinite... And on those keys, the music that you can make... is infinite. I like that. That I can live by..."

[Xp] switch and pair programming

The working day starts with a stand-up meeting.
One of the key points is define the daily plan: who is working on what.

Sometimes i hear: " today i don't want to switch pair, i want to continue to work with the same coworker "

I think it's exactly the time when the switch is necessary.
I think the pair is working in a comfortable area; he know that his solution is not the best, but it works for the current task.
Probably he neither want to describe his problem nor to share his solution.

The bells are ringing!

[Metodo] i falsi miti del Customer On Site

Nel tempo ho rivalutato l'importanza della pratica 'Customer on Site' così sponsorizzata dai metodi agili quale ad esempio eXtreme Programming.

Mantengo valida l'assunzione che la collaborazione deve essere costante e collaborativa; gli sviluppatori dovrebbero smettere di arguire e approfondire l'analisi facendo domande e scavando per soddisfare i veri bisogni del cliente, così come il cliente deve continuare a definire le priorità etc...

Un'ottima opportunità sarebbe avere il cliente sempre disponibile. Ciò accade di rado, anche quando il customer è 'on site'. Spesso accade che bisogna rincorrerlo e farsi dare risposte mentre viaggia tra un meeting e l'altro. Questa modalità di ricevere risposte può sembrare agile ma porta con sè vari svantaggi: ogni scelta deve infatti essere meditata; non può essere frutto della fretta.

Avendo un filo diretto di comunicazione, il cliente è stimolato a fare richieste di change request, a volte piccole ma non certo trascurabili (magari una mezz'ora di tempo); la pratica suggerirebbe di raccoglierle e considerarle in una opportuna fase di planning; ed ecco un altro problema: non sempre il planning è definito in un certo lasso temporale ben definito. Ciò che ho visto spesso succedere è che il planning viene fatto al termine di una funzionalità, quando lo sviluppatore chiede su cosa deve iniziare a lavorare.

Riassumendo, il cliente non si abitua a destinare tempi ben definiti per il planning, per le demo, per l'analisi. Ritaglia questi tempi quando gli capita, e questo è un peccato per tutti.
Secondo me il lavorare a distanza fissando tali periodi di tempo potrebbe essere una buona soluzione. Planning lunedì mattina, le demo giovedì pomeriggio e l'analisi il venerdì, ad esempio.

E' certo possibile farlo anche lavorando dal cliente, ma entrano in gioco altre componenti: il cliente comincia a criticare le pratiche di sviluppo del team e vuole imporre una atmosfera di controllo. Comincia a questionare l'efficacia del pair programming, delle pause, degli orari di lavoro etc.. tutto questo per vari fini, che forse non è nemmeno interessante analizzare.

Se non c'è un coach oppure il coach non riesce a 'difendere' il team si creano tensioni che sarebbe meglio evitare.

Dalla mia esperienza preferisco mille volte non lavorare nella sede del cliente, pur mantenendo l'abitudine di comunicare spesso e bene.

[Metriche] Le uniche metriche del codice che servono sono qui

Molto si è detto e scritto circa quali metriche è opportuno considerare durante lo sviluppo di un progetto.

Poichè le metriche servono esclusivamente a incoraggiare un comportamento, trascrivo qui quelle che piacciono a me, seguendo le quali si riuscirà a diventare un ottimo programmatore.
Seguitemi:

> Minimizzare il numero di user stories lavorate in modalità Last In First Out
Quando l'ultima user story descritta è sempre la più importante vuol dire che non c'è un vero e proprio planning e si è perso qualsiasi concetto di pianificazione e priorità: il vostro progetto sta andando a ramengo.


> Profondità coverage
Sapere che l' 80 % del codice è testato è una buona cosa. Eppure sapere che dalla stessa riga di codice ci passano più test in generale può voler dire che sono stati scritti non solo dei test unitari, ma anche dei cluster test o degli integration (o acceptance) test.
Se due test di diversa natura passano dalla stessa riga di codice la profondità di coverage è 2, che è meglio di una profondità di 1.


> Massimizzare la varietà di dati di test (suggerita dal mio collega Marco Gulino)
Non siamo abituati a pensare alle boundary conditions. Un eventuale codice del tipo: if (i < i ="=" i =" MAX_INT" i =" -1" style="font-weight: bold;">> Monitorare il rapporto Errore di stima / Numero di framework usati

L'errore di stima cresce a seconda del numero di tecnologie attraversate. Per completare la vostra user story dovete toccare solo maven, java, spring ? Oppure anche hibernate, fitnesse, wicket, selenium etc..? Calcolate un fattore correttivo adeguato!


> Duplicazione divergente
Certo la duplicazione è un male: ogni modifica in un codice copiato va riportato paro paro da altre parti e tale processo è error-prone, ma alcuni eroi con un po' di lavorio con search&replace e espressioni regolari riescono senza dubbio a lavorare in questa modalità. Eppure se i pezzi di codice duplicato divergono si perde la capacità eccezionalmente umana di riconoscere ad occhio le differenze. Il tuo codice non solo è duplicato ma non è più nemmeno simmetrico!


> Il rapporto Numero di classi / Numero di metodi pubblici deve tendere a uno
Una classe, una responsabilità, un solo metodo pubblico. E' facile identificare di quante responsabilità è caricato un oggetto: il piu delle volte basta contare il numero di metodi privati


> Il tempo di esecuzione test non deve degenerare all'aumentare del numero di test
Per lo meno garantisci che rimanga costante al crescere del numero di test. 100 test ci mettono 100 secondi? Se 200 test ci mettono 200 secondi stai adottando una strategia non peggiorativa.


> Minimizzare il numero di user stories che tornano "in progress"
Non mi ricordo chi l'ha detta, ma è di certo sintomo che gli AT non sono efficaci, e rilavorare funzionalità considerate finite è frustrante e puà essere dannoso se chi sistema i bachi non coincide con chi ci ha lavorato.