Tutto è pronto dunque, let’s start!
Nella sala Auditorium Fabio Ghislandi, presidente della Italian Agile Movement nonchè partner di Intré ci ha introdotto alla giornata, lasciando poi la parola a Ran Nyman per il keynote.
Il programma della giornata è stato il seguente:

Ran Nyman ha preparato un talk incentrato sulla sfida, spesso complicata, che le grandi aziende affrontano nel cercare di adottare una metodologia di lavoro agile passando attraverso i più noti framework.
Nello specifico, Ran ha focalizzato l’attenzione sul framework LeSS, evidenziando i fattori di successo comuni su 2 casi di esempio.

Andrea Francia ha condotto il suo talk in 3 coccinelle temporali…sì avete capito bene, coccinelle, perchè per non rischiare di sforare con i tempi, di volta in volta ha caricato un timer, a forma di coccinella appunto, della durata di 10 min.
La prima coccinella è stata impiegata per spiegarci del perchè sia necessario passare dal modello Waterfall ad un modello iterativo, spostando il focus su esigenze puramente di business. Importanti sono stati gli studi fatti da Kent Beck sul costo del cambiamento che lo hanno portato a definire, assieme a  Ward Cunningham e Ron Jeffries, la metodologia di sviluppo software XP.

Nei successivi 10 minuti, Andrea ci ha mostrato una tabella elencante le caratteristiche di Scrum ed XP per metterli a confronto e successivamente un grafico raffigurante le 12 pratiche XP (che poi in realtà sono 50, ma lui stesso  ha ammesso di non averle messe in pratica tutte):

Prima di iniziare a spiegarci le pratiche, ci ha fatto notare come la retrospettiva, lo stand-up meeting non sono pratiche XP, bensì devono essere pratiche implicite per chi adotta sia XP che Scrum.

• Pratiche di Business:
  • Small Releases: ogni release dovrebbe essere più piccola possibile ma contenente il requisito di più alto valore di business;
  • Planning Game: il team di sviluppo dovrebbe decidere quali feature far rientrare nella prossima release cercando di combinare priorità di business con appunto le stime tecniche per ciascuna di esse;
  • Acceptance Test: per Andrea equivale a Customer Test dato che è appunto il customer che dovrebbe specificare gli acceptance test dell’applicazione che serviranno appunto per derivare dettagli per le user stories;
  • Customer on site: il customer deve far parte del team, essere disponibile al team per qualunque chiarimento.
• Pratiche di Team:
  • Sustainable Pace: sostanzialmente, ogni membro del team deve lavorare 8 ore, evitando di fare straordinari. Come esempio, Andrea ci ha portato il recente problema dell’erronea rimozione della directory di produzione dal server, dovuta pare ad un “amministratore stanco che in tarda notte ha compiuto l’errore”;
  • Collective Code Ownership: chiunque può modificare e committare modifiche al codice di chiunque, a qualunque ora;
  • Coding Standard: gli sviluppatori dovrebbero scrivere codice utilizzando uno specifico template e\o regole ben precise;
  • Pair Programming: il codice che “andrà in produzione” dovrebbe essere sviluppato in coppia, seduti alla stessa postazione; uno sviluppatore fa il navigator (supervisiona, revisione del codice), l’altro il driver (scrive il codice);
  • DRIIIIIN, mancano 10 minuti Andrea!
• Pratiche di Design:
  • Metaphor: dovrebbe esserci un’unica semplice storia che spiega il funzionamento dell’intero sistema, e che quindi dovrebbe guidare l’intero sviluppo;
  • Test-Driven Development: ogni feature dell’applicazione deve essere corredata di test automatici; se non li ha, semplicemente non esiste;
  • Refactoring ( o Incremental Design): quando si fa refactoring del codice, non si dovrebbe alterarne il comportamento bensì immettere nuovo design;
  • Simple Design: per essere definito semplice, un codice dovrebbe rispondere alle seguenti 4 regole:
    • tutti i test devono passare;
    • non deve contenere duplicazioni;
    • è chiaro ed esprime l’intento per cui è stato scritto;
    • non contiene parti superflue

