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.

Qualche analogia

Ancor più che il mio solito, stavolta partirò davvero da lontano; prima qualche analogia, poi piano piano mi avvicinerò al nucleo dell’argomentazione. Spero tu possa seguirmi senza annoiarti. Un minimo di diluizione in più sarà il prezzo che pagherai insieme a me per ottenere, spero, più chiarezza.

La crisi e la crescita nell’arte

Picasso - Chitarra

Chiunque abbia avuto l’ardire di buttarsi completamente digiuno a capofitto nell’arte contemporanea conosce quella sensazione di rifiuto un tantino impregnata di arroganza: “questo lo sapevo fare anche io”. Quella sensazione ha origine dalla constatazione di un significato molto profondo, ma apparentemente oscuro, racchiuso in un involucro apparentemente molto facile se non addirittura rozzo. Insomma, se mi presenti un ammasso di quadratini dipinti e mi dici che è una chitarra, io ti dico che una chitarra c’è chi la fa molto meglio. Picasso e altri autori degli ultimi 100 anni sono soggetti a commenti di questo tipo, mentre Caravaggio gode di consenso virtualmente universale.

Caravaggio - Concerto di giovani

Quello che si ignora con decisamente troppa facilità quando il senso comune si affaccia al mondo di Picasso e stenta ad accettarlo, è che un grande pittore come lui non è mai tale se ignora superficialmente il vincolo del realismo. Un grande pittore contemporaneo può – e sottolineo può – trascendere il vincolo del realismo, bucarne la barriera per portare lo spettatore in una zona di espressività che noi nerd chiameremmo augmented. Per fare un esempio della cui primitività chiedo scusa a tutti, alla mia prof di storia dell’arte in primis, qui

Picasso - Scienza e Carità

vediamo come il giovane Picasso fosse in grado di dipingere perfettamente in uno stile molto più prossimo al realismo. Anche Gauguin, uno degli impressionisti più noti, vanta dei precedenti giovanili molto molto vicini al realismo di Caravaggio e Velazquez.

Ma non devo perdere di vista il punto cui voglio arrivare. Di questa parentesi artistica si trattenga solo questo concetto: fermo restando che un pittore avrà molte più possibilità di espressione se saprà dotarsi degli strumenti e delle tecniche “classiche”, il fatto stesso che un Picasso abbia deciso di abbandonarne buona parte, per crearne altre, ci suggerisce e dimostra come le prime non fossero sufficienti ai suoi scopi espressivi. Bene, abbiamo un primo fatto.

La crisi e la crescita nella scienza

Se ti sembra troppo aereo, vago, improprio, fricchettone l’argomento sostenuto fin qui, forse qui troverai l’argomento che cerchi.

Albert Einstein

Einstein ha pubblicato 3 articoli fondamentali nel 1905: uno sulla relatività, uno sull’effetto fotoelettrico e uno sul moto browniano. Secondo te per quale delle tre teorie gli è stato conferito il premio Nobel?

Molto sono convinti che il prodotto più dirompente del pensiero di Einstein sia stato quello della Relatività, mentre in realtà Einstein avviò, senza nemmeno desiderarlo, una profonda rivoluzione del pensiero scientifico con la scoperta dell’effetto fotoelettrico, rivoluzione profonda al punto di non essere ancora per nulla assorbita dal senso comune più di 100 anni dopo.

In sostanza e brevemente, solo per rendere il mio discorso più chiaro, con la spiegazione dell’effetto fotoelettrico (secondo cui bla bla bla) Einstein ha dato il la alla slavina scientifica che ha portato Bohr e Eisenberg, fra gli altri, a impostare le basi per la meccanica quantistica, disciplina che a dispetto delle innumerevoli conferme sperimentali ha completamente trasceso, bucato la barriera dell’intuitività, mostrando come il senso comune sia insufficiente a spiegare la realtà perfino nelle percezioni apparentemente più ovvie. Tra le altre novità, nella fisica quantistica il concetto di probabilità non è più legato all’ignoranza dell’osservatore, ma costituente essenziale della struttura del mondo.

