IAD Brescia – 10 Novembre 2018

Venerdì

Sono stati organizzati diversi interessanti workshop sia tecnici che non, dalle mappe mentali al coderetreat, dalle powerful question alle strategie di testing usando Kotlin, il tutto condito con un po’ di continuous delivery del collega Gianni Bombelli.
E’ stato un vero peccato non esserci, ma faccio mea culpa. Sfortunatamente (o fortunatamente 😉 ) i biglietti per i workshop sono letteralmente volati 🙂
Almeno alla cena dovevo esserci, non potevo assolutamente perdermi questo momento di festa nonché occasione per fare nuove conoscenze e perché no, parlare di agilità.

Conferenza del Sabato

Sin dalle 8:30 i primi avventori si sono presentati nell’enorme atrio del dipartimento, accolti dallo staff composto dai membri dell’Italian Agile Movement e da diversi ragazzi volontari pronti a consegnare borsette, badge, magliette dell’evento e fornire indicazioni sull’ubicazione delle aule.

Colgo l’occasione per ringraziare tutti coloro (sponsor e volontari) che hanno reso possibile questa due giorni di workshop e conferenza.

Quest’anno, oltre al consueto spazio dedicato al coffee break, c’era un ulteriore luogo dove poter bere del caffè e fare 2 chiacchiere agili.
Tutti conosciamo “Quattro amici al bar” di Gino Paoli, giusto?
Ecco, i ragazzi di Agile Reloaded, in collaborazione con noi di Intré, hanno pensato di organizzare lo stand come se fosse un bar, quindi tavolini, sedie…e caffè.

E’ tempo di iniziare a parlare della giornata. Questo il programma, composto da talk sia tecnici che non.

Introduzione

“Cosa mi interessa maggiormente? Oh no, ma questi 2 talk sono in parallelo!”

Questi e mille altri dubbi frullavano nella mia testa (e immagino in quella degli altri partecipanti), viva l’abbondanza 🙂

Tutti in aula magna ora, che si apra il sipario dell’agilità!

Alessandro Giardina, tesoriere dell’Italian Agile Movement, ha introdotto la giornata parlandoci e soprattutto mostrandoci i numeri relativi all’organizzazione di questo evento:

• oltre 151 proposte di talk
• più di 800 iscritti.

Per il 2019 sono già stati confermati diversi eventi del circuito agile venture, a testimonianza di un interesse e di una comunità in continua crescita.

Keynote

Mike Burrows, riconosciuto per il suo lavoro pionieristico in Lean, Agile e Kanban e per la sua difesa di approcci partecipativi e orientati ai risultati al cambiamento, alla trasformazione e alla strategia.
E’ fondatore di Agendashift, un modello Lean-Agile di engagement che aiuta tutti i livelli  in un’organizzazione, dai singoli collaboratori alla leadership senior, a partecipare e partecipare al cambiamento Lean-Agile.
E’ anche autore di 3 libri:

• Kanban from inside.
• Agendashift: Outcome-oriented change and continuous transformation.
• Right to Left: the digital leader’s guide to Lean and Agile (disponibile dal 2019).

Nel tempo a sua disposizione, Mike ha cercato di rispondere ai seguenti interrogativi:

• Come si presenta un processo di consegna Lean-Agile?
• Se dovessi descriverne uno, dove cominceresti – “da sinistra”, con un arretrato di lavoro da scavare, o “da destra”, con i bisogni soddisfatti dal software funzionante?
• E la differenza di prospettiva è importante?

Con l’intento di paragonare 2 diversi modi di intendere un processo Lean-Agile, portando come esempio il suo modello agendashift.

Pensiamo ai mattoncini Lego. Cosa ci viene in mente? Che immagine associamo?

Da un lato (right), pensiamo subito ai bambini che giocano assieme, dall’altro (left), lo si può intendere come un insieme di mattoncini.

Lo stesso vale per un processo agile. Riprendendo l’analogia con i mattoncini Lego, possiamo intendere un processo agile in 2 modi:

• left: assieme di item in un backlog in Jira
• right: insieme di persone che collaborano per raggiungere un obiettivo condiviso

Mike ha posto la stessa domanda in merito allo scrum, al SAFe. Come li intendiamo?

• left: un insieme di oggetti, dal backlog al planning, a meeting…
• right: obiettivi condivisi perseguiti obiettivo per obiettivo.

Quando adottiamo un modello, processo Agile, come lo intendiamo? (dalle slide di Mike):

• left:
  • prescribe a process
  • justify it
  • roll it out
  • deal with the consequences
• right:
  • agree on outcomes
  • generate some options
  • test assumptions
  • begin to treat change as a part of the day job

La differenza di prospettiva quindi è molto importante.
Si dovrebbe iniziare dal valore anzichè dal risultato che si vuole ottenere.
Questa decisione pilota quindi un approccio diverso al modello agile da adottare ed applicare.

Agendashift può essere una soluzione.

Citando il suo libro Agendashift: outcome-oriented change and continuous transformation, questo modello ha una triplice finalità:

• Aiutare l’agente di cambiamento a strutturare il proprio impegno con la propria organizzazione cliente e il proprio personale.
• Assistere l’organizzazione del cliente a coinvolgere il proprio personale in modo significativo nel lavoro correlato al cambiamento.
• Dare supporto alle parti coinvolte nella trasformazione dell’organizzazione a impegnarsi in modo costruttivo con il resto dell’organizzazione, in modo che entrambe possano prosperare.

E si presenta sotto forma di cinque attività:

• Scoperta: stabilire un senso di direzione condiviso, identificare i bisogni, le ambizioni e le aspirazioni, nonché i risultati a breve termine.
• Esplorazione:  basandosi sui risultati di un assessment iniziale, identificare le opportunità di cambiamento, articolandole come risultati,  e scegliere approcci di gestione del cambiamento appropriati.
• Mappatura: visualizzazione di piani e priorità, testing thinking, identificazione delle lacune.
• Elaborazione: Mantenere il processo di cambiamento alimentato da idee, inquadrare le opzioni come ipotesi e svilupparle come esperimenti.
• Operazione: le tecniche e gli anelli di feedback necessari per sostenere i cambiamenti a lungo termine, vengono trattati come un vero lavoro.

Queste attività possono fornire una struttura per workshop (il libro propone una serie di esercizi) o per attività di engagement che coprono un periodo di settimane o mesi.
Inoltre, identificano cinque attività prioritarie che sono fondamentali per l’applicabilità del modello Agendashift:

• Start with needs: prendi coscienza di cosa sia necessario, sulla base dello stato attuale dell’organizzazione (chi siamo? dove siamo?) per perseguire l’obiettivo che ci si è posti.
• Agree on outcomes: esplorare un panorama di ostacoli e risultati, arrivare ad un accordo sui risultati come base per il cambiamento.
• Keep the agenda for change visible: uso di visual mapping per organizzare, stabilire delle priorità, verificare e comunicare.
• Manage options, testing assumptions: generare e selezionare opzioni, formulare ipotesi e sviluppare esperimenti che convalideranno o invalideranno le ipotesi chiave.
• Organise for clarity of intent, speed of decision-making, and alignment of impact: organizzare esperimenti e linee di comunicazione tali che:
  • È chiaro a tutti cosa stia succedendo e perché.
  • Le decisioni vengono prese rapidamente dalle persone giuste.
  • Le singole azioni si combinano per far si che l’organizzazione continui a muoversi nella direzione concordata.

Un keynote davvero interessante nonché istruttivo. Non ero a conoscenza di questo modello agile e dei principi che ne stanno alla base, grazie Mike!

Quanto conosciamo i nostri utenti?

Agli Italian Agile Days di Urbino dello scorso anno Emanuele Mantovani, collega nonché Head of Design di Intré e di Thanks Design, ci aveva parlato di UX, Scrum e gilde spiegando come appunto il suo team di designer lavorasse in un contesto agile, passando in rassegna i differenti modi di collaborazione con il resto del team.
Emanuele aveva posto l’attenzione su 2 punti:

• quando progettiamo non abbiamo risposte certe, bensì ipotesi
• iterazione sì, ma non basta (da un’idea iniziale del PO, si va avanti per tentativi).

Come fare?

Lo UX design attraverso la ricerca con gli utenti ci può aiutare.

Eccoci dunque arrivati al tema sul quale verte il talk 🙂

Quali sono gli strumenti da usare per comprendere gli utenti e quindi generare valore con essi?
Che vuol dire soddisfare l’utente?
Creare valore con l’utente?

Vediamo come l’esperienza ed il lavoro di Emanuele possano dare le giuste risposte.

E’ importante considerare l’età dell’utente:

• Le vecchie barriere competitive non bastano più, né per vincere e tanto meno per sopravvivere.
• Nell’era pre-Internet, il venditore aveva il controllo. Oggi invece è il cliente che ha il controllo del business. Si pensi a tutte le volte che, prima di acquistare un prodotto, facciamo una ricerca sul web per confrontare i prezzi.
• Si salva chi riesce a creare, offrire esperienze utente migliori, la sfida è questa.

Per meglio comprendere quest’ultimo punto, Emanuele ha portato l’esempio di FedEx.
Nonostante la compagnia registrasse buone performance nel numero di consegne, avevano ricevuto feedback bassi da parte degli utenti.
Si rivolsero quindi ad uno studio di designer per capire, attraverso un lavoro di analisi, quale fosse il motivo. Scoprirono che molti utenti erano sfiduciati nel vedere pacchi su pacchi impilati. Ciò trasmetteva sfiducia, portandoli magari a rivolgersi altrove per il futuro.
Come risolsero il problema? Semplicemente nascondendo queste pile di pacchi agli occhi dell’utente in un secondo locale del magazzino, lasciando una parete pulita o comunque in ordine.

Cosa insegna il caso FedEx?

Che avere buone performance non basta.
Focalizzarsi non solo sui bisogni dell’utente, ma anche sull’esperienza che offriamo.

Cosa intendiamo per esperienza?

Secondo Emanuele, per esperienza si intende tutto ciò che una persona vive quando interagisce con i prodotti.

Si possono identificare 3 fasi di esperienza:

• aspettativa
• interazione con il prodotto\servizio
• ricordo

Quando sviluppiamo un prodotto\servizio, tenere conto di questi valori:

• utilità: produrre qualcosa che sia utile
• usabilità: il prodotto deve essere facile da usare
• piacevolezza: l’esperienza utente deve essere piacevole: nell’esempio precedente, FedEx falliva in questo
• affidabilità (trasversale ai precedenti): pensando ad una qualunque app per smartphone, può essere la più bella ed usabile, ma se il server cade ogni 5 min…

Come possiamo generare un prodotto che rispetti questi valori?

Portando “a bordo” gli utenti e validando le ipotesi con loro.

Vediamo come, per i primi 3 valori, Emanuele ed il suo team lavorano e con quali strumenti.

Utilità

Il prodotto risponde ai bisogni degli utenti? Che strumenti abbiamo a disposizione?

• Interviste: raccolta di dati qualitativi.
• Questionari.
• Focus group, workshop.
• Ricerche sul campo.
• Metriche analitiche: per l’e-commerce ad esempio, dati quantitativi.

Usabilità

Che strumenti abbiamo a disposizione?

• Expert review: svolto dal designer, esistono linee guida per analizzare una UI per capire se rispetta determinati standard.
• User testing: svolto con utenti reali, tramite sessioni di gruppo si chiede loro di completare alcuni task osservandoli durante il lavoro, magari misurando alcune metriche (ad esempio: tempo impiegato per completare un task, numero di click).
• Questionari: per misurare l’usabilità percepita.

Piacevolezza

Citando Aarron Walter e quanto riportato nel suo libro Designing for emotion, esistono 2 tipologie di piacevolezza:

• Superficiale: data dagli elementi all’interno di una UI (look and feel, naturalezza delle interazioni, animazioni fluide, multisensorialità) che rendono appunto l’interazione piacevole.
• Profonda: ottenuta eliminando i cosiddetti pain point (tornando all’esempio di FedEx, rimuovendo la catasta di pacchi) mantenendo usabilità e utilità.

Che strumenti abbiamo a disposizione?

• interviste
• questionari
• ricerche sul campo
• recensioni e valutazioni
• riconoscimento delle espressioni del volto, risonanza magnetica del cervello, conducibilità derma (tanto più sudo, tanto più sono emozionato e quindi contento).

Ora che abbiamo compreso come realizzare un prodotto utile usabile e piacevole, vediamo con Emanuele un caso di studio relativo alla riprogettazione di un prodotto esistente, focalizzandoci sulla fase di Starting (da 2 settimane a 1 mese).

Attori coinvolti: PO, team scrum, responsabili dei dipartimenti, utenti finali.
Che elementi devono emergere in fase starting?

1. Obiettivi del progetto.
2. Analisi prodotto attuale.
3. Utenti: loro bisogni e journey (attività all’interno del prodotto).
4. Formulazione di macro ipotesi.

1. Obiettivi

Importanti per la fase di ricerca utente. Senza obiettivi non c’è progetto
Due domande iniziali da porsi:

• Perché questo prodotto?
• Come mai questo progetto?

Che strumenti abbiamo a disposizione?

Workshop con po, team, responsabili dei dipartimenti, durante il quale si chiede a ciascun partecipante:
Quali obiettivi si vuole raggiungere?
Quali bisogni ha l’utente?
E di conseguenza formulare delle macro ipotesi. Ogni partecipante poi espone agli altri le sue idee.

L’obiettivo di questa fase? Arrivare ad avere una visione condivisa sugli obiettivi e i bisogni dell’utente.

2. Analisi del prodotto e del contesto

Nella sua esperienza di coaching UX Emanuele ha notato come anche nel team dei designer si avessero idee poco chiare sul prodotto.
Quindi è utile coinvolgere tutto il team in questa fase.

Che strumenti abbiamo a disposizione?

• Workshop con team ed expert del prodotto, mappando le diverse esperienze utente che si hanno.
• Questionario sull’usabilità per appunto misurare l’usabilità del prodotto.

L’obiettivo di questa fase? Far emergere le problematiche legate all’usabilità; valutare il grado usabilità percepita dagli utenti.

3. Utenti

Come lavorare con gli utenti?
Si devono conoscere:

• ruolo
• bisogni
• attività
• relazioni
• background.

Che strumenti abbiamo a disposizione?

• Interviste da 1 o 2 ore con ogni utente con uso dell’applicativo, per meglio comprendere il loro background, bisogni, eventuali problematiche di utilizzo.
• Workshop con un utente per ogni categoria , per realizzare un product canvas (informazioni sull’utente, bisogni, aspettative) e compilazione del journey.

Alla fine di queste 4 fasi, si hanno:

• Elenco obiettivi.
• Analisi del prodotto attuale.
• Analisi dell’usabilità.
• Informazioni sugli utenti, loro bisogni e journey.
• Elenco feature aggiuntive.

Da ciò si può quindi formulare delle macro ipotesi, come?

• Durante il cosiddetto Sprint 0 dove il team dei designer sviluppa il wireframe, cioè schermate rappresentative della futura versione dell’applicazione.
• Con un workshop per “mergiare” utenti e wireframe, cioè mostrare loro il wireframe e validarlo assieme.

Che dire Emanuele, il viaggio nel mondo dello UX design si fa sempre più avvincente. Grazie per questa interessantissima presentazione!

I’m a mediocre developer

Ferdinando Santacroce si sente uno sviluppatore mediocre, e vorrebbe capire come migliorarsi.
Racconterà di alcune figure lavorative incontrate nella sua esperienza, dirà la sua, consapevole che non tutti potranno essere d’accordo.
Anche tu caro lettore, qualora possa sentirti offeso da ciò che stai per leggere, prenditela pure con Ferdinando non con me 🙂

Partiamo con 2 riflessioni che Ferdinando fa e continua a fare:

• Mediocrità: capita a volte di sentirsi inadeguati nel proprio lavoro.
• La percezione che si ha degli altri, soprattutto quelli bravi.

Ma che cosa si intende per mediocrità? 
Qualcosa che sappiamo fare, ma per il quale si hanno carenze.

Essendo Ferdinando uno sviluppatore, di quali carenze parla?

• Carenze tecniche (conoscenza del linguaggio di programmazione, framework).
• Difficoltà nel risolvere problemi.
• Generale senso di inadeguatezza.

Questo senso di inadeguatezza che Ferdinando sente quando:

• Capita di dimenticarsi di alcune cose basilari, e allora via di ricerca su Google e inevitabile link a Stackoverflow.
• Quale linguaggio devo imparare per primo?

Eppure un tempo non era così, pensava di essere bravo. Da assistente di laboratorio in una scuola superiore, aveva realizzato il sito della scuola, e poi il registro dei voti elettronico!

WOW…e poi?

Ha deciso di cambiare mestiere, di fare lo sviluppatore software…ed ecco quel senso di inadeguatezza, dovuto al fatto che tutto ciò che pensava di sapere era in realtà una goccia nel mare della conoscenza…si è reso conto di non essere più così bravo.

Avete mai sentito parlare dell’effetto Dunning-Kruger?

L’effetto Dunning-Kruger è una distorsione cognitiva a causa della quale individui poco esperti in un campo tendono a sopravvalutare le proprie abilità autovalutandosi, a torto, esperti in quel campo. Come corollario di questa teoria, spesso gli incompetenti si dimostrano estremamente supponenti. – Wikipedia

Ferdinando si sentiva talmente incompetente da non capire nemmeno quanto potesse essere competente.

In fondo, sai di sapere perché conosci quella tal cosa.

E quando scopri qualcos’altro di nuovo? Lo impari, certo, ma scopri altrettante cose  che non sai.

Si passa quindi da:
“Uao, che figo che sono, quanto sono in gamba (ma so poco)”
a
“So un sacco di cose, ma penso di non essere in gamba”

Ma torniamo al discorso della gente brava, della percezione che si ha di queste persone. Ecco, da qui in poi potresti non essere d’accordo, ricordati che sono opinioni di Ferdinando eh 🙂

Cosa si intende per quelli bravi?

Non di certo gli scagnozzi di don Rodrigo (grandissimo Ferdinando 🙂 ) bensì coloro i quali lo sono per davvero.

Quelle persone da accogliere a braccia aperte, intelligenti, perseveranti, generose, geniali. E non:

• Gli individualisti, impazienti, da prendere con le pinze.
• Bravi ma solo perché:
  • lavorano nella stessa azienda da decenni
  • conoscono benissimo una cosa e se la tengono stretta, si barricano nel loro castello ed impediscono a chiunque di avvicinarsi
  • si immolano per la causa, lavorano sempre (forse non hanno una vita privata).

I bravi per davvero sono ad esempio, Ken Thompson e Dennis Ritchie (hanno sviluppato il linguaggio C, Go…).
Poi esistono i bravi perché geniali come Steve Jobs.

Ma.

Se sei un apple addicted, passa oltre.
Che combinò Steve Jobs tanto da indisporre Ferdinando?
Steve Jobs aveva scoperto, o qualcuno gli aveva suggerito, un bug nella legge statale che regola l’affissione delle targhe ai veicoli a motore.
In California il proprietario di un’autovettura nuova ha tempo sei mesi per apporre la targa al proprio veicolo.
Steve aveva stretto un accordo con un concessionario Mercedes locale e aveva sottoscritto un leasing che gli permetteva di cambiare auto, appunto, ogni sei mesi.
E quindi non prendere multe in caso ad esempio avesse posteggiato l’auto nel posto riservato ai disabili…

Poi esistono i bravi con riserva.
I silos, come li chiama Ferdinando.
Come accennato prima, coloro che sì hanno la conoscenza, ma dato che hanno faticato anni per ottenerla, se la tengono ben stretta.
Ad esempio, gli sviluppatori che per anni hanno lavorato su una applicazione, quindi solo loro sanno dove e come mettere mano al  codice.
Una sorta di conoscenza tacita: pochi lo sanno, e se lo tengono stretto.
I guardiani del castello, per intenderci. E Ferdinando lo è stato, negli anni.
Persone che si barricano nel loro castello di conoscenza, e non permettono a nessuno di entrare.

Poi ci sono i bravi perché lavorano nello stesso posto da anni:

• conoscono il dominio
• conoscono tutti i segreti, i dettagli

Sono custodi gelosi della conoscenza tacita, e fuori da questo mondo sarebbero in difficoltà

Poi ci sono gli eroi.
c’è un bug nell’applicativo, lo sistemo subito, a costo di stare davanti al computer tutta la notte.
“Tu vai pure a casa, ci penso io.”

Poi ci sono gli stakanovisti.
Simili agli eroi, grande devozione al lavoro, con la differenza che lo fanno inconsapevolmente.

E i bravi da contratto.
Ferdinando ha avuto esperienze con figure quali:

• analisti
• solution architect
• software architect.

Imposte dall’alto, piombate da un certo momento nel progetto nel quale lavorava.
Sono anti pattern. Perchè?
Per quanto sia scritto sul loro profilo LinkedIn, o sul cartellino, non si rivelano utili, o meglio si fanno vedere in fase di decisione architetturale del progetto, poi però svaniscono nel nulla…Quindi sono solo bravi ma da contratto.
Ma se sei un solution architect e sei bravo per davvero, sei una figura di tutto rispetto.
E’ che in alcuni casi è solo scritto sul cartellino.

Ricapitolando, esistono i bravi, i bravi per davvero, i geni, gli eroi…e Ferdinando? Lui è mediocre, si sente inadeguato

Quindi?

Per fortuna non è l’unico.

Un certo David Heinemeier Hansson, uno che “qualcosina ha fatto” (sviluppatore del linguaggio Ruby, Ruby on rails framework per applicazioni web, conosciuto anche nel mondo di corse automobilistiche come DHH) scrisse un twit nel quale ammetteva di fallire se qualcuno gli avesse chiesto di scrivere alla lavagna l’algoritmo del bubble sort 🙂

Ferdinando riconosce 4 categorie della conoscenza:

• Cose che so di sapere.
• Ciò che so di non sapere.
• Tutto ciò cose che non so di sapere.
• Cose che non so di non sapere.

Bonus: cose che pensi di sapere, ma che poi non sono vere.

Giorno dopo giorno si passa dalla consapevolezza di sapere poco, di non sapere, di sapere di non sapere…

Come si può limitare questo senso di inadeguatezza?

Scegli bene come investire le tue risorse:

• Non si può imparare tutto:
  • Cerco di scegliere le cose di più alto valore, senza quindi dover dipendere da Google (es: come scrivere test di una app legacy? Non facile da trovare).
  • Imparare i fondamentali.
  • Keep it simple come processo di apprendimento.

Cercare di essere una t-shaped.

• I-shaped: persona esperta ma in una sola cosa. Ad esempio, conosco il linguaggio Cobol, sono fenomenale in questo. E basta.
• Generalist: credono di sapere un pò di tutto, ma esperto in nulla.
• T-shaped: capace in un bel pò di cose, esperto in una di queste.

Come ci dobbiamo comportare con tutte quelle categorie di bravi, gli eroi, gli stakanovisti, i guardiani?

Non sentirti mediocre nei confronti di queste persone, aiutale.

Vi ricordate dei guardiani, dei silos? Lavoriamo con loro, impara, coinvolgili, svuotali o alla peggio abbattili!
Sconfiggi i guardiani insomma, come ne parla Paolo D’Incau nel suo talk I terribili guardiani della codebase (seguito allo scorso IAD di Urbino).

Salva gli eroi: se sei sempre in emergenza, niente è più in emergenza.
Se c’è un bug, ma è ora di andare a casa…ci pensiamo domani, comunque non muore nessuno, non ammazziamo nessuno.

Rifiuta i falsi titoli: mi impongono il solution architect, non va bene.
Piuttosto chiedo consulenza ad uno esperto per davvero, che ti segue e ti aiuta.

E gli stakanovisti? Secondo Ferdinando, barano.
“Ehi, hai visto? Ora il bug non c’è più, sai ci ho lavorato 14 ore”. Molte grazie.

Ma ricordatevi sempre, se l’azienda per il quale lavorate tutti questi personaggi NON SONO UN PROBLEMA beh…Ferdinando suggerisce che forse è arrivato il tempo di cambiare azienda.

E i bravi per davvero?

GODIAMOCELI. Sono un dono, coinvolgiamoli spesso, facciamoci aiutare.

Ricordate John Von Neumann? Un altro bravo per davvero.
Ferdinando ha riportato un bell’aneddoto su di lui.

Chiunque avesse formulato una tesi, un’idea brillante, per prima cosa la mostrava a von Neumann per capire se fosse davvero una tesi valida. In poco tempo riusciva a capire se la tal tesi potesse reggere o meno.

Tirando le somme, Ferdinando ha capito perché si sente mediocre, e anche come smettere di sentirsi tale.

Volete sapere come? Guardate le foto.

Grandissimo Ferdinando, un talk tanto divertente quanto ricco di spunti di riflessione.

Qui le slide del suo personalmente geniale intervento.

Un approccio empirico alle trasformazioni agili

Piccola premessa: questa presentazione rientra nel gruppo di talk Agile goes to Hollywood, che ha l’intento di dimostrare quanto il processo Agile sia sempre più adottato da grandi realtà e quindi diventando sempre più famoso, portando le esperienze accumulate negli anni sul campo dagli agile coach di Agilereloaded.

In questo senso, un altro talk molto interessante è Agile goes to Hollywood: portare agile all’interno di una grande azienda tenuto da Giovanni Puliti (con l’aiuto di suo figlio 🙂 ) durante l’agile venture di Prato.

Torniamo a noi.

Pino Decandia e Stefano Leli, agile coach e trainer per Agilereloaded, hanno proposto una sessione durante la quale sì, si è parlato di agilità ma non con l’intento di vendere un mezzo, convincere ad usare uno strumento, bensì spostare il focus sull’empiricità, cioè sull’esperienza.

L’agilità si fonda sull’empiricità?

Secondo il processo empirico, si osserva il contesto e si provano a fare delle ipotesi, esperimenti per capire come comportarmi.

Ricordiamoci sempre il modello Cynefin di Dave Snowden

OSSERVIAMO, per prima cosa.

Che cosa?

L’azienda, la sua cultura. Capire e carpire informazioni parlando a tutti i suoi livelli, dallo sviluppatore al management, sulla sua organizzazione, e magari captare anti-pattern che non permettono all’azienda di essere veramente agile.

Che cos’è un anti-pattern?

Un modello, comportamento, messo in atto per migliorare le cose ma che in realtà le peggiora.

Vediamo quindi in quali anti-pattern Pino e Stefano si sono imbattuti  durante la loro esperienza.

Business e dev divisi

In molte aziende, questi 2 reparti (business e sviluppo appunto) è come se stiano in 2 torri separate.

Lavorano a compartimenti stagni, non si parlano.

Ad esempio, il Product Owner non partecipa alle cerimonie, mandano i cosiddetti PROXY PO…persone esterne.
Queste persone però non hanno la cultura, il potere di prendere decisioni…magari posticipano.

Team con componenti verticali

Sono uno sviluppatore, mi occupo di sviluppo per iOs, lo farò per sempre.
Mi occupo di marketing, farò questo per sempre.

Riprendendo il talk di Ferdinando, delle I-shaped people.

Si viene staffati in base ad una precisa competenza, quindi ad esempio i tester stimeranno le loro story, i dev le loro.

Riporti multipli

Le persone nel team hanno riporti organizzativi diversi, su più livelli.
Magari durante un meeting, arriva il capo del P.O. che chiede al P.O. di abbandonare la riunione per presenziare ad un’altra.

Cargo cult

Anti-pattern che Pino e Stefano hanno notato durante esperimenti svolti nelle aziende.

Il nome inglese ha origine dal culto del cargo nato fra i polinesiani e i melanesiani nel XIX e XX secolo, quando fra loro si diffuse la credenza che i cargo, i carichi di manufatti, cibo, e materiali portati da navi e aerei dei paesi occidentali, fossero doni del Cielo.
La pratica di queste tribù, era quella di costruire aerei e piste di atterraggio fittizie nella speranza di evocare gli aerei divini che avevano portato cibo e provviste durante la guerra.

Lo stesso avviene per le pratiche agili.
Talvolta si praticano e si misurano alla lettera, basandosi su qualche simulacro, ma senza aver davvero capito il loro scopo, la loro utilità.

Sorge quindi una domanda: quanto siamo agili?
Oggigiorno un’azienda vorrebbe saperlo, un’azienda lo vorrebbe sapere.

Se si effettua una ricerca su Google delle parole assessment agile, si trovano una miriade di immagini di diagrammi, grafici…contenuti però privi di contesto.
Ad esempio, magari si misura la velocity di un team, ma il team non applica scrum.

Si è notato, soprattutto in grandi aziende, che si è lontani dal contesto. Vengono eseguite attività di assessment magari dalla sede centrale, essendo quindi lontani, non solo geograficamente ma anche culturalmente, dalla realtà oggetto della valutazione

Torniamo alle basi, al Manifesto Agile, a chi serve questa valutazione, la misura? a che serve?

Serve per il team.

Un team la utilizza per crescere, migliorare le proprie performance.

Quando Pino e Stefano chiedono ad un team in azienda di auto valutarsi, chiedendo loro di proporre delle proposte di autovalutazione piuttosto che servirsi di un template pronto ma fuori dal contesto di quello specifico team.

Cosa siete disposti a fare per migliorarvi in alcune metriche? Poi è compito del team.

Come rispondere ad un’azienda che vuole sapere il suo grado di agilità?
Ad esempio, con delle viste sui team ma anche sui coach, con contesto. Contesto dato da valutazioni date sia dal team, che dai coach.

Un’azione importante da intraprendere in azienda è condividere la roadmap di trasformazione dell’it. Avvisare tutti, a tutti i livelli, in merito a riorganizzazioni dei team e quant’altro.

Tornando agli anti-pattern, Pino e Stefano hanno citato quello secondo loro più importante di tutti.

Il modello

Un’azienda che vuole diventare agile, lo fa avvalendosi di un modello.

Il modus operandi tipico è “Nell’azienda X ha funzionato applicare quel modello, applichiamolo pure noi”.

Sbagliatissimo.
Meglio invece un approccio guidato dall’esperimento, empirico quindi.

Come agile coach, capire innanzitutto se un’azienda che dice di adottare un certo modello, effettivamente lo applica.

Come?

Misurando l’efficacia di un modello.
Un’azienda dice di adottare un certo modello, mappiamo i team di questa azienda per vedere se davvero applicano il modello.

Prima di salutarci, Pino e Stefano hanno ricordato quanto sia importante:

• Rispettare la cultura aziendale, capire quali sono i casi di successo e conservarli.
• Individuare anti-pattern e con piccoli esperimenti provare a rimuoverli.
• NON affidarsi mai ad un pacchetto già pronto, piuttosto sperimentare più volte per arrivare ad un modello proprio.
• Concentrarsi sulle persone, stare con loro, lavorarci assieme, sviluppare empatia.
• Parlare con il management, con le persone.
• Mettere in atto esperimenti rapidi e fondati su dati oggettivi, e condividerli con tutta l’azienda, perché magari non si percepiscono anti-pattern che darebbero un senso al cambiamento.

Smettere quindi di cambiare, passando ad agile, solo perché va fatto.
Che motivo c’è di cambiare se non si capisce veramente il perché.

Condividere dati a tutti i livelli è importante, perché altrimenti in azienda continuerebbero ad esistere persone che resistono.

Grazie Pino e Stefano!

Scaling Agile: pattern e anti-pattern

Che significa fare scaling agile, chiede Alessio?

Alessio, agile coach, si occupa da qualche anno di trasformazioni, notando sempre più spesso gli stessi anti-pattern.

Un’altra domanda, un dubbio, però sorge nella sua testa.

Gli anti-pattern che noto sono veri, o lo sono solo per me?

Spesso nelle trasformazioni agili, si fa riferimento ad un modello.
E’ capitato che molte aziende prendessero spunto dal modello Spotify…ecco il primo anti-pattern

Il framework è un anti-pattern quando prendiamo un modello di successo e lo facciamo nostro.
Quello di Spotify non è un modello, lo dicono gli stessi coach in Spotify. Lo è diventato con il tempo, a forza di esperimenti. E’ derivato dall’esperienza.
Quindi per un’azienda X che decide di adottarlo facendo il più classico dei copia e incolla, non può funzionare perché non ha la stessa storia, esperienza, cultura di Spotify.
Lo stesso varrebbe se decidessimo di adottare un altro framework, come il SAFe.
“Adottiamo SAFe perché abbiamo letto il libro”…no, sbagliato!
Il copia e incolla è il male, non solo quando sviluppiamo codice 🙂

Da dove partire quindi per fare scaling agile?
Creando team, magari partendo dall’IT, o dai progetti in essere.

Un criterio per creare un team?
In base ai progetti in essere, si costituiscono i team. Ma che siano stabili nel tempo, e non legati alla vita del progetto.
Ecco quindi un altro anti-pattern. Creare team non duraturi nel tempo.

Bisogna creare team stabili, duraturi. orientati al business, non all’IT (team backend, team db…).
Tornando al modello Spotify,  le tribe di spotify sono orientate verso uno specifico business.

Il business.
Mai trascurarlo in fase di scaling agile.
Trascurare il business è un altro anti-pattern, ma si tende a trascurarlo perché le difficoltà che si hanno nel coinvolgerlo durante il processo di trasformazione, perché non si riesce a far capire il valore che c’è dietro questa trasformazione.
In molti casi è a bordo, ma per imposizione dall’alto. Magari è partecipe nelle cerimonie per i primi tempi, ma poi tende a scomparire perché appunto non ha la percezione del valore di questa trasformazione.
Importantissimo quindi occuparsi del business fin da subito.

E il Product Owner? Che fine fanno queste figure durante uno scaling agile?
Prima erano dei Project Manager.
Ma avevano focus sul valore?
Può essere. Facevano il loro mestiere. Nel passato però. Per soddisfare le richieste del business
Ma ora?
In questa trasformazione, è importante conoscere il cliente.
Si può essere P.O. senza conoscere il cliente?
L’anti-pattern qui è che il Product Owner non conosce il cliente, quindi lavora come ha sempre fatto.
Un Project Manager può diventare P.O., ma è necessario fare dei corsi, e anche un lavoro atto a conoscere il cliente, le sue aspettative, i suoi bisogni.

I fornitori?
Spesso le grandi aziende si servono di fornitori esterni.
E che contratti si stipulano?
Come sempre, tenendo come variabili fisse lo scope, il tempo e il budget.
E qualora dovessero cambiare i requisiti? Non può funzionare.
Quindi l’anti-pattern è continuare a stipulare contratti scope-tempo-budget.

Rimanendo in tema fornitori, un altro anti-pattern si ha quando nel team è presente un solo rappresentante dell’azienda fornitore, perciò sarà sempre e solo 1 persona a partecipare ai vari daily scrum, planning.
Va contro i principi fondamentali dell’agilità, secondo Alessio.

E il management? Come si adatta alla trasformazione?
Sbagliatissimo assegnare ruoli solo perché imposti dall’adozione di un certo modello.
Prendiamo come esempio il SAFe. Adottandolo, c’è l’esigenza di adattare il management ai ruoli che tale modello impone, quali
System architect, RTE (Release Train Engineer) solo per citarne alcuni.
Ogni componente del management si identifica in uno di questi ruoli.
Chi era Project Manager diventa Product Owner, chi era team Leader diventa Scrum Master.
“Cambiano solo il ruolo sul loro profilo LinkedIn e sul loro cartellino, ma non cambiano il modo di lavorare, quello rimane lo stesso.
L’anti-pattern per eccellenza.

Torniamo a Spotify.
Se si decide di adottare il loro “modello”, lo si conosce veramente?
Ad esempio, cosa sono i Chapter?
Sono dei gruppi aggregati per tematica, ruolo (ad esempio, tutti gli sviluppatori front-end dei vari team) che si incontrano periodicamente per condividere conoscenze, esperienze. Esiste un Chapter Leader, responsabile.
Una figura nata con il tempo in Spotify, dato che il Chapter Leader prima era un Line Manager.
Sono figure che rimangono all’interno del team, dato che prima un Line Manager era all’interno del team.
Quindi non è cambiato nulla a livello operativo.
Per Spotify è naturale, ne avevano la cultura.

Un anti-pattern che si nota è il continuare a fare affidamento sugli stessi manager anziché far crescere nuovi leader.

E parlando di devOps?
Esistono aziende con cultura devOps, altre con un team devOps.
devOps è una cultura, piuttosto che un gruppo di persone.
All’interno del team è importante che ci sia questa cultura, magari è sufficiente una persona che si occupi di operations oltre che development.
Quindi l’anti-pattern è intendere devOps come un team piuttosto che come una cultura.
I team devOps inoltre non sono autonomi, devono dipendere dall’operato di altri. Se sorge un problema, hanno bisogno dell’intervento di qualcun altro.

Che dire sul discorso test automatici?
E’ fondamentale avere dei test automatici di non regressione.
Secondo Alessio, non si è agili fintantoché non si hanno dei test automatici che coprano una certa percentuale di copertura di codice legacy.

E sul debito tecnico derivante dell’architettura?
Ad esempio, un progetto nasce con un’architettura senza test automatici.
Negli anni, l’architettura cresce e si mettono pezze su pezze.
Perché non fare diversamente? Non è meglio ad un certo punto fermarsi e ripensare tale architettura, magari inserendo i test. Non lo si fa perché non si ha tempo.
Ma è bene Frenare per accelerare, come  suggerisce Alessio.

Per un’azienda che si sta trasformando, chi ha seguito questo processo? Chi era lo sponsor?
Non c’è un vero sponsor, qualcuno che veramente segua il processo.
E’ bene che si costituisca un team dedicato che segua la trasformazione, non 1 persona sola.
Tutta l’azienda deve adattarsi al cambiamento dopotutto, non solo IT.

Quali sono quindi dei pattern positivi?

• Scegliere con un programma pilota che faccia da apripista per gli altri.
  Tramite un pilota, di durata anche breve,  emergeranno sicuramente dei problemi importanti, e magari si riesce a risolverli.
• Avere una vision chiara, che richiede un cambio culturale, con uno sponsor vero, che supporti e aiuti (ad esempio gli agile coach).
• Istituire un trasformation team, che segue il processo con attività di coaching, esperimenti e che motivi continuamente tutte le persone durante il processo di trasformazione.

E ricordarsi sempre che LA RICETTA PRONTA NON ESISTE!

Grazie Alessio, tanti spunti di riflessione e consigli per evitare che gli anti-pattern abbiano la meglio.

Projecting a product

Jacopo Franzoi ha condotto un talk basato sulla sua esperienza di sviluppatore software e mentoring per  aiutare i team con cui lavora a raggiungere gli obiettivi di progetto, auto-organizzandosi.