Prima dei saluti, Andrea ci ha suggerito di leggere il libro The Art of Agile Development: Pragmatic Guide to Agile Software Development, contenente la spiegazione a quasi tutte le pratiche XP.
Bravo Andrea, talk molto interessante, peccato per il poco tempo a disposizione! Qualche coccinella in più sarebbe stata gradita.

Nello spazio a sua disposizione, Angela Senger ha raccontato la sua esperienza di coach agile presso una grossa software house del milanese.

La storia inizia con un’azienda di belle ambizioni che, in procinto di costruire a loro detta “la piattaforma di e-commerce del futuro”, si rende conto di dover diventare agile per non deludere le attese del proprio cliente.
La consegna era prevista in 15 mesi, ma per fortuna il budget non era un problema: quel che sarà necessario spendere per avere le migliori tecnologie o per acquisire nuova forza lavoro, verrà speso.

Le condizioni erano ottime: in genere si sente di aziende con poco tempo e denaro a disposizione, in questo caso invece tutto sembrava essere al suo posto; Angela però ha raccontato di come l’abbondanza, se mal gestita, possa nuocere tanto quanto l’indigenza, se non di più. L’azienda ha iniziato ad assumere persone a più non posso, aggiungendo in pochi mesi decine di risorse al progetto (chi ha detto Mythical Man-Month?); erano così partiti corsi di formazione che sono durati mesi, accorgendosi solo alla fine che era stato tutto tempo sprecato: inserire persone in nuovi team richiede tempo, che difficilmente si riesce a contrarre.

Ma nonostante i problemi, nonostante l’azienda pensasse inizialmente di poter “comprare l’agile” come un qualsiasi altro bene, il mood era positivo: le persone erano entusiaste delle pratiche introdotte da Angela, ed anche se spesso si inciampa ancora sugli ostacoli, erano determinate a percorrere la strada tracciata.

E sarà grazie a questo che il progetto sarà portato a termine con successo.

La sessione è stata di forte ispirazione, e mi ha dato buoni spunti per riflessioni ed approfondimenti sul tema.

Grazie Angela!

Ed eccoci ad uno dei talk dal  nome personalmente tra i più accattivanti, vuoi per il titolo, vuoi perché sono uno sviluppatore.

Mario Russo ha iniziato chiedendoci “Cosa vuol dire legacy code?”.
Dopo aver  ascoltato le risposte di tutti, Mario ci ha poi dato la sua risposta, e cioè che per legacy code lui intende quel codice, contenente valore, che abbiamo paura di modificare – per il rischio di “spaccare tutto”.
Come fare?
2 le domande sul quale poi Mario ha voluto ragionare e farci ragionare:

• Possibile gestire legacy code in modo pragmatico? Certo, seguendo alcune best practice, cercando di bilanciare qualità e time to market.
• Perchè preoccuparci del legacy code?

A questo punto, ci ha posto di fronte ad un bivio, come il Morpheus di Matrix nella sua slide: pillola rossa o pillola blu?

• Edit and Pray: andiamo avanti nello sviluppo aggiungendo ulteriore codice, e preghiamo che vada tutto bene
• Cover and modify: prendiamo il controllo del legacy code creandoci una rete di sicurezza grazie ai test, e solo dopo apportiamo modifiche

Ovviamente pillola rossa, che nel nostro caso ha voluto dire vedere come secondo Mario si affronta il legacy code

Prima di farci vedere con una sessione live del legacy code da gestire, Mario ci ha spiegato le 4 fasi:

• Understand: comprendere, studiare il codice. Per farlo, può essere utile cercare le keyword all’interno di esso, studiare lo stack trace per capire bene la catena di chiamate ai metodi.
  Dopodichè ci ha suggerito che può essere utile:
  • fare uno sketch refactoring del codice (estrazione metodi, rinominare variabili) ma solo per aiutarci a capire meglio; tali modifiche vanno poi buttate, per intenderci;
  • cercare di comprendere del codice complicato scritto da altri sviluppatori, solo per tenere la nostra mente allenata e magari fare nostri dei pattern
• Cover: è importantissimo implementare una suite di test che copra il 100% dell’area di codice che stiamo studiando.
  Mario ci ha suggerito di iniziare con test semplici, ad esempio in caso di if annidati, partire dal test sull’if meno annidato.
  Qualora fossimo di fronte a del codice mai visto prima, ha introdotto il concetto di Exploratory testing:
  • creo un metodo di test dal nome X
  • imposto un risultato atteso qualsiasi
  • eseguo il test e ottengo un failure
  • modifico il codice del test usando il risultato effettivo, lo rieseguo per farlo passare
  • rinomino il test

Quando si fa test, concediamoci delle licenze speciali, come ad esempio sfruttare il nostro ambiente di sviluppo per fare in sicurezza i refactoring necessari a rendere testabile il codice, e non preoccupiamoci della qualità di quello che scriviamo.

• Refactor: grazie ai test, stiamo imparando a conoscere e gestire il legacy code. Modifichiamolo!
  Facciamoci poi guidare dal test; se il test passa facilmente, applico la modifica (Change), altrimenti si va di refactoring.
  In questa fase, Mario ci ha suggerito di ricorrere ad una delle pratiche XP (talk di Andrea Francia), è cioè il Pair Programming.
  Ci ha anche consigliato, relativamente al codice nuovo che andremo a scrivere, di cercare di separarlo da quello esistente. Nella pratica, se so che devo immettere nuovo codice all’interno di un metodo, evitare di scrivere tale codice all’interno del vecchio metodo perché:
  • aumenterebbero i test da far passare, dato che aumenterebbe la complessità ciclomatica del metodo;
  • si complicherebbe ulteriormente la futura manutenibilità del codice

Prima di chiudere la spiegazione di questa fase, Mario ci ha ricordato di fare refactoring limitandoci alla funzionalità che stiamo studiando, pertanto limitare anche l’area di codice da analizzare. Anche se la tentazione di lasciarsi prendere la mano e sistemare tutte le brutture che capitano sott’occhio è tanta, è comunque più importante e produttivo concludere il task corrente senza distrazioni.

• Change: effettuare modifiche al codice, testarle e, una volta assicurati che le modifiche passano tutti i test, committare. In tal senso, ci ha suggerito l’uso di plug-in di versionamento del codice per l’ide che stiamo utilizzando, nonchè di effettuare commit molto frequenti, contenenti ognuno piccole ma significative modifiche.

It’s demo time!
Mario ha dedicato l’ultima parte del tempo a lui dedicato mostrandoci un IDE con 2 file:

• classe Car, contenente del legacy code da trattare; nel caso specifico, un metodo per calcolare l’affitto dell’auto contenente l’istruzione switch-case per il calcolo diverso in base al tipo di auto
• classe di test

La sessione live ha avuto lo scopo di mostrarci come, applicando il flusso precedentemente descritto, Mario ha gestito ed eliminato lo switch-case (code smell) dapprima cercando di capire il codice eseguendo i test e man mano applicando del refactoring semplice. Una volta compreso il codice, ha lavorato per eliminare lo switch-case ricorrendo al polimorfismo, quindi creando una classe per ogni tipo d’auto e personalizzando in ognuna di esse
il metodo che calcolasse il noleggio, tramite override del metodo della classe base.

Gran bel talk, ne siamo usciti tutti soddisfatti e muniti di un nuovo arsenale per affrontare gli agenti Smith del codice, e personalmente anche di un simpatico gadget per aver azzeccato la risposta alla domanda iniziale!
Qui le slide di Mario, contenenti anche il link al codice della sessione live.

Mauro Servienti ha detto la sua su di un tema molto interessante, e cioè il lavoro da remoto.

Il lavoro da remoto è sempre stata un’aspirazione dei dipendenti ma visto con scetticismo dagli imprenditori. Chi ha ragione? Vediamo la storia, reale, di un Remote worker.