La teoria della Relatività invece accoglie la fisica newtoniana determinista e ne sposta avanti il confine. Potremmo dire che la generalizza, non uscendo quindi dal solco già impostato dal grande scienziato inglese, sebbene certamente regalando all’umanità nuovi strumenti di immensa potenza analitica.

Ovviamente non è questa la sede per approfondire questo pur interessantissimo tema, né ne posso vantare le competenze per permettermelo, ma qui basti solo considerare lo scenario venutosi a creare, articolato in tre punti:

1. La fisica newtoniana, già superata dalla teoria della Relatività, è completamente sovvertita dalla fisica quantistica.
2. La fisica relativistica è il massimo punto della fisica classica, dove il determinismo regna incontrastato.
3. La fisica quantistica, confermata dagli esperimenti e – non mi sembra un dettaglio – impiegata a scopi industriali, nega realtà intuitive e fa dell’intero Universo uno scenario *non* deterministico.

Stabilendo un primo ponte con l’argomento precedente, potremmo dire che la fisica di Galileo e Newton sta a Giotto come Einstein sta a Caravaggio, come Bohr sta a Picasso. Questi paralleli ci portano finalmente al nocciolo del mio post.

La didattica e il coaching agile

Troviamo normale che nella scuola venga insegnata la fisica newtoniana sebbene completamente inadeguata ad abilitare i cervelli degli studenti alle sfide scientifiche non dei nostri giorni, ma ormai persino di 80-100 anni. Troviamo altrettanto normale che le metodologie agili e anche tutto ciò che viene e verrà dopo lo sviluppo agile sia preteso dalle persone meno esperte di chi da anni è sulla breccia della disciplina? Dai discorsi in giro per mailing list e user group sembra di sì. Troviamo infine ammissibile che una persona sulla breccia della disciplina 10-15 anni fa possa oggi – e sottolineo possa – essere soggetto a nuove pressioni culturali, legate all’evoluzione della disciplina stessa, analogamente a come Einstein fu spinto ai margini della rivoluzione quantistica dalle sue ostinate convinzioni classiciste? Dai discorsi in giro per mailing list e user group sembra di no.

Shu Ha Ri

Nel contesto dei metodi agili si prendono spesso in prestito dalle arti marziali i tre stadi della maestria: Shu, Ha e Ri.

Shu – Segui la regola

Nello stato Shu l’allievo applica pedissequamente le tecniche senza modifiche e addirittura, nei casi più estremi, senza neppure porsi domande sulla vera ragione dietro alle tecniche stesse. La fase metti la cera, togli la cera di Daniel-san per intenderci. Nell’agile le regole abbondano e molte servono soprattutto nella fase iniziale della vita di un team per spezzare abitudini e routine precostituite e date per scontate nella quotidianeità. Quando per esempio il buon Pino decide di seguire ferree regole per scrivere i metodi di una classe, sta esattamente cercando di sollecitare in modo brutale ma comunque virtuoso le sue capacità di progettazione del software.

Ha – Vìola la regola

Nello stato Ha l’allievo ne sa abbastanza da poter suggerire agli altri allievi modi di avanzare nel loro percorso e l’individualità può emergere sulla base delle forti fondamenta costruite nella fase Shu. Per capirci: imparati per bene i kata (toh guarda, questa parola la conosco già!), il nostro Karate Kid può affrontare anche avversari reali in torneo, abbandonando necessariamente – pena la sconfitta – la rigida schematicità dei kata stessi. Il Manifesto Agile non è prescrittivo e anche il più campanilista degli autori dei testi “classici” dell’agile concordano tutti sulla necessità di ritagliare i metodi sulle proprie realtà. Purché questo avvenga a valle della fase Shu! Insomma Einstein conosceva la fisica di Newton molto bene!

Ri – Sii la regola

