Il nostro ciclo di sviluppo è estremamente veloce e abbiamo costruito strumenti per mantenerlo così. E’ normale scrivere codice e averlo in produzione pochi giorni dopo. Questa è una piacevole sorpresa per gli ingegneri che hanno lavorato in altre aziende dove il codice ci mette mesi o anni a vedere la luce del giorno. Se lavori con noi, potrai avere un impatto immediato.(*)
Hai notato? “Pochi giorni dopo”, “piacevole sorpresa”, “impatto immediato“. Perché loro sì e tu no?
“Eh ma da noi è diverso!”.
Ne sono convinto: quella differenza la stai facendo anche tu.
Lo scorso ottobre sono stato invitato come speaker alla PHPNW 2011, dove ho tenuto il talk intitolato Many to many – No man is an island. Si parla di comunità, di nerd, di social skill e di incidenti aerei. La registrazione è buona; il talk spero.
Molto probabilmente ricorderai dai tempi della scuola il concetto di mitosi, quello per cui la cellula, raggiunto un certo stadio del suo ciclo di vita e un certo accrescimento, si divide in due cellule figlie duplicando perfettamente il proprio patrimonio genetico e assegnando ad entrambe grosso modo lo stesso numero di risorse.
Se non ricordi la lezione di scienze a scuola forse ricorderai il fatidico momento ricorrente nella serie animata Siamo fatti così in cui i globuli bianchi rispondevano ad un’infezione duplicando rapidamente l’organico di truppe disponibili. Nelle ultime retrospettive in ideato si è pensato di ricorrere allo stesso meccanismo per rispondere agli inconvenienti della crescita: comunicazione più complessa, gestione lenta della conoscenza e colli di bottiglia nel processo a monte del team di programmatori. E così ora ideato si ritrova con due team grandi la metà di quello originale. continue reading »
Il buon Gianandrea, attivo e paziente compare di riflessioni sui problemi dell’organizzazione del lavoro, sottopone alla mia attenzione questo articolo di Alessandro Cravera sul lean thinking. Un articolo rivelatorio delle distorsioni costantemente in agguato e in atto sempre più nel contesto manageriale che adotta metodologie agili per poi tradirne l’essenza. Lascia che ti spieghi come mai la pensi così.
Il pensiero di assunto da Cravera nella sua critica è quello di Womack per cui
Per usare le parole dello stesso Womack, il lean thinking è “un modo per fare sempre di più consumando sempre di meno”.
e da questa considerazione Cravera fa conseguire una riflessione sui rischi che il lean thinking comporta quando eventuali ridondanze vengono eliminate in nome della riduzione degli sprechi. Riflessione, questa, legittima perché effettivamente la riduzione tout court di ogni ridondanza è effettivamente a rischio di subottimizzazione, quella condizione in cui un ottimo locale può inficiare la prestazione globale di un sistema. Effettivamente lo scenario dello sviluppo di prodotti può fare tesoro di alcune ridondanze – basti pensare alla creazione di più ipotesi di interfaccia utente, per fare un esempio banalissimo. Quello che della riflessione non va, se vogliamo legarla ad una critica sana del lean, è l’assunto che il lean thinking sia devoto e prono alla subottimizzazione quando è assolutamente il contrario!
Nel Lean Primer di Craig Larman e Bas Vodde, la cui lettura consiglio a tutti gli interessati al pensiero lean, gli autori liquidano il punto di vista di Cravera già nella prima pagina (!) con questa considerazione che io riporto, tradotta da me:
L’immagine e la metafora con cui vorremmo porre l’accento su un errore – ed un’opportunità – chiave è la staffetta.
Considera i podisti di una staffetta in attesa del testimone da parte dei loro compagni di squadra. L’account manager, inorridito da questo spreco da sottoimpiego indicato in qualche report, probabilmente definirebbe una nuova policy con l’obiettivo “dell’impiego al 95% delle risorse” per assicurare che tutti gli staffettisti abbiano da fare e siano produttivi. Forse – suggerirebbe – gli staffettisti potrebbero correre tre staffette contemporaneamente per incrementare l’occupazione delle risorse. [...]
Divertente… ma questo tipo di ragionamento è più tipico del management e dei processi tradizionali nello sviluppo e in altri domini. Invece, per contrasto, ecco l’idea alla base del lean thinking:
Tieni d’occhio il testimone, non gli staffettisti
Già traspare quindi il grave vizio di sostanza dell’ emerso – non capisco se solo per citazione o per effettivo sposalizio – nell’articolo di Cravera: guarda all’approccio lean attraverso le lenti dei processi classici e ne analizza l’eventuale risultato, ormai però distorto. Non mi dilungo oltre: se ti interessa il pensiero lean leggi l’articolo di Cravera con attenzione. Poi leggi quello di Larman e Vodde per capirlo davvero.
Domani sarò al jsDay dove potremo apprezzare lo stato dell’arte del know-how Javascript e delle tecnologie a contorno. Trovo sia un bell’evento, considerato che è il primo in Italia nel suo genere e con un’ottima line up fin da questa prima edizione.
Da giovedì sarò al phpDay dove avrò l’onore ed il piacere di presentare il keynote venerdì, intitolato Many to many: no man is an island. Tratterò il tema particolarmente importante delle community e dello sviluppo della competenza.
Oggi mi trovo a Madrid, dove stasera si terrà il primo ALE Gathering al termine della prima giornata di XP 2011. Si tratta di un neonato network europeo centrato sulla diffusione dei valori agili e lean nello sviluppo del software. L’obiettivo di stasera sarà quello di settare la vision del network. Sarà divertente perché, mentre la delegazione italiana sarà ben rappresentata, io mi sono offerto per rappresentare la comunità bulgara, impossibilitata ad inviare dei propri delegati. Se non è networking questo…
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!
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 (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.
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.
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?
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é
Suo interesse è poter pianificare e per pianificare c’è bisogno di affidabilità.
Suo interesse è consegnare valore una volta per tutte, user story dopo user story, senza doverci ritornare per qualche disattenzione.
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.
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
non risolvere i problemi realmente emersi, ma problemi già vecchi.
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.
![[del.icio.us]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/facebook.png)
![[Google]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/google.png)
![[LinkedIn]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/linkedin.png)
![[Technorati]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/technorati.png)
![[Email]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/email.png)
) permettendoci di raggiungere i livelli crescenti B’, B” e B”’ di semplicità sul breve termine, salvando capra e cavoli.