Better Software 2013

Anche quest’anno abbiamo partecipato alla conferenza Better Software giunta alla sua quinta edizione. Molte novità, e una consapevole scelta di privilegiare i temi inerenti l’organizzazione delle moderne aziende IT, la loro transizione verso la filosofia lean, i riscontri dell’applicazione delle metodologie Agile.

Un anno di novità

Eccoci al nostro ormai “consueto” resoconto su Better Software [1], conferenza giunta alla sua quinta edizione tenutasi a Firenze nei giorni 11 e 12 novembre scorsi. Questa edizione segna una svolta consapevole nella direzione che caratterizza Better Software: un nuovo gruppo di organizzatori raccolto intorno ad alcuni “veterani”, ai quali Develer, inventore dell’evento, ha amichevolmente ceduto il “marchio”, e la scelta consapevole di privilegiare i temi inerenti l’organizzazione delle moderne aziende IT, la loro transizione verso la filosofia lean, i riscontri dell’applicazione delle metodologie Agile in reali contesti lavorativi e in progetti condotti a termine in maniera positiva.

Figura 1 – Gli organizzatori della conferenza danno il benvenuto ai numerosi partecipanti.

Resta invariata, invece, la formula: due giornate, interventi frontali di numerosi relatori distribuiti in parallelo su due “binari”, un terzo spazio workshop in cui si sono svolti seminari interattivi per gruppi non eccessivamente numerosi, e nei quali era possibile farsi un’idea, in maniera esperienziale, di alcune metodologie o tematiche (Soft skills e Agile Management con il nostro Giovanni Puliti, User Stories con Matteo Vaccari, Change Management con Stelio Verzera e Jacopo Romei), oppure dove si è discusso, in una sorta di “panel” di esperti, di temi “caldi” (lavoro in remoto, con Luca Mearelli, Alberto Brandolini, Michele Orselli e Bruno Bellissimo, e di Startup, con Francesco Fullone, Stefano Fontanelli ed Emanuela Zaccone).

Il resoconto: testi e immagini

Quello che segue è un resoconto di ciò a cui abbiamo assistito: la prima giornata prevedeva come tematiche alcuni interventi più tecnici e altri che avrebbero trattato di design dell’esperienza utente e della realizzazione di interfacce (UX); la seconda giornata, in teoria, si occupava invece di tematiche Lean e del management in generale. A essere onesti, in alcuni casi la collocazione di certi interventi all’interno di un determinato “contenitore” c’è parsa abbastanza artificiosa, ma del resto occorreva creare un minimo di struttura in cui collocare i contenuti o, drasticamente, sarebbe stato necessario adottare la formula della “non conferenza” che è molto in auge attualmente in alcuni contesti. Abbiamo pertanto deciso di riportare gli interventi non in maniera cronologica o legata alle “track” ufficiali definite dagli organizzatori, ma raggruppati per gli argomenti e le tematiche che a nostro giudizio mettevano maggiormente in evidenza.

Inoltre, in una sorta di cedimento alla presenza quasi oppressiva sui social network, e non solo, delle foto ritagliate a quadrato e trattate con filtri “retrovintage” della più diversa specie, ci siamo divertiti ad applicare i filtri di Instagram alle diverse fotografie dell’evento, cercando di giustificare l’aderenza tra le caratteristiche del filtro e quelle dell’intervento o della tematica trattata dal relatore. I lettori ci perdoneranno per tale scemenza…

Sistemi complessi ed evoluzione aziendale

Diversi interventi si sono concentrati sulla presa di coscienza della complessità che regna nell’ambito della organizzazione delle aziende che devono occuparsi di IT e del necessario cambio di paradigma organizzativo e di processo che occorre per poter continuare a svolgere progetti in maniera sostenibile, senza incappare negli evidenti limiti del sistema “industriale” classico di produzione.

Andrea Provaglio: Dreaming

Apparentemente pretenzioso nel titolo, l’intervento di Andrea Provaglio [2] si dimostrerà uno dei più concreti ed efficaci dell’intera kermesse.

Figura 2 – Andrea Provaglio presenta un intervento basato sul concetto di “sogno”, inteso in modo molto concreto come visione di prodotto e di progetto. Vista la tematica, applichiamo il filtro “Sierra”, con alta esposizione, basso contrasto e tonalità “sognanti”.

In questa presentazione, che apre la prima giornata, si parte dall’idea di sogno, distinguendo tra “sognare” e “fantasticare”. Il design è sogno, ma sognare non è ne’ fantasticare, ne’ pianificare. La nostra cultura post industriale ha perso la dimensione del sogno.

Schematizzando, è possibile immaginare un triangolo con i tre vertici rappresentati da sogno, ordine e azione.

sogno: intento, visione, missione;
ordine: ruoli, funzioni, protocolli, procedure, processi;
azione: produzione, competenze tecniche.

Figura 3 – Sogno, ordine e azione come i tre pilastri di un progetto agile (Sierra).

Esiste un rapporto dialettico tra sogno e bisogno, e anche se tutti i modelli preconcetti sono sbagliati, qualcuno può essere utile.

L’intervento decolla quando questi concetti, molto suggestivi e sensati, vengono ulteriormente rafforzati con un paragone riferito agli elementi della pratica Agile, ad esempio Scrum

rapporto tra sogno e backlog di prodotto;
rapporto tra ordine e ruoli (Scrum e cerimonie) e pianificazione;
rapporto tra produzione e competenze tecniche.

Si introduce il concetto di actionability threshold: “soglia di azionabilità”, ossia il momento in cui un “pezzo di sogno” diventa qualcosa che può essere messo in azione, in produzione: tra sogno e azione c’è l’ordine che serve a rendere solido il sogno.

L’esempio di Walt Disney è piuttosto illuminante: l’azienda enorme, che non è esente anche da aspetti e pratiche criticabili, crea attualmente circa 6 miliardi di utile netto, e rappresenta una applicazione concreta di un processo che porti dal “sogno” al “business”. Tale processo, già ai tempi di Walt Disney, prevedeva tre fasi da svolgere in tre situazioni un po’ differenziate:

stanza del creativo
stanza del realista
stanza del critico

Tre stanze, tre configurazioni diverse, e un processo iterativo e incrementale: nella stanza del creativo l’idea è al centro e le persone sono intorno e discutono liberamente; nella stanza del realista l’idea è sul lato corto della stanza e le persone sono disposte a ferro di cavallo mettendo in luce come trasformarla in qualcosa che funzioni; nella stanza del critico l’idea è sul lato lungo della parete, le persone sono disposte su una riga come se fossero un “plotone di esecuzione” e “fanno le pulci” all’idea progettuale mettendone in luce tutti i punti deboli. A questo punto, con tutti i dati raccolti nelle tre fasi, si ritorna alla prima e si migliora l’idea in un processo che a poco a poco porta al prodotto finito che mantiene sia le caratteristiche creative, che quelle di sostenibilità reale, e di resistenza alle eventuali critiche.

Questo è un modo reale di trasformare il sogno in realtà imprenditoriale, dove assumono grande importanza i cicli produttivi: micro, macro, meta.

micro: ciclo di interazione;
macro: ciclo di rilascio;
meta: ciclo di strategia.

Si conclude infine parlando di una figura che dovrebbe esserci in ogni azienda che voglia mantenere la sua visione a lungo termine, il dreamkeeper, o “custode del sogno”, che si assicura che le scelte si conformino con la “vision”: la nota di chi scrive è che un tempo, e in altri contesti, questa figura c’era eccome, e si chiamava “ideologo”, ma poi il termine ha purtroppo assunto un connotato negativo.