Nello stato Ri l’allievo non pensa più alle regole, ma le usa tutte implicitamente, comprese quelle inventate di sana pianta, per perseguire il suo obiettivo. Se mi consenti di abbandonare qui il karate di Miyagi e Daniel-san, Bruce Lee inventando il Jeet Kune Do non dimenticava affatto il suo buon vecchio kung-fu, ma si consentiva la libertà di reimpostarlo a piacimento in virtù di una nuova definizione di valore (toh guarda, anche questa parola mi sembra di averla già vista!): non più la ricerca filosofica per se, non più l’autodifesa o l’attacco, ma la spettacolarità cinematografica. Un team agile “in Ri” può decidere di integrare tecniche per nulla agili come un Gantt chart e abbandonarne di agilisssssssssime come il test automatico se, ma solo se, il valore del software consegnato ne godrà di vantaggi reali.

Teaching, coaching, advising

Ad ognuna di queste fasi cognitive è ovviamente associata una fase (auto)didattica del coach. Lyssa Adkins nel suo Coaching agile teams le individua così: teaching, coaching e advising.

Teaching

In questa fase il coach decide il come si faranno le cose. Come persona la cui conoscenza di modi migliori di lavorare è riconosciuta, il coach trasmette esplicitamente al team pratiche e principi, le prime per definire cosa fare, i secondi per definire perché. Un po’ come dire: “queste pratiche funzionano, tutto il resto è un intralcio“. Una volta padroneggiate le pratiche ed i principi la transizione allo stato Ha avviene naturalmente.

Coaching

In questa fase il coach allenta la presa sul team e può farlo nella misura in cui nella fase di teaching ha ben innestato le pratiche e i principi agili. I team in genere tendono a questa fase con troppo fretta e dovere del coach è quello di ripristinare la fase di teaching qualora necessario. In una solida fase Ha il team ha colto i valori agili e li sa perseguire con un generico approccio di ispezione ed adattamento. Un po’ come dire: “sapete perché questo modo di lavorare funziona? Quindi sapete anche perché quest’altro modo di lavorare che proponete funzionerà anche meglio?“.

Advising

In questa fase il coach ha a che fare con un team maturo in cui sia il successo che il fallimento sono momenti gestiti correttamente ed in autonomia. Così auto-organizzato, auto-monitorato e auto-correttivo, il team non ha più bisogno di un coach e serve solo che se ne renda conto. Per completare questa transizione il coach affronterà una transizione completa al ruolo di consigliere (advisor) fornendo più domande che risposte. Un po’ come dire: “in effetti potrebbe funzionare: provate e mi fate sapere come va?“.

Ovviamente gli stati Shu, Ha e Ri coesistono in un team e così coesisteranno gli stili di coaching. L’abilità del coach starà nel riconoscere la configurazione a chiazze di maestria impronta digitale di ogni team e nel saltare continuamente da uno stile all’altro.

Accogliere il cambiamento. Anche quello altrui.

Fatte tutte queste considerazioni, mi sembra più pacifico riconoscere che non c’è un modo corretto di adottare o rifiutare in toto un compendio di regole e principi. Non solo alcune regole giuste in questo team potrebbero essere inutili in quello; non solo lo stesso team potrebbe non avere più bisogno di un set di regole dopo anni di serena adozione; non solo lo stesso set di regole potrebbe essere valido temporaneamente in senso didattico anche se non corretto in senso assoluto (quello della conoscenza non è un campo vettoriale conservativo). Quello che mi riterrei fortunato di far emergere in questo post è l’incontrovertibile dato di fatto che un coach non può pensare di fare il proprio lavoro correttamente se si affida ad uno schema semplice.

Tutte le volte che sento un coach vendere frasi, slogan e soluzioni one-size-fits-all drizzo le orecchie ed il mio sistema immunitario anti-brand (sviluppatissimo, poiché nativo di un mondo in cui i brand sono le linee guida della società) va in allerta. Che senso ha parlare di sviluppo bottom-up, emergente delle competenze se poi neghiamo questo approccio affermando un’unica via maestra, in pieno spirito top-down? Avete mai sentito di un modo corretto e unico di insegnare ad un bambino a camminare? No e sarebbe impossibile.

