IAD Urbino 2017 – Unconference 17 Novembre

Unconference

Che cosa si intende per unconference ?

Pierluigi Pugliese ha spiegato ai circa 150 avventori l’origine dell’idea di unconference, nata dalle pause caffè durante le conferenze come momento di scambio di idee ed opinioni.

E allora… Perché non creare un nuovo format di conferenza che riprenda la modalità di una pausa caffè ? Incontriamoci, scambiamo due chiacchiere, confrontiamo opinioni… Discutiamo.

Ma che cosa proporre?

• Magari un argomento sul quale si è preparati, magari per semplice diffusione di conoscenza
• Un’idea, una proposta di collaborazione che può scatenare ulteriori incontri e chiacchierate
• Semplicemente un aiuto: non so nulla \ ho dei dubbi su una certa tematica

Pierluigi ha poi spiegato il COME affrontare una sessione di una unconference.

C’è una sola legge, la LEGGE DEI 2 PIEDI: andiamo dove possiamo trarre / apportare valore, e 4 principi:

• QUANDO COMINCIA E’ IL MOMENTO GIUSTO
• CHIUNQUE VENGA E’ LA PERSONA GIUSTA
• QUANDO E’ FINITA, E’ FINITA
• QUALSIASI COSA ACCADA, E’ L’UNICA CHE POTEVA ACCADERE

E come i calabroni e le farfalle, spostiamoci di stanza in stanza, trasportando in questo caso informazione e conoscenza 😊

Via alle proposte quindi!

Tanta roba, come si dice 😊
Giusto il tempo di fare mente locale su chi e cosa seguire (purtroppo non ho appreso la Tecnica Superiore della Moltiplicazione del Corpo) e GOOOOOONNNGGGGGG!!!
Pierluigi ha dato inizio alla giornata.

Nel frattempo…
Dalle 9:00 alle 13:00 Matteo Vaccari, Gabriele Tondi, Stefano Leli e Vaishnavi Jayakumar hanno coordinato un workshop.

Workshop Coderetreat

Per Coderetreat si intende una particolare tipologia di evento, legato al software development e al design, che si svolge sempre in maniera simile.

Cogliendo l’occasione del Global Day of Coderetreat pianificato in tutto il mondo il 18 novembre, IAD ha giocato d’anticipo organizzando un coderetreat mattutino di 4 ore nella cornice suggestiva della Sala del Maniscalco.

Come scritto nel sito ufficiale, si tratta di un evento il cui scopo è quello di far sì che i partecipanti possano esercitarsi nel Test Driven Development, nel “clean code”, nel “simple design”, nel “refactoring”, in maniera iterativa e collaborativa.

I 30 partecipanti – fra cui il nostro collega Damiano – hanno lavorato a coppie, seguiti dai facilitatori sempre pronti a dare qualche dritta o suggerimento. E’ un format che, anche perché svolto in un clima di assoluta non pressione, ha dato prova di essere estremamente efficace per assicurare il miglioramento delle capacità dei partecipanti.

Basta poco per cominciare: dopo aver ripassato come funziona il TDD e quali sono i princìpi del simple design che dovrebbero guidare lo sviluppo, sono state spiegate le regole del famoso Game of Life di John Conway, per poi formare coppie di sviluppatori pronti a confrontarsi fra loro ed affrontare insieme il problema. Finita la prima sessione di sviluppo di 45′, abbiamo buttato tutto il codice, ci siamo messi in cerchio per una breve retrospettiva ed abbiamo iniziato una seconda sessione con nuove coppie, e poi una terza con coppie ancora diverse (anche se stavolta in molti abbiamo invece seguito sul maxischermo come Matteo e Vaishnavi affrontavano il problema).

Un ultimo giro di retrospettiva ha fatto emergere una marea di osservazioni (guardate qui sotto quanti post-it!), alla fine delle quali siamo tornati all’unconference, approfittando del percorso per visitare la mostra di retro-computing 1977 – 1987: Quando il Computer divenne Personal.

Do bots dream of electric retrospective?

Dimitri Favre ha proposto una sessione di scambio opinioni basata su un suo quesito: “possono coesistere i mondi A.I. e Agile?”, a seguito dell’intervista rilasciata qualche tempo fa dal CEO di GitHub, il quale ha dichiarato che in futuro il software sarà scritto da altro software.