L’intervento si chiude con una serie di strategie per mantenere la vision: i leader devono assicurarsi che la visione del loro progetto sia chiara ai collaboratori; la visione deve essere condivisa.

Poco da aggiungere: un intervento pieno di ispirazione ma molto concreto e addentellato alla realtà, senza “fuffa” e in grado di suscitare numerose riflessioni nei presenti. Ottimo.

Claudio Bergamini: L’IT, il mito della fabbrica e l’esperimento della rana bollita

Di idee imprenditoriali dal punto di vista… dell’imprenditore parla al martedì anche l’intervento di Claudio Bergamini [3] che si concentra sulle teorie della complessità e sulle differenze tra management “classico” di tipo industriale ed esigenze dell’azienda IT attuale (e del futuro).

Si parte dalla differenza tra sistema complicato (articolato, con elementi anche relativamente numerosi, ma certi, e comunque scomponibile, analizzabile, ricomponibile e prevedibile) e complesso (elementi molto numerosi e incerti, con relazioni reciproche molteplici, tali da impedirne la scomponibilità in singoli “ingranaggi”, non analizzabile con tecniche classiche, difficilmente prevedibile). Di tali argomenti, peraltro, ci stiamo occupando da tempo sulle pagine di MokaByte.

Si tratta di assunti che alcuni imprenditori cominciano a comprendere grazie agli stimoli derivanti dalla loro esperienza, ma che hanno una solida base teorica ed empirica, poiche’ sono l’oggetto di numerosi saggi, alcuni dei quali prendono a modello proprio le organizzazioni aziendali.

Il modello della fabbrica novecentesca male si applica al mondo sempre più complesso della produzione IT in senso lato, dove tale modello “verticistico” basato sul principio “velocità = produttività” si è dimostrato inadatto: “produttività” non vuol dire la stessa cosa per tutti gli attori, specie per i manager.

Ma che cosa definisce un sistema complesso?

il grande numero e la molteplicità di elementi in gioco (persone, prodotti, mercato, processi etc.);
le interazioni non lineari tra gli elementi: dipendono tra loro ma in maniera non semplicistica, che non può essere ridotta alla classica, lineare e rassicurante causa-effetto;
l’impossibilità del controllo centrale: avere informazioni non significa “controllare”;
il manifestarsi di proprietà emergenti: nuovi comportamenti interni ed esterni, eventi incontrollati e altre caratteristiche che non sono linearmente prevedibili.

Anche solo uno di questi elementi determina la complessità di un sistema, figuriamoci quando ne possiamo riscontrare più di uno contemporaneamente: attenzione alle false certezze!

Figura 4 – Claudio Bergamini affronta il tema della complessità: contrasto elevato e viraggio dei colori del filtro X-Pro II ben si adattano al “viraggio” del cambio di paradigma necessario nelle aziende per affrontare tale complessità.

Interessante una precisazione: la complessità esclude l’applicabilità universale di certe leggi, ma non vuol dire che, nel particolare, queste leggi non abbiano un loro valore.

Tali leggi sono:

principio di assunzione di ordine: è quello per cui il rapporto di causa-effetto individuato nel passato consente una previsione del futuro grazie alle “best practices”;
principio di assunzione di scelta razionale: è quello per cui le persone tendono sempre a fare scelte razionali che puntano a minimizzare la paura e massimizzare il piacere;
principio di capability intenzionale: le azioni personali e collettive sono deliberate.

In un sistema complesso, tali principi, che di per se’ hanno il loro valore, possono anche non valere e di questo bisogna essere ben consapevoli, anche perche’, nelle aziende, situazioni, strutture, stili sono variabili.

Che c’entra, in tutto questo, l’esempio della “rana bollita”? La rana preferisce l’acqua tiepida e non sta bene nell’acqua gelida. Se la mettessimo in una pentola in cui la temperatura dell’acqua sale a poco poco, inizialmente si passa da un’acqua fredda a un’acqua tiepida in cui si sta bene. Il problema è che, se questa temperatura continua a salire sempre un po’ alla volta, ci si adegua gradualmente all’aumento del tepore, si sostiene il calore, ma alla fine si arriva fino all’ebollizione che è fatale.

Questo è ciò che è accaduto nell'”industria della conoscenza”: inizialmente l’applicazione del pensiero unico di organizzazione aziendale e produttiva derivante dalla fabbrica ha favorito l’innalzamento della temperatura a livelli buoni e accettabili. Ma continuare con l’applicazione al mondo IT del mito della fabbrica finisce per portare la temperatura a livelli di ebollizione, con conseguenze funeste.

Occorre pertanto applicare una serie di strategie che tengano in considerazione la peculiarità della produzione di software e delle attività affini e collaterali, svincolandole dal mito della fabbrica.

Figura 5 – L’importanza della visione ampia: siamo sicuri di controllare veramente il sistema o abbiamo solo una visione limitata e parziale (rettangolo blu) che ci può indurre a valutazioni e scelte completamente sbagliate?

Alcune strategie individuate sono le seguenti:

profitto come risultato dell’lavorare bene;
organizzazione del knowledge worker;
servant leadership e autoorganizzazione;
trasparenza nelle valutazioni;
collaborazione;
allargare la visione;
più produzione di valore;
conoscenza più diffusa;
decisioni più condivise;
più coinvolgimento nei progetti;
meno cost accounting e più produzione di valore;
meno piani dettagliati.

La presentazione si chiude con due slide significative: in una viene presentata una nutrita serie di testi a supporto di tali teorie; nella seconda, sono raccolti i nomi di aziende importanti, non solo IT, che nel mondo hanno adottato tale filosofia e stanno portando avanti con successo questo cambiamento di paradigma: nomi come Gore-Tex, Ikea, Google, Statoil, solo per citarne alcune, dovrebbero far riflettere gli scettici.

Francesco Dominidiato. Qualità degli individui e gestione delle interazioni: le chiavi per un software migliore

Da un punto di vista più prossimo a quello di chi ogni giorno deve sviluppare applicazioni e produrre codice, temi analoghi erano già stati affrontati nell’intervento di Francesco Dominidiato [4] al lunedì pomeriggio. La creazione del software è un processo maggiormente assimilabile a un lavoro creativo, come quello del mondo dell’editoria, e occorre sempre tenere in considerazione di differenza tra produzione industriale e sviluppo del software. Inoltre, è fondamentale che l’aspetto business e il reparto tecnico lavorino molto insieme.

Figura 6 – La differenza tra produzione industriale e sviluppo software: un punto di vista corroborato da esperienze professionali quotidiane. Filtro Valencia che con la sua alta esposizione, e temperatura tiepida, ben si adatta al tono dell’intervento.

Nell’esperienza di gestione di gruppi di lavoro vissuta dal relatore, con una convinta adozione di metodologie agili, sono emersi alcuni punti fondamentali che vengono proposti al pubblico, in particolare per quanto riguarda l’eliminazione del preconcetto “sviluppatore = ingranaggio di meccasnismo”, che ci portiamo dietro dalla organizzazione industriale fordista, ma che nel mondo complesso dello sviluppo spesso porta a disastri.

Una maggiore valorizzazione delle persone che devono svolgere il ruolo di programmatori può partire da una serie di punti importanti:

importanza del processo di reclutamento e assunzione del personale tecnico;
le persone al primo posto, come pratica e non come belle parole;
facilitazione delle interazioni;
valutazione sui risultati, non sul tempo trascorso a lavorare;
adeguato supporto a chi sviluppa: paga, fiducia, tempo, formazione;
carriere nel ramo tecnico: i bravi programmatori possono continuare a fare il loro mestiere, guadagnando di più senza dover diventare manager, se a loro non interessa diventarlo e preferiscono restare programmatori; è un fenomeno che in altre nazioni accade perche’ sono previste carriere tecniche anche ad alto livello.

Quest’ultimo punto è stato molto interessante, poiche’ affrontava una esigenza reale di cui spesso, almeno in Italia, non si ha consapevolezza.

La conclusione, molto serena, del è stata che, a livello di business, queste strategie hanno avuto successo, poiche’ l’azienda è andata meglio: la “spesa” fatta per il migliorato e più qualitativo processo di assunzione comporta un buon rientro. I programmatori, in definitiva, sono un asset fondamentale per ogni azienda IT o per ogni reparto tecnico, e questo, anche e soprattutto da manager, non va mai dimenticato.

UX design: riflessioni e strumenti

Altra tematica che ha visto interessanti proposte e numerosa partecipazione è stata quella relativa alla progettazione di esperienza utente. Di seguito riportiamo il resoconto di alcuni interventi che, anche se non tutti attribuiti alla track “UX” nel programma della conferenza, possono comunque essere tranquillamente fatti rientrare in questo ambito.

Hoang C. Huynh. Thank you for coding

Ci sono alcuni interventi più difficili da raccontare rispetto ad altri poiche’ non è solo il contenuto, ma anche la modalità con cui sono stati svolti a determinarne il senso e la portata. Sicuramente fra questi rientra quello di Hoang Chau Huynh [5] che i nostri lettori dovrebbero conoscere, visto che ha scritto per noi una bella serie intitolata “Appunti di UX design” [6]. Consigliamo quindi, quando sarà disponibile il video, di guardarlo sul sito di Better Software: la presentazione è stata molto divertente, con slide creative e piene di cultura pop, e ha proposto una riflessione legata al rapporto tra codice ed esperienza utente.

Figura 7 – L’intervento di Huynh si è caratterizzato per la brillantezza e le tinte forti: temperature calde e alta saturazione dei colori sono alla base del filtro Lo-Fi.

Siccome però vogliamo in qualche modo sintetizzare almeno i punti salienti della presentazione, diremo che il concetto principale espresso è tutt’altro che leggero: cattivo codice può rendere pessima la vita delle persone. Occorre avere coscienza che progettare esperienze e realizzare codice è un atto etico.

A dimostrazione di questo, vengono illustrati casi realmente drammatici dovuti a problemi “di codice”: scambio di codice fiscale, scambio di cartelle cliniche che in certi casi hanno portato anche ad esiti fatali, ma anche casi non certo drammatici ma con una portata significativa, come il tasto “one click” di Amazon. Vi è quindi una responsabilità sociale nella scrittura del codice di cui UX designer e programmatori devono essere consapevoli: è necessario adottare delle strategie per pensare al futuro anche quando si programma nel presente.

Raffaele Boiano. The storygraph: a cross-channel visualization tool for storytelling research

Raffaele Boiano [7] presenta lo storygraph, una tecnica per analizzare la ricerca utente, basata sulla “narrazione”.

Si parte, però, con un premessa metodologica tutt’altro che scontata e, invece, molto utile: nell’attuale panorama della antropologia culturale, ambito dal quale proviene il relatore, si è preso atto della cosiddetta “morte dell’osservazione partecipante” ossia del fatto che non sia tanto più possibile andare ad osservare ciò che fanno gli “oggetti” della nostra ricerca senza creare delle reazioni. Una volta prese in considerazione tutte le tecniche di “investigazione”, ci si concentra su quella rappresentata dalla “narrazione”: lo storytelling.

Come si evince anche dal nome, storytelling è legato al concetto di “storia”. È quindi importante comprendere questo concetto che viene utilizzato sia in ambito antropologico, sia in ambito di progettazione informatica.

Figura 8 – Il concetto di “storia” tanto importante nell’ambito antropologico quanto in quello della progettazione di applicazioni ed esperienze utente. Un filtro come Walden dona ai colori un tono “pittoresco” adatto all’approccio “obliquo” al problema adottato in questo intervento particolare e interessante.

Anzitutto va detto che esiste una differenza fra

storia
racconto
narrazione

Una storia è una serie di eventi in successione logica e cronologica; un racconto è la forma del discorso, le parole usate per raccontare una storia; la narrazione è invece un passo ulteriore e riguarda il modo, l’atto, le strutture con cui una determinata storia viene veicolata a un determinato pubblico da parte di un narratore. Le storie possono essere interpretate in modo diverso e questo è ciò che hanno fatto i diversi studiosi che si sono occupati in maniera più approfondita di queste tematiche.

Julian Orr concepisce la storia come “uno spazio condiviso”: nel suo “Talking about machines” questo autore definisce una vera e propria etnografia del lavoro moderno rendendosi conto che gran parte della conoscenza nell’ambito dei tecnici delle riparazioni di stampanti e macchine affini passava proprio in quello spazio comune rappresentato dalle storie, riguardo alla loro attività lavorativa quotidiana, che i diversi tecnici si raccontavano nella pausa pranzo o in altri momenti non formali.

Jan Chipchase considera la storia come dei “dati di campo” nel senso che il suo studio si orienta a comprendere gli oggetti che le persone portano con loro, specie in ambito di culture diverse, ed è abbastanza simile a quello che veniva fatto sul campo con popolazioni “primitive”, nel senso che questo autore va in giro e osserva, domanda, intervista per capire cosa è ritenuto fondamentale dalle persone come “corredo” da avere sempre con se’. Questi studi sono di grande interesse per le aziende che si occupano di mobile poiche’ le aiutano a comprendere ciò che va messo nello hardware e nel software dei dispositivi mobili che poi dovranno produrre e vendere. Un esempio dell’applicazione di questi studi sta nella realizzazione di un sistema di pagamenti e di prelievo del denaro utilizzando una tecnologia estremamente semplice e apparentemente superata come quella degli SMS, con cui è stato possibile creare, ad esempio in Uganda, una specie di bancomat decentrati nei vari villaggi.

L’italiano Alberto Marradi, invece, interpreta le storie “come strumenti”: usando le storie è possibile far raccontare alle persone tante cose che, altrimenti, potrebbero non venir fuori per la reticenza o la riservatezza. L’esempio tipico è quello utilizzato con una storia in cui un ipotetico guidatore nel deserto in mezzo al nulla si trova all’improvviso davanti a un semaforo rosso, avendo perfetta visibilità su tutto ciò che lo circonda e con l’assoluta sicurezza che non ci sono mezzi che arrivino in quel momento da nessuna parte: che fare? Fermarsi al rosso? Ignorarlo vista la situazione? Rallentare e poi ripartire? Ecco questo è un caso in cui una storia aiuta a mettere in luce il modo di pensare del soggetto. Le storie quindi, diventano strumento.

Ed ecco che passiamo al modo in cui tutta questa “teoria” può venirci incontro nell’ambito della progettazione dell’esperienza utente. In senso ampio e non solo agile, una “storia utente” (user story), è una descrizione parziale dell’esperienza utente con un prodotto o servizio: questo concetto ha fatto sì che nell’ambito dello studio dell’esperienza utente e anche del marketing si sia messa a punto la tecnica dell’intervista narrativa, l’uso delle personas, e il cosiddetto “libro dell’azienda” che raccoglie tutte le storie.

Il problema con queste tecniche è però che occorre riassumere: nessuno, anche se dovrebbe, si legge un libro di 200 pagine con tutte le storie; per questo diventa importante la rappresentazione visuale delle informazioni/storie in adeguate “mappe”.

