Serendipità: un viaggio nell’incerto mondo dello sviluppo software

Mettetevi comodi quindi, come abbiamo fatto noi tra le gradinate del nuovissimo spazio da poco inaugurato nella sede di Seriate.
Uno spazio dedicato a chiunque voglia proporre workshop, presentazioni, meetup e chi più ne ha più ne metta 🙂

Perchè serendipitous?

Il termine, che in italiano è tradotto in serendipità, indica la fortuna di fare felici scoperte per puro caso e, anche, il trovare una cosa non cercata e imprevista mentre se ne stava cercando un’altra.
Il termine fu coniato dallo scrittore Horace Walpole.

Walpole spiegò una scoperta inaspettata che aveva fatto su un dipinto perduto di Bianca Cappello di Giorgio Vasari con riferimento alla fiaba persiana Tre prìncipi di Serendippo di Cristoforo Armeno.
Nel suo racconto, i tre protagonisti trovano sul loro cammino una serie di indizi, che li salvano in più di un’occasione.
La storia descrive le scoperte dei tre prìncipi come intuizioni dovute sì al caso, ma anche alla loro sagacia, uno spirito acuto e alla loro capacità di osservazione.

Torniamo a noi.
Pensiamo al viaggio nella sua accezione più classica.
C’è chi lo intende come il periodo durante il quale vuole rilassarsi senza dover pensare a nulla, magari vicino casa o comunque senza fare sforzi.
C’è poi chi cerca qualcosa sì di rilassante ma esotico, in posti lontani. Per organizzarlo quindi è bene rivolgersi ad agenzie viaggio, a persone esperte del posto.
C’è chi per viaggio cerca un’esperienza movimentata, avventurosa (in qualche giungla, o isola disabitata). In questi casi non basta affidarsi ad esperti, possono sorgere imprevisti.
Infine c’è il viaggio più brutto, più pericoloso…quando si deve abbandonare la propria casa in cerca di una sistemazione e una vita più tranquilla.

Quattro tipi di viaggio, quindi.

Quali elementi ci aiutano a differenziarli?

• la conoscenza che si ha o meno relativamente al posto in cui sto andando
• il numero di elementi coinvolti nel viaggio. Un conto è prenotare un unico albergo, un altro è prenotare più alberghi e voli interni per spostarsi tra una meta e l’altra del viaggio
• la predicibilità, o prevedibilità, degli eventi che possono accadere
• il rischio, basso quando si decide di andare nel solito posto di ogni anno perché siamo nella nostra comfort zone, o più alto quando si decide di visitare una nuova località
• profitto, in termini di nuovi posti ed esperienze acquisite quando si fa un viaggio in un posto nuovo. Dopotutto se si fa una cosa semplice raramente si trae vantaggio. Più rischioso è, meglio è.

Considerando questi elementi e le quattro tipologie di viaggio, potremmo provare a classificarli.
Avvaliamoci del modello Cynefin:

Nel primo dominio, quello dell’OVVIO, tutto è evidente, non ci sono sorprese. Una villeggiatura in un villaggio turistico, o in un albergo a mezza pensione.
Vedo, categorizzo il problema che è noto, e lo risolvo.
In questa situazione, ciò che si fa si riassume in 3 parole sense-categorize-respond: stabilire i fatti , categorizzare, quindi rispondere seguendo la regola o applicando delle best practice.

Nel dominio COMPLICATO, o dominio delle cose sconosciute, la connessione tra causa ed effetto è più complicata, richiede analisi ed esperienza. Ma si riesce a dare una prevedibilità.
E’ raccomandato agire secondo il sense-categorize-respond: valuta i fatti, analizza e applica le buone pratiche operative appropriate.

Nel dominio COMPLESSO, o dominio delle incognite sconosciute, c’è una parte di imprevedibilità che complica tutto. Causa ed effetto possono essere dedotti solo in retrospettiva e non ci sono risposte giuste.
Come scrive Snowden “I modelli istruttivi … possono emergere se il leader conduce esperimenti che sono sicuri di fallire“. Questo dominio è anche conosciuto come probe-sense-respond, cioè bisogna fare prove, sperimentare per trovare la soluzione.

Infine abbiamo il dominio CAOTICO. Causa ed effetto non sono chiari e l’imprevedibilità è massima. Act-sense-respond, cioè agire per prima cosa, non c’è tempo per pensare.
Per quanto si faccia analisi, ci si prepari, può sempre accadere qualcosa di imprevedibile.
Tornando all’analogia dei viaggi, si fugge dalla propria casa per una situazione di pericolo improvvisa. La prima cosa da fare è scappare.

