Diversificazione linguistica, su più livelli.

Forse avevi già letto delle “mie” kanban board marchigiane. La tecnica segue a dare ottimi frutti anche in Liguria e ho documentato qualche pensiero in proposito sul mio nuovo blog in inglese.

Questo post è solo il pretesto per farti presente dell’esistenza del mio nuovo blog che, lungi dall’essere sostitutivo di questo in italiano, ne sarà invece la ormai dovuta integrazione, rivolta allo scenario internazionale dei metodi agili e dei processi lean. Se apprezzi questo blog di tanto in tanto ci sono buone probabilità che leggerai volentieri anche Thoughts of a strange loop. Ciao!

March 19 2011 | Recensioni | No Comments »

La competenza che porta semplicità: mission possible.

La semplicità, l’arte di massimizzare il lavoro non svolto è una virtù strettamente legata alla competenza delle persone. Prendendo in prestito alcuni concetti dall’economia e dalla fotografia, mi sarà possibile dimostrartelo, perlomeno qualitativamente.

In economia esiste il concetto di isoquanto, ovvero

l’insieme delle combinazioni efficienti di input che forniscono lo stesso livello di produzione.

Questa arcana formula equivale a dire che più di una combinazione di ingredienti potrà darmi lo stesso risultato valido. Un esempio classico è quello del rapporto tra lavoro e capitale: fermo restando l’obiettivo di una start-up (il nostro output), se ho molto capitale e poco know-how potrò finanziarne una senza scrivere una riga di codice – il concetto di venture capital; se ho invece molto know-how e poco capitale potrò chiudermi in un garage tutte le notti e lanciarmi nell’impresa nerd.
Per opportune coppie capitale/know-how le chance di successo saranno le stesse e queste, in un diagramma cartesiano, saranno disposte lungo linee continue.

Isoquanti su Wikipedia

Isoquanti (fonte Wikipedia)

Un concetto simile esiste in fotografia: date certe condizioni di luce, sulla carta infinite coppie tempo di scatto/apertura diaframma mi garantiscono una corretta esposizione del fotogramma. Potrò chiudere il diaframma ed esporre per tempi più lunghi o potrò aprire il diaframma ed esporre per tempi più brevi.
Anche in un diagramma tempo-apertura perciò tutte le coppie accettabili saranno disposte lungo una linea continua. Ognuna di quelle linee corrisponderà ad un valore ISO della pellicola e sarà analoga all’isoquanto (hai notato qualcosa?) di cui sopra.

Cosa cambia di isoquanto in isoquanto? E di in ISO in ISO?

Banale ed intuitivo: se io posso disporre dello stesso know-how e di più capitale di un concorrente, avrò, ceteris paribus più chance di successo; se io posso disporre di un sensor… ehm di una pellicola caratterizzata da maggiori ISO, avrò, in condizioni per esempio di scarsa illuminazione, la possibilità di usare tempi di esposizione rapidi a parità di apertura diaframma, evitando un indesiderato effetto mosso.

Bene. E la competenza?

Si parla spesso di scegliere nel design del software fra una soluzione quick & dirty e soluzioni più “lente” ma più pulite. Se ne parla sempre. Se ne parla troppo. Il compromesso che si stabilisce è fra la massimizzazione del lavoro non svolto oggi e quello non svolto domani, tra 3 mesi o tra un anno. È possibile però ipotizzare l’esistenza di uno sviluppatore molto bravo che riesca a trovare una soluzione gagliarda oggi e facilmente estendibile in futuro, riuscendo quindi ad operare scelte win-win che trascendano il compromesso apparentemente inevitabile.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Il diagramma qui sopra spero sia sufficientemente chiaro da farti afferrare che a parità di lavoro non svolto nel futuro – il nostro A, la competenza può farci saltare da una linea all’altra (le linee di isocompetenza? :-) ) permettendoci di raggiungere i livelli crescenti B’, B” e B”’ di semplicità sul breve termine, salvando capra e cavoli.

Ipotizzare l’esistenza di uno sviluppatore molto bravo è utile ai fini di questo post. Diventarlo, una missione impossibile. La parola d’ordine è competenza, la sua espressione più diretta il refactoring.

February 24 2011 | Visione agile | 4 Comments »

Il sorriso in viso

Certo, ideato è la realtà in cui da anni passo la maggior parte del mio tempo come coach agile, ma se hai letto anche solo saltuariamente questo blog saprai che e-xtrategy è un’altra azienda che da qualche anno mi regala grandi soddisfazioni. Pochi giorni fa Michele ‘Miki’ Focanti, da qualche mese responsabile delle priorità di user story e task, mi ha scritto in vista dei nostri prossimi incontri.

[...]

Ad occhio mi sembra che “ci siamo”; abbiamo fatto la retrospettiva di gennaio ed abbiamo identificato le cose da migliorare che verificheremo a fine febbraio.
In questi giorni sta cambiando tutto “in tempo reale” (entrano progetti che devono essere consegnati dopo 2 giorni) e, incredibilmente, le persone continuano ad avere il sorriso in viso!

Il cambiamento epocale è stato questo:

prima qualsiasi evento (il cliente è contento, il cliente rompe le palle, c’è una cosa da modificare, etc) era legata all’e-xer [membro del team e-xtrategy, n.d.r.] responsabile del progetto (neanche al team). oggi qualsiasi evento diventa una “cosa di e-xtrategy” a cui dare una priorità e tutti si sbatteranno per portarla avanti prendendosi oneri ed onori.

in passato la telefonata al cliente era una delle cose più critiche. oggi è diventato: “Non riesci a chiamare Tizio? ok, allora lo chiamo io per te!”.

A presto

Miki

Capisci che fare il coach agile e parlare di lean development con persone così coraggiose è il lavoro più bello del mondo?

Miki, ci vediamo presto! ;-)

February 23 2011 | Dalle trincee | 1 Comment »

Lavoro sostenibile. Indefinitamente.

Una delle pratiche primarie dell’Extreme Programming è denominata, nel libro seminale Extreme Programming Explained, energized work. Letteralmente traducibile con lavoro rinvigorito, trovo più felice la traduzione lavoro sostenibile ed è una delle pratiche meno diffuse tra i programmatori, in questo caso spesso senza nemmeno l’alibi del management brutto-e-cattivo. La pratica è banale da descrivere: fatte le tue ore, stacca la spina, torna a casa e fai altro, vivi la tua vita. Distruggerti di lavoro oggi ti impedisce di garantire l’adeguata produttività domani, mancando di rispetto a te stesso, al team e, nei fortunati casi di maggiore autonomia degli sviluppatori, persino al datore di lavoro.

Non esiste alcuna prova che una persona in un team di sviluppo software sia più produttivo lavorando 70-80 ore la settimana invece che 40. Citando Kent Beck

Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.

E’ già molto facile rimuovere valore da un progetto su cui stiamo lavorando in condizioni normali – per esempio introducendo debito tecnico, ma se siamo stanchi allora il problema diventa accorgersi che stiamo rimuovendo valore. E allora diventa anche interesse del datore di lavoro quello di garantire la sostenibilità ad libitum del proprio processo di sviluppo. Perché

  1. Suo interesse è poter pianificare e per pianificare c’è bisogno di affidabilità.
  2. Suo interesse è consegnare valore una volta per tutte, user story dopo user story, senza doverci ritornare per qualche disattenzione.
  3. Suo interesse è preservare l’integrità del team nel tempo, considerato il valore inestimabile che la seniority ha nel nostro mercato.

Certo, se poi il meccanismo in cui si incappa è banalmente quello di accettare stipendi di qualche punto percentuale sopra la media per lavorare il doppio 30% in più del tempo, allora siamo di fronte ad una raffinata truffa e l’interesse nel lavoro sostenibile diventa tutto dello sviluppatore. Ma a giudicare dalla salubrità del mondo IT in Italia e in Europa, sembra proprio che certe catene siano ancora invisibili agli occhi degli incatenati.

February 18 2011 | Le pratiche XP | 6 Comments »