Queste mappe che visualizzano l’esperienza dell’utente con un dato prodotto o servizio esistono e si chiamano experience map o user journey. Grandi aziende come Lego o Starbucks ne fanno uso perche’ le aiutano a capire come l’utente interagisce con i diversi touchpoints, ossia i “punti di contatto” tra l’utente e il canale o la modalità con cui fruisce del servizio o del prodotto. Lo schema è abbastanza semplice: su un sito, ad esempio, di prenotazione online di biglietti, si osserva che cosa fa l’utente nei diversi momenti e si verifica se a quelle determinate azioni corrisponde uno stato di soddisfazione, di insoddisfazione oppure di neutralità.

Figura 9 – Lo storygraph è uno strumento visuale che ci consente di sintetizzare l’esperienza utente.

L’invenzione del relatore è lo storygraph, che serve a riassumere e sintetizzare in maniera visuale le storie: il concetto è lo stesso delle mappe d’esperienza o dei viaggi utente, ma il modo in cui viene fatto è diverso. Lo storygraph è infatti una matrice in cui sulle colonne (indicate da lettere) abbiamo i touchpoints, ossia i diversi canali di interazione come blog, pubblicazione istituzionale, ufficio fisico, servizio di assistenza telefonica ai clienti; sulle righe, invece (indicate da numeri), ci sono i bisogni utente, cioè quello che l’utente desidera fare.

La valutazione di come sono andate le cose viene fatto attraverso dei cerchietti che, se vuoti, indicano che il canale non è adatto, se pieni indicano che il canale è perfettamente adeguato, mentre se sono pieni a metà indicano che il canale è adatto ma non ideale.

Lo storygraph ci consente di:

identificare punti di entrata e punti di uscita nel percorso dell’esperienza utente;
assegnare a ogni punto dei valori emozionali (+2, +1, 0, -1, -2);
valutare ciò che funziona meglio e ciò che non funziona nell’esperienza utente che si offre;
ripensare il modo in cui la UX è stata realizzata, in un’ottica di change management.

Si tratta di uno strumento utile e abbastanza intuitivo nella consultazione, che però ha un valore soprattutto qualitativo: tante storie aiutano ma non è detto che siano necessariamente storie significative; a volte bastano due o tre storie significative per capire molto di ciò che sta accadendo al nostro utente. Per la ricerca sugli utenti (user research), conta la quantità ma anche molto la qualità.

Un intervento lungo, ben strutturato e capace di mettere insieme basi di ricerca e risultati di una applicazione pratica a prodotti.

Luca Mearelli. Sulle spalle dei giganti

In che modo il “comune mortale” che sviluppa applicazioni “normali” (come software gestionali o applicazioni per il settore finanziario) può prendere atto delle lezioni impartite dai grandi attori del panorama IT mondiale? A un interrogativo di questo genere risponde Luca Mearelli [8] con un intervento molto lineare.

L’utente medio ha poca voglia di imparare a usare cose nuove o programmi complicati: vuole semplicemente “farci qualcosa”. L’esempio tipico è quello del software gestionale: perche’ non sfruttare l’esempio di applicazioni già esistenti e molto utilizzate (i “giganti”) per desumere alcune lezioni e applicarle anche in ambiti diversi, rendendo più immediato l’uso e l’apprendimento di applicazioni “noiose” o complicate?

Figura 10 – Luca Mearelli e l’imitazione dei modelli di interazione proposti dai big player del mondo IT. Il filtro Kelvin scalda moltissimo, carica i colori, ma è anche di difficile applicazione a tante situazioni, proprio come accade con le esperienze utente dei big player IT da applicare a settori quali quello finanziario o gestionale.

L’utente medio, ad esempio, usa il motore di ricerca per qualsiasi cosa: questa ricerca immediata in un campo testo dovrebbe funzionare anche con i gestionali. Strategie per applicarla:

applicazione destrutturata e full text;
applicazione che “impara” quali sono i risultati più rilevanti;
funzioni in tempo reale con accesso a dati che si sono accumulati anche nell’ultimo periodo.

Con un meccanismo del genere, diventa importante la condivisione delle informazioni che vengono generate all’interno dei processi aziendali: nei gestionali, ad esempio, diventa fondamentale la presentazione delle scadenze.

Altro esempio è quello del diario di Facebook o di altri social network: questi sono connotati dal concetto di cronologia (si capisce cosa è prima e cosa è dopo) e di correlazione (si capisce cosa è legato a cosa). Questo è un meccanismo molto utile ma va bene solo per un certo tipo di informazioni: quelle che hanno un tempo di vita breve o medio possono essere trattate bene con una interfaccia a “wall” come quella di Facebook o Twitter. Le informazioni a vita lunga, invece, non si prestano bene a questo tipo di trattamento.

Un ulteriore esempio di strategia che può essere imitata è rappresentato dallo hashtag che diventa un vero e proprio aggregatore; grazie ad esso infatti è possibile ottenere:

una dichiarazione di interesse per un contenuto;
l’aggregazione di tutti i contenuti marcati con quello hashtag.

Quindi, le strategie che possiamo copiare dagli “giganti” anche nel mondo dei gestionali, degli ERP e così via sono principalmente:

ricerca;
messaggi e notifiche;
aggregazione;
presentazione cronologica della successione delle informazioni.

Non è facile, ma occorre cercare una armonizzazione tra modello dati, desideri della committenza e bisogni del reale utente finale.

Marianna Cerato & Ilaria Mauric. Cosa manca a un brief

Confesso che sono andato a questa presentazione con un minimo di “prevenzione”: la parola brief riusciva ad avere su di me un effetto quasi irritante, e mi sembrava così lontana da un certo modo agile di affrontare i progetti, al punto che avrei accettato volentieri un più classico e pesante “documento dei requisiti”… Ma le relatrici hanno subito diradato ogni dubbio, presentando un mix empirico di Agile UX e lezioni imparate “in trincea” con un approccio molto sensato e concreto. Marianna Cerato e Ilaria Mauric lavorano allo sviluppo frontend e alla progettazione della UX per GNV & partners [9] e si trovano spesso a lavorare con aziende molto “classiche”, che però, e questa sarà una delle conclusioni, recepiscono bene un modo più snello di lavorare quando vedono che il metodo funziona, quando questo viene loro spiegato e se si crea fiducia a piccoli passi.

Figura 11 – Marianna Cerato e Ilaria Mauric: come passare dal classico documento dei requisiti a un processo di progettazione della UX più agile collaborativo ed efficace. Toni tenui, basso contrasto: il filtro applicato è Nashville.

Si parte dal prendere atto dei limiti del brief come documento per la trasmissione di informazioni per progetti “creativi” e “grafici”, intendendo per brief un documento di 5-100 pagine, spesso con lacune e informazioni non chiare o richieste “bizzarre”. Ma il brief, come indicato dal nome, dovrebbe essere breve, sintetico, informativo.

Da chi nascono le idee contenute in un brief? Su cosa si basa l’idea contenuta in un brief? Chi deve approvare il brief? Questa è un po’ la classica “intervista doppia”, in cui i committenti danno un certo tipo di risposte, spesso molto diverse da quelle che cercano gli sviluppatori. C’è un disallineamento tra committente e realizzatore. Ne derivano rigidità e mancanza di informazioni, o informazioni incomplete.

La realizzazione del brief può prendere un tempo variabile, da 1 settimana a 1 mese, e spesso in esso vengono citati uffici tecnici, legali, amministrativi, che però non vengono mai coinvolti nel processo di scrittura. Il committente, infatti, si aspetta spesso semplicemente che il designer si occupi della grafica, lo sviluppatore del codice, e che queste figure non partecipino alla realizzazione del documento dei requisiti.

In genere, il brief non è stato verificato con gli utenti e con le persone che comunque saranno coinvolte, così come spesso non è esplicitato chiaramente il dominio del committente, che invece costituisce una informazione importantissima e cruciale.