Per A.I. intendiamo tutti quei software composti di intelligenza artificiale, in grado di imparare (si pensi anche ai bot) e quindi evolvere.
Questa classe di software apprende molto più rapidamente di noi poveri esseri umani; si pensi al campione mondiale di Go battuto da una macchina grazie ad una mossa inizialmente considerata nonsense ma che poi si è rivelata determinante… Cosa se ne deduce ?
Se ne deduce che la macchina ha utilizzato uno schema di ragionamento nuovo per l’essere umano, che sicuramente potrà sfruttare per altre partite di Go.

Tornando al dubbio di Dimitri: se saranno delle macchine a scrivere software, che ne sarà di noi sviluppatori? Che ne sarà delle pratiche agili, dell’agile manifesto?
Rileggendo alcuni principi dell’agile manifesto, si è discusso se avesse senso poter a questo punto pensare ad una versione per l’A.I.

Si è poi provato ad analizzare la situazione vedendo il lato positivo, ovvero una coesistenza tra i 2 mondi. Possiamo apprendere, imparare l’un l’altro. Dopotutto, le macchine ricevono un input dall’uomo, lo elaborano, eseguono quel determinato task magari meglio cosicché noi possiamo migliorare.

Grazie Dimitri, quella notte non ho dormito ma che bella conversazione!

Uno, nessuno o centomila PO!

Nonostante abbia abbracciato il mondo agile da qualche anno, qualche dubbio in merito alla figura del Product Owner l’ho sempre avuta.
Pensando a questo IAD, tra me e me mi son chiesto “ma ci sarà qualche anima pia che sarà in grado di aiutarmi a diradare le nubi attorno a questa figura?”

Ebbene sì, Alessio Del Toro ha letto nella mia (e non solo) mente, proponendo un talk sull’argomento 😊
Va detto, tra i partecipanti io ero NESSUNO, perché gli altri erano tutti P.O., poco male!

Divisi in 2 gruppetti, Alessio ha organizzato in maniera efficiente il tempo a sua disposizione facendo fare ad entrambi i team una prima fase di raccolta idee sulle responsabilità di un P.O., seguita da una fase di discussione in base ai Post-it attaccati su di una flipchart.

Una volta raggiunto un accordo sulle responsabilità, Alessio ci ha chiesto di fare altrettanto relativamente alle pratiche che un buon P.O. dovrebbe mettere in atto per rispondere a tutte le responsabilità.

Un talk davvero interessante. Essendo l’unico non P.O. partecipante ho colto l’occasione per portare la mia esperienza e dibattere con chi ricopre tale posizione.

Grazie Alessio 😊

Da Monolite a Microservizi

Alberto Brandolini, per gli amici zio Brando, ha proposto un chiacchierata sull’annoso problema del passaggio da un’architettura monolitica ad una più snella e moderna basata sui microservizi.

Avvalendosi di tanti pennarelli ed una flipchart, ha iniziato col porci la seguente domanda: “Cosa intendiamo per microservizio ?“
Può essere inteso come l’unità di rilascio più piccola possibile ?

Fatto chiarezza su questo primo dubbio esistenziale 😊, Alberto ha lasciato che il pubblico continuasse la discussione, moderando con interventi misurati e man mano aggiungendo “ingredienti” (come li chiama lui) sui fogli.

Si è ragionato su come indentificare i componenti di un nostro sistema (può essere tutto inglobato in unico servizio “pippo” deployato sul cloud ? Sì, il cliente è contento, noi anche).

Ma attenzione alle dipendenze con altri servizi estratti dal monolite!

E come la mettiamo con la base dati del nostro monolite ? Sarà sicuramente un unico database, magari relazionale, magari condiviso da altre applicazioni… Meglio aggiungere l’ingrediente Event Bus, e passare ad una architettura basata sugli eventi 😊

A questo punto, si è disquisito su quali alternative architetturali considerare:

• macchina a stati che riceve in input dei comandi e genera in output eventi ?
• il servizio riceve in input degli eventi e genera come output degli accessi a risorse (certa porzione del db \ vista particolare del db)
• un processo che riceve in ingresso eventi e genera dei comandi come output

Alla fine del tempo a sua disposizione, di ingredienti sul piatt… Ehm, sui fogli ce n’erano !

Peccato, io e gli altri partecipanti avremmo continuato volentieri questa chiacchierata istruttiva con lo zio!

IAM