Quality assurance e metodi agili

Alessandro commenta in modo ineccepibile un post sul collocamento delle attivita di Quality Assurance (QA) nei metodi agili e mi sento solo di integrare con qualche considerazione di livello più basso, avendo lui già fatto gli opportuni riferimenti ai concetti di eccellenza nello sviluppo agile.

A mio avviso, l’autore del post commette la gravissima ingenuità di non tenere conto del concetto di project velocity o forse la concepisce – come spesso mi capita di ascoltare – solo in modo prospettivo:

Quanti punti facciamo la prossima settimana?

E basta.

In realtà almeno metà del senso della project velocity è retrospettivo:

Per garantire la qualità necessaria – test compresi, tutti: da unit test a test sugli utenti – la scorsa iterazione siamo stati capaci di “bruciare” 7 punti. Ne avevamo pianificati 18, ma evidentemente con tutti i test siamo riusciti a fare 7. Bene la prossima iterazione pianificheremo 7.

Ovviamente a prima vista questo significa rallentare. Perlomeno non meno che fare un’iterazione solo per fare test, come suggerisce l’autore. Tuttavia gli approcci sono ben lungi dall’essere equivalenti, perché in quello proposto nel post otteniamo feedback con minor frequenza, garantendoci solo una cosa: l’aumento delle chance di lavorare su un sistema che non rispecchia più la realtà dei fatti. Fatto che significa

  1. non risolvere i problemi realmente emersi, ma problemi già vecchi.
  2. spendere effort e quindi denaro su falsi problemi, pagando elevati costi opportunità.

Tutto sta nel tenere bassi i costi della contemporaneità, della coesistenza della fase di sviluppo e di test. Non per tutti i professionisti attorno allo sviluppo del software è, ad oggi, altrettanto facile. In ambiti come la progettazione UX per esempio i dibattiti sono ancora vivaci e dall’esito poco chiaro. Per gli sviluppatori però ormai ci sono tecniche e strumenti maturi. Basta solo la voglia.

January 04 2011 | Base | No Comments »

Agile è… non dire mai “ci pensi tu”

Un committente crede che tu ed il resto del tuo team di sviluppo possiate semplificare per delega, grazie ai metodi agili, il suo lavoro. Lui crede che possiate prendere il suo canovaccio, espanderlo nei dettagli, metterlo in piedi e portarlo pronto in tavola. Molti credono – come lui – che i metodi agili siano uno stupendo scenario in cui sponsorship illuminate da un’idea fulgida possano premere il pulsante rosso di veloci e precisi missili fire-and-forget che andranno a colpire il bersaglio del successo senza ulteriore necessità di azione e pensiero, certe volte addirittura senza alcun rischio d’impresa, “tanto facciamo tutto agile, no?”

A questi diluitori di significato, ricordo che da queste parti si predilige la collaborazione col cliente piuttosto che stare lì ad aspettare che i contratti vengano impugnati inesorabilmente da una delle parti contro l’altra e che invece sarebbe bene giocare allo stesso tavolo dall’inizio alla fine del progetto senza stare lì a sostituire la voglia di lavorare con deleghe e regolette, perché la prima serve comunque, le seconde non funzionano e le terze nessuno le ha ancora trovate.

La forma mentis è la stessa di chi dice che l’agile tutto sommato è solo buon senso riorganizzato rivelando a chi ascolta solo una grave superficialità nel parlare di una mentalità che offre parecchi punti di vista a volte persino controintuitivi.

Ecco, il buon senso: farebbe bene a farne uso un committente del genere e nel frattempo cercarsi un altro team, un’altra metodologia. Di sicuro un altro coach.

December 21 2010 | Dalle trincee | 4 Comments »

Dei dubbi, delle certezze, della crisi e della crescita.