Che cosa manca , quindi, nel concreto, affinche’ questo documento serva veramente al processo di sviluppo e non sia soltanto il frutto di sterili rituali?

Definire il dominio in maniera condivisa.
Dichiarare la strategia di business: il committente deve dire qual è il suo business e quali sono gli obiettivi, quali le aspettative, quali i soldi a disposizione. Gli obiettivi devono essere SMART (specifici, misurabili, raggiungibili, pertinenti, con tempi definiti).
Verificare la sostenibilità del progetto, non solo in termini economici: è possibile arrivare in fondo insieme? Questo implica anche una “pulizia” del linguaggio: scegliere i termini potenzialmente dubbi e chiarirli, in maniera da avere una esatta sovrapposizione delle definizioni.
Ridefinire i ruoli: tutti partecipano, non in maniera settoriale.
Condividere la “visione progettuale” (design vision): team multidisciplinare che “va sul campo”. Si mescolano poi le varie idee e le si dettagliano in meglio, fino a definire le epic stories.

Arriviamo alle buone pratiche:

chiedere sempre il perche’;
guarire dalla sindrome del “me l’avete detto voi”;
individuare chiaramente interlocutori e Product Owner;
effettuare rilasci su priorità;
misurare quello che si può;
rinunciare al proprio ego: il progetto è pagato dal committente e fatto per l’utente, non è lì per la gloria degli sviluppatori e dei grafici.

Tutte queste pratiche riducono nettamente i tempi e garantiscono altri vantaggi:

meno spreco;
meno dispersione di informazioni;
significativa riduzione del rischio;
famigerate “riunioni” che diventano più operative e fruttuose;
scelta consapevole grazie ai team multidisciplinari.

Nel complesso, un bell’intervento, capace, come detto, di calare certi principi Lean/Agile UX nel reale processo di definizione e raccolta dei requisiti e nella pratica della progettazione di esperienza utente e frontend.

Prodotto e progetti: stime, previsioni e gestione del rischio

Numerosi interventi hanno trattato il tema del “prodotto” in senso lato e del “progetto” che, almeno in parte lo implementa, affrontandolo dalle più diverse angolature. Tra questi interventi, vanno sicuramente inseriti quelli dei due ospiti stranieri, Olav Maassen e Yoav Aviram, che quest’anno hanno conferito alla conferenza un respiro di maggiore internazionalità.

Olav Maassen. Risks and decisions. The “when” rather than the “how”

Olav Maassen di Xebia [10] affronta nel suo keynote un dicorso sul processo decisionale e sul concetto di rischio, presentando il modello real options secondo il quale:

le scelte hanno un valore;
le scelte hanno una scadenza;
è bene evitare di impegnarsi troppo presto a meno che non si sappia molto bene perche’.

La “scadenza” delle scelte, ossia il momento in cui o si fa la scelta o l’opzione non è più percorribile, è denominato “ultimo momento responsabile”.

Che cosa è il commitment cioè l’impegno? È qualcosa che “si deve fare”. Che cosa è opzionale? Per spiegare tutto questo vengono riportati degli esempi inerenti un tuffo in acqua da una scogliera (si può scegliere se saltare o no, ma una volta in volo diventa impossibile decidere di tornare indietro durante il tuffo) e del biglietto aereo (si può acquistare e non volare, oppure andare in aeroporto, fare il check in e non salire sull’aereo, ma una volta che si è al proprio posto, con la cintura allacciata, e l’areo sta decollando, non si può più scegliere di non volare).

Uno dei problemi delle scelte è che non ci piace stare nell’incertezza e che però ci piacciono le scelte reversibili: il roll back ci dà sicurezza. Le scelte che facciamo ci inducono a pensare a come posso tornare indietro, ma anche a quanto tempo ci vuole per farlo. La probabilità c’entra poco.

Figura 12 – È possibile utilizzare una graphic novel come strumento per trattare le tematiche inerenti le decisioni e la gestione del rischio. In accordo con lo stile bianco/nero del fumetto “Commitment”, scegliamo il filtro Inkwell.

Su tutte queste tematiche, il relatore, insieme a un coautore (Chris Matts) e a un disegnatore (Chris Geary) ha pubblicato un libro a fumetti, intitolato appunto “Commitment” [11], dal quale appare chiaro che sono importantissimi i tempi cui si fanno le scelte: il quando assume un valore grande almeno quanto il come.

Yoav Aviram. Business model innovation by experimentation

Anche l’altro ospite straniero, Yoav Aviram, direttore di Energized Work [12], ha affrontato tematiche legate al rischio nei progetti IT. Si parte, prendendo atto del fatto che i progetti IT falliscono in un numero elevato di casi. Perche’?

Il problema non è solo ne’ nel software ne’ nella metodologia, ma nell’idea alla base del prodotto. È una questione di prodotto e pertanto occorre anzitutto chiedersi:

Chi sono i clienti?
Chi è il competitore?
Qual è il segmento di mercato in cui si colloca il prodotto?

È una questione di business model in cui la distinzione tra personale tecnico e personale business è anacronistica.

Figura 13 – Anche Yoav Aviram affronta il ruolo di incertezza, rischio e informazione per la buona riuscita dei progetti IT. La focalizzazione del talk sul concetto di prodotto, rispetto al focalizzarsi su software e metodologia, è associabile al filtro Toaster, che aggiunge esposizione e messa a fuoco al centro dell’immagine.

E veniamo al discorso inerente l’incertezza e il rischio, introdotta con il riferimento a un gioco televisivo britannico, in cui i concorrenti sono messi davanti a delle opzioni continue e mutevoli e vincono dei premi in base alla bontà delle scelte che fanno. Per una azienda è fondamentale la gestione del rischio, dell’incertezza e l’uso adeguato delle informazioni disponibili.

Gestione e riduzione del rischio:

variegare le “scommesse” su un insieme di idee, non su una soltanto;
decidere che tipo di strategia di investimento si intende adottare;
suddividere l’investimento in piccole “scommesse” che aumentano progressivamente, puntando in particolare sulle idee migliori che, a poco a poco, prendono corpo.

Gestione e riduzione dell’incertezza:

l’informazione riduce l’incertezza;
la riduzione dell’incertezza migliora le decisioni.

Dove si va a prendere l’informazione?

dentro l’azienda (ce n’è tanta);
grazie alle ricerche altrui;
grazie ai risultati di esperimenti;
dai dati derivanti da prodotti, grazie agli Analytics.

Per avere informazioni, diventano importanti gli esperimenti e la scoperta “sperimentale”, nonche’ la misurazione, sia da un punto di vista qualitativo che quantitativo. Spesso il qualitativo ci dà indicazioni buone tanto quanto il quantitativo. Le metriche quantitative devono essere comparabili e aiutare nelle decisioni. La chiave per il successo di progetti IT sta nella migliore gestione del rischio, riducendo l’incertezza. Gli esperimenti rappresentano il modo più efficace per ottenere informazioni.

Si è trattato di un intervento molto peculiare, che dimostra però il modo innovativo di affrontare i problemi da parte di molte aziende estere, e che avrà colpito in particolare coloro che si occupano di investimenti in imprese tecnologiche e startup.

Gaetano Mazzanti. Uno, nessuno, centomila… progetti

Gaetano Mazzanti di Agile42 [13] presenta una serie di considerazioni che si possono applicare all’arte di condurre progetti, perche’, anche se ci sono differenze tra portare avanti un solo progetto per volta o molti progetti in parallelo, tra lavorare a una startup o a un progetto legacy, tra essere i diretti “inventori” del progetto o dei consulenti “esterni” che forniscono servizi e supporto, ci sono comunque dei tratti comuni nel modo in cui affrontare il lavoro, che valgono in tutte le situazioni, primo fra tutti la comprensione di come scorre il flusso.