Da questo derivo un altro paio di corollari. Innanzitutto un coach non può vivere la fase di teaching con l’arroganza indotta dalla sua competenza. Questa arroganza, a volte mascherata da ironia socratica, è più spesso solo sarcasmo. L’ironia socratica è una fase sì dialetticamente distruttiva, ma del preconcetto, non della persona in cui quel preconcetto alberga. Lo stato Shu altrui è già una conquista, umiliarlo, non fa che essere controproducente, allontanando i meno esperti, e danneggia l’intero sistema culturale di qualsiasi disciplina, quella agile compresa.

Il secondo corollario trovo sia ancora più importante, soprattutto nello scenario delle metodologie agili in Italia. Se un coach ama la sua disciplina sinceramente allora la amerà più del proprio successo personale. Se Einstein oggi potesse usare una memoria compact flash basata su tecnologie quantistiche probabilmente avrebbe l’onestà intellettuale di ammettere il proprio errore iniziale. Anzi, probabilmente con rinnovato entusiasmo saprebbe affiancare la ricerca a valle del fatto riconosciuto. È dovere di un coach quindi ambire ad allievi che superino il maestro e a non irriderne i tentativi di transizione dallo stato Ha al loro stato Ri.

Nell’etimologia della parola ‘crisi’ si legge che la parola è vicina al significato di “separazione”. Nella crisi si separa la vittoria dalla sconfitta, la crisi è il momento in cui si decide della vita o della morte del paziente. Se l’agile, vecchio di un decennio e più ormai, è davvero in crisi – ammesso e non concesso peraltro – allora i tentativi di integrarlo e trascenderlo, purché non siano tentativi di evaderne, sono davvero così mal riposti? Kaizen, kanban e muda sono quindi parole che meritano di essere sbeffeggiate solo perché valide anch’esse solo temporaneamente, fino a nuovo ordine, come è sano che sia se si vuole fare Scienza con la ‘S’ maiuscola?

[1] Non ho resistito

Non resisto alla tentazione di integrare con una metafora sportiva: in una squadra di football ci sono i manager e c’è il coach. Non credo debba aggiungere altro, secondo me messa così rende bene l’idea.

Kent Beck, papà di Extreme Programming, Test Driven Development e Manifesto Agile, per dirne giusto due o tre, in questo suo post fa una breve analisi del poker e ne trae una interessante lezione: nelle negoziazioni in cui non siamo al corrente di tutti i retroscena – caso peraltro abbastanza tipico – è possibile scambiare un certo valore in denaro con un corrispondente valore in informazioni.

Nel poker lo facciamo tutte le volte che vediamo il gioco avversario, raccogliendo informazioni sulle sue attitudini strategiche, o le volte in cui dichiariamo accettiamo il gioco in apertura – versando la quota opportuna nel piatto, per avere una prima impressione sul gioco in mano agli avversari. Nei negoziati a monte di tutti i nostri progetti lo facciamo tutte le volte che scopriamo di aver chiesto meno di quanto avremmo potuto, rinunciando quindi ad una certa quantità di denaro ora ottenendo informazioni sul vero valore del nostro lavoro preziose nel futuro.

È importante capire che tutto ciò è vero su entrambi i fronti del negoziato; anche il nostro cliente si chiede se il nostro lavoro vale la somma esborsata ed è pronto a sborsarne meno la volta successiva se scopre che il gioco non vale esattamente la candela. Questo significa che, a lungo termine, gli accordi, per mantenersi sostenibili, rischiano di attestarsi su valori più bassi del migliore possibile a causa dell’esborso necessario a raccogliere informazioni strategiche. Un po’ come dire che l’etica può essere pragmatica, no?

Ciò detto scritto, ti sembrano più ricchi accordi fatti in trasparenza o quelli fatti in un contesto opaco? Tu hai mai scoperto il bluff di un tuo cliente? E non hai mai bluffato? In quale caso il progetto ha avuto più successo?

