La nostra unconference all’Intré Virtual Camp di febbraio 2022

Unconference

Basata sulla metodologia Open Space Technology, una unconference (o open conference) è una conferenza la cui agenda è organizzata al momento. L’idea è che le proposte arrivino dal basso, dai partecipanti stessi, affinché si abbiano argomenti tutti di reale interesse. Non solo argomenti da proporre, ma anche richieste di aiuto, dubbi, spunti che possano generare una discussione costruttiva.

Esiste una sola legge, la Legge dei due piedi, ossia che abbiamo il dovere di andare dove possiamo trarre/apportare valore, e si basa su quattro principi:

• Quando comincia è il momento giusto.
• Chiunque venga è la persona giusta.
• Quando è finita, è finita.
• Qualsiasi cosa accada, è l’unica che poteva accadere.

Come i calabroni e le farfalle, i partecipanti sono liberi di spostarsi di stanza in stanza, trasportando in questo caso informazione e conoscenza.

La nostra unconference…virtuale

Alessandro Giardina, nostro Agile Delivery Manager (se volete saperne di più, vi invito a iscrivervi a questo gruppo LinkedIn) e cerimoniere ufficiale delle unconference, ha curato l’evento avvalendosi di Miro e Microsoft Teams per le stanze virtuali. Brevemente, Miro è una online collaborative whiteboarding platform che consente a team distribuiti di lavorare efficacemente insieme, dal brainstorming con sticky notes digitali alla pianificazione e gestione di flussi di lavoro Agili. Miro mette a disposizione una serie completa di funzionalità di collaborazione tra cui video, chat, presentazione e condivisione, per rendere più semplice il lavoro cross-funzionale di team e semplificare la collaborazione.

Come è organizzata la whiteboard della nostra unconference?

Alessandro, con l’aiuto del collega UX/UI designer Giacomo Nava, ha allestito quattro spazi ben definiti.

• Marketplace, contenente immagini evocative dei quattro principi e la regola dei due piedi, e appunto la scaletta dell’unconference con le sessioni proposte.
• Parking lot, un vero e proprio parcheggio di tutte le proposte fatte e magari scartate.
• Una tabella che rappresenta l’agenda. Tante colonne quante sono le stanze virtuali e solitamente sette righe che scandiscono i tempi dell’unconference: apertura, due sessioni di talk, coffee break, altre due sessioni, e chiusura dell’evento.
• Feedback, con tre poster per collezionare pareri positivi e negativi, basato sullo schema Mad Sad Glad.

Il resto della whiteboard è a disposizione dei partecipanti per creare qualunque nota relativa a spunti acquisiti, link a slide o altro materiale inerente alle sessioni.

Qual è l’agenda della nostra unconference?

Dopo una fase introduttiva in cui Alessandro spiega il format per i nuovi, vengono dedicati 15 minuti per proporre i talk/discussioni/domande in cerca di risposta.
Terminato questo momento si entra nella fase di introduzione delle proposte e marketplace per decidere, in accordo con tutti i partecipanti, il luogo e il momento migliore per dare vita a ogni sessione.
Come accennato prima, ognuna delle quattro stanze è rappresentata da una room con Microsoft Teams. Il link a ogni stanza virtuale è raggiungibile dall’intestazione della colonna della tabella nel marketplace.

Coppa Sapiens

Il nome di questa competizione, pensata da Marco Loregian, prende il nome dalla piattaforma Web, i3 Sapiens appunto, sviluppata nel corso di due nostre gilde e con lo scopo di avere uno strumento per la valutazione delle skill tecniche in stile Codewars. La piattaforma viene utilizzata sia internamente (durante un colloquio) che esternamente, con approccio gamification (per ogni problema risolto si guadagna un badge).

La competizione, aperta a tutti gli invitati, è durata all’incirca 20 minuti, il tempo del coffee break.