E’ importante partire dall’assunto che la Persona deve essere il centro dell’interesse aziendale, il suo asset primario e per capire appieno forse è meglio partire dal basso, dalla fine.
Il nostro Remote worker lavora dove vuole e quando vuole e si assiste ad uno strano fenomeno: i lavoratori, lasciati liberi da vincoli orari, tendono a lavorare di più di quello che dovrebbero.
Seguendo il mantra di organizzare il lavoro sulla propria vita privata (del resto è meglio poter andare in palestra di giorno, con poca gente, che la sera dopo il lavoro dove si concentra la maggior parte dell’utenza).
Inoltre lavora su quello che vuole (poi capiremo meglio il perché di questa affermazione)!
Più che Distributed, questo Remote Worker piace definirsi come Dispersed dato che non ci sono concittadini e l’azienda ha personale in 17 time zone.

Fino a 3 anni fa questa azienda era tradizionale; ma quindi come si è arrivati a questo nuovo paradigma?
L’azienda ha notato che le decisioni sbagliate sono state prese in solitaria, dove solitaria ha l‘accezione di “senza un consulto” e che le autorità e le regole possono portare solo a sottomissione e\o adattamento mentre le metriche servono solo a permettere imbrogli al sistema: una persona fa esattamente quello che permette di avere una buona metrica e non è detto che vada nella stessa direzione aziendale.
Un’azienda non può essere il suo organigramma: l’organigramma è una collezione di caselle in cui le persone sono inserite e soffoca i talenti che esse hanno in altri ambiti (esempio: ti ho assunto per fare il developer e sei un developer anche se magari puoi essere bravissimo nella stesura dei requisiti o nelle relazioni).
Tutto ciò è come avere un Post-it sulle persone.
Ogni dipendente dovrebbe fornire una valutazione di se stesso sui suoi punti di forza; e l’azienda dovrebbe accompagnare, a questa valutazione, i giudizi dei colleghi per confermare o bilanciare l’autovalutazione.
La struttura aziendale è quindi da considerarsi flat, non gerarchica: un impiegato può alzare la mano e dire al CEO aziendale che sta sbagliando, ovviamente motivando l’intervento. Non ci deve quindi essere situazione in cui uno ha autorità su di un’altra persona ma “dimenticare” è difficile, le persone tendono ad agire in base alle esperienze pregresse; ogni decisione dovrebbe invece essere calata nell’ottica della nuova mission aziendale: SAFE BY DEFAULT.

Ma come organizzare quindi il lavoro quotidiano?

Nel caso specifico, il codice Open Source è su GitLab; quando si apre un task si forma, intorno ad esso, una squadra, denominata Squad, di figure responsabili del processo (PO e Scrum Master in genere); anche il Marketing è coinvolto e ognuno può fare parte della Squad, a turno, secondo una logica FIFO.
A seguito della Squad si forma anche una Task Force per risolvere il task aperto, che esso sia un baco, una miglioria o altro.
E’ più importante il processo del risultato perché se il processo è buono allora lo sarà sicuramente anche il risultato; da ciò deriva che Squad e Task Force sono libere di osare perché nessuno sarà colpevolizzato in prima persona in caso di fallimento: è l’intera Task Force a fallire, non il singolo. Se uno non ha alzato la bandierina prima, allora anche parte della colpa è sua.
Alla base della piramide resta comunque la fiducia; la fiducia che il proprio collega farà la cosa migliore con le informazioni di cui è in possesso.

Questa storia dimostra che lavorare da remoto e creare profitto è possibile ma, come detto, alla base di tutto deve esserci la fiducia reciproca tra colleghi e imprenditori; che entrambi facciano il loro lavoro con competenza e impegno ovunque si trovino e non per forza ancorati ad una scrivania.

Ammetto, il talk che più ha stuzzicato la mia curiosità, assieme a quello sul legacy code curato da Mario Russo.

Che cos’è la 4^ rivoluzione industriale? Come affrontarla, lavorando secondo i principi e le metodologie del mondo agile, nel mondo industriale hardware?