Questa visione dei test come side effect di una tecnica di design – Test Driven Dev… Design – mi ricorda un mio vecchio post in cui sostenevo la maggiore importanza della manovrabilità delle specifiche rispetto al codice sorgente, relegando quest’ultimo al ruolo di mero strumento. Ovviamente la decentralizzazione del software che ho sostenuto in quell’occasione e in molte successive non ha nulla a che vedere con una presunta dequalificazione del codice stesso, che anzi, essendo espressione efficace dei nostri obiettivi, deve essere garantito di qualità eccellente. Nel corso dell’ultimo anno però ho potuto riflettere parecchio sul legame tra (sviluppo) software e user experience e sono quindi giunto ad una conclusione ulteriore, che integra quelle precedenti, estendendole.

Io credo che l’intero concetto di software sia in realtà un concetto collaterale. Noi sviluppatori vendiamo sì manovrabilità, ma non per ottenere software come prodotto finale. L’elevata qualità del nostro prodotto, il codice – che a questo punto scopriamo essere un semilavorato – serve infatti a garantire il successo del prodotto finito vero e proprio: la user experience. Il flusso di cassa diventa positivo nel momento esatto in cui il primo utente vive con successo l’esperienza che il nostro software contribuisce a realizzare. Non un solo attimo prima.

Una prova del 9 semplice semplice? Prova a sviluppare del software e a non farlo usare mai a nessuno. Pensi possa valere qualcosa?

10. Change Your Idea

To benefit from engaging with users you have to be willing to change your idea. We’ve always encouraged founders to see a startup idea as a hypothesis rather than a blueprint. And yet they’re still surprised how well it works to change the idea.

Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that’s easy for you to solve. Optimizing in solution-space is familiar and straightforward, but you can make enormous gains playing around in problem-space.

Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum:

When someone is determined, there’s still a danger that they’ll follow a long, hard path that ultimately leads nowhere.

You want to push forward, but at the same time twist and turn to find the most promising path. One founder put it very succinctly:

Fast iteration is the key to success.

One reason this advice is so hard to follow is that people don’t realize how hard it is to judge startup ideas, particularly their own. Experienced founders learn to keep an open mind:

Now I don’t laugh at ideas anymore, because I realized how terrible I was at knowing if they were good or not.

You can never tell what will work. You just have to do whatever seems best at each point. We do this with YC itself. We still don’t know if it will work, but it seems like a decent hypothesis.

Mi sembra evidente che qui si alluda ad una serie di valori e principi ampiamente previsti ed esaltati nel compendio culturale dei metodi agili.Ci sono riferimenti alla capacità di accogliere il cambiamento, alla necessità di iterazioni strette per avere feedback frequente e via dicendo.

Il passaggio che mi ha colpito di più però è questo

Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that’s easy for you to solve. [...] Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum

Trovo importantissimo ribadire l’importanza di uno scope mutevole che ci permetta di ridefinire il problema (il backlog, il lavoro da fare) dinamicamente per poi trovare soluzioni possibili. Un po’ come poter correggere la rotta di una nave deviata da una forte corrente. Un po’ anche come capire definitivamente la differenza fra indaffarato e produttivo.

Un professore, prima di iniziare la sua lezione di filosofia, pose alcuni oggetti davanti a sé, sulla cattedra. Senza dire nulla, quando la lezione iniziò, prese un grosso barattolo di maionese vuoto e lo riempì con delle palline da golf. Domandò quindi ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.

Allora, il professore rovesciò dentro il barattolo una scatola di sassolini, scuotendolo leggermente. I sassolini occuparono gli spazi fra le palline da golf. Domandò quindi, di nuovo, ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.

Il professore, rovesciò dentro il barattolo una scatola di sabbia. Naturalmente, la sabbia occupò tutti gli spazi liberi. Egli domandò ancura una volta agli studenti se il barattolo fosse pieno ed essi risposero con un sì unanime.

