27 Giugno 2019
A serendipitous journey in an uncertain world

Bentrovati cari lettori,

oggi vorrei raccontarvi la storia di un viaggio, narrato dal collega Marco Testa.
Un viaggio non come quello che siete soliti immaginarvi in chissà quale meravigliosa località, bensì un viaggio in un mondo incerto, complicato. Come può essere quello dei progetti software.

Alla ricerca dell’essenza della Programmazione Orientata agli Oggetti affronteremo, malgrado i nostri limiti cognitivi, il demone della complessità, guidati dalla mappa Cynefin, scoprendo i valori, i princìpi e le pratiche dell’Extreme Programming.

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à 😉

Tag
A serendipitous journey in an uncertain world

Il racconto dell'esperienza di viaggio del collega Marco Testa nell'incerto mondo dei progetti software

Agile Venture Vimercate 2019

Il racconto della giornata di conferenza tenutasi a Vimercate.

Gildonferenze – Marzo 2019

Resoconto delle conferenze del 12 Marzo e 19 Marzo per approfondire alcuni temi trattati durante le ultime gilde.

Intré Camp – 5 Marzo 2019

Racconto del camp aziendale svoltosi ad Arcore, agriturismo La Bergamina.

IAD Brescia – 10 Novembre 2018

Racconto della giornata di conferenza svoltasi presso l'Università degli Studi di Brescia.

Intré Camp – 30 Ottobre 2018

Racconto del camp aziendale svoltosi a Erba, castello di Casiglio.

Intré Camp – 26 Giugno 2018

Racconto del camp aziendale svoltosi all'agriturismo La Camilla

Agile Venture Prato 2018

Il racconto della giornata della prima edizione di un agile venture in quel di Prato.

A reactive programming example
Milan Kotlin Community Conf

The first Kotlin related Italian conference made from the community to the community!

Let's see how was it...

DroidCon IT, Turin, 19 & 20 April 2018: our report
Milan Kotlin Community Conference

How, why and what has lead us to the Milan Kotlin Community Conference.

Intré Camp – 13 Febbraio 2018

Racconto del camp aziendale svoltosi a Pontida, agriturimo Polisena

Vert.x – 4o articolo su Mokabyte!

4o articolo sul mondo Vert.x a cura di Marco

Vert.x – 3o articolo su Mokabyte!

3o articolo sul mondo Vert.x a cura di Marco

NoSlidesConf 2017

NoSlidesConf: una conferenza diversa dal solito

Vert.x – 2o articolo su Mokabyte!

2o articolo sul mondo Vert.x a cura di Marco

Vert.x – 1o articolo su Mokabyte!
IAD Urbino 2017 – Conferenza 18 Novembre

Racconto della conferenza presso l'università degli studi Carlo Bo di Urbino

IAD Urbino 2017 – Unconference 17 Novembre

#IAD17: Racconto della giornata di unconference presso l'Università degli Studi Carlo Bo di Urbino

Intré Camp – 5 Ottobre 2017

Racconto del camp aziendale svoltosi all'agriturismo La Camilla

Intré Camp – 18 Maggio 2017

Resoconto del camp aziendale svoltosi all'Oasi di Galbusera Bianca

CloudConf Torino 2017

CloudConf 2017 a Torino. Come è andata?

Mini IAD Vimercate 2017

Il racconto della giornata al Mini Italian Agile Day tenutasi a Vimercate.

Codemotion Milano 2016

Nel week-end del 25-26 novembre 2016 si è svolto il Codemotion Milano 2016.
Francesco Sacchi e Ferdinando Santacroce ci raccontano com'è andata.

Angular Conf 2016

Il racconto della nostra giornata alla Angular Conf 2016 a Torino, sia come spettatori e soprattutto come sponsor.

Intré Camp – 3 Novembre 2016

Un racconto di come è andata la nostra giornata di team building, tra sorrisi e battaglie ;)

Node.Js Italian conference – V edition

Cronistoria sulla nostra partecipazione alla 5^ edizione della Node.Js Italian Conference, con tante belle foto, stickers e...leggete :)

Business24 TV: Fabio Ghislandi presenta Intré

In questo breve intervista viene presentata Intré e il suo innovativo approccio allo sviluppo di software.

Come cambia il mondo dei linguaggi
WebRTC – #1 Video-Chat in javascript

Con la tecnologia WebRTC (Real Time Communication www.webrtc.org) è possibile integrare, all’interno di applicazioni che comprendono javascript, funzionalità di audio e video-chat, registrazione chat, condivisione schermo e signaling.

Future e Promise in Scala

Primo post sulla programmazione in Scala dedicato a future e promise, due costrutti fondamentali per la programmazione concorrente.

Come inviare dati live da un’applicazione C# Desktop al web usando le WebSocket

Questa è una guida passo passo su come esporre dati live da un'applicazione C# console ad un web browser usando le WebSocket. L'esempio è stato testato su Windows 7.

IOS Push notifications iOS 6 con Sencha Touch 2.2

Se state cercando di inviare una Push Notification al vostro iOS6 iPhone/iPad usando Sencha Touch 2.2 probabilmente avrete incontrato diversi problemi. In questo articolo vedremo passo passo come configurare i certificati, impostare il file Sencha package.json ed inviare una push notification con uno script PHP o C#.

Creare una issue in Jira con i sub-task predefiniti

E' possibile programmare script in Atlassian Jira usando Groovy. Questi script possono essere eseguiti allo scattare di un evento come alla creazione di una issue o al suo aggiornamento. Sfruttando questo principio vediamo come creare uno script che crea i sub-task in automatico alla creazione di una Issue.

Lego controllato con Cloudfoundy via WebSockets

Questo è un breve test di come è possibile controllare Lego Mindstorm con Cloudfoundry usando HTML5 e WebSockets.

Beaglebone how-to. Come cambiare lo stato di una pagina web premendo un pulsante con node.js

Questo articolo descrive come intercettare l'interrupt GPIO di una beagle bone e aggiornare, via web sockets, una pagina web usando node.js.

youSCADA presentato al Graphical Web 2012

Come controllare e monitorare i device usando una piattaforma Cloud? La soluzione è stata presentata al Graphical Web 2012 a Zurigo.

Chiamare una REST API con node.js

Node.js sta rivoluzionando il modo di programmare le piattaforme software. Basato sul Google V8 JavaScript Engine permette di scrivere codice lato server in JavaScript.

Top
Ogni nostro Sprint ha l'obiettivo di massimizzare il Valore per l'utente finale
Il tuo browser non è aggiornato!
Aggiornalo per vedere questo sito correttamente.Aggiorna ora

×