Dopo aver affrontato il tema dello stile di coaching con Federico Galassi, Stefano Leli e Gabriele Lana durante la cena pre-IAD 2010 e risollecitato da un recente, recentissimo thread della mailing list SIAgile, in cui la discussione avviata da Pino riguardo i pattern SOLID ci ha portato a discutere di crescita personale, evangelizzazione, didattica costruttiva, didattica distruttiva, regole e principi ho pensato di scrivere qualcosa su questo sempre più avaro blog. Alla fine ruota tutto attorno alla questione: è utile imparare a seguire regole ed affermarle e riaffermarle in seno ad un percorso (auto)didattico? In questo post intenderò mostrarti perché a mio avviso la risposta sia un SOLIDo[1] “sì”.

continue reading »

December 08 2010 | Esperti | 18 Comments »

Checklist e approccio lean in barca

Gentilmente sollecitato insieme ad Alessandro da Matteo eccomi qui a raccontare qualcosa sull’impiego di checklist nel nostro team… di regata. Partiamo dal problema: come assicurarsi che in ogni fase della regata, a cominciare dall’allestimento della barca, le azioni necessarie vengano eseguite? Come garantire che vengano eseguite nell’ordine corretto? Come prevenire vuoti di memoria, potenzialmente pericolosi?

continue reading »

October 16 2010 | Uncategorized | 8 Comments »

Lean e-xtrategy

e-xers

Sono di ritorno da una splendida due giorni passata lavorando con i ragazzi di e-xtrategy pensata per svolgere una retrospettiva su un progetto appena concluso, che ho avuto modo di seguire sin dall’inizio. Inutile dire che l’esperienza è stata formativa per me almeno quanto lo è stata per loro, che mi offrono sempre grande fiducia e libertà di svolgere le nostre analisi, senza sovrastrutture inutili, senza pregiudizi e senza la pretesa di dover nascere imparati, né io né loro.

I topic emersi e sviscerati sono stati diversi e purtroppo qui in questa sede posso solo riassumere i maggiori: kanban, value stream map, automatizzazione dei test e agile ux.

Kanban

Il problema immediatamente emerso dalla retrospettiva è stato quello di gestire le attività dell’azienda che non producono valore diretto per il cliente ma che vanno in ogni caso raccolte, valutate, inserite in una coda di priorità. Per tutti questi task la necessità di un punto di gestione concorrente e la possibilità per lo staff di e-xtrategy di lavorare in uno spazio di aperto e condiviso (elegantissimo peraltro n.d.r.) ha fatto emergere in pochi brevi passaggi l’adozione del kanban. Il kanban, lo scrivo brevemente a beneficio dei neofiti, è sostanzialmente una lavagna dove viene tracciato secondo poche ma ben determinate regole lo stato dei diversi task, abilitando il team ad una modalità di lavoro

  1. concorrente, dove sono ridotti al minimo gli stati di attesa per svolgere il proprio lavoro
  2. pull, dove si annulla la necessità di una figura responsabile dell’erogazione del lavoro da svolgere
  3. trasparente, dove ognuno sa e può sapere cosa sta facendo l’azienda nel suo insieme in un dato momento.

Abbattimento della burocrazia, trasferimento del controllo verso il basso e tracciamento di tutte le attività sono il cuore di questa soluzione.

Kanban in salsa marchigiana

'Porta' può essere tradotto dal marchigiano in questo contesto come 'Done' :-)

Value stream map

Sempre nell’ottica di individuare con precisione le attività che producono valore diretto per il cliente e distinguerle dalle attività accessorie abbiamo fatto ricorso alla mappatura del flusso del valore, che permette di individuare quali punti del processo ostruiscano la consegna del valore stesso al cliente. Come attività complementare abbiamo stabilito un ranking delle attività interne all’azienda secondo l’importanza percepita dal cliente rispetto al valore consegnato. Questo ranking è stato utile per capire in maniera più oggettiva quali siano le attività su cui cercare di tagliare i costi.

Interessante a dir poco, in un’azienda che passa la gran parte del tempo a scrivere codice PHP per consegnare siti web più o meno complessi, l’attività di scrivere PHP risulta essere fra le meno rilevanti per il cliente finale, quindi fra le meno dense dal punto di vista del valore consegnato. In sostanza una prova a posteriori di quanto sostengo da un bel po’: il codice è un mezzo, mai l’obiettivo.