Paolo Sammicheli ci ha portato l’esempio di Wikispeed, azienda fondata da Joe Justice e oggi affermata e riconosciuta che propone progetti e pezzi per la realizzazione di automobili, nacque inizialmente per partecipare all’Automotive X Prize, un concorso che metteva in palio 10.000.000 di dollari a chi fosse stato di costruire un’automobile a più basso consumo su 100 km.
Fu sorprendente come il team di volontari (eh sì, volontari!) di Joe riuscì a classificarsi decimo in una competizione aperta al mondo intero.
Come ci riuscirono?
Applicando alcuni principi dell’eXtreme Manufacturing (che prende spunto da eXtreme Programming):

• Pair Programming sull’hardware, lavorando a coppie sui componenti dell’automobile
• Sprint da 1 settimana
• realizzando un progetto dell’automobile Object-Oriented style

Paolo ha poi proseguito raccontandoci della sua esperienza ad un gathering sull’agile in USA dove conobbe Joe Justice. Durante quei giorni sperimentò, lavorando in team peraltro assieme ad altri italiani, la realizzazione di un’automobile tramite Wikispeed, e lo stupore e la soddisfazione che ebbe dato che in un 1 giorno di lavoro furono in grado di montare ruote, il braccio dello sterzo e altre componenti.
Tale stupore ed euforia hanno portato Paolo, una volta tornato in Italia, a fondare Scum for Hardware (Scrum4HW) una community per agilisti hardware, con l’intento di riunire tutti coloro che come lui hanno il desiderio di migliorare il loro lavoro cercando di rispondere ad un mondo in continua evoluzione.

Un mondo dove secondo Klaus Schwab, fondatore del World Economic Forum, non vige più la regola “il pesce più grande mangia il pesce più piccolo”, bensì “il pesce più veloce mangia il pesce più lento”.
Un mondo dove le esigenze cambiano, di natura e complessità, ed è proprio quest’ultimo aspetto che la 4^ rivoluzione industriale, secondo Paolo, cambierà.
Per chiarire meglio ciò che intende, ci ha mostrato in una slide il modello Cynefin di Dave Snowden:

Secondo Snowden, in base alla complessità del problema, bisogna adottare diverse strategie:

• Obvious: è tutto noto, mi organizzo per gestirlo
• Complicato: conosco il problema, devo studiarlo\analizzarlo, poi mi organizzo per gestirlo
• Complesso: non so, il problema non è deterministico, eseguo una serie di esperimento poi, in base ai risultati, mi organizzo per gestirlo
• Caotico: non so nulla, agisco e mi regolo di conseguenza

Ma come applicare i principi e le pratiche del mondo agile nel settore industriale dell’hardware?
Paolo ci ha dato una sua risposta con 2 parole: Industrial Agility, spiegandoci come:

• Pratiche
• Metodologie
• Principi
• Valori

sono collocati su di un iceberg, dall’alto verso il basso.
Tornando alla sua esperienza con Joe Justice e il forte interesse al connubio agile + hardware, ci ha mostrato il manifesto agile per progetti hardware, redatto da lui, Justice ed altri agilisti:

Prima di concludere, Paolo ci ha regalato un pensiero sulla 4^ rivoluzione industriale, tratto dall’articolo Design Principles for Industrie 4.0 Scenarios:

Posso dire che la curiosità e aspettative sono state ampiamente soddisfatte.
Porto a casa un’idea molto più chiara di quello che vuol dire 4^ rivoluzione industriale, raccontato da una persona in grado di trasmettere tutta la passione ed energia in quello che fa.
Bravo Paolo!

Alessandro Bonometti ha organizzato il suo talk in due fasi:

• introduzione all’approccio del  Domain-driven design, o più comunemente ddd, in un progetto software
• pro e contro dell’utilizzo del ddd su di un progetto al quale ha lavorato.

Che cosa s’intende quindi per ddd?
Un approccio dello sviluppo del software che risolve problemi complessi connettendo l’implementazione ad un modello in evoluzione. E’ basato sulle seguenti premesse:

• Focus primario del progetto su domini delle entità e la loro logica.
• Basare il design sulle entità di dominio.
• Collaborazione tra tecnici ed esperti di dominio per definire in maniera iterativa un modello concettuale che possa essere applicato ai particolari problemi del caso.