Ora che abbiamo capito come utilizzare il modello Cynefin, come applicarlo al contesto dei progetti software?

Marco porta come esempio di un progetto semplice, ovvio, quello di una pagina internet statica da realizzare. Nulla è ignoto, sappiamo come realizzarla. Esistono diversi template, ne adottiamo uno e la implementiamo.
Passando al dominio complicato, pensiamo a tutti quei progetti in cui il dominio è prettamente informatico. Che cosa sia un server web lo sa lo sviluppatore, non ad esempio il chirurgo che usa il sito web.
Il problema subentra qualora il chirurgo chieda un nuovo software. I 2 mondi devono parlarsi, incontrarsi, confrontarsi. E qui si può avere imprevedibilità.
Nel caso in cui sviluppatore ed esperto del dominio non dovessero coincidere, ci troveremmo nel dominio complesso.

Relativamente al dominio del caos, ne fanno parte tutti quei progetti appartenenti ad un dominio ma che vengono affrontati e gestiti in un altro dominio. Per intenderci, un progetto OVVIO gestito come se fosse COMPLICATO.

Come possiamo gestire i progetti nel dominio caotico?
Marco propone la visione del video Monkey business illusion, durante il quale si chiede di contare quante volte la squadra bianca si passa la palla.
Impegnati a contare il numero di passaggi, magari non ci si accorge del passaggio di un gorilla e/o del fatto che un componente del team nero lasci il gioco.
Potrebbe quindi essere un problema di attenzione. Magari concentrati su un particolare, perdiamo di vista il contesto e viceversa.

Ancora una volta, pensiamo ad un progetto informatico come un viaggio nella giungla. Che attitudini mentali dovremmo avere?

• Serve una grossa attenzione verso il feedback. Dobbiamo avere più informazioni possibili sugli strumenti che ci servono, dove dobbiamo andare. Bisogna mettersi nella condizione di ricevere tanti feedback
• Cercare ed implementare soluzioni più semplici possibili, quindi avvalersi di strumenti semplici da usare
• Cercare di comunicare il più possibile
• Avere coraggio. L’imprevedibilità può spaventare, va affrontata
• Avere rispetto. Proprio perché il risultato non è scontato, dobbiamo avere rispetto di tutti i componenti del progetto
• Avere fiducia. Deve esserci fiducia in tutte le persone coinvolte. Quando si presenterà il problema, il mio compagno mi affiancherà?

Quali princìpi andrebbero messi in pratica?

• Umanità. Meglio una chiacchierata che il documento scritto
• Economia. Rendere economicamente utile il progetto
• Mutui benefici. In un gruppo allargato, è bene che tutti gli stakeholder abbiano benefici
• Self-similarity. Un progetto deve essere senso in diversi ambiti. Un feedback settimanale è utile? Allora lo è anche un feedback giornaliero
• Improvement. Cercare sempre di migliorarsi, cercando di fare il meglio quotidianamente
• Diversità. Se ci sono delle cose non chiare, magari c’è bisogno di attitudini e punti di vista diversi. Se un team è troppo omogeneo in questo senso, si rischia di rilassarsi su un’attitudine simile
• Riflessione. Guardarsi dentro, dare feedback su se stessi
• Flusso di valore. Far sì che il lavoro continui a fluire
• Opportunità. Essere sempre pronti a cambiare soluzione non appena si presenta un’opportunità
• Ridondanza. Meglio avere più soluzioni che concentrarsi su un’unica
• Fallimento. Fallire è un valore, perché dà informazioni su una strada sbagliata. Prima si fallisce, meglio è
• Qualità. Dobbiamo avere l’attrezzatura giusta. Una volta che ce l’abbiamo, non abbiamo più scuse. Lavoriamo al meglio, nel nostro caso…cerchiamo di non lasciare bug in giro
• Piccoli passi. Meglio fare piccoli passi, semplici ma di valore
• Accettare la responsabilità

E per un progetto software, quali sarebbero i princìpi da adottare secondo Marco?

• Sedersi assieme. Il team dovrebbe lavorare in uno stesso luogo, questo favorisce la comunicazione diretta
• Tutto il team insieme. Non solo sviluppatori, ma anche il product owner ad esempio
• Spazio di lavoro il più possibile volto verso il feedback, mettendo in evidenza tutto tramite post-it, oppure utilizzare board costantemente aggiornate
• Lavoro energico. Essere sempre riposati per poter dare il massimo. Inutile lavorare 12 ore al giorno, magari anche la sera.
• Applicare il più possibile pair programming
• Tradurre i requisiti in storie comprensibili a tutti gli stakeholder
• Organizzarsi in cicli di durata variabile (settimanali, bisettimanali, quadrimestrali) dipendentemente dalla durata del progetto
• Agio. Darsi del tempo per gestire l’imprevedibile
• Le build devono durare poco. Forniscono feedback, quindi è bene che debbano durare pochi minuti
• Continuous integration
• Scrivere prima i test e poi il codice
• Pensare ad un design incrementale. Ciò che va bene oggi non sopravviverà a lungo