Automatizzazione dei test

Per stabilire un punto di incontro oggettivo che stabilisca l’impalcatura di lavoro per il maggior numero di persone possibile all’interno dell’azienda si è stabilito di far attecchire i test funzionali una volta per tutte, incarnati da Selenium – nelle sue nuance Selenium RC per PHP e Selenium IDE. Il workflow per ora ipotizzato – perché solo dopo qualche settimana o mese di riscontri se ne potrà stabilire la bontà assoluta e relativa ad e-xtrategy – vede lo specialista XHTML/CSS produrre test funzionali di alto livello basati sui prototipi scritti in XHTML (vedi sotto) usando Selenium IDE – che permette di scrivere i test semplicemente usando il browser -  e poi una serie successiva di raffinamenti nelle fasi di sviluppo in cui i programmatori PHP con Selenium RC possono integrare gli stessi test in PHPUnit.

Interaction design (più) agile

Ale inizia a scrivere l'html del wireframe
Le intraprendenti decisioni prese dal team e-xtrategy in quei due giorni sono state argomento di discussione anche al di fuori delle mura e-xtrategy con commenti dei soliti noti ad un post di Alberto – Ilaria Mauric compresa, interaction designer di e-xtrategy. L’obiettivo che condivido con il team e-xtrategy in questo frangente è quello di mitigare, se non risolvere, il problema posto dall’integrazione di un team UX con un team di sviluppo. Dopo i primi esperimenti negli anni scorsi, infatti, i principali interaction designer con cui ho collaborato hanno rivisto al ribasso il loro entusiasmo per i metodi agili e si sono arroccati dietro un “per la progettazione il waterfall è inevitabile”, nonostante i pochi esperimenti fatti avessero lasciato soddisfatti tutti i team coinvolti – intesi nel loro senso più eterogeneo. Ovviamente, poi ho capito, per le aziende specializzate in interaction design il discorso ha senso: perché impelagarsi ad integrare il mio metodo con quello di chi sviluppa se il mio business è esclusivamente basato sulla progettazione?

E-xtrategy però presenta una situazione diversa in cui la multidisciplinarietà del team interno è elevata e in cui quindi una metodologia agile integrata ritorna immediatamente di altissimo interesse. Interaction designer, visual designer, sviluppatore XHTML/CSS e sviluppatori PHP, poiché a stretto contatto, possono condividere molto spesso i loro semilavorati e perfino lavorarli in pair cross-funzionali!

Il succo insomma sta nel ridurre al minimo l’approccio fornitore-cliente che vuole – per fare un mero esempio – che l’interaction designer sviluppi un wireframe che poi venga traformato in prototipo che poi venga passato al visual designer che poi passi il template al programmatore XHTML/CSS che poi passerà il lavoro finale alla gente del PHP, in una lunga serie di piccoli waterfall. Con alcuni accorgimenti è possibile circoscrivere molto la necessità di una progettazione upfront: sviluppato un prototipo XHTML molto simile al wireframe, si comincia a scrivere test funzionali per garantire che quel wireframe-ormai-prototipo sia la base di tutto il lavoro successivo per tutto il team. Si fa in modo insomma che il wireframe venga sugellato dai test automatici come il codice eseguibile, con un immenso guadagno sia in termini di formalismi e oggettività – il wireframe esaltato dai test nel suo giusto ruolo di contratto – sia in termini di organizzazione del lavoro – gli sviluppatori e i grafici possono in questo modo lavorare in parallelo sin dalle prime fasi dello sviluppo.

Non mi rimane che ringraziare e-xtrategy per la rinnovata esperienza di coaching e promettere a te di riportare qui la cronaca dei prossimi sviluppi più rilevanti relativamente a tutti questi temi .

July 31 2010 | Dalle trincee | 8 Comments »

L’importante è avere disciplina

Ma sì dai, l’importante è avere disciplina, darsi un metodo. Poi agile o non agile non importa, è uguale.

No, hai capito?

No.

July 23 2010 | Base | No Comments »

« Prev - Next »