Come detto da Pierluigi nell’openspace, in una unconference tutto può succedere, anche seguire un talk dove si spiega che cosa sia IAM, cioè l’Italian Agile Movement, cioè l’organizzazione che organizza l’Italian Agile Days.

Penserete: “a che serve seguire un talk sull’argomento, c’è tanto di sito sull’organizzazione!”. Sì, vero, ma quale miglior momento per farselo spiegare direttamente da chi ne fa parte, meglio se è il presidente in carica ? 😊

Fabio infatti ha pensato bene di proporre questo talk, e coadiuvato da Alessandro Giardina (attuale Consigliere e Tesoriere) hanno spiegato il perché dell’esistenza e i fini di questo movimento, illustrando come e con quale cadenza vengono organizzati gli eventi del movimento.

Da questo talk porto a casa una conferma: che IAM non è solo un gruppo di volontari, bensì un gruppo di amici e una sempre più folta comunità di persone che credono veramente nelle pratiche agili.

Fabio e Alessandro ci hanno trasmesso passione e voglia di non fermarsi, nonostante siano on-fire da 15 anni.

Per una  volta, posso dire che ho fatto bene a non limitarmi a consultare il sito 😀

TEST TEST TEST!

Mentre in un corridoio Fabio spiegava chi e cosa è IAM, in un altro corridoio ci si sedeva in circolo insieme a Charlie Poole e si chiacchierava di test.

Si è trattato di una chiacchierata informale, in cui tutti si sono raccolti attorno a Mr.Poole come dei bimbi desiderosi di ascoltare una fiaba, e “nonno” Charlie (come qualcuno l’ha soprannominato scherzosamente) non ha deluso. Dall’alto della sua lunga esperienza, ha condiviso con noi numerosi episodi, sempre cercando di utilizzarli come spunti per un dibattito e per stimolare osservazioni personali.

In un discorso iniziato dalle definizioni di TDD, BDD e Test-Centric Development, si è arrivati ad esempio a riflettere su: come cambia (in meglio) il lavoro di uno sviluppatore con un cliente on-site; quali sono i vantaggi di lavorare fianco a fianco coi tester, anche in ambienti poco agili; come potrebbe aiutarci l’esistenza di un framework user-friendly per permettere ai clienti stessi di definire formalmente dei test automatici.

Abbiamo anche avuto qualche anticipazione sul keynote del sabato, ma per questi succosi spunti dovrete aspettare il prossimo articolo! 😉

Patterns: da linguaggi O.O. a linguaggi funzionali e viceversa

Alessandro Bonometti, a.k.a Bauno, ha pensato bene di proporre uno spazio tecnico per disquisire di come poter sfruttare alcuni pattern per passare da un linguaggio di programmazione object oriented ad un linguaggio funzionale.

Portando in dote un caso d’uso di un generico metodo scritto in C# per la gestione d’una prenotazione, Bauno ci ha regalato alcuni trucchetti per passare allo stesso metodo scritto in un linguaggio funzionale (dando per scontato che si stesse lavorando seguendo i dettami del T.D.D.) facendo attenzione a evitare T.I.D. (Test Induced Damage o Test Induced Design Damage, cioè Danno Indotto dai Test).

Gran bel talk, condotto con flipchart, pennarello ed improvvisazione da una persona molto competente.
Quella competenza che personalmente latita in fatto di linguaggi funzionali, ma che il buon Bauno non ha affatto fatto pesare ai suoi ascoltatori (perlomeno a me 😊 ).

Conclusioni

Tra un pattern e una nozione, una chiacchiera e uno scambio di opinioni, é arrivata l’ora di salutarci.
Pierluigi ha riunito tutti laddove la giornata è iniziata. Facce distese, contente.
Soddisfazione emersa quando appunto Pierluigi ci ha permesso di esprimere pareri su quanto vissuto.
La pallina rimbalzava tra una mano e l’altra manco fossimo in un flipper 😊
Ricordandoci la giornata della conferenza del giorno successivo, ha chiesto a tutti noi di alzarci in piedi, disporci tutto intorno le pareti dell’aula, memorizzare i volti dei presenti e chiudere gli occhi.

GOOOOOONNNGGGGGG !!!

La unconference si è chiusa così. Ognuno torna a casa con il proprio bagaglio culturale arricchito, e con nuovi, agili amici. Incluso te, caro lettore, che sicuramente non vedrai l’ora di sapere come è andata la giornata successiva 😉