Ogni partecipante ha risolto il problema utilizzando uno dei tre linguaggi supportati dalla piattaforma (Java, JavaScript, Python) scrivendo il codice direttamente nella piattaforma – nella quale è innestato un editor – oppure utilizzando il proprio IDE abituale, purché il codice girasse obbligatoriamente su i3 Sapiens.

Al termine della unconference Marco ha annunciato i tre vincitori: il più veloce a risolvere il problema, il poliglotta (chi lo ha risolto con tutti e tre i linguaggi) e il più veloce tra gli under 30.

Bravi tutti!

Main Room

Di che cosa si è parlato nella sala principale di questa prima unconference del 2022?

• “Continuous Delivery e Continuous Deployment“: Raffaele Colace, uno dei nostri graditi ospiti, ci racconta la sua esperienza con le pratiche CI/CD.
• “GIT“: Francesco Sacchi dimostra le potenzialità di git, il famoso tool per il controllo di versione del software.
• “Agile Product Management“: Fabio Ghislandi, Executive Agile Coach nonché partner di Intré, cura un excursus sulla gestione di un prodotto secondo la metodologia Agile.
• “Test“: Giacomo Giovenzana e Alberto Acerbis, insieme a Ferdinando Santacroce, nostro amico e ospite, trattano la tematica del test del software.

Continuous Delivery e Continuous Deployment

Raffaele ha aperto la sessione sulla Continuous Delivery mostrando un video su 20tab-standard-project, la soluzione sviluppata da lui e i suoi colleghi in 20tab s.r.l. per l’automatizzazione di tutti quei task che porterebbero via tempo a ciò che dà realmente valore a un progetto: lo sviluppo di codice. Che cosa mostra il video? Eseguendo una riga di comando si scarica il progetto base, viene poi fatto il setup in locale e vengono creati i due servizi principali, frontend e backend, e un orchestratore Kubernetes, dopodiché il tutto viene deployato su GitLab. Per chi volesse approfondire, è disponibile il video su YouTube dove Raffaele spiega la configurazione e l’utilizzo del pacchetto.
Da questa presentazione è nata una discussione sulle best practice della Continuous Delivery.

GIT

Git è uno strumento che gli sviluppatori utilizzano durante il lavoro, e per molti è un automatismo. Alcuni però lo utilizzano solo tramite IDE e non sono in grado di sfruttarne le potenzialità da riga di comando perché carenti delle nozioni che stanno alla base. Durante il talk Francesco ha affrontato i concetti fondamentali di git:

• commit;
• puntatore HEAD;
• navigazione tra i commit;
• branch.

Altri concetti importanti quali push, pull, fetch non sono stati affrontati per limitazioni temporali, magari verranno approfonditi alla prossima unconference in una seconda parte di questo interessante talk.

Agile product management

Questa discussione moderata da Fabio è iniziata con una semplice domanda posta alla platea: “Che cosa è un prodotto?”.
Da qui Fabio ha introdotto la tematica vedendola da un punto di vista Agile: “Un prodotto è un oggetto di valore che risponde ai bisogni dell’utente”. In Agile, un prodotto è l’elenco minimo di funzionalità che risolvono i bisogni dell’utente.
In primo luogo, bisogna mettere al centro l’utente e il suo punto di vista. Dopodiché si inizia a lavorare, in maniera iterativa e incrementale, coinvolgendo continuamente il cliente per ottenere feedback che ci permettono di realizzare un prodotto che davvero soddisfi le sue esigenze.
Fabio identifica tre zone:

• zona di controllo: il prodotto software sul quale lavoriamo;
• sfera di influenza: attraverso il prodotto influenziamo il comportamento del cliente;
• contesto esterno.

Attraverso la User Story mettiamo l’utente al centro e individuiamo il tipo di azione che l’utente vuole e il cambio di comportamento. Tutte le User Story vengono impilate, in ordine di valore che apportano al progetto, in un Backlog dal quale si attinge sprint dopo sprint.
A seguito della presentazione di Fabio è nata una discussione interessante e ricca di esperienze portate non solo da sviluppatori ma anche da UX designer come Urszula Anatriello e Alejandra Ponce.

Test

In quest’ultima sessione della Main Room si è parlato di test del software trattando due tematiche molto importanti.

• Specification test, per testare il comportamento e non le funzionalità.
  Questa tipologia può essere utile anche per le app nel cloud in quanto l’obiettivo di questi test è verificare che il software soddisfi ciò che ci aspettiamo, non le funzionalità interne. Utilizzando il paradigma Gherkin (“Given…When…Then…“) lo specification test risulterebbe comprensibile a tutti, non solo agli sviluppatori. Esistono diversi framework per la scrittura di questi test, per esempio SpecFlow per il mondo .NET e Cucumber per Java.
• Testing di applicazioni distribuite, in particolare l’approccio “Chaos Enginering” (il link rimanda a un mio articolo di una presentazione sul tema organizzata da Alberto Acerbis per un meetup di XPUG Bergamo) ideato da Amazon e implementato anche da Netflix. L’idea che sta alla base del Chaos Engineering è di contenere il caos appunto che si potrebbe generare qualora alcuni microservizi di un sistema distribuito risulterebbero non raggiungibili. Per questo motivo vengono effettuati i cosiddetti monkey test che rendono appunto irraggiungibili un numero randomico di microservizi di un’applicazione distribuita per verificarne la robustezza e la continuità operativa.

The Oval Room

Queste le sessioni che hanno animato il pomeriggio nella stanza ovale, moderata dal sottoscritto insieme a Stefano Maffeis.

• “Protocollo MQTT“: Claudio Volpi ci parla di MQTT, un protocollo royalty-free molto usato nel mondo IoT e nel M2M (Machine-To-Machine).
• “I Beatles e il lavoro di squadra“: Pierpaolo Muzzolon, uno dei nostri amici e ospiti fissi delle unconference, guida una discussione sulle dinamiche interne di un team prendendo come riferimento la famosa band The Beatles.
• “.NET MAUI? Are desktop applications back?” Questa è la domanda che si pone Roberto Federiconi, uno dei nostri ospiti. Le applicazioni desktop stanno tornando?
• Luca Ballerin, un altro dei nostri ospiti, desidera parlare di “passaggio generazionale” tenendo delle esperienze e della diffusione dell’approccio Agile nelle aziende.

Protocollo MQTT

Claudio ha preparato una presentazione esaustiva sul protocollo MQTT, nato nel 1999 e arrivato oggigiorno a essere molto utilizzato e apprezzato per la sua semplicità e affidabilità, oltre che essere royalty-free.
“Che cos’è MQTT?”
È un protocollo binario basato sul modello Publish / Subscribe per lo scambio di dati binari nel payload attraverso un Message Broker, il punto centrale dove vengono pubblicati i dati e dove tutte le entità interessate si sottoscrivono per riceverli. Le entità in questo caso sono i Publisher e i Subscriber: il Publisher pubblica messaggi ad ambiti specifici, definiti Topic, mentre i Subscriber si sottoscrivono. Sia i Publisher che i Subscriber sono da considerarsi client che possono comunicare esclusivamente attraverso il Message Broker.
Claudio ha descritto le caratteristiche che fanno di MQTT un protocollo tanto semplice da implementare (ha solamente tre funzioni: Connect, Publish e Subcribe) quanto affidabile con la possibilità di configurare tre livelli di Quality of Service.

I Beatles e il lavoro di squadra

Pierpaolo ha trovato ispirazione dopo aver guardato il documentario “Get Back” di Peter Jackson che ripercorre i giorni trascorsi insieme dal gruppo, nel gennaio 1969, mentre scrivevano e registravano canzoni per un nuovo album.
Attraverso la visione di tre clip abbiamo discusso sul tema delle dinamiche che si innescano all’interno di un team, in cui non è semplice capire quale direzione prendere.
“Che fare nel caso in cui ci si rende conto che un membro emerga come leader?” “Qualora si accettasse la figura di leader all’interno del gruppo, come si dovrebbe rapportare e lavorare all’interno del team?”.
Intorno a queste domande è nato un momento di dialogo intenso e ricco di spunti utili portati da tutti i partecipanti.
Dopotutto, e concludo citando l’articolo di “Internazionale” che Pierpaolo consiglia di leggere in merito al documentario:

“…la questione di cosa faccia funzionare una squadra è uno dei pilastri della ricerca sulla gestione aziendale, e il documentario sui Beatles è una rara occasione di vedere all’opera una squadra di livello veramente mondiale. Rafforza i princìpi noti e ne aggiunge di nuovi.”

.NET MAUI? Are desktop applications back?

Roberto ha approfittato di questa unconference per scambiare pareri e informazioni su alcuni framework in rampa di lancio per lo sviluppo di applicazioni desktop.

.NET MAUI è un framework multipiattaforma per la creazione di app desktop e per dispositivi mobili native con C# e XAML. Le app sviluppate con MAUI possono essere eseguite in sistemi Android, iOS, macOS e Windows avendo un’unica codebase condivisa. Di seguito due link condivisi durante la chiacchierata:

• .NET MAUI Roadmap Previews
• .NET MAUI Blazor – Build Hybrid Mobile, Desktop, and Web apps

La discussione si è poi spostata su altre tecnologie interessanti come Flutter, un framework open source creato da Google per la creazione di interfacce native per iOS e Android, e Oxygene, un progetto per lo sviluppo di app multi-platform usando un unico linguaggio e un unico IDE.

Parliamo di passaggio generazionale

“Come viviamo il passaggio generazionale?”
Luca Ballerin è partito da questa domanda per animare un momento di riflessione su un tema molto delicato. Perché tutti siamo stati – o siamo – giovani, e con il passare del tempo diventiamo “anziani” agli occhi di altri giovani.
Luca ha raccontato la sua piacevole esperienza nella scoperta della metodologia Agile, un qualcosa di nuovo per lui (tenete presente che la prima redazione del Manifesto per lo Sviluppo Agile di Software risale al febbraio 2001).
Come è avvenuto a Luca con l’Agile, parlare di un argomento a persone ignare è complicato. Una complessità che aumenta se tra gli interlocutori passa qualche anno, o anche qualche decina d’anni, di differenza. L’esercizio che dobbiamo fare tutti in questo caso è trovare una chiave di volta, un qualcosa che ci permetta di entrare nel mondo dell’altro. E di occasioni, quantomeno nella nostra quotidianità lavorativa, ne avremmo. Basti pensare al momento della pausa caffè, o della pausa pranzo.
Un altro tema emerso è quello della sete di conoscenza, forse il vero motore del passaggio generazionale. Ciò che non dobbiamo mai fare è accontentarci di ciò che sappiamo e delle esperienze che abbiamo vissuto. Dobbiamo sempre avere sete di conoscenza, e soprattutto avere l’umiltà di accettare consigli e insegnamenti anche dal collega molto più giovane.

Panic Room

Di cosa si è parlato nella Panic Room?

• Fabio Fortini ci racconta l’evoluzione storica del team nel quale lavora, accompagnato dal suo collega nonché nostro ospite Alessio Coser.
• Lorenzo Testa e Xhoana Aliu spiegano come portare e fare proprie le pratiche “Clean Code” all’interno di un team di sviluppo.
• Veronica Brosio ci parla di un viaggio particolare, ovvero quello di uno sviluppatore junior all’interno di un nuovo team e di un nuovo progetto.
• Alessandro Rosa pone alla platea di tecnici la seguente domanda: “Qual è il vostro rapporto con i code smell?“

Vi raccontiamo la storia del nostro team

Fabio e Alessio hanno ripercorso l’ultimo anno del loro team raccontando come le varie cerimonie erano svolte e come fosse strutturato il loro backlog.
Nella seconda parte della sessione hanno spiegato in cosa già hanno migliorato certi aspetti e in cos’altro stanno focalizzando i loro obiettivi.

Clean Code nel team

