Agile Venture Firenze: Evolution over Revolution

9 Ottobre 2019 - 8 minuti di lettura

Sabato 28 Settembre si è tenuto il primo Agile Venture Firenze.
E’ stata la prima volta di un evento del circuito Agile Venture nello splendido capoluogo toscano, precisamente tra le aule dell’Istituto Europeo di Design sito nel bel mezzo del centro storico.

Negli ultimi anni, l’approccio agile allo sviluppo di progetti software e all’organizzazione del lavoro è passato da tema per pochi entusiasti a movimento su scala globale.
Di fronte a questo cambiamento, è importante focalizzare l’attenzione sui principi e sulle pratiche che permettono di rispondere ai cambiamenti e generare valore, adottando quindi un processo di cambiamento adattivo che risponde al termine di evoluzione.
Non dimentichiamoci del passato, teniamo ciò che funziona e partiamo da ciò per innescare questo processo di miglioramento continuo.
Evolution over Revolution.

Per la giornata sono stati organizzati talk e workshop tecnici e non, proprio perché essere agili ed adottare l’agilità dovrebbe riguardare tutta la catena del business, dalle figure tecniche al management.

Nei successivi paragrafi troverete un riassunto di quanto raccontato a questo primo Agile Venture Firenze, a partire dal keynote a cura di Andrea Provaglio proseguendo con le sessioni tecniche seguite.

Keynote: Finding your agility

Andrea Provaglio, forte della sua esperienza come agile coach a contatto con il management aziendale, ci parla di agile e agilità.
Quando un’azienda si avvicina all’agile, perché lo fa? Cosa si aspetta di trovare, quali problemi sta cercando di risolvere?
E non dimentichiamoci che viviamo in un mondo in continua evoluzione, dove i servizi si sono sostituiti ai beni materiali. Quale approccio bisogna assumere per abbracciare il cambiamento?

Agile Venture: sessione mattutina

Metafora: la pratica perduta di eXtreme Programming

Delle 12 pratiche previste da eXtreme Programming una delle meno usate e forse meno capite è la metafora.
Lo stesso Kent Beck l’ha esclusa nella seconda edizione del suo libro Extreme Programming Explained: Embrace Change e persino Martin Fowler non ha fatto mistero di non averne compreso l’utilità.
Un po’ controcorrente Marco Fracassi nella sua esperienza ha provato ad applicarla, e ci spiega il perché della sua importanza e come usarla per ottenere una comunicazione più efficace e facilitata, dopotutto usare una metafora vuol dire sostituire un termine con un altro per dare forte carica espressiva.
Pensando alle architetture software, chissà quante volte ci è capitato di rappresentarle con un agglomerato di blocchi e frecce, incomprensibili alla lunga persino per chi le ha disegnate. Si potrebbe pensare di sostituire i blocchi con parole significative del contesto, e cercare di mantenerla il più semplice possibile. Un buon modo per iniziare è applicarla alla parte dell’architettura che ci risulta più chiara.
Marco crede in questa pratica perché ci vede del valore. Non tanto nello spiegare un software in un modo alternativo bensì perché tale pratica genera discussione, che se sana danno seguito spesso a nuove idee.

Cosa può insegnarci FizzBuzz sul design

Chi è sviluppatore software non può non conoscere il kata del gioco FizzBuzz. L’obiettivo è stampare una lista di numeri da 1 a 100; la parola Fizz sostituisce tutti i numeri divisibili per 3, Buzz quelli divisibili per 5, FizzBuzz per i divisibili sia per 3 che per 5. Massimo Iacolare non vuole parlare dell’esercizio in sé bensì degli insegnamenti che possiamo trarre dal refactoring, partendo dal design del codice, per implementare un’ipotetica feature.

Test-Driven Infrastructure with Ansible

Gianni Bombelli ha condotto un talk tecnico su Ansible, un software open source scritto in linguaggio Python, utile per automatizzare le procedure di configurazione, provisioning, deploy di applicazioni per sistemi Windows e Unix.
Nel tempo a sua disposizione Gianni ha dapprima introdotto Molecule, una libreria utile per sviluppare e testare in Ansible, dopodiché ha implementato una semplice configurazione per l’installazione di un pacchetto software in due sistemi (o nodi): CentOS e Ubuntu. Il tutto applicando TDD, quindi scrivendo dapprima il test e poi la configurazione.

In un primo step Gianni ha creato il playbook utile ad Ansible per leggere appunto le istruzioni da eseguire sui nodi. Per farlo ha utilizzato Ansible Galaxy che permette di scaricare una configurazione già pronta appunto da una fonte continuamente aggiornata dalla community.
Negli step successivi è stato definito lo scenario di test, specificando diverse informazioni quali il nodo da testare, il driver da utilizzare (ad esempio Docker) ed altre informazioni come il framework e le eventuali dipendenze.

Infine con l’esecuzione del caso di test Gianni ha spiegato la catena di operazioni che vengono eseguite tra cui la verifica del playbook, l’esecuzione del nodo e l’esecuzione vera e propria del test.

Agile Venture: sessione pomeridiana.

A Journey to Microservices Architecture

Alessio Coser ha parlato della sua esperienza in merito alle architetture a microservizi, di come ci si può arrivare in modo iterativo ed incrementale.

Passare da un’architettura monolitica ad una a microservizi non è stato facile, soprattutto quando il monolite è complesso e il dominio applicativo ancor di più… Scorporando il monolite, i microservizi risultanti avevano diversi problemi strutturali (la responsabilità era spalmata su più processi anziché uno solo). Alcuni microservizi gestivano le operazioni CRUD su entità condivise da altri componenti perciò una modifica doveva essere propagata su diversi microservizi.

