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.

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.

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.

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.

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

No, hai capito?

No.

[Unified Process] has [a flow with all the steps] formally described. I know [extreme programming] have different philosophies but they are both methodologies and should them both have a formal process.

rispondeva così

Sorry. Agile processes are not formal.

Questa risposta sintetizza (perché chiaramente si tratta di sintesi affatto esaustiva) molti aspetti difficili dell’approccio al mondo agile. Tra i primi che mi vengono in mente ora, mentre devo scappare per tornare al mio lavoro, trovo:

1. I metodi agili non possono essere spiegati top-down. Una spiegazione frontale può aiutare, può introdurre, ma poi basta: bisogna fare e capire. La mera inesistenza di una impalcatura formale scardina ogni tentativo di verbalizzarne una.
2. I processi agili sono facilmente fraintendibili da chi non è disposto ad approfondire il tema perché è più facile fare di concetti dai contorni sfumati quello che si vuole per giustificare le proprie esigenze dirette o addirittura le proprie debolezze. Penso a quanti ritengono che l’agile si risolva nella formula iteratività+incrementalità facendosi sfuggire che anche Unified Process contempla un approccio iterativo e incrementale.
3. I metodi agili sono adatti a fronteggiare la realtà perché ne riflettono la complessa vaghezza. Non esiste squadra di calcio che possa vincere una partita applicando schemi rigidi. Non esiste medico serio che si aspetti che un paziente sia un sistema che restituisce output lineari . Non esiste ecologo che pensi che si possa agire per step contemporanemanete deterministici e lineari per rimettere a posto un ecosistema. Esistono invece molti professionisti IT che credono che un sistema complesso – come un progetto – possa essere controllato da entità (più) semplici – una persona o addirittura un tool.

Quello che credo sia il nostro dovere tutti i giorni è crescere aumentando la nostra consapevolezza della complessità del contesto dei progetti IT e saper galleggiare su quelle onde ridefinendo ogni giorno il nostro equilibrio, senza affetto per quello trovato oggi, senza nostalgia per quello abbandonato ieri.

Trovi sia difficile? Lo è!

L’argomentazione di Martin parte da considerazioni sulla metafisica aristotelica per giungere a dichiarazioni concrete e molto chiare. I riferimenti alla storia della filosofia, devo ammettere, mi permettono di togliermi qualche soddisfazione: se anche luminari indiscussi del software internazionale come Martin li usano, allora io non devo aver fatto troppo male in passato! Scherzi a parte, il passaggio che mi è piaciuto di più è questo

The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

Io ho smesso di usare la parola agile da qualche tempo. I miei ultimi clienti – perfino quelli che mi contattano perché non vedono l’ora di entrare nel mondo dei metodi agili – non mi sentono più pronunciarla. Combatto una lotta linguistica quotidiana per formulare concetti e frasi che aggirino queste 5 lettere in successione: a, g, i, l, ed e. Sono talmente preso da questa decisione ellittica da nutrire ormai forti dubbi anche sul nome di questo blog.

Perché questa avversione? Perché così all’improvviso? Per diversi motivi.

1. Una parola, usata depauperata del suo significato più denso, è come un magazzino pieno di componenti non usate, come un set di user story iniziate e non completate: è, in sostanza, una forma di waste. Trovo sia più importante per un team mettersi in marcia concretamente verso l’agilità che fregiarsi di tale caratteristica.
2. Persone che in buona o cattiva fede per motivi più o meno legati al marketing si vendono come agilisti e attribuiscono (anche) a passate collaborazioni con me la loro agilità mi danneggiano. Questo danno è vero qualunque sia il grado di evangelizzazione io abbia volontariamente apportato, questo danno è vero quantunque io abbia potuto ritenermi anche solo in grado di evangelizzare. E questo mi porta diritto al terzo punto.
3. Io sono agile? Io posso davvero ritenermi arrivato ad un punto degno di tale fatidico attributo? Domanda difficile da esaurire con una risposta netta e sai perché? Perché l’agilità non è un valore assoluto e con questo non intendo affatto abbandonarmi al più facile dei relativismi. Intendo invece stabilire una natura relativa a priori dell’attributo di agilità: come la sicurezza è definita solo in termini di “fare A è più sicuro che fare B” e non certo di “fare A è sicurissimo”, così l’agilità è definibile in termini di “fare X è più robusto rispetto al bisogno di produttività in un contesto mutevole rispetto a fare Y” ma non certo di “facciamo così, facciamo così tutti e facciamolo sempre perché funzionerà ovunque”!

Qualcuno diceva riguardo l’abuso di cose e concetti:

Inventato il martello, tutto diventa un chiodo

Ecco, io vorrei fare l’uso migliore del mio martello, ma solo sui chiodi.

I processi agili sono il mio mezzo, chiunque mai li chiamerà come vorrà. Cercare di essere produttivi nel mondo reale, questo è il mio unico obiettivo.

Saccottino fallato

Sai cos’è questo? Un saccottino.

Non sembra, non è esattamente l’immagine familiare che hai del saccottino che forse ha accompagnato la tua infanzia, ma è invero un saccottino. L’ho trovato ieri nel mio pacco e sono rimasto abbastanza sorpreso. Anzi, devo ammettere di aver provato inizialmente un certo sgomento, una certa diffidenza. Farà mica male? Poi ho capito che si trattava solamente di due mezzi saccottini evidentemente sfasati [1] rispetto alla catena di produzione in azione nello stabilimento industriale dove questi due sfortunati saccottini erano in fase di confezionamento .

Poi ho capito anche un’altra cosa. Il mio sgomento trovava le sue radici nella rarità. Non mi era mai successo di comprare saccottini difettosi. Il prodotto esente da difetti nell’industria del saccottino è una rarità. E così in molte, moltissime altre industrie.

Che l’industria del software sia storicamente di tutt’altra qualità è una cosa che percepisco io e percepisci anche tu, anche senza dati oggettivi.

Ecco, tutto il senso dietro a SCRUM, dietro a Extreme Programming, dietro allo sviluppo agile, dietro al Lean Software Development… è proprio questo: lo sforzo di ricerca di un mondo in cui un software difettoso generi lo stesso sgomento di un saccottino sfasato.

[1] Uno sfasamento di mezzo saccottino è, in termini controllistici, uno sfasamento di 90°. Lo scrivo qui un po’ perché amo le note a pie’ di pagina, un po’ perché l’ingegneria dell’automazione è leggermente off topic in questa sede, ma solo leggermente.

Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.

tratto da un post di Ron Jeffries.

Il refactoring è una pratica essenziale. Essenziale, nel caso la sedimentazione linguistica non lo portasse alla luce immediatamente, significa relativo all’essenza, fondamentale, che è assolutamente necessario.

Assolutamente necessario.

Troppo spesso si parla di agile – buzzword che francamente sto cessando di impiegare – e si pensa di poter garantire evolutività incrementale solo con un po’ di iterazioni buttate in un calendario e delle user story scritte male. Bisogna essere produttivi per un mercato che cambia. Bisogna essere pronti a rispondere agli stimoli.

Il codice deve essere pronto a seguirci. Ovunque.