Lorenzo e Xhoana, attraverso l’utilizzo di una board Miro, hanno raccolto le esperienze riguardo il “Clean Code”, ragionando attorno i seguenti punti.

• Quanta attenzione nei team viene riposta sulle pratiche Clean Code.
• Quali azioni sono state apportate per migliorare.
• Quali altre cambiamenti sarebbe utile apportare.

Al termine della sessione si sono formulate alcune azioni da provare a condividere nei vari team.

Il viaggio di uno sviluppatore junior

Veronica ha raccontato il percorso affrontato da uno sviluppatore junior all’interno di uno specifico team. È nata poi una discussione tra i partecipanti alla sessione sui diversi approcci, non solo di Intré ma anche nei team esterni.

Qual è il vostro rapporto con i code smell?

I partecipanti hanno discusso di code smell e di come vengano approcciati nei vari team di appartenenza. Per fare un esempio, un buon metodo per evitare i code smell che è stato consigliato è seguire i consigli dell’IDE per evitare di lasciare codice non utilizzato oppure per scrivere una determinata porzione di codice in una maniera più efficiente.

The Chamber of Secrets

Ecco le quattro sessioni nella nostra personalissima “Camera dei Segreti” per questa prima unconference del 2022.

• “Our working agreements journey“: Francesco Agozzino, nostro amico e ospite, ci racconta il percorso svolto con un nuovo team per definire i Working Agreements.
• “Ciao, sono un designer, come posso aiutare?“: Massimo Azzolini è a disposizione per un’interessante conversazione.
• “È possibile lavorare in modo Agile all’interno di un processo Waterfall?“: Da questo interrogativo Dario Magri propone una discussione che mette a confronto due grandi metodologie: l’Agile e il Waterfall.
• “Regret calculator“: Fabio Nava ci presenta un’applicazione sviluppata insieme al collega designer Roberto Aceti.

Our working agreements journey

Francesco ha raccontato come, in fase di partenza di un nuovo team, ha organizzato, insieme agli altri membri, un workshop per definire una serie di regole condivise che potessero garantire comportamenti, processi e flussi di lavoro ottimali. A distanza di sei mesi, che cosa è andato bene e che cosa necessita di revisione?

Ciao, sono un designer, come posso aiutare?

Massimo ha portato la sua esperienza di designer il quale spesso, per le dinamiche di un progetto, non ha la possibilità di confrontarsi con il team di sviluppo nelle fasi iniziali di ricerca e progettazione. È nato un confronto interessante su come migliorare il processo coinvolgendo il prima possibile le figure più tecniche e su come, in generale, una maggiore condivisione tra i vari stakeholder possa portare a risultati migliori e minori rilavorazioni.

È possibile lavorare in modo Agile all’interno di un processo Waterfall?

Dario ci ha parlato del suo attuale contesto lavorativo dove, in qualità di Scrum Master, cerca di introdurre l’Agilità in un ambiente organizzato secondo il modello Waterfall.

Parlandoci della sua esperienza, le criticità emerse e l’approccio utilizzato, Diego ha fornito alcuni spunti utili.

• Data una specifica da implementare creare subito una sorta di backlog.
• Cercare di coinvolgere il più possibile il cliente per avere feedback immediati.
• Cercare di fare team anche con sviluppatori esterni.

Nella seconda parte della sessione si è discusso su cosa poter migliorare per rendere sempre più Agile un ambiente Waterfall e ogni partecipante ha portato la propria esperienza e i propri suggerimenti.

Regret Calculator

Fabio e Roberto hanno presentato un primo prototipo di un’applicazione che hanno ideato e realizzato: Regret Calculator. Si tratta di una Web app che permette di calcolare, a partire da una data passata, quale sarebbe a oggi il valore di un investimento nelle principali criptovalute. L’obiettivo è quello di rendere evidente in maniera “giocosa” il rimpianto (da qui “regret”) per il mancato investimento oppure la soddisfazione nel caso in cui l’acquisto avrebbe portato a una perdita di capitale.