Un aspetto importante, come sempre, è il valore nella sua diversa accezione: quindi anche il valore economico, che non va trascurato, ovviamente. In realtà, spesso le decisioni sono prese su altre ragioni: chi si impone gridando, l’opinione della persona più pagata nella struttura (HIPPO: HIghest Paid Person’s Opinion), oppure non meglio chiare motivazioni “di alto valore strategico”.

Uno dei miti più rischiosi è quello dell’impiego delle persone al 100%: insieme a quello del multitasking, è causa delle “code” e di una serie di task incompiuti. Tutto questo può comportare fallimento e conseguente frustrazione.

Figura 14 – Per Gaetano Mazzanti esistono dei tratti comuni da tener sempre presenti nella gestione, sia che si affronti un singolo progetto o una serie di progetti paralleli, sia che si lavori a una startup che a un progetto legacy. L’intervento getta luce su alcuni aspetti spesso lasciati in ombra, proprio come il filtro Amaro che, aumentando leggermente l’esposizione, rende più chiare le immagini.

Quindi, che fare? Occorre un meccanismo trasparente per bilanciare domanda e offerta con un modo chiaro di selezionare cosa fare e cosa non fare. “Se non lo vedi, non lo puoi gestire!”: occorre comprendere il sistema, anche se è difficile. Molte aziende pensano di sapere esattamente cosa sta succedendo, magari grazie al loro ERP, ma in realtà non hanno una visualizzazione chiara della situazione.

Si deve anzitutto mettere in luce ciò che non funziona. Occorre bilanciare la capacità disponibile e le richieste accettate, ed è necessario condividere in maniera collaborativa cosa facciamo, cosa mettiamo in coda, e cosa abbandoniamo. Dobbiamo fornire un servizio per far sì che il flusso delle attività vada avanti.

Le metriche che contano sono quelle che devono interessare l’azienda: qui c’è spesso una forte discrepanza tra metriche incentrate sul cliente e quelle che interessano al management classico.

Inoltre occorre comprendere l’opposizione dialettica che c’è tra selezione e prioritizzazione: scelte e priorità non sono la stessa cosa: passare dal “che facciamo dopo?” al “che cosa finiamo ora?”.

È possibile calcolare il “costo della procrastinazione” (cost of delay) per avere una risposta alla domanda “quale faccio come prossima cosa?”. Valutando la durata, valutando il costo del ritardo, valutando se non sia meglio rimandare qualcosa sulla base del costo del ritardo, possiamo fare delle scelte più informate.

La conclusione del talk è netta: a differenza di quanto propugnato dal Taylorismo… non ci sono “best practice”; laddove sia presente la componente umana, la complessità è tale da impedire di fare pianificazioni certe.

Luca Mascaro. Non mi rompete i c*******!

Luca Mascaro di Sketchin [14] affronta invece il concetto di collocazione e penetrazione di un prodotto, nello specifico delle app per mobile. La curva di esperienza utente con un prodotto ha una forma tipica e può anche ripetersi nel senso che, quando la fine di questa esperienza non è positiva, si ha la tendenza a ripartire con una nuova esperienza che magari si concluderà anch’essa in maniera non positiva. Dopo alcuni di questi “giri” molto simili l’uno all’altro, si instaura il meccanismo del buono abbastanza o, se vogliamo, del “meno peggio”.

C’è una necessità di “energia per il cambiamento” che diventa una sorta di barriera di uscita; è il concetto riassunto nel detto “il gioco vale la candela”: se lo sforzo che devo fare, se l’impegno che devo profondere è troppo elevato in relazione al risultato atteso, è probabile che non mi sforzerò per cambiare servizio o prodotto. Questo fenomeno ha anche una componente emozionale: a fronte del meccanismo del buono abbastanza, del “mi accontento”, c’è anche quello contrario, ossia quello del cambio di continuo.

Il meccanismo del “buono abbastanza, mi accontento” funziona in genere in ambiti “statici”, come il mercato dei trasporti o delle telecomunicazioni o dei servizi (acqua, gas, luce e così via). Il meccanismo del “cambio di continuo” funziona invece tipicamente nei mercati molto dinamici e meno strutturati: il primo esempio è quello delle app e dei giochi per i dispositivi mobile.

Figura 15 – Luca Mascaro affronta la tematica della collocazione e della penetrazione sul mercato di prodotti come le app per dispositivi mobile. Il filtro Brannan, con le sue tinte “metalliche” e distinte, fotografa abbastanza bene i “meccanismi” di adozione di cui si parla nell’intervento.

Un’applicazione, un servizio di successo fanno leva su un meccanismo caratterizzato da quattro fasi:

promessa
adozione
coinvolgimento
fedeltà (“value services”)

Per quanto possa apparire strano, una buona esperienza utente non garantisce automaticamente il successo del prodotto. Perche’? Perche’ io posso creare la migliore app del mondo, ma ce ne sono anche altre, magari quasi altrettanto buone, e il numero di applicazioni usate in media è limitato e molto basso. In Italia, la media di app adottate è 15, in Svizzera è 25: è chiaro che ci sono persone che ne usano molte di più rispetto alla media, ma anche se ipotizziamo un uso di 40-50 app, il numero resta comunque basso, e alla nostra applicazione occorre in ogni caso rientrare nella “top 50”, per essere adottata.

Questo non è affatto facile quando magari esistono già altre 3-4 app ottime che fanno la medesima cosa della nostra (per non parlare delle decine di “buone abbastanza”). A ciò aggiungiamo il fatto che preferiamo avere poche relazioni “commerciali” cioè preferiamo avere pochi provider per molti servizi.

Da tutto questo ragionamento deriva una scelta di collocazione sul mercato: il “buono abbastanza” vale per chi punta al risparmio, ma, per fasce di consumatori più ricche e che possono spendere qualche soldo in più, avere un’esperienza utente migliore, e che si integra bene nel loro ritmo circadiano, è molto più importante del prezzo. Questo va tenuto presente.

Aziende che cambiano

Alcuni interventi si sono incentrati su come cambiano in senso Agile aziende e metodologie, portando all’attenzione casi d’esempio ed esperienze dirette, oppure si sono focalizzati su come e perche’ alle aziende conviene cambiare verso Lean/Agile, favorendo delle riflessioni e individuando possibili percorsi.

Alberto Brandolini. Kanban unbounded

Tra coloro che si sono focalizzati sul possibile cambiamento, c’è Alberto Brandolini [15] che ha proposto una serie di spunti di riflessione per interrogarsi su quel che accade quando filosofia lean e pratica agile cominciano a interessare non solo il team di sviluppo, ma altri settori dell’azienda, influenzandone le scelte strategiche.

Figura 16 – Vignettatura, forte contrasto, colori saturi: il filtro Hefe ben si adatta all’intervento di Alberto Brandolini intitolato “Kanban unbounded”.

Per Alberto, kanban è una scusa… per affrontare i problemi. Non possiamo risolvere un mucchio di problemi, ma possiamo affrontarne uno per volta e in questo kanban ci aiuta senza dubbio. Anche i problemi e le i modi per risolverli possono essere classificati. I problemi creati da noi per noi… li possiamo risolvere tra noi: è faticoso, ma si fa.

I problemi che noi creiamo per gli altri… sono più complessi. Non basta una code coverage perfetta per risolverli, perche’, molto semplicemente, software non equivale esattamente a prodotto. Il Product Owner serve quindi anche in kanban, ed è quindi una figura centrale, per quanto, in certi casi, evanescente. Dobbiamo ridurre il numero di cose da dirci. L’Object Oriented è un paradigma applicabile all’organizzazione aziendale, prendendo spunto, ad esempio, dai pattern GRASP: i modelli di comunicazione e collaborazione sono prevedibili (modello del Domain Driven Design).