Cos’è un progetto, per Jacopo?

I progetti sono degli obiettivi di business, dei risultati tangibili da ottenere.
Senza scope non si ha un progetto, e questo termine è legato a tempo e obiettivi (outcomes).
Lo scope è un mezzo per raggiungere l’obiettivo.
Il prodotto è l’artefatto, qualcosa di tangibile usabile dal cliente finale.

Parlando di team, risulta difficile pensare ad un unico team che lavora al progetto, solitamente ci lavorano più team.
Ma ci deve essere una guida per i team, una figura che si faccia carico di portare avanti la pianificazione degli vari team.

Negli ultimi anni, sono nate diverse iniziative, e tra queste…products over projects
Narayan nel suo libro Agile IT Organization Design: For Digital Transformation and Continuous Delivery dice di concentrarsi sui prodotti piuttosto che i processi…

#noprojects

#noestimates

Concetti che minano le convinzioni che si hanno.
Martin Fowler dice che ci sono 3 obiettivi nell’agilità:

• lasciare i team liberi di auto-organizzarsi.
• L’eccellenza tecnica deve tornare ad essere il nostro pane quotidiano.
• Abbandoniamo i progetti, abbracciamo una gestione legata ai prodotti.

Product over process, quindi.

• Budgeting sui team anziché budgeting di progetti. Team get funded anziché Scope get funded.
• Istituire team stabili nel tempo, anziché formati per un certo progetto. I team si concentrano su un chiaro problema di business, un obiettivo.
• Ideate-build-run team vs Build-only team.
  Non solo sviluppo e realizzazione, ma tutto il ciclo di vita (dalla analisi alla progettaziome, allo sviluppo e deploy).
  Quindi stop con i team dedicati ad un certa attività.
• Roadmap per prioritizzare e coordinare il lavoro quotidiano.

Si scorgono dei pericoli:

• Nuovi silos: si possono creare specializzazioni, legate al contesto specifico. Come mitigarlo? Demandando al team la responsabilità di portare avanti il progetto, decidere le tecnologie
• Dov’è il prodotto? Alla fine si parla di “isole di dominio” all’interno dell’azienda. Il prodotto è proprio questo, la competenza di un team, riutilizzabile.
• Roadmap: un backlog utopico. Coordinare il lavoro di tanti team sarebbe bello.

Jacopo ha poi portato un esempio su come organizzare un’area di competenza per progettare la funzionalità legata all’offerta di bagagli in fase di prenotazione volo:

• Studio sulle modalità di bagaglio offerto, e cosa genericamente offre una compagnia.
• Fase di studio dell’architettura, ricorrendo al modello dello User Story Mapping per concentrarsi sul flusso di azioni che compie l’utente(shopping, checkout, purchase, mail di conferma, customer area).
• Pianificazione di un piano di rilascio, con poche funzionalità ad ogni iterazione, e soprattutto competenze sui vari componenti dell’architettura del sistema.

Prima di salutarci, Jacopo ha fatto alcune riflessioni legate all’applicabilità di un modello orientato al prodotto, più facilmente applicabile in organizzazioni che realizzano prodotti  piuttosto che compagnie che realizzano  software.

Talk interessante, grazie Jacopo per le tue riflessioni e per aver condiviso la tua esperienza.

E se provassi Kotlin?

Damiano ha trattato un talk tecnico, incentrato (come suggerisce il titolo) sulla sua esperienza con il linguaggio Kotlin con l’obiettivo di trasmetterci i vantaggi che si hanno nell’adottarlo per scrivere codice migliore.

Come?

Attraverso slide relative al kata Supermarket pricing da lui svolto.

Nota: Damiano ha preso spunto dal kata svolto dal mediocre Ferdinando Santacroce. Nando, forse tanto mediocre non sei 😉

Tornando a noi, dapprima Damiano ha mostrato l’implementazione ugly Java e quindi il codice.

Come lo risolviamo in Kotlin?

Obiettivo del kata: refactoring per poi aggiungere nuove feature.

Prima di tutto, perchè Kotlin?

Kotlin è un linguaggio di programmazione, sviluppato da JetBrains.

E’ un linguaggio moderno, conciso, espressivo, intuitivo, 100% compatibile con Java e Java Virtual Machine, nonché linguaggio ufficiale per lo sviluppo Android.

Perchè piace a Damiano? 🙂
Ti permette di scrivere codice fluente e conciso, oltre ad altri aspetti quali la possibilità di ridurre code smell rendendo il codice più chiaro e leggibile.

Iniziamo con il refactoring, dove Damiano ha mostrato le novità e potenzialità del linguaggio:

• Dichiarare nuove classi: class ImprovedCheckout. Senza graffe. Non serve, se non si ha un body.
• Implementare un’interfaccia, tramite l’istruzione class ImprovedCheckout : <nome interfaccia> anziché class ImprovedCheckout implements <nome interfaccia>.
• Override di metodi: override fun <nome metodo>.
• L’uso dei costrutti List e Map in Kotlin che sono gli stessi utilizzati in Java ma arricchiti dalle feature aggiuntive del linguaggio Kotlin 🙂
• Interoperabilità del linguaggio: è possibile istanziare, in un pezzo di codice scritto in Kotlin, oggetti di classi sviluppate in Java.
• Conversione automatica del codice: fortemente consigliato usare l’IDE IntelliJ per convertire codice Java in Kotlin, oppure l’auto conversione di IntelliJ qualora si volessero copiare pezzi di codice Java.
• Utilizzare il costrutto when anziché il classico switch.
• Dichiarare variabili dichiarate senza esplicitarne il tipo.
• Destructuring assignment.
• MutableMapOf: costrutto che, tra le altre cose, ti permette di ciclare una lista di elementi senza dover ricorrere al classico for.
• Elvis Operator: la variabile può essere nulla, con questo operatore si garantisce che tale variabile non è null. Qualora lo sia, sai che è in quel punto.
• Lambda expression: funzione dichiarata al volo, inline.
• Data classes: per modellare un’offerta, Damiano ha mostrato come con una riga di codice.

data class Offer (val quantity: Int, val price: Int) si abbiano già a disposizione i metodi di set,get, equals…

Durante la sua presentazione, Damiano ha messo in evidenza la distinzione tra val e var:

• val <nome variabile>: la variabile è immutabile
• var <nome variabile>: la variabile è mutabile
• const <nome costante>: in fase di dichiarazione di costanti, applicando la type inference non serva specificare il tipo
• metodi sulle collection, come per gli stream in Java 8, ma molto più semplici (es: sumBy).