E definizioni fondamentali:

• Dominio: un contesto di conoscenza (ontologia), influenza, o attività. L’area in cui l’utente lavora con il software è il dominio dello stesso.
• Modello: un sistema di astrazione che descrive specifici aspetti del dominio e che può essere usato per risolvere problematiche relative alla definizione del dominio.
• Ubiquitous Language: Un set di termini create attorno al modello di dominio utilizzati dal team per indirizzare e contestualizzare i problemi da risolvere durante l’implementazione.
• Contesto: L’ambiente in cui un determinato termine assume un determinato significato.

Durante la spiegazione, Alessandro ci ha più volte citato il libro Domain-Driven Design: Tackling Complexity in the Heart of Software di Eric Evans, dove vengono introdotti una serie di concetti chiave e pratiche. ll libro è fortemente orientato a descrivere lo strato di dominio in un sistema orientato agli oggetti con un’architettura multistrato, o a cipolla.

Alessandro ha poi proseguito spiegandoci come il pattern Command Query Responsibility Segregation, in cui sostanzialmente la logica di lettura è separata dalla logica  di elaborazione e dove le entità sono ben definite e chiare, possa essere considerato in un approccio ddd.

Ma perché “fighting the leviatan”?
Alessandro ha voluto raccontarci come, grazie all’approccio domain-driven design, sia riuscito, assieme al suo team, a districarsi tra i tentacoli di un leviatano appunto rappresentato da un’applicazione, scritta interamente in Access, che doveva essere completamente riscritta…panico e delirio iniziale, dato dalla confusione architetturale e dei processi dell’applicazione, che pian piano hanno trasformato in un’architettura multistrato appunto.
Nel caso specifico, ci ha poi spiegato come l’adottare un’architettura Enterprise Service Bus li avesse particolarmente aiutati nel ridisegnare l’architettura in maniera più chiara e semplice.

Prima di salutarci, Alessandro ci ha raccontato dei pro e contro nell’adottare un approccio Domain Driven Design.
Al fine di mantenere il modello come un costrutto del linguaggio puro e utile, il team deve tipicamente implementare l’isolamento con grande attenzione e prestare attenzione all’incapsulamento all’interno del modello di dominio. Di conseguenza, un sistema costruito attraverso il Domain Driven Design può essere oneroso in termini di costo di sviluppo.
Quindi un sistema basato sul Domain Driven Design ha un costo relativamente alto, per quanto offra certamente numerosi vantaggi tecnici, ad esempio la manutenibilità.

Un talk personalmente tanto interessante quanto non sempre facile da seguire, infatti credo proprio che seguirò il consiglio di Alessandro acquistando il libro di Eric Evans. I leviatani sono sempre pronti a divorarci!

La giornata si è conclusa laddove è iniziata, in Auditorium, dove Fabio e gli altri organizzatori dell’evento hanno dato il “rompete le righe” dopo aver ringraziato gli speaker e tutti i partecipanti.
Fabio ha colto l’occasione per ricordare i prossimi appuntamenti curati da Italian Agile Movement, tra i quali l’agile day a Napoli, simpaticamente nominato Agile O’Day dagli organizzatori della Agile Community Campania.
Prima di salutarvi, vorrei anche io spendere due parole sull’organizzazione di questo mini agile-day.

Molto carina anche l’idea di lasciare un feedback via post-it su di un foglio, che sicuramente aiuterà a migliorare ulteriormente i futuri agile e mini agile day

La location, semplice e comoda da raggiungere; anche le aule e lo spazio ristoro a noi dedicato sono state molto confortevoli.
L’organizzazione della giornata, curata in ogni dettaglio: dalle indicazioni precise per parcheggiare l’auto, ai talk tutti (o perlomeno, quelli che ho potuto seguire) molto interessanti.
La ricchezza degli argomenti trattati dai talk e dai 3 workshop organizzati dei quali mi hanno parlato molto bene.
Le persone, perchè da Fabio Ghislandi  a Simone Longoni (altro membro dell’Italian Agile Movement) agli speaker, sono stati sempre disponibili al dialogo e confronto.