Il professore tirò fuori da sotto la cattedra due bicchieri di vino rosso e li rovesciò interamente dentro il barattolo, riempiendo tutto lo spazio fra i granelli di sabbia. Gli studenti risero!

“Ora”, disse il professore quando la risata finì, “vorrei che voi consideraste questo barattolo la vostra vita. Le palline da golf sono le cose importanti; la vostra famiglia, i vostri figli, la vostra salute, i vostri amici e le cose che preferite; cose che se rimanessero dopo che tutto il resto fosse perduto riempirebbero comunque la vostra esistenza.”

“I sassolini sono le altre cose che contano, come il vostro lavoro, la vostra casa, l’automobile. La sabbia è tutto il resto, le piccole cose.”

“Se metteste nel barattolo per prima la sabbia”, continuò, “non resterebbe spazio per i sassolini e per le palline da golf. Lo stesso accade per la vita. Se usate tutto il vostro tempo e la vostra energia per le piccole cose, non vi potrete mai dedicare alle cose che per voi sono veramente importanti.

[...]

Un po’ come le feature marginali o addirittura inutili che occupano tempo e testa degli sviluppatori al posto delle core feature. Un po’ come assegnare sempre la priorità più alta ai task che promettono una conclusione più immediata tentati dalla possibilità di sembrare più produttivi.

Un po’ come rinunciare alla gallina oggi per l’uovo domani.

p.s. ho scoperto che odio la retorica un po’ new age delle catene di Sant’Antonio…

La teoria della complessità ci insegna che comportamenti complessi possono emergere da sistemi costituiti da agenti semplici in relazione tra di loro in virtù di regole semplici. Craig Reynolds può introdurti a questi concetti sul web con spettacolari sciami virtuali.

Bene. Poniamo ora un team soggetto a queste due regole:

1. ogni sviluppatore – ogni coppia – deve fare commit del codice solo a test verdi sulla sua macchina
2. ogni sviluppatore – ogni coppia – deve prendersi carico della risoluzione dei conflitti che incontrerà al momento del proprio commit

È evidente che la probabilità di avere conflitti nel codice tende a 1 col passare delle ore; i commit degli altri sviluppatori infatti avranno sempre maggiori possibilità di introdurre linee di codice non integrabili automaticamente con le nostre. Questo dato sommato al fatto che eventuali conflitti su poche righe sono comunque preferibili a conflitti su interi moduli del nostro software fanno sì che ogni sviluppatore sarà quindi fortemente incentivato a fare frequenti commit che, in virtù della prima regola, non violeranno la stabilità della repository. Abbiamo quindi introdotto con queste due semplici regole una delle pratiche più preziose del contesto agile: la continuous integration.

Spesso introdurre pratiche nuove nei team può essere complicato anche quando il vantaggio che ne deriverebbe può essere facilmente dimostrato. Individuare regole molto semplice e deburocratizzanti può essere molto utile ad indurre i giusti comportamenti nel team di sviluppo con una redditività molto elevata, anche – perché no – in termini di morale.

I find way too many companies after each iteration still trying to close things down in order to get this potentially shippable code shipped. More often than not there’s on-going QA etc long after the iteration is over. This is not a healthy state of affairs.

Credo sia un’ottimo spunto di riflessione da incrociare e mediare dopo aver letto questo post di Francesco Trucchia.

Il problema è ben articolato: da una parte il bug fixing non è valore consegnato al cliente - repetita juvant; dall’altra un iteration plan sovraccarico è il tipico sintomo di un cliente avido che non lascia al team lo spazio di manovra necessario a produrre quel valore tanto agognato e, chiaramente, di un team in posizione di debolezza rispetto al cliente.

Continuo a credere che alcune mie vecchie passioni da ingegnere gestionale ritrovate poi nel Lean Software Dvelopment possano essere la risposta a questo tipo di situazioni. Devo rifletterci ancora un po’…

Gabriele fa riferimento nella sua mail al rigore di un processo, all’autorità all’interno di un team e alle buone pratiche scrivendo:

Durante il primo stadio dell’apprendimento (di qualsiasi cosa) si
devono seguire delle regole per non farsi male e per non fare male,
non c’è molto spazio per la democrazia, se fossi sotto i ferri e ci
fosse un team di medici pronti ad operarti vorresti che per democrazia
vincesse il “per questa volta non ci laviamo le mani prima di
operare”?

Leggere queste righe mi ha fatto subito pensare che avevo intenzione da un po’ di parlare di buone pratiche e di processi di decisione nei gruppi facendo riferimento al dottor Ignác Fülöp Semmelweis, noto come il Salvatore delle madri.

Semmelweis è amaramente celebre per aver scoperto che l’elevata incidenza di febbre puerperale tra le partorienti della sua epoca era dovuta alla scarsa igiene dei medici. Semplicemente i medici non si lavavano le mani, ciò causava un alto tasso epidemico nei reparti ospedalieri e di conseguenza un’alta mortalità tra le pazienti. Fin qui, oggigiorno, nessuna sorpresa. Ti potrai chiedere quindi perché la sua sia stata una storia amara.

Semplicemente i colleghi di Semmelweis decisero di non credere alle sue parole. Anzi, peggio, di non credere ai numeri che Semmelweis portò in sostegno ai suoi argomenti. Lo isolarono, lo screditarono e, sebbene in qualche occasione Semmelweis riuscì anche ad implementare i protocolli igienici che salvarono già in quelle prime occasione vite preziose, il riconoscimento dovuto alle ricerche del medico ungherese arrivarono solo postumi. Addirittura il povero Semmelweis venne estromesso dalla comunità scientifica dell’epoca in virtù di un risentimento diffuso nella classe medica dell’epoca: noi medici causa di queste morti??? Non ci si permetta!

Purtroppo anche in quell’occasione la maggioranza ebbe la meglio, perlomeno in prima battuta – ad un costo comunque alto, anche fosse stato di una sola vita umana.

Il regime democratico assiste spesso ad una sua degenerazione verso un mero criterio numerico maggioritario: “siccome siamo tanti a dire questa cosa, abbiamo ragione sicuramente; tanta gente non può sbagliarsi tutta insieme.” Una specie di principio di autorità distribuito, con tutti i difetti dialettici tipici del principio di autorità.

Nello sviluppo agile si centra molta dell’attenzione sulla condivisione delle responsabilità e delle decisioni e si punta a non ignorare nemmeno le sensazioni che le persone, poste al centro del processo di sviluppo, devono usare come spunto per andare avanti, motivarsi, analizzare la qualità di ciò che si fa e di come lo si fa. Questo potrebbe indurre a pensare che si possa quindi

1. dirigere i nostri sforzi solo dove ti porta il cuore
2. ignorare l’oggettività di dati rilevati, anche solo qualitativamente

E invece no! Un solo membro del team che misurasse con precisione sufficiente e in base ad una metrica valida che una scelta di processo porta dei concreti vantaggi al progetto su cui si lavora basterebbe da solo a controvertire il parere congiunto di una muraglia di colleghi più istintivi.

Per questo l’adozione dei metodi agili può essere così ardua nelle aziende che non siano nativamente basate su queste metodologie: perché richiedono l’adozione di un compendio culturale ed etico che deve necessariamente essere presupposto del processo e non conseguenza del processo stesso. Un compendio che permetta da una parte l’individuazione delle vere sorgenti dei problemi, con franchezza, onestà e, perché no, spirito di sacrificio, dall’altra di essere rigorosi quanto basta perché si possa essere certi che la mancanza di risultati sia dovuta ad una vera inappropriatezza di una data pratica al contesto di applicazione e non all’imprecisione nell’attuazione.

Si tratta di essere disposti a guardare in faccia lo stato delle cose, qualunque verità rischi di saltare fuori. Il movimento open source, esponendo il codice e i relativi bug, ci ha abituati al successo di questo approccio riguardo la qualità del codice. Non credi che per la qualità del processo di sviluppo esistano altrettali margini di miglioramento?