E ricordato come, durante un refactoring, sia importante utilizzare variabili che abbiano nomi significativi, evocativi e non i classici a,b,c.
Inoltre ha rimosso man mano commenti superflui o di codice morto 🙂

Dulcis in fundo, Damiano ha mostrato alcuni dati legati relativi al linguaggio (è secondo più amato, secondo meno odiato), e continui sviluppi che hanno portato all’uscita della versione 1.3.

Sì Damiano, ci hai convinti tutti a provare ad emularti e quindi utilizzare Kotlin 🙂

Qui trovate le slide del suo intervento, mentre a questo link il repo GitHub con un paio di soluzioni passo-passo del kata presentato.

Stop Meetings, Start Coding

Basta meeting.

Nell’agilità la conversazione è uno dei punti cardine, quindi Stop meeting suona molto come una provocazione 🙂

E’ partito da qui Giulio, partner di Intré e CEO di Agile Reloaded, per il suo talk, rivolto soprattutto a sviluppatori.

Qual’è il valore che creiamo dal nostro lavoro?
Non codice pulito, non qualcosa realizzato con tecnologia avanzata…piuttosto realizzare servizi che soddisfano i bisogni degli utenti.

Ad un costo accettabile, al momento giusto e che siano convenienti nella nostra operatività.

Ma come possiamo realizzare questo valore?

SCRIVENDO CODICE.

Tutto il resto è potenzialmente uno spreco.

Non ci si pensa, ma ogni volta che partecipiamo ad un meeting di 1 ora con altre 7 persone vuol dire che si sta investendo 1 giorno uomo. Per un meeting.

Come poter evitare riunioni?

Si può, basta lavorare da soli, team composto da un’unica persona, che lavora per un progetto per se stesso 🙂
Sono contento, soddisfatto perché lavoro per creare qualcosa per me stesso.
Io sono il team, il cliente e io pago 🙂

La realtà è ben altra, infatti un contesto tipico lavorativo è molto più complesso:

• Molti stakeholder: tanti canali di comunicazione e tante idee.
• Utenti finali: non solo 1 bisogno chiaro ma diverse sfumature.
• Obiettivi contrastanti: non 1 solo obiettivo ma diversi livelli a seconda del ruolo in azienda.

Tutto ciò porta confusione, poca chiarezza, quindi RIUNIONI. Spesso poco efficaci.

Piuttosto non facciamolo.

Certo spiegare come non fare riunioni non è l’obiettivo del  del talk di Giulio, bensì come evitare di arrivare ad avere bisogno di riunioni.

Tornando alla nostra quotidianità lavorativa, passiamo più tempo in riunione che a scrivere codice.
Passare da una riunione all’altra non aiuta a concentrarsi sullo sviluppo. Questo può portare ad arrivare a fine giornata che non si è concluso nulla, e di conseguenza essere scontenti.
Inoltre si rischia di andare in ritardo sugli sviluppi, creare quindi debito tecnico. quindi gestire interruzioni impreviste perché il software rilasciato è di bassa qualità.

Un disastro.

L’insoddisfazione inoltre ci porta a cercare cause all’esterno quando forse dobbiamo provare a cambiare noi. Dall’interno.

Ancora una volta. Come?

INIZIAMO A SCRIVERE CODICE
Magari partendo dal test.

Scriviamo un test basico, semplice, che ad esempio testi che una stringa non sia vuota.
Iniziamo a dare il buon esempio. Poi magari qualcuno ci segue.

Scriviamo sì codice, ma buono. Con ordine e disciplina, seguendo un metodo, delle linee guida.

Come per il più classico dei cassetti dove riponiamo magliette e calzini.

Se tenessimo il nostro cassetto in disordine, quanto tempo perderemmo nel recuperano un paio di calzini 🙂
E se ci pensiamo, quanto ci costerebbe riporre ogni volta i nostri calzini in ordine…tutto sarebbe più semplice.

Con il codice è uguale!
Perché non partire da una situazione più pulita possibile?
Aiutiamoci con il libro Clean Code.

Dove c’è logica di business, fare copertura dei test. E magari iniziamo a sviluppare facendo TDD.
E magari sviluppiamo seguendo TDD, quindi guidato dal test.

Adottiamo delle regole comuni (uso di lint ad esempio) per lo sviluppo del codice.

E non dimentichiamoci del principio di Pareto, o legge 80/20, che nel campo dello sviluppo software dice che

Quando sviluppiamo software, fare il cosiddetto giro che funziona costa relativamente poco. E’ nel dettaglio che si insidiano i veri costi e problemi.

Non innamoriamoci della tecnologia!
I tecnici si innamorano delle tecnologie, quelli che fanno business del kpi.

MA NON DIMENTICHIAMOCI DEL BISOGNO DELL’UTENTE FINALE.
Innamorandoci del cliente finale facciamo il salto di qualità.

Framework last: non pensiamo subito al framework\tecnologia migliore per il progetto, concentriamoci partendo con qualcosa di semplice e farlo evolvere piano piano.

L’informagica non esiste. Se nel nostro applicativo notiamo un problema che poi si risolve da solo, stiamo pur certi che si riproporrà quando il codice andrà in produzione.

Puntare alla semplicità!
Diventiamo dei programmatori pigri che:

• Scrivono poco codice per raggiungere l’obiettivo.
• Automatizzano tutti i lavori noiosi.
• Non si arrovellano a progettare cose che non conoscono ancora.
• Dormono la notte, per cui fa in modo tale che un crash di sistema venga gestito con uno script che fa ripartire il sistema.
• Si dimenticano le cose, per cui si scrive codice leggibile e non criptico.
• Cercano di riusare il più possibile quello che hanno fatto.
• Odiano il copia e incolla (troppo noioso da mantenere).

Lavoriamo assieme, quindi sì alle riunioni qualora portino ad un output, qualcosa di utile.

Prima di salutarci, Giulio ci lascia tre consigli:

• Il cambiamento parte da noi e dal nostro modo di scrivere codice.
• Fidiamoci dei colleghi: non sempre tutti in riunione, ma solo dei “rappresentanti”.
• Facciamo riunioni brevi, massimo di 45 minuti con un’agenda e conversazione visuale.

Grazie Giulio, da oggi ho una nuova concezione dell’essere pigro 😉

Conclusioni

La giornata si è conclusa laddove tutto è iniziato, e cioè in aula magna.

Fabio, presidente dell’Italian Agile Movement nonché partner di Intré, ha colto l’occasione per ringraziare ancora una volta tutti coloro (sponsor, volontari, e speaker 🙂 ) che si sono adoperati per la realizzazione dell’evento.

Alla prossima cari lettori.