E infine… i problemi che l’esterno crea a noi verso l’interno. Qui la situazione è molto complessa, con numerose componenti: un valore veramente forte per la loro risoluzione sta nella trasparenza e nel continuo, sempre maggiore coinvolgimento del gruppo di sviluppo cui devono arrivare informazioni che riguardano altri dipartimenti, e che deve poter influenzare le scelte strategiche dell’azienda cui appartiene o per cui sta lavorando.

In tutto questo, emergono alcune pratiche:

ripensare i servizi;
criticare le supposizioni e la “scontata” esattezza dei fogli di calcolo (guardatevi, nel video, a quali errori di portata mondiale ha condotto la fede cieca nelle righe, colonne e celle…);
comunicare;
ricordarsi sempre che le persone non sono righe di Excel.

Questo è stato un altro di quegli interventi che varrà la pena di rivedere completamente in video, per la sua ampia portata e per il gran numero di considerazioni lanciate al pubblico, oltre che per lo stile sempre divertente del relatore

Francesco Degrassi. Building software that matters

Il resoconto di quel che avviene quando si effettuano in maniera “gentile” cambiamenti anche drastici nell’approccio ai progetti e alle aziende costituisce il succo dell’intervento di Francesco Degrassi [16].

Si racconta un caso reale, con l’analisi di una azienda che aveva diversi dipartimenti indipendenti, a “silos”: nonostante l’uso di Test Driven Development, XP e altre pratiche avanzate, spesso si sono creati automatismi di processi inutili; e spesso il cliente non ha riconosciuto il valore di quello che veniva fatto. È stato quindi necessario un cambiamento di prospettiva: dalla creazione di software, al raggiungimento di obiettivi. Quindi appare chiaro come sia importante definire insieme al cliente, di volta in volta, obiettivi realistici su cui impegnarsi insieme, e come le aziende di sviluppo/consulenza debbano entrare nell’ottica di lavorare con il cliente e non per il cliente.

Figura 17 – Realizzare software che abbia importanza per gli obiettivi del cliente: un esempio di cambiamento nell’approccio con il cliente e nelle pratiche di sviluppo. Un approccio radicale al cambiamento, che pero è gentile e morbido nei rapporti con il cliente: il filtro Rise rende i toni caldi e garantisce una luce più diffusa alle immagini.

In questo caso specifico, si è decisa l’adozione del continuous delivery, abbandonando addirittura il backlog: proporsi al cliente con tali premesse è stato difficile; ma poi, visti i primi risultati, le cose hanno funzionato: con un approccio anche radicale nella pratica, ma “gentile” e coinvolgente nei confronti del cliente, questo riesce, a poco a poco, a prendere atto della complessità e ad accettare ben volentieri questo nuovo modo di lavorare.

Alcune considerazioni conclusive che derivano da questa esperienza sono così riassunte:

L’importanza di veri stakeholder: avere contatti diretti con gli operativi, mettere in contatto diversi gruppi, trovare manager che gestissero insieme costi e ricavi e non lo facessero in maniera separata.
Costruire fiducia: rapporto personale, trasparenza, favorire la condivisione delle informazioni.
L’importanza della consegna di software funzionante.
Cultura del rispetto tra cliente e sviluppatori: l’importanza di terminologie e lingua condivise.
Le guerre tra innovatori e conservatori servono a poco: da noi non funziona il buttare platealmente nel cestino il documento dei requisiti.
Non dimenticarsi di mostrare i risultati ottenuti: demo del gruppo di sviluppo con il cliente.
Il cliente non è interessato alle funzioni del software ma al valore che esso può creare.

Lorenzo Masacci & Alessandro Violini. Team agile versus budget fisso: la nostra esperienza e i nostri errori

Altro intervento che illustra come si può applicare una metodologia agile a situazioni “classiche”, sperimentando dei cambiamenti anche drastici in situazioni reali è quello di Lorenzo Masacci e Alessandro Violini di e-xtrategy [17], dove svolgono principalmente il ruolo di sviluppatori frontend per la realizzazione di applicazioni web e mobile in cui utilizzano metodologie agile.

I due partono da una considerazione molto realistica: ci sono situazioni in cui il budget è fisso (bandi pubblici, pubblica amministrazione, etc.) e questo già blocca uno dei tre vincoli fissi del cosiddetto triangolo di ferro di scopo/qualità, risorse/budget e tempo. Come ci si può muovere in questo scenario?

Spesso anche la pianificazione temporale del progetto è abbastanza vincolata: i tempi vanno rispettati, anche se sono stati definiti a priori senza che ci fosse una precisa delineazione del progetto.

Resta allora il lato rappresentato da scopo/qualità su cui si può andare a intervenire. La qualità, secondo i relatori, non si tocca, proprio per ragioni etiche e comportamentali: non si può chiamare per un concerto un bravo pianista classico e dirgli poi “Ti pago meno, quindi puoi suonare male”… Per lui suonare male non è una opzione, visto che, oltretutto, danneggia anche se’ stesso e la propria reputazione.

Quindi, in definitiva è la “portata”, lo “scopo” del progetto la dimensione più malleabile, ed è lì che si deve andare a lavorare in un progetto a budget fisso.

Il progetto viene riassunto con la metafora del viaggio:

carburante = budget;
motore = team di sviluppo;
autista = Product Owner;
navigatore satellitare = tutti coloro che sono coinvolti.

Se il carburante è limitato, conterà anche lo stile di guida, ma la distanza che è possibile percorrere dovrà rimanere comunue entro un ben preciso intervallo. Assume pertanto importanza una soluzione contrattuale che prevede un contratto aperto a budget fisso, ma che non blinda lo scope il quale viene ricontrattato insieme al cliente a mano a mano che il progetto progredisce.

Una volta spiegato questo approccio, i relatori si concentrano sull’importanza della retrospettiva: una valutazione critica sui loro progetti pregressi li ha portati a quantificare un 60% di fail, e un 40% win. Ma su quali basi? Non tanto quelle della consegna del progetto e del rispetto del contratto, ma la valutazione viene effettuata prendendo in considerazione l’aderenza ai principi del manifesto agile, e le modalità di attuazione del metodo.

Figura 18 – L’importanza della retrospettiva nei progetti agile è uno dei punti forti dell’intervento di Lorenzo Masacci e Alessandro Violini. In “retrospettiva” guardiamo anche noi, scegliendo come filtro “1977” che modifica le fotografie con la sua alta esposizione e il viraggio verso toni rossi, facendole apparire come se fossero state scattate molti anni prima.

Da queste retrospettive, emergono alcuni elementi comuni, sempre importanti per la riuscita di un progetto:

presenza di un vero product owner: se c’è, ed è vero (non un intermediario), il PO ha visione e potere decisionale;
la “portata”, lo scopo è fondamentale: se è chiaro ed è adattato in base agli altri vincoli, è il vero fattore di successo o fallimento di un progetto a budget fisso;
assenza di conflitto fra le parti: tra committente e realizzatore deve esserci condivisione di informazioni, desideri, aspettative, e collaborazione nella metodologia adottata e nelle diverse fasi di realizzazione.

Intervento molto concreto, molto legato alla pratica sul campo, e dal quale emergono alcune interessanti considerazioni rispetto a come sia possibile cambiare modo di lavorare anche in situazioni più “rigide”.

Franco Lucchesi. I vantaggi di essere agili a 717 anni