Tutte queste pratiche hanno senso se ancorate a dei valori.

Fate attenzione alla seguente storia.

In Melanesia, durante la seconda guerra mondiale, le truppe costruirono molte basi militari.
Su queste isole arrivavano quindi enormi quantità di materiale e viveri, scaricate dagli aerei cargo.
Potete immaginarvi lo stupore dei nativi, i quali vedevano questi enormi oggetti far cadere ogni bene possibile dal cielo.
Finita la guerra però, le truppe sbaraccarono e tutto tornò come prima.
Gli abitanti delle isole si riorganizzarono affinché il cielo continuasse a rifornirli. Per farlo, realizzarono riproduzioni grossolane di piste di atterraggio, aeroplani e radio e persino imitazioni del comportamento osservato presso il personale militare che aveva operato sul luogo. Un vero e proprio culto del cargo, meglio noto come cargo cult.

Perché Marco ci ha raccontato questa storia?
Pensiamo al lavoro quotidiano, a quando facciamo il daily scrum. Qualora venisse fatto senza cogliere il valore che porta al progetto, potrebbe essere tranquillamente paragonato ad un cargo cult.
Non ha senso parteciparvi se non si è convinti, non si ha coraggio di dire se ci sono difficoltà.
Riconosciamo quindi il valore dietro ogni nostra pratica, ne va del bene nostro e del progetto.

Alla base di tutto comunque c’è il codice. Perlomeno per chi come me o Marco è sviluppatore software 🙂
Scriviamo e produciamo codice, ed in qualche modo questo codice prodotto deve rispecchiare dei valori. Deve darci feedback. Bisogna essere coraggiosi nel volerlo cambiare. Deve ispirare fiducia.

Ma come possiamo scrivere codice comprensibile?

Marco ci mostra un video relativo a 3 figure geometriche che si muovono in uno spazio.
Al termine del video, ha chiesto al pubblico cosa volesse significare.
C’è chi ha risposto facendo analogie con branch di codice, chi ha visto una lotta tra figure geometriche…il video, ideato da 2 psicologi, vuole dimostrare che agli esseri umani piacciono le storie e che vedono ovunque storie.

Ecco, STORIE.

Quante volte ci è capitato di scrivere o dover gestire codice complicato, magari un metodo lungo diverse centinaia di righe, o composto da tanti if-else.
Più è complicato e più è alto il carico cognitivo. L’attenzione e la memoria a breve termine si logorano.

Ma ci piacciono le storie. Perché quindi non cercare di gestire il progetto come una narrativa e di conseguenza scrivere codice migliore?

Diversi progetti hanno una struttura a 3 atti, o three-act-structure:

• Setup
• Confrontation
• Resolution

Perché non scrivere il software come se fosse una storia, seguendo un modello narrativo fatto di soggetto, stato e trasformazione? Si avrebbe quindi un programma narrativo.

Pensiamo ai linguaggi di programmazione Object Oriented, come Java.
E’ possibile avere entità più o meno autonome che si scambiano messaggi.
Dato che ci piacciono le storie e spesso ne facciamo uso, dovremmo riuscire a scrivere codice come se stessimo scrivendo una storia. Magari che verrà letta da qualcun altro.
Marco ha mostrato l’esempio di uno scenario di uno script di una macchinetta erogatrice di bevande e merendine:

Ogni entità è chiara ed è esplicitato in maniera chiara quali azioni può compiere e come comunica con altre entità.
La lettura è scorrevole, come quella di una storia. Va da sé pensare che il codice che ne scaturisce può essere altrettanto chiaro e semplice.

Purtroppo termina qui il viaggio.
Un viaggio che ci fa sentire tutti un po’ più confidenti di poter gestire al meglio i nostri progetti mettendo in pratica princìpi e pratiche, senza dimenticare però chi siamo.
Siamo sviluppatori, perciò il nostro contributo, il valore che generiamo è il codice del software. Abituiamoci a scriverlo in maniera più semplice e descrittiva possibile. Come se fosse una storia. A lieto fine, si spera 🙂

Grazie Marco!

E al prossimo viaggio…chissà 😉