20 Novembre 2018
IAD Brescia – 10 Novembre 2018

Novembre 2018. Un altro anno è passato, ma non la voglia di agilità 🙂

La quindicesima edizione degli Italian Agile Days si è tenuta a Brescia, presso gli spazi del Dipartimento di Ingegneria dell’Informazione.

E’ stato un ritorno, in quanto la sede della giornata di Sabato è  stata la stessa in occasione dello IAD del 2015. Per chi non c’era… ecco qualche foto e i video delle conferenze.

Ma torniamo al presente, siete pronti per rivivere quanto accaduto a questo IAD?

Di seguito leggerete un resoconto della giornata di conferenza di Sabato, ma anche Venerdì è successo qualcosina 🙂

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.
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à.

Sabato

Sin dalle prime luci dell’alba (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 (bella bella, ce l’ho anche io :)) e fornire indicazioni sull’ubicazione delle aule.

Colgo l’occasione per ringraziare tutti coloro (sponsor e volontari) che hanno reso possibile questa 2 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, ora 🙂

Questo il programma, composto da talk sia tecnici che non.

“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
  • oltre 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.

Che dire, platea scaldata come meglio non si potesse, ora spazio al keynote di Mike Burrows

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:

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
  • aiutare l’organizzazione del cliente a coinvolgere il proprio personale in modo significativo nel lavoro correlato al cambiamento
  • aiutare le 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?

Dove eravamo rimasti con Emanuele? Ora ricordo.

Agli Italian Agile Days di Urbino dello scorso anno Emanuele, collega nonché responsabile del team di designer 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 tantomeno 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.

UTILITA’

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

USABILITA’

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:

  • 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
  • Piacevolezza 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
2 domande iniziali da porsi:

  • Perchè questo prodotto?
  • Perchè 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 PRODOTTO E 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 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:

  • la 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
  • cose che so di non sapere
  • 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?

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.
  • 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).
  • studio 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
  • molti 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

l'80% del tempo di esecuzione è impiegato solo dal 20% delle istruzioni di un programma; l'80% delle operazioni degli utenti sono dovute al 20% delle funzioni a disposizione di un applicativo; l'80% degli errori di codifica è riconducibile al 20% dei moduli; l'80% dei visitatori di un sito vede solo il 20% delle pagine. - Wikipedia

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 arrovella 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 3 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 🙂

Tag
Intré Camp – 30 Ottobre 2018

Racconto del camp aziendale svoltosi a Erba, castello di Casiglio.

Intré Camp – 26 Giugno 2018

Racconto del camp aziendale svoltosi all'agriturismo La Camilla

Agile Venture Prato 2018

Il racconto della giornata della prima edizione di un agile venture in quel di Prato.

A reactive programming example
Milan Kotlin Community Conf

The first Kotlin related Italian conference made from the community to the community!

Let's see how was it...

DroidCon IT, Turin, 19 & 20 April 2018: our report
Milan Kotlin Community Conference

How, why and what has lead us to the Milan Kotlin Community Conference.

Intré Camp – 13 Febbraio 2018

Racconto del camp aziendale svoltosi a Pontida, agriturimo Polisena

Vert.x – 4o articolo su Mokabyte!

4o articolo sul mondo Vert.x a cura di Marco

Vert.x – 3o articolo su Mokabyte!

3o articolo sul mondo Vert.x a cura di Marco

NoSlidesConf 2017

NoSlidesConf: una conferenza diversa dal solito

Vert.x – 2o articolo su Mokabyte!

2o articolo sul mondo Vert.x a cura di Marco

Vert.x – 1o articolo su Mokabyte!
IAD Urbino 2017 – Conferenza 18 Novembre

Racconto della conferenza presso l'università degli studi Carlo Bo di Urbino

IAD Urbino 2017 – Unconference 17 Novembre

#IAD17: Racconto della giornata di unconference presso l'Università degli Studi Carlo Bo di Urbino

Intré Camp – 5 Ottobre 2017

Racconto del camp aziendale svoltosi all'agriturismo La Camilla

Intré Camp – 18 Maggio 2017

Resoconto del camp aziendale svoltosi all'Oasi di Galbusera Bianca

CloudConf Torino 2017

CloudConf 2017 a Torino. Come è andata?

Mini IAD Vimercate 2017

Il racconto della giornata al Mini Italian Agile Day tenutasi a Vimercate.

Codemotion Milano 2016

Nel week-end del 25-26 novembre 2016 si è svolto il Codemotion Milano 2016.
Francesco Sacchi e Ferdinando Santacroce ci raccontano com'è andata.

Angular Conf 2016

Il racconto della nostra giornata alla Angular Conf 2016 a Torino, sia come spettatori e soprattutto come sponsor.

Intré Camp – 3 Novembre 2016

Un racconto di come è andata la nostra giornata di team building, tra sorrisi e battaglie ;)

Node.Js Italian conference – V edition

Cronistoria sulla nostra partecipazione alla 5^ edizione della Node.Js Italian Conference, con tante belle foto, stickers e...leggete :)

Business24 TV: Fabio Ghislandi presenta Intré

In questo breve intervista viene presentata Intré e il suo innovativo approccio allo sviluppo di software.

Come cambia il mondo dei linguaggi
WebRTC – #1 Video-Chat in javascript

Con la tecnologia WebRTC (Real Time Communication www.webrtc.org) è possibile integrare, all’interno di applicazioni che comprendono javascript, funzionalità di audio e video-chat, registrazione chat, condivisione schermo e signaling.

Future e Promise in Scala

Primo post sulla programmazione in Scala dedicato a future e promise, due costrutti fondamentali per la programmazione concorrente.

Come inviare dati live da un’applicazione C# Desktop al web usando le WebSocket

Questa è una guida passo passo su come esporre dati live da un'applicazione C# console ad un web browser usando le WebSocket. L'esempio è stato testato su Windows 7.

IOS Push notifications iOS 6 con Sencha Touch 2.2

Se state cercando di inviare una Push Notification al vostro iOS6 iPhone/iPad usando Sencha Touch 2.2 probabilmente avrete incontrato diversi problemi. In questo articolo vedremo passo passo come configurare i certificati, impostare il file Sencha package.json ed inviare una push notification con uno script PHP o C#.

Creare una issue in Jira con i sub-task predefiniti

E' possibile programmare script in Atlassian Jira usando Groovy. Questi script possono essere eseguiti allo scattare di un evento come alla creazione di una issue o al suo aggiornamento. Sfruttando questo principio vediamo come creare uno script che crea i sub-task in automatico alla creazione di una Issue.

Lego controllato con Cloudfoundy via WebSockets

Questo è un breve test di come è possibile controllare Lego Mindstorm con Cloudfoundry usando HTML5 e WebSockets.

Beaglebone how-to. Come cambiare lo stato di una pagina web premendo un pulsante con node.js

Questo articolo descrive come intercettare l'interrupt GPIO di una beagle bone e aggiornare, via web sockets, una pagina web usando node.js.

youSCADA presentato al Graphical Web 2012

Come controllare e monitorare i device usando una piattaforma Cloud? La soluzione è stata presentata al Graphical Web 2012 a Zurigo.

Chiamare una REST API con node.js

Node.js sta rivoluzionando il modo di programmare le piattaforme software. Basato sul Google V8 JavaScript Engine permette di scrivere codice lato server in JavaScript.

Top
Ogni nostro Sprint ha l'obiettivo di massimizzare il Valore per l'utente finale
Il tuo browser non è aggiornato!
Aggiornalo per vedere questo sito correttamente.Aggiorna ora

×