Questo è stato un intervento particolare, poiche’ è il racconto, dall’interno, di un processo di adozione di metodologie agili per il sito e l’infrastruttura informatica di una azienda… molto particolare. Si tratta infatti dell’Opera del Duomo [18] ossia l’ente che ha il compito istituzionale di manutenzione, memoria (quindi, adesso, digitalizzazione a beneficio di tutti), promozione delle strutture architettoniche, del museo e del patrimonio culturale legato alla Cattedrale di Santa Maria del Fiore di Firenze. In breve, una “azienda” davvero molto… “classica”, visto che è stata fondata nel 1296 contestualmente all’inizio della costruzione della cattedrale.

L’azienda si sostiene, essenzialmente, grazie ai proventi derivanti dal turismo oltre che dalla gestione di immobili e altri asset entrati nelle sue compentenze grazie a lasciti ed eredità. È pertanto orientata, ora più che mai, a massimizzare il flusso di visitatori alle varie strutture del Grande Museo del Duomo, cosa non facile in una città che offre, accanto a questa, un’offerta di turismo culturale tra le più imponenti al mondo.

Dopo tanti anni di storia, anche l’Opera del Duomo si è trovata a “scontrarsi” con l’adozione delle metodologie agile, per la realizzazione della sua infrastruttura informatica e del sito. Il presidente attuale, l’avvocato Franco Lucchesi, ha raccontato quale fosse il progetto e i passi che sono stati percorsi fin qui per realizzarlo. Il progetto: unificare il biglietto, creare il Grande Museo del Duomo, creare interazione con il sito.

Figura 19 – Franco Lucchesi, presidente dell’Opera del Duomo di Firenze, racconta dall’interno il processo di adozione di metodologie agili che è in atto in una delle “aziende” più antiche del mondo. I colori tenui e le luci soffuse del filtro Earlybird sortiscono un effetto “vintage” che ben si adatta alla storia secolare della particolare azienda in questione.

Il metodo prevedeva progettazione completa di tutti i canali, microstep operativi, report e strumenti di valutazione. C’è stato un vero e proprio product owner incaricato di occuparsi del progetto.

Ci sono anche state delle criticità derivanti in gran parte al tipo di organizzazione pregressa:

mancanza di comunicazione interna;
autoreferenzialità;
pochi stimoli interni al cambiamento;
approccio molto “istituzionalizzato”;
necessità di creare risorse dedicate al progetto;
riuscire a selezionare le informazioni pertinenti da condividere.

Nonostante questo, le metodologie agili di progettazione e sviluppo hanno comportato dei cambiamenti all’interno della struttura, e hanno portato l’Opera del Duomo a impegnarsi su alcuni “valori”:

trasparenza nella comunicazione;
apertura alla critica;
flessibilità e disponibilità al cambiamento.

La conclusione dell’intervento è stata che, anche nell’adozione di metodologie Agile, il passato e la storia di una azienda non deve mai essere un peso, ma una risorsa a cui attingere e su cui innestare l’innovazione.

Tecnologie e architetture

Sebbene in misura ridotta, non sono mancati anche alcuni interventi più strettamente legati ai tool, alle tecnologie e alle architetture software. Ne abbiamo seguito solo uno, che riportiamo di seguito, a conclusione del nostro resoconto.

Sam Reghenzi. Scimmie, noccioline e codice

In questa presentazione, Sam Reghenzi [19] ha affrontato la tematica dell’uso e abuso dei framework nello sviluppo del software. Il relatore si considera un “sopravvissuto” a un’epoca in cui si programmava da zero, senza adeguata progettazione; e a un progetto aziendale enorme per la realizzazione di un framework utilizzato per lo sviluppo applicativo.

Vengono messi in luce limiti e difetti dei framework: i framework sono utili, ma in certe situazioni possono veramente fare del male. “La strada dell’inferno è lastricata di buone intenzioni”: questo non significa essere in assoluto contro i framework, ma per un loro buon uso.

Figura 20 – Sam Reghenzi affronta i rischi di “abbrutimento” del programmatore insiti nell’abuso o nell’uso sbagliato di strumenti come i framework. Certi toni “drammatici” inerenti i rischi di un uso sbagliato dei framework sono presenti anche nel filtro Sutro, con il suo forte contrasto tra alteluci e ombre, e la prevalenza di tonalità quali il seppia e il viola.

Uno dei motivi principali per cui i framework vengono usati a sproposito è la trappola dello standard: il framework mi consente il riuso, la modularizzazione, si basa sulla specializzazione delle persone in un determinato linguaggio/determinata tecnologia, consente la sostituzione intercambiabile di personale. Il management così ritiene di poter fare stime lineari (primo errore), di pensare a una “equivalenza” delle capacità tra i vari lavoratori visti come se fossero “ingranaggi” (secondo errore), di garantirsi una manutenzione a costi ridotti in maniera “meccanica” (terzo errore).

Interessante mettere a fuoco due categorie principali di chi adotta il framework:

i fondamentalisti, che si innamorano di un framework e lo difendono in maniera “talebana”;
gli sperimentatori compulsivi, che sentono il bisogno irrefrenabile di provare ogni nuovo framework, lo adottano per un breve periodo e poi lo abbandonano per uno nuovo, lasciando in giro lavori senza supporto futuro.

Il framework può creare una sindrome per cui non si cresce e ci si vincola adesso. Per quanto un framework possa essere eccezionale, non sostituisce conoscenza, ragionamento ed esperienza. Senza visione globale sul progetto, e senza adeguata conoscenza di programmazione, si va poco lontano.

Chiaramente, ci sono situazioni in cui i framework possono aiutare il processo di sviluppo: in ogni caso, è preferibile un framework open source per evidenti ragioni di “libertà”. Questo non significa che non esistano ottimi framework proprietari: al contrario, ce ne sono di eccellenti ed estremamente potenti, ma essi finiscono per creare dipendenza da un venditore e limitazione tecnica. Ciò nonostante i framework in house rappresentano comunque un prodotto diffuso e usatissimo poiche’ danno risultati più immediati, almeno apparentemente.

Conclusioni

Mi ero ripromesso che quest’anno avrei scritto poco, ma, alla fine, è venuto fuori il solito, kilometrico resoconto. Del resto, di argomenti e suggestioni ce ne erano molte, e limitarsi a brevi cenni sarebbe stato un cattivo servizio agli sforzi dell’organizzazione e alla competenza dei relatori. Spero inoltre che i lettori tollerino la “trovata” dei filtri Instagram: è solo un modo per scherzare e per movimentare un po’ delle immagini che altrimenti apparirebbero davvero tutte troppo uguali (già così lo sono).

Tornando seri, questa è stata una edizione “di svolta”: gli organizzatori hanno deciso di privilegiare temi dell’organizzazione aziendale, della conduzione di progetto, della gestione del cambiamento e, in misura minore, dello UX design, rispetto a quelli strettamente tecnologici e architetturali. Del resto, di ottime conferenze tecniche è pieno il panorama degli eventi in Italia e connotare Better Software come punto di riferimento per l’azienda in evoluzione verso il management Lean/Agile è una scelta legittima.

Accanto a sviluppatori e tecnici, erano presenti quest’anno direttori tecnici di piccole e medie aziende, creatori di startup e CEO di imprese più “anziane” e strutturate. A questo punto, speriamo che alla prossima edizione inizino a essere presenti i quadri e i manager delle grandi aziende/strutture che non conoscono o non vogliono adottare un approccio di questo tipo; più facile, in ogni caso, che qualcuno dei presenti, magari tra qualche anno, possa finire per sostituire, in un ricambio culturale, prima che generazionale, il management taylorista che ancora, in massima parte, rappresenta lo zoccolo duro delle aziende in Italia e non solo.