Si è deciso quindi di rivedere l’architettura applicando Event Storming assieme al management per cercare di fare chiarezza sui compiti dei diversi microservizi coinvolti.
Con il passare del tempo la situazione è decisamente migliorata sino ad avere microservizi ben definiti ognuno con il suo compito.
Ciò che Alessio ha imparato e suggerisce è di avere un alto livello di comunicazione nel team, avvisare sempre quando si effettuano rilasci e in caso di problemi evitare di incolpare la persona ma piuttosto collaborare per risolvere l’inconveniente.

Altro aspetto importante è il team, deve essere ben identificato e mappato su tutto lo stack quindi non solo sviluppatori ma anche figure lato IT e business.
Senza dimenticarsi del codice, ovviamente. La semplicità e la qualità del software devono essere le basi. Iniziare da un monolite il più pulito possibile (con logiche di business separate) di modo tale da creare un microservizio estraendo il componente più semplice ma calato in un contesto ben preciso.

Nella mente di un alchimista

Un talk dedicato alla programmazione funzionale, un mondo popolato da sviluppatori che applicano soluzioni semplici ai moderni problemi di fault-tolerance, scalabilità e distribuzione. Un mondo fatto di pattern che possono sembrare contro-intuitivi e dove la programmazione funzionale ha una reale ragione di esistere e non è solo la moda del momento.

Elixir ed Erlang sono termini collegati e interscambiabili, ci spiega Nicola Fiorillo. Elixir è un linguaggio di programmazione funzionale concorrente il cui codice compilato viene interpretato da BEAM, la macchina virtuale Erlang. A sua volta Erlang è un linguaggio di programmazione non orientato a contesti specifici ma in grado di lavorare con la programmazione concorrente.

Il linguaggio Elixir è nato con lo scopo di consentire una maggiore estensibilità e produttività della virtual machine Erlang, preservando al contempo la compatibilità con gli strumenti e l’ecosistema stesso di Erlang. La sua nascita è stata motivata dal fatto che la capacità di calcolo dei processori è in continuo aumento dando luogo ai processori a core multipli. L’ecosistema Erlang, compresa la sua macchina virtuale, sfrutta appieno questo tipo di architettura multi-processore, così che un programma in esecuzione può essere suddiviso in una serie di micro processi paralleli.
Con Elixir quindi si superano le carenze di Erlang su alcuni paradigmi e si rendono disponibili taluni approcci di programmazione non ammessi da Erlang, come la meta-programmazione ed il polimorfismo.

Continuando l’analogia con il mondo object-oriented, l’analogo dell’oggetto è il processo in Erlang. In una macchina virtuale, che si definisce nodo, risiedono tanti processi che comunicano tra loro in modalità asincrona a differenza di quanto avviene nel mondo degli oggetti.
Per intenderci, un processo A manda un messaggio asincrono a B ma A continua l’esecuzione. Non esistono messaggi sincroni. In tal senso, un pattern noto è che i messaggi che vengono mandati, definiti funzioni, contengono il payload del mittente di modo tale da non perdere il filo dell’esecuzione.
Nicola ha spiegato altre caratteristiche di un processo Erlang quali la leggerezza e la velocità. Leggerezza perché il processo contiene informazioni sul proprio stato e nulla di più, non condivide memoria con altri processi.

L’intervento è stato chiuso con una breve demo durante la quale Nicola si è collegato con una macchina in produzione e ha mostrato come eseguire una query verso il database da console dopo essersi collegato ad un processo.

My Story with Open Source

Come suggerisce il titolo del talk, Nicola Iarocci ci ha raccontato la sua storia nel mondo dell’open source, passando dall’essere uno sviluppatore C# introverso a manutentore di progetti scritti in Python.
Non solo manutentore , ma anche relatore, trainer e consulente.
Questa svolta Nicola la deve ad Eve, un framework per API REST che consente di sviluppare e rilasciare servizi RESTful in maniera semplice e veloce. Fornisce supporto per MongoDB e SQL grazie ad estensioni sviluppate dalla community. Il grande supporto derivante dalla community è uno dei pro dell’open source, gli altri per lui degni di nota sono:

feature: nuove funzionalità che possono arrivare continuamente
bug fixing: più persone utilizzano la tua libreria, più è alta la probabilità di trovare malfunzionamenti e proporre correzioni
qualità e longevità: le pull request che arrivano sul repository github possono anche riguardare la documentazione, il che aumenta la qualità del progetto

Attenzione però a non farsi illusioni. Nicola riporta anche dei contro, quali:

linguaggio e barriere culturali: capita di dover avere a che fare con richieste di utenti che parlano lingue diverse e che hanno culture diverse dalla propria
mantenimento: un progetto open source richiede tempo da dedicare a segnalazioni, bug, pull request. E quel tempo è tuo tempo, non è pagato da nessuno
imparare a dire no: per un altro progetto open source, Nicola ha dovuto rifiutare una richiesta di implementazione del software per una versione di .net vecchia. A malincuore, ma ciò poi avrebbe richiesto ulteriore tempo per la manutenzione
responsabilità: fare attenzione ad accettare pull request da chiunque. I malintenzionati sono sempre pronti ad agire, e nel caso tramite trojan a altre minacce nascoste tra righe di codice
sostenibilità: con i progetti open source raramente si guadagna.

Conclusione

Fabio Ghislandi, presidente dell’Italian Agile Venture nonché Executive Agile Coach e partner di Intré ha ringraziato i volontari e sponsor che hanno reso possibile questo Agile Venture Firenze 2019.

La giornata si è chiusa con un momento goliardico, la riffa finale con premi di tutti i tipi: dalle maglie dell’azienda doubleloop a copie di libri tecnici sino a biglietti per conferenze imminenti.

Ai prossimo appuntamento agili, tra i quali segnaliamo: