Anche quest’anno arriva il consueto resoconto sulla conferenza Better Software, uno dei punti di riferimento in Italia per il mondo Lean/Agile e per le tematiche relative all’organizzazione dei gruppi di lavoro e alla gestione dei processi. Svoltasi a Firenze alla metà di ottobre, quest’anno il programma ha presentato alcune interessanti sorprese accanto ad attese riconferme. E già si guarda all’autunno 2015, quando Better Software cambierà in parte formula, con una veste più lineare e una forte internazionalizzazione.

L’edizione 2014

Sesta edizione di Better Software, seconda del “nuovo corso” in cui si è dato sempre maggiore spazio ai temi inerenti la gestione dei processi e l’organizzazione dei gruppi di lavoro, le metodologie Lean e Agile, ma anche ad argomenti quali la UX e la progettazione di interfacce, limitando, ma senza eliminarli, gli aspetti strettamente tecnologici.

Se si fa eccezione per quella del 2009, chi scrive ha partecipato a tutte le edizioni e ha tentato di raccontarle su queste pagine. Negli anni, Better Software è stata una vetrina importante per osservare le tendenze e i (som)movimenti che stanno interessando il mondo del “software” in senso lato. Better Software ha seguito, e in molti casi anticipato, certi temi legati a una nuova idea di organizzazione aziendale, a un nuovo sistema di produzione, ai nuovi strumenti di controllo del flusso di lavoro e ai principi che da questa visione scaturiscono.

Negli ultimi anni, infatti, idee e sistemi di produzione che, anche solo poco tempo fa apparivano come pratiche “esoteriche” riservate a pochi iniziati, hanno cominciato ad affermarsi in maniera consistente: se la filosofia Lean e le metodologie Agile non sono ancora totalmente mainstream lo si deve più alla adozione ancora limitata da parte di molte realtà produttive, che non a limiti intrinseci del Lean/Agile, visto che la validità di tale approccio viene confermata ogni giorno in molte realtà diverse, non solo del panorama IT.

La struttura 2014 e le novità previste

Come per gli altri, anni, anche in questa sesta edizione le due giornate sono state declinate ciascuna su tre “track” parallele per ogni giorno [1]: da una parte i workshop, di durata consistente, in genere uno al mattino e uno al pomeriggio, che hanno affrontato in forma esperenziale temi quali la gestione del tempo, la cosiddetta “hosting leadership”, la gamification applicata ai progetti, e l’auto-organizzazione in rapporto con la la leadership, oltre a un panel sull’open source; dall’altra le classiche “presentazioni” tenute o in sessione plenaria o su binari separati i cui temi erano “Mangement” e “Agile & UX” al lunedì e “Lean & IT” e “Tech & Legal” al martedì. Ribadisco che, come per gli altri anni, si tratta di titoli molto generici, adatti a tener dentro interventi di argomento e di stile anche molto differenziato…

Come per lo scorso anno, anche a Better Software 2014 c’è stata una importante presenza internazionale, incarnata da Dan North, che ha riscosso giustamente unanimi consensi in virtù della sua competenza e della ottima capacità comunicativa.

Ma questo tipo di formula è destinato a cambiare nella prossima edizione: gli organizzatori hanno comunicato che l’intenzione è quella di riorganizzare la formula sia per quello che attiene ai talk che per quanto riguarda i workshop, e di introdurre come “lingua ufficiale” della conferenza l’inglese. Già in questa edizione alcuni interventi (i keynotes anzitutto) erano in inglese, e questa decisione dà una spinta verso l’internazionalizzazione di un evento che ha mostrato negli anni capacità di rinnovamento e che è giunto probabilmente quest’anno a un punto di svolta, in cui era sensato cercare di introdurre delle novità per dare a Better Software una ulteriore spinta propulsiva.

Che cosa abbiamo visto

È sempre difficile stare dietro a tutti gli interventi, e in particolare quest’anno ne ho privilegiati alcuni sulla carta meno “gettonati” (in certi casi, poi, non è stato affatto così), rinunciando magari a quelle presentazioni che in genere richiamano giustamente il grosso dei partecipanti (tanto per non fare nomi… non ho seguito quest’anno le presentazioni di Andrea Provaglio e Alberto Brandolini che sono ormai divenute dei “classici” di Better Software). Non sono comunque rimasto deluso, ma anzi ho avuto occasione di assistere, in alcuni casi, a interventi di assouto spessore.

Qualche ulteriore considerazione generale è riportata in fondo all’articolo e rimando a quei paragrafi coloro che non sono interessati alla descrizione delle diverse presentazioni. Di seguito, invece, riporto le presentazioni suddivise secondo una mia personalissima classificazione che non segue l’argomento, quanto piuttosto l’approccio del relatore.

Ho infatti notato che i diversi interventi potevano essere suddivisi grosso modo in tre categorie:

• le “lezioni“: talk che si sono incentrati sullo spiegare un argomento in maniera lineare e circostanziata; in alcuni casi si è trattato di interventi di alto livello, in cui sono stati introdotti concetti poco noti a molti dei partecipanti;
• le “esperienze“: talk che hanno raccontato esperienze vissute, spesso non strettamente legate al mondo software, e hanno portato agli ascoltatori una serie di dati e di considerazioni derivate da quanto sperimentato dai relatori;
• le “riflessioni“: talk che, a un livello di astrazione relativamente elevato, hanno condotto delle riflessioni, a volte quasi delle vere e proprie “meditazioni” su argomenti in genere legati all’organizzazione dei processi, all’adozione delle metodologie agili in contesti particolari, alla gestione dei gruppi e così via.

Si tratta di una classificazione un po’ arbitraria, ma del resto anche le track individuate dagli organizzatori un po’ lo erano… quel che conta è che sia stato possibile assistere a scambi di informazioni e di esperienze, capaci di suscitare qualche spunto di riflessione nei partecipanti.

E quindi, passiamo a riassumere un po’ di interventi, ricordando che, nei prossimi mesi, sul sito di Better Software [1] saranno resi disponibili i video degli interventi.

Le “lezioni”

Come appena detto, riportiamo qui quegli interventi in cui sono stati “spiegati” dettagliatamente determinati argomenti. Le tematiche sono state varie, dall’UX e la progettazione di interfacce al modo di condurre interviste con gli utenti/stakeholder, dal modo in cui scalare in maniera agile il portfolio di progetti di una azienda enterprise, ai fondamenti dell’architettura basata sugli eventi.

Davide Casali, “Gestalt design principles for developers”

Collocata come keynote del lunedì mattina, quella di Davide Casali [2] è stata però una vera e propria lezione di design che ha affrontato il mai facile rapporto tra sviluppatore/tecnico e progettista/designer o, per dirla in modo ancora più terra terra, la classica dicotomia fra grafica e codice.

Il discorso ha presentato il modo in cui sia possibile applicare i principi della Gestalt al design della UX e delle interfacce. la psicologia della Gestalt è una corrente psicologica che si concentra sui temi della percezione e del modo in cui sperimentiamo la realtà, affermando che gli oggetti, le situazioni, i contesti vengono percepiti in quanto interi e non come semplice sommatoria delle singole parti.

la Gestalt si concentra molto sull’aspetto visivo e, a tal proposito, identifica 4 principi fondamentali.

1. emergenza: le forme emergono dalla relazione con altre forme;
2. reificazione: si percepisce più di quello che si vede;
3. invarianza: si percepisce un oggetto semplice come tale, indipendentemente da scala, rotazione, eccetera
4. multistabilità: meno adatto al digitale

Tralasciato quest’ultimo, e presi i primi tre principi, è possibile individuare delle leggi della Gestalt che si mettono in relazione a emergenza, reificazione e invarianza:

1. legge della continuità: percepiamo la continuità di un oggetto, ad esempio un chiodo che trapassa un’asse di legno, anche se in effetti non vediamo il pezzo di ferro inserito nel legno (emergenza);
2. legge del destino comune: ciò che si muove insieme viene percepito come un unico elemento (emergenza);
3. legge della “chiusura“: tendiamo a concludere le forme o a percepire l’intero, anche se effettivamente c’è solo una parte visibile (reificazione);
4. legge di prossimità: raggruppare insieme gli elementi congruenti (reificazione);
5. legge di somiglianza, di similarità: le forme già suggeriscono delle idee in quanto simili ad esse (invarianza);
6. legge del punto focale: usare i punti focali con parsimonia, anche per sottolineare i cambiamenti (invarianza)

Vengono poi mostrati degli esempi tratti da pagine di siti e social media, in cui si mette in luce il rapporto tra interfacce, principi generali della Gestalt, e le sei specifiche leggi appena descritte.

Non manca un accenno a uno degli strumenti classici della progettazione grafica ed editoriale, le griglie: l’importanza delle “gabbie di impaginazione”, sta nel fatto che esse consentono di applicare contemporaneamente le diverse “leggi”. Per esempio, similarità, punto focale, chiusura vengono “riassunte” tutte insieme in una griglia grafica ben progettata.

In quest’ottica, l’idea del “pixel perfect” va subordinata ai principi della Gestalt: ciò che conta sono gli allineamenti, le forme, i gruppi coerenti e così via.

Francesco Improta, “Atomic design: un problema di aspettative”

Di argomenti analoghi legati alla progettazione di interfacce ha parlato al martedì anche Francesco Improta, partendo da una disamina del vecchio modo di realizzarle. Si partiva da un approccio di tipo “Photoshop” in cui si facevano pagine pixel perfect e si lavorava su layout standard, secondo il processo di lavoro classico del “grafico”. Ma con questo sistema, come è possibile ricevere feedback? Il meccanismo tipicamente utilizzato è quello della presentazione: strumenti statici, senza interazione.

Il contesto odierno costringe a una frammentazione dei dispositivi e quindi non si può più lavorare in pixel perfect, ma occorre un nuovo modo di condurre l’esecuzione dei progetti che non preveda il mockup statico: è l’era “post PSD”.

Occorre rivedere il processo di design, e quindi organizzarlo intorno alle giuste aspettative: il cliente deve sapere che cosa gli vorrà mostrato, il team deve sapere su che cosa lavorerà, e il designer stesso ha le sue legittime aspettative.

Si passa pertanto dalla presentazione alla collaborazione & cooperazione. Si passa dal progettare pagine al progettare sistemi; non a caso si parla di Design Systems: tipografia, colore, griglie, forme. Un sistema responsive è basato su moduli. Andando sul concreto gli strumenti a disposizione del web designer sono sostanzialmente tre:

• style tiles: prodotti consistenti in font, colori ed elementi di interfaccia che riescono a comunicare l’essenza di un brand visivo; ottimo per chi ha già una marcata identità grafica, ma comunque più adatto al graphic design che al web design;
• style guides: derivano dai tradizionali fogli di stile editoriali,  sono semplici e lineari, ma hanno anche degli svantaggi, primo fra tutti il fatto essere in genere costruiti a posteriori, e di essere sostanzialmente un tool interno al team di grafici, meno adatto al rapporto con il cliente;
• progettare nel browser: ottimo strumento per prototipare, presenta però una limitata possibilità di personalizzazione e fornisce spesso risultati che hanno un senso di “già visto”, poichè i framework utilizzati sono molto diffusi.

È in questo contesto che si inserisce il concetto di Atomic Design e di Element Collage. In pratica, come accade nel mondo naturale, le strutture più complesse sono in realtà composte da parti più piccole: così come un oggetto è composto da molecole, le quali sono a loro volta composte da atomi, c’è la possibilità applicare questa scomposizione con progressivo aumento della strutturazione al mondo del design: è appunto il  “design atomico”.

E gli elementi su cui si basa l’Atomic Design sono, dal più semplice al più complesso:

• atomi
• molecole
• organismi
• template
• pagine

Sebbene questa sia la loro organizzazione nel senso di una strutturazione sempre maggiore, non è detto che si debba progettare a partire dall’elemento atomo: è possibile affrontare il design cominciando da uno qualunque questi elementi, senza però perdere di vista ciò su cui si sta lavorando, gli elementi di gerarchia inferiore da cui è composto, e quelli di complessità superiore che va a costituire. Ma vediamo nel dettaglio in cosa consistono questi elementi.

Gli atomi sono i blocchi, i colori, i caratteri, le immagini, i pulsanti e così via.

Le molecole sono gruppi di atomi, anche diversi: in concreto un form, un menu di navigazione, un footer possono essere tutti considerati come molecole poichè raccolgono in sè diversi elementi atomici.

Gli organismi sono quei raggruppamenti di molecole che diventano pronti per una esplorazione visuale: riquadri che riportano informazioni, lo header di un sito in cui vengono raccolti elementi grafici, logo e menu di navigazione.

I template forniscono il contesto e si realizzano in HTML: non sono quindi delle mere gabbie grafiche ma un vero e proprio prototipo, con possibilità di navigazione.

Le pagine, infine, sono l’elemento completo, alla più alta fedeltà.

Per spiegare questi concetti, il relatore mostra quindi una serie di esempi reali in cui si è partiti dal template per poi fare gli elementi sottostanti.

Ma, oltre a fornire una ordinata strutturazione teorica, cosa può fare in concreto il “design atomico”? La prima risposta è che esso consente di realizzare prototipi buoni per l’interazione con il cliente che può subito dare un feedback, anche più ordinato e utile rispetto al tradizionale mockup.

Un altro aspetto da non sottovalutare è che in questo modo si può creare un proprio inventario visuale di progetto (Element Collage) che contiene tutti gli elementi che possono eventualmente servire e dai quali si pescheranno quelli che effettivamente verranno utilizzati.

Infine, da un punto di vista strettamente tecnico è possibile organizzare gli elementi dell’atomic design “mappandoli” dentro i CSS, con un’aumentata coerenza visuale e di navigazione nel prodotto finale.

Raffaele Boiano, “L’inter(s)vista: se l’intervista diventa una war story”

Su tematiche maggiormente legate al coinvolgimento dell’utente e del cliente nella progettazione e nel feedback ha parlato Raffaele Boiano [4], citando tanto per cominciare lo psicologo Jurgen Kritz. L’intervista è un insieme di tecniche: “l’intervista è una conversazione con un indirizzo”. L’intervista è uno strumento molto utile in diversi ambiti della progettazione e della verifica dei progetti: definizione e valutazione della UX, raccolta dei requisiti e così via. L’intervista ha diverse regole, molte delle quali non scritte.

L’intervista può svolgersi secondo diversi gradi di strutturazione (domande già tutte decise, oppure domande “improvvisate” in base a come si svolge il dialogo), standardizzazione, direttività (si “conduce” l’intervistato in un quadro di alcune possibili opzioni).

Tutti pensano di essere in grado di realizzare una buona intervista, ma in realtà molti sono gli errori che si possono commettere: in questo senso può essere molto utile un elenco degli errori tipici dell’intervistatore che è bene non commettere.

• Tralasciare il peso delle reciproche aspettative: non è detto che l’intervistatore e l’intervistato abbiano aspettative sovrapponibili, nè che quell’intervista rivesta la stessa importanza per l’uno e per l’altro.
• Eccedere con il preambolo: qualche informazione generale sull’intervista è necessaria, però occorre andare subito al sodo, spiegando velocemente le cose.
• Forzare una risposta per avere un dato: questo porta al conflitto tra intervistatore e intervistato. Se un determinato dato non emerge dall’intervista, questo fatto è esso stesso un’informazione preziosa.
• Tenere un atteggiamento valutativo: non bisogna approvare o disapprovare quello che ci dice l’intervistato, nè in maniera implicita con cenni del corpo o tono della voce, nè tantomeno con esplicite frasi di approvazione o disapprovazione.
• Fornire dei suggerimenti alle risposte: anche qui bisogna evitare di “imbeccare”, implicitamente o esplicitamente, l’intervistato in modo che dia le risposte che l’intervistatore si attende.
• Rinunciare a migliorare lo strumento di ricerca: è vero che esistono tracce e “griglie” per condurre le interviste che sono state realizzate da professionisti. Ma non è detto che questi schemi preimpostati siano sempre adatti a ogni situazione. È pertanto importante sottoporre a feedback e revisione anche questi schemi, soprattutto quando si evince che mal si adattano al contesto che stiamo affrontando.
• Tralasciare l’ascolto: ascoltare con la massima attenzione l’intervistato è fondamentale poichè ci consente di effettuare i dovuti aggiustamenti del tiro durante l’intervista stessa (è ciò che in inglese viene spesso indicato con il termine “probing”).

Accanto agli errori tipici, ci sono anche cose che invece si possono fare. Vengono presentate di seguito utilizzando i termini inglesi che si possono ritrovare nei testi specializzati:

• Probing. Si tratta, come già visto, del “rilancio” effettuato sulla base di ciò che sta emergendo dall’intervista. È un comportamento di adattamento volto ad adeguare il tiro durante l’intervista stessa.
• General. Con questo termine si indica il tentativo di sollecitare l’interlocutore a spiegare, in maniera generale, il suo percorso.
• Comprehension. Qui si tratta di far chiarire bene all’intervistato il senso dei termini che usa. Non è detto che una determinata parola abbia sempre il medesimo significato in ogni contesto ed è quindi molto importante, per evitare fraintendimenti, che l’intervistato chiarisca bene il senso di alcuni termini non univoci.
• Paraphrasing. È la “riformulazione” ossia il classico “spiegalo con altre parole”.
• Confident. Si tratta di verificare quanto l’intervistato sia sicuro di una determinata affermazione. Un conto è fare una affermazione riferita all’esperienza diretta o a una certezza profonda, un altro conto è riportare qualcosa solo per sentito dire, senza davvero essere convinti dell’affermazione. Questo grado di sicurezza va verificato.
• Specific. Può essere importante indagare se per l’intervistato esistano ulteriori argomentazioni a supporto di quello che viene detto nell’intervista.
• Recall. Qui si tratta di indagare i percorsi di memoria e i ricordi.

L’intervista è una “relazione” e funziona solo se ci si mette in gioco e non se l’intervistatore fa il “dominante”.

Tommaso Grotto, “Caccia al tesoro: tecniche di tutela del patrimonio digitale”

Molto lineare il talk di Tommaso Grotto [5] che ha affrontato temi quali l’antipirateria, la protezione dei marchi, il diritto d’autore, e i brevetti. Consigliamo vivamente di recuperare il video dell’intervento una volta che sarà disponibile, poichè riassume in maniera chiara, nel giro di venti minuti, molte tematiche su cui spesso le informazioni che si posseggono sono lacunose o imprecise.

Potrete in tal caso scoprire, ad esempio, che registrare in Italia un marchio (cioè un segno grafico che identifica un “prodotto” in modo univoco e che non è mai stato usato prima) costa circa 1000 €, oppure che depositare il proprio software presso la SIAE per usufruire del diritto d’autore ad esso connesso costa 250 €, anche se esistono oggi delle alternative come Patamu.com.

E che dire dei brevetti: registrarne uno in ambito nazionale costa 5000-10.000 €; in ambito internazionale si va anche oltre i 25.000 €. Ma il fatto paradossale è che, udite udite, in Italia non si può brevettare il software, ma solo registrarne il diritto d’autore.

Com’è possibile attivarsi per combattere la “pirateria”? Va tenuto presente che il trend della pirateria è in rialzo. Gli strumenti legali possibili sono diversi effettuare delle notifiche di rimozione, magari incrociando i dati derivanti da account vari (nome, Paypal etc.). C’è poi lo strumento dell’antidiffamazione con il quale è possibile attivarsi anche ex ante. Sul famoso “diritto all’oblio”, il talk si sofferma brevemente, ma significativamente, mettendo in luce le difficoltà e anche certe contraddizioni legate a questo tema.

Se quindi è vero che la pirateria è forte e che il frutto del proprio ingegno del proprio lavoro è sempre sotto minaccia da parte di coloro che se ne vogliono appropriare indebitamente, è anche vero che un utilizzo mirato di alcuni strumenti in qualche modo usati dai “pirati” può portare a risultati positivi e sorprendenti. Sebbene non ci siano dichiarazioni ufficiali al proposito, pare infatti che il gruppo musicale degli Iron Maiden abbia deciso di fare il suo tour dedicando particolare attenzione alle date in Sudamerica, dopo che si era notato come sui canali Peer-2-Peer i loro dischi fossero scaricati illegalmente soprattutto in quell’area geografica: quando si dice fare di necessità virtù.

Felice Pescatore, “Agile@Scale: portfolio level”

Un intervento di alto livello, e anche piuttosto difficile per i non specialisti, è stato quello di Felice Pescatore [6] che ha presentato strategie e strumenti per consentire a una azienda di dimensione Enterprise di scalare i progetti nel proprio portfolio in un’ottica agile.

Lasciando a chi è interessato (ed esperto) di approndire l’argomento con il video, riportermo qui solo alcuni veloci cenni che sono emersi dal talk: anzitutto la necessità di affrontare un progetto in maniera olistica e l’importanza di figure che siano in grado di parlare diversi “linguaggi” a seconda di coloro con cui ci si relaziona.

Per la gestione più oculata del portfolio, esiste il cosiddetto “Adaptive Portfolio Credo” che è una sorta di “manifesto”. Altra considerazione importante nella strategia di pianificazione del portfolio è che il solo fatto di vedere che per un progetto ci vuole tanto tempo a capire se vale o non vale la pena di farlo indica che…  è meglio non farlo.

Anche i fallimenti possono servire: progetti falliti nella realizzazione del prodotto possono comunque essere stati utili per imparare nuove tecnologie, oppure per adottare nuovi paradigmi organizzativi. Vengono infine presentati i framework SAFE e DAD. SAFE è più aziendale e orientato all’organizzazione, DAD è maggiormente orientato al prodotto.

Domenico Musto, “Event Driven Architecture in practice”

Un’altra “lezione” molto tecnica, dedicata alle architetture guidate dagli eventi, è stata quella di Domenico Musto [7] che si inserisce un po’ nella tradizione degli interventi a forte connotazione tecnica che in passato erano tipici di Better Software. E anche il relatore, fin dal suo esordio, ribadisce questa impronta, affermando che vuol parlare di software e di codice in senso quasi “artigianale”, criticando la tendenza a trascurare il codice.

Tra i punti toccanti, c’è stato quello che non bisogna confondere architettura e design, una disamina sulle architetture SOA e sulle loro evoluzioni (“Microservices è un po’ solo una nuova incarnazione di SOA”), l’uso di Huddle.

Ci sono differenze fra sistema con architettura ad eventi e sistema senza, ma non bisogna erroneamente ritenere che Event Driven Architecture sia solo una questione di “code”. E viene infatti fornita la definizione di ciò che è evento, di ciò che è comando e di document message. Gli interessati alle architetture potranno recuperare il video quando sarà disponibile sul sito.

Le “esperienze”

In questo “capitolo” ho riportato una serie di interventi che si sono caratterizzati per essere sostanzialmente il racconto di una esperienza fatta: un progetto, un prodotto, una situazione in cui si sono sperimentate certi approcci Lean/Agile. È chiaro che anche le “lezioni” o le “riflessioni” si basano su esperienze e non sono campate in aria, ma in questo caso ciò che contava davvero era portare l’esperienza agli ascoltatori e lasciare a loro di trarre le conclusioni. In questa categoria ho raccolto anche alcuni interventi davvero particolari per la loro trasversalità e per la capacità dei relatori di “allargare” gli orizzonti.

Ilaria Mauric – Manuel Spezzani “Agile e Design: progettare e realizzare prodotti in Italia è possibile”

Si è trattato di una presentazione in cui Ilaria Mauric [8] e Manuel Spezzani [9] hanno raccontato un caso di esempio per spiegare come due team abbiano lavorato insieme a un determinato prodotto. E la cosa “buffa” è che le due aziende coinvolte, che si sono lanciate nella ideazione e nella realizzazione di questo prodotto, sono però abituate a fare consulenze piuttosto che a ideare e realizzare prodotti. Questo pone delle sfide: un “prodotto”, infatti, non è solo sviluppo ma comporta tanti altri aspetti da gestire: il ciclo di vita dei prodotti, il loro supporto, la loro commercializzazione.

Nel corso della presentazione, si è passata in rassegna l’esperienza del progetto, mettendo in luce le caratteristiche del prodotto, l’organizzazione che si adottata per realizzarlo, le metodologie e gli strumenti che hanno contribuito a portare a termine l’impresa.

Ma in sostanza, di cosa si trattava? Si trattava di realizzare uno strumento che fungesse da “indagatore” della struttura di un data warehouse. Il prodotto ha due facce: una è prettamente tecnica, l’altra è uno strumento di esplorazione e visualizzazione del data warehouse rivolta a un pubblico di “non tecnici”.

L’organizzazione adottata è consistita nel creare una sorta di “startup” all’interno dell’azienda, che rispondeva ai capi come se questi fossero dei venture capitalists, più che dei dirigenti strutturati.

Le metodologie impiegate sono state di tipo agile, in particolare Scrum.

Gli strumenti adottati sono stati, oltre a quelli per la progettazione, diversi tool di sviluppo per pubblicazione automatica: automatizzazione e continui test con utenti, infatti,  sono state delle costanti per tutta la durata dell’impresa.

Per quanto riguarda la progettazione del frontend, sulla base dei principi di design stabiliti in maniera collaborativa, si è poi passati alla vera e propria esecuzione, effettuata seguendo i dettami di Scrum: un aspetto importante è che gli sprint erano sufficientemente “lunghi” e hanno consentito di fare tutti i test utente necessari. Questo è un aspetto su cui i relatori insistono: l’importanza dei test e delle interviste con gli utenti (10-12 persone). Da un punto di vista pratico, gli strumenti usati sono stati product canvas e journey maps.

La conclusione è che solo le aziende in cui tutti lavorano per l’utente, superando certe tradizionali strutture organizzative, creano prodotti validi in tempi relativamente brevi.

Sebina Pulvirenti, “Adapting Scrum to the editorial world”

Altra esperienza particolare è quella raccontata da Sebina Pulvirenti [10], che riguarda l’adozione e l’adattamento di una metodologia come Scrum al mondo editoriale, e le reazioni del suo gruppo di lavoro a questo mutamento di prospettiva.

L’intervento, infatti, parte parlando di come ci si pone di fronte al cambiamento. Le reazioni possono essere di diverso tipo:

• qualcuno si motiva per il cambiamento: “finalmente si fa qualcosa di nuovo!”;
• qualcuno resta perplesso e in attesa: “va bene, stiamo un po’ a vedere che cosa succede”;
• qualcuno ha un atteggiamento conservatore e si irrigidisce: “No! Non voglio cambiare”.

Di fatto ogni cambiamento porta con sè una nuova strategia, dei nuovi obiettivi, una nuova struttura. E ciò che è ancora più importante porta a un cambiamento di atteggiamento.

Portare Scrum nell’ambito della produzione e redazione dei contenuti non è una novità: ci sono esempi famosi di applicazione di Scrum al mondo editoriale, specie nel campo dei quotidiani e dell’editoria periodica statunitense. Si tratta comunque di pochi casi e l’esperienza raccontata dalla relatrice è molto interessante proprio perchè ha presentato anche i limiti e i problemi che questo tipo di approccio comporta, oltre a mostrare gli innegabili vantaggi. Da un punto di vista pratico, il primo cambiamento è stata la necessità di creare un team di prodotto con un mutamento organizzativo forte in un ambito già molto strutturato e “tradizionale” come quello editoriale.

Ma come è stato possibile adattare la metodologia Scrum al lavoro di tipo editoriale? Il team editoriale è andato a pescare Scrum dal team tecnico, su suggerimento di uno dei capi. Successivamente è stato svolto un workshop di due giorni per spiegare e insegnare la tecnica. Durante tutto il periodo di apprendimento, è stata grande l’importanza del coach agile per insegnare certe tecniche e per consentire degli adattamenti che non tradiscano lo spirito della metodologia.

Ma in che modo è stato possibile introdurre gli elementi di Scrum (artefatti, “cerimonie”, ruoli etc.) nel flusso di lavoro editoriale? Vediamo di seguito cosa è stato fatto.

Per quanto riguarda gli artefatti, il Product Backlog è stato mappato sul “tradizionale” calendario editoriale, in modo che fosse chiara la relazione tra due cose che hanno nomi molto diversi ma presentano alcuni aspetti comuni. Lo stesso è stato fatto con lo Sprint Backlog che è stato messo in relazione con la “lavagna editoriale” (tenendo oltretutto presente che c’era il vincolo di dover usare JIRA…).

Qualche problema in più è stato rappresentato dalle cerimonie Scrum poichè, per sua caratteristica, il lavoro editoriale è diverso dal flusso di lavoro che si ha nello sviluppo del software. In ogni caso, lo Sprint Planning Meeting si è concretizzato in una “riunione editoriale” ogni lunedì per la durata 2 ore, anche se è stato necessario aggiungere a questo anche una riunione mensile e una trimestrale, per una programmazione editoriale a più lungo termine che è necessaria in un campo come quello delle pubblicazioni. Nessun problema per il Daily Standup Meeting, cui però è stata aggiunta un’ulteriore riunione di 30 minuti a settimana, inventata per la situazione e denominata “Scrum Breakfast”, inizialmente difficile da far passare, ma poi molto fruttuosa e compresa da tutti.

Ovviamente non sono mancate le retrospettive, di vario tipo e di varia calendarizzazione: accanto alla retrospettiva “tipica” (anche se spostata al giovedì pomeriggio) per 45-60 minuti si è aggiunta una retrospettiva mensile sulla qualità editoriale e sui contenuti più legata alla tipo di prodotto a cui si sta lavorando che, appunto, è diverso dal software. Gli schemi adottati per i vari tipi di retrospettiva hanno spaziato dal semplice “Mad – Sad – Glad” al cosiddetto “Triple B – Bouquet, Brickbats and Bulbs”, fino a tematiche di stampo maggiormente editoriale per quanto riguarda la retrospettiva mensile.

Sui ruoli, fermi restando i principi di auto-organizzazione, trasparenza, flessibilità, ci sono stati alcuni problemi nell’identificare esattamente il Product Owner, con il rischio che venisse confuso con la persona che fa lo Scrum Master, mentre per quest’ultimo non ci sono stati problemi.

Si è trattato di un “esperimento” i cui risultati, dopo un iniziale periodo di “smarrimento” sono stati evidenti poichè rendere palesi ruoli e flussi di lavoro ha consentito un miglioramento e un maggior coinvolgimento dei professionisti.

L’intervento si è concluso mettendo in evidenza anche alcune problematiche riscontrate; va infatti tenuto presente un problema tipico del mondo editoriale: l’interruzione del flusso di processo determinata dalle “breaking news”, ossia delle notizie improvvise e non presenti già nel product backlog ma che non possono essere trascurate per la loro importanza e che devono essere trattate interrompendo lo “sviluppo” delle “user stories” previste per quello sprint.

Marco Calzolari, “Lean startup high school”

Un’altra presentazione che non si è occupata strettamente di sviluppo software ma ha focalizzato la sua attenzione su un processo formativo in un istituto scolastico è stato quello di Marco Calzolari [11] che aveva peraltro condotto alla mattina del lunedì il workshop sulla gestione del tempo insieme a Giovanni Puliti.

L’intervento ha raccontato un’esperienza svolta all’interno di una  quarta classe di scuola superiore, nell’ambito di un progetto denominato Parnasus. Si trattava in pratica di un “esperimento” consistente nel portare all’interno dell’istituzione scolastica delle competenze di tipo “agile“, coinvolgendo i ragazzi in attività che consentissero loro di esperire in prima persona certe dinamiche e di impadronirsi di determinate conoscenze e capacità.

L’attività è consistita nel creare con i ragazzi una ipotetica startup, passando poi alla individuazione di un prodotto da realizzare e simulando tutte le fasi necessarie, con l’uso di strumenti tipici della gestione di progetto in ambito agile. Nel loro processo di Lean Startup, i ragazzi si sono dovuti confrontare con concetti e strumenti quali Business Model, prototipo, pitch, Scrum, Lean UX e retrospettive. Da notare che, in un progetto come questo, la tecnologia è importante ma non è fondamentale tanto che i computer non sono stati usati e si è lavorato soprattutto con quella “cancelleria agile”, costituita da matite, pennarelli, lavagne, Post-it e così via.

Quali sono stati i risultati, vale a dire che cosa hanno imparato questi studenti? Va anzitutto detto che le metodologie di sviluppo agile hanno svolto un ruolo di “empowerment” personale, ancor più importante per ragazzi così giovani in una fase cruciale della loro formazione scolastica e personale. Certi concetti, come quello della retrospettiva, sono stati compresi anche per il loro valore al di fuori dell’attività della startup. Oltre a questo va detto che certe conoscenze (che cosa è un modello di business, che cosa è un prototipo etc.) hanno arricchito anche da un punto di vista strettamente tecnico la formazione di questi studenti.

Studenti e insegnanti si sono dimostrati molto soddisfatti dell’esperienza fatta. Che cosa serve allora per ripetere un percorso di questo tipo all’interno di un contesto simile? Servono uno sponsor, in grado di coprire le spese per i coach agili e per i materiali; servono degli “agenti del cambiamento“, vale a dire delle persone presenti all’interno della struttura (professori, preside etc.) che desiderino aprire a nuove idee e nuovi concetti la formazione dei ragazzi; ma serve soprattutto una comunità di persone, in questo caso studenti di liceo, con la quale lavorare in maniera collaborativa.

È stato questo un intervento molto lineare, che ha raccontato un’esperienza anche un po’ distante dai soliti casi di studio derivanti dal mondo aziendale, ma che ha avuto il merito di far comprendere come certe metodologie di gestione del processo possono essere molto importanti per la formazione delle persone, anche al di fuori dell’ambito strettamente IT. In questo, Marco ha saputo trasmettere entusiasmo e, usando una parola che in genere non sarebbe di pertinenza del mondo dello sviluppo del software, speranza.

Matteo Guidotto, “Buyer vs user personas”

Nel talk di Matteo Guidotto si focalizza l’attenzione sui concetti di “personas” sia in senso di user che nel senso di buyer attraverso il racconto dello sviluppo di alcune personas usate veramente in alcuni progetti.

Tra i concetti esposti, c’è quello che occorre pensare a un design che riesca a tenere presenti i desideri delle altre persone. Viene inoltre messa in luce la differenza che spesso nasce nelle personas tra utente e compratore: in molti casi il lavoro di progettazione della UX deve puntare a soddisfare le esigenze delle “buyer personas”. Si passa pertanto da una “esperienza utente” a una “buyer experience”, un po’ in maniera analoga a quello che accade con certi locali i quali ricercano un determinato pubblico selezionato.

Si ribalta il paradigma: sono io che stabilisco chi è il mio utente–compratore e questo implica la realizzazione del contenuto giusto per il mio pubblico.

La struttura della “esperienza compratore” può essere riassunta in quattro fasi:

• attrazione
• conversione
• chiusura
• “delizia”: il cliente finisce per diventare promotore

È un approccio di marketing piuttosto aggressivo, molto ben strutturato: viene riportato l’esempio di un blog realizzato a partire dalle personas, in cui il piano editoriale è pensato con post indirizzati a precise personas di tipo buyer.

Luca Sartoni, “Life and work at the distributed wonderland”

È stato l’intervento che ha chiuso la conferenza al martedì sera, ed è stato probabilmente uno dei più discussi e commentati perchè Luca Sartoni [12] ha letteralmente scatenato l’interesse da parte di molti per l’azienda di cui ha parlato: Automattic che, per chi eventualmente non lo sapesse, è ciò che sta dietro, tra l’altro, alla piattaforma WordPress…

Anche questo è uno di quei talk che è difficile riassumere e consigliamo la visione del video non appena sarà disponibile.

In breve, è stata raccontata l’esperienza lavorativa di Luca che, con un percorso abbastanza comune a molti professionisti IT, l’ha portato infine a lavorare per Automattic. Questa è una azienda che si basa su un’organizzazione del lavoro e un sistema di controllo che cozzano frontalmente con quanto affermato dalle teorie classiche di organizzazione aziendale e gestione del progetto… eppure funziona bene.

Alcuni dei concetti alla base del funzionamento di questa azienda sono riassunti in alcuni semplici punti:

• il tempo sul lavoro non equivale a produttività;
• l’autogestione migliora i risultati;
• la trasparenza garantisce condivisione di obiettivi, aiuta nel fare scelte più oculate e migliora la motivazione;
• la comunicazione accresce le competenze di tutti e dell’azienda nel complesso, ed evita intoppi e colli di bottiglia;
• il reclutamento è fondamentale per far funzionare il sistema: occore ricercare persone in grado di comprendere i principi esposti sopri e capaci di applicarli.

In una delle frasi che conclude il racconto dell’esperienza in Automattic, Luca Sartoni ha detto che i profitti passano, ma il lavoro fatto bene e i rapporti interpersonali restano. E in più d’uno, alla fine dell’intervento, ha preso informazioni su come proporre la propria candidatura per un lavoro del genere…

Le “riflessioni”

Molti interventi hanno avuto la forma di “riflessioni” su alcune tematiche che emergono dal fare impresa, dal gestire progetti a diversa scala e a vari livelli, dallo sviluppare prodotti e così via. Tra questi spicca senza dubbio il keynote del martedì mattina, tenuto da Dan North, ma non sono mancate riflessioni di tutto rispetto da parte di altri relatori. Vediamone alcune qui di seguito.

Dan North, “Why agile doesn’t scale… and what you can do about it”.

Uno dei temi più attuali e più ricorrenti nel mondo della gestione del progetto è quello incarnato dal verbo “scalare“. E di questo si è occupato, nel suo keynote della mattina di martedì, Dan North [13], personaggio di spicco capace di unire una innata simpatia e un’ottima capacità di comunicazione alla solida preparazione sia in ambito tecnico, sia per quanto riguarda le metodologie per la gestione del progetto. Nel giorno successivo alla conferenza, oltretutto, Dan North ha tenuto un seminario pratico sul tema “Accelerated Agile: from months to minutes” [14] organizzato da Avanscoperta.it nella medesima location e che, a detta di chi ha partecipato, ha confermato ulteriormente lo spessore e la capacità di questo professionista, capace di proporre soluzioni innovative, che superano gli stessi principi dell’Agile quando questi si irrigidiscano in formule ripetitive.

Nel suo keynote, Dan North parte dall’assunto che in effetti è difficile scalare “automaticamente” in Agile. Oltretutto, nella letteratura “canonica” di Agile, il tema “scala” non è discusso esplicitamente, e questo lascia ampio margine di discussione tra chi afferma che “scalare e Agile non vanno d’accordo” e chi mette a punto “metodologie agili per scalare, come Scrum of Scrums”. Tutto questo non significa che, con Agile, non si possano in certi casi affrontare e gestire progetti sul larga scala, magari con team distribuiti; significa invece che occorre un approccio molto particolare che non affronti il modo di “scalare” in Agile con lo stesso approccio con cui si è implementata “l’economia di scala” in senso tradizionale.

Il video dell’intervento di Dan North è già disponibile sul canale YouTube di Better Software [15] e consigliamo vivamente di guardarselo con calma. Di seguito, però vogliamo riportare alcuni punti salienti che ci sono parsi molto esplicativi.

Che cosa significa “scalare”? “Scalare” può riguardare tutte le situazioni in cui si debba far fronte a un maggior numero di utenti, a un maggior numero di progetti, a progetti che hanno maggiore complessità, o a progetti di dimensioni maggiori.

Perchè scalare è difficile? Sostanzialmente per due ragioni: la prima è che le ottimizzazioni locali non funzionano; la seconda è che, a tal riguardo, Agile non ha una soluzione già pronta. Basti pensare che all’inizio si lavorava su sprint da sei settimane e adesso questa misura si è notevolmente ridotta, per capire come anche Agile, pur con i suoi principi e le sue regole, si adatta ai tempi e alle condizioni.

Prima di proporre alcune possibili soluzioni volte a rendere “scalabile” Agile, è bene dare uno sguardo ai modelli di adozione di agile e ai problemi tipici che si verificano in una situazione grande dove può essere necessario scalare.

Uno dei tipici cicli che porta un’organizzazione enterprise a sperimentare dei problemi fino addirittura ad arrivare al fallimento può essere riassunto in sei passaggi successivi:

• la gente “non funziona”;
• gli strumenti non funzionano più;
• la governance viene meno;
• i clienti diminuiscono e sono insoddisfatti;
• i soldi vengono a mancare;
• l’organizzazione fallisce.

Ma perchè si verifica questo ciclo vizioso? In una grande organizzazione, spesso c’è un abisso tra sviluppatori e management, e anche certe strutture intermedie che dovrebbero legare queste due realtà distanti, come la Governance e la Delivery Assurance, finiscono per non rendersi conto di ciò che accade veramente nella Execution poichè le loro preoccupazioni sono focalizzate su aspetti che poco aiutano, quando addirittura non danneggiano, il team di sviluppo. La Delivery Assurance si preoccupa di chiedere continuamente “Quanto manca? Ci siamo?” e non si chiede invece “Che cosa è cambiato?”, preoccupata come è dai compromessi sul prodotto o dai compromessi tecnici. la Governance si preoccupa dell’organizzazione e degli investimenti, ma poi non viene a sapere ciò che effettivamente dovrebbe conoscere per fare le migliori scelte organizzative e di investimento…

Di fronte a uno scenario un po’ sconfortante come questo, l’unico modo per scalare consiste in una “coerenza contestuale” vale a dire che non tutto deve essere uguale e uniformato rigidamente, ma che è importante sviluppare una certa coerenza attraverso i seguenti aspetti:

• una chiara visione condivisa che riguardi obiettivi e tecnologia;
• pochi e concisi principi guida, che sono cosa ben diversa dalle procedure, poichè queste ultime sono binari fissi da seguire, mentre i principi guida rappresentano la possibilità di rimanere sulla direzione giusta pur prendendo flessibilmente la strada più adatta in quel momento;
• una leadership forte e coerente, vale a dire che non ci sia un continuo cambiamento di CEO, la cui durata media in un incarico è, per inciso, solitamente di appena un anno e mezzo;
• decisioni locali guidate dai principi;
• assunzione delle decisioni trasparente e spiegabile.

Questo discorso si traduce semplicemente nel seguente risultato: a parità di contesto e di vincoli si prenderanno probabilmente le medesime decisioni. Scalare non significa solo fare qualcosa di più grande o mettere in piedi un sistema di Scrum of Scrums, che il più delle volte non funziona. Scalare in agile significa avere una serie di principi guida che, al mutare delle condizioni di dimensione o di complessità, consentiranno comunque agli interessati di assumere le decisioni più adeguate e coerenti.

Hoang Huynh, “Keep doing waterfall UX and survive the menace of the agile integralists”

L’intervento di Hoang Huynh [16], di cui potete leggere una serie su MokaByte proprio in questo periodo, ha affrontato da un lato non convenzionale le tematiche della progettazione dell’esperienza utente, e si è connotato per la consueta brillantezza espositiva che a tratti sfocia in una serie di battute e riferimenti “pop” di tutto rispetto.

Il tema della riflessione è volutamente “provocatorio” e va contro certi estremismi dell’Agile: “waterfall è bello!” dice Hoang a più riprese, rimarcando questa sua affermazione, e sottolineandola con la “copertina” delle slide che imita la copertina del libro “Lean UX” ribattezzato per l’occasione “Waterfall UX”…

È chiaro che dobbiamo affrontare la materia con un approccio di user-centred design, ma il modello waterfall può avere alcuni aspetti da non buttare via. Ad esempio, il lavoro di ricerca è tipicamente un processo in cui sono naturalmente presenti diversi aspetti di tipo waterfall.

Per esempio sprint e iterazioni non necessariamente si adattano sempre e comunque a tutte le discipline. In tal senso lo Sprint 0 è un po’ un pretesto in cui si “nascondono” alcuni residui di waterfall. Ma è in questo senso che, più che come a “culture”, occorre guardare a waterfall e Agile come “strumenti”, “metodologie”. Le culture sono infatti basate su valori di qualità, sull’empowerment delle persone, e così via. Gli strumenti invece, anche se si confanno a determinati valori, possono essere adottati proprio perchè funzionano: nel caso delle metodologie agili abbiamo gli esempi del daily standup meeting  o delle retrospettive, oltre che altre pratiche.

Con un approccio come questo, che può apparire “eretico” ai più intransigenti integralisti, in realtà diventa possibile separare sprint di design e sprint di execution, o tenere una traccia di ricerca parallela a quella di sviluppo, in cui la traccia di ricerca è primariamente waterfall.

Un intervento che ha avuto la capacità di suscitare riflessioni adatte a superare certe rigidità di impostazione che si riscontrano a volte anche in ambito Agile.

Pietro Polsinelli “From gamification to game design”

Il talk ha affrontato in maniera semplice e lineare l’argomento dei “giochi”, parlando delle diversità tra strategia di gamification e vero e proprio game design. Non esiste una sola idea di gioco, visto che il “gioco applicato” e il “serious gaming” indicano un tipo di gioco “istruttivo” il cui scopo non è solo il divertimento. Chiaramente, ogni gioco ha in sè una componente ludica e una istruttiva, e occorre comprendere in che misura questi due aspetti siano presenti e come si prestino allo scopo ultimo per cui tale gioco è stato realizzato.

Esistono pertsanto sostanzialmente due possibilità di progettazione di un gioco: da un lato ideare e realizzare un gioco che ponga l’utente all’interno di un “cerchio magico” di un’esperienza; dall’altro si può progettare un gioco che “addestri” a fare qualcosa o facilti la comprensione di un determinato argomento. Questa seconda opzione è il caso tipico delle richieste di gioco fatte da enti, associazioni, e così via.

Un grosso problema del game design è anche che, siccome tutti hanno giocato a qualcosa, tutti sono convinti di sapere che cosa sia un gioco e, molti pensano di sapere come lo si progetta. Vengono a tal proposito presentati degli esempi, tra cui un gioco per l’educazione alla salute realizzato per conto di una azienda sanitaria.

Occore quindi partire dall’assunto che game design e gamification sono cose ben diverse! Il gioco in sè (game design) può essere competitivo ed esclusivo; il gioco con un fine istruttivo non può essere esclusivo: chiaramente, se poi questa cosa la si spiega bene al committente, il concetto passa, ma occorre mettere in condizione chi commissiona il gioco con fine istruttivo di fare un salto ideale tra un certo tipo di gioco e un altro, mettendo bene in chiaro quali elementi, anche molto piacevoli o accattivanti, dovranno passare in secondo piano, se non addirittura essere eliminati.

Discorso analogo vale quando si adottino strategie di gamification per affrontare temi specifici con uno scopo istruttivo, come viene illustrato con esempi di giochi sulla salute, sugli effetti negativi dei cambiamenti climatici, su problemi sociali come l’integrazione dei minori immigrati, e così via.

In questo tipo di giochi è fondamentale l’aspetto della narrazione (“storytelling”), così come tener presenti alcuni consigli pratici per la produzione:

• basso costo
• prototipo veloce
• flessibilità
• gioco inclusivo

Una bella riflessione adatta forse più a un pubblico di potenziali committenti che a uno di potenziali sviluppatori, ma comunque molto sensata e ben condotta.

Claudio Bergamini, “Enterprise culture and agile: fallimento annunciato?”

L’intervento di Claudio Bergamini [17] ha riportato una lunga serie di riflessioni sulle difficoltà di introdurre cultura agile in strutture Enterprise, in particolare facendo riferimento al contesto italiano. C’è una visione “pessimistica” su questo tema ma anche una serie di esempi per dimostrare come, almeno in parte, questa integrazione sia possibile grazie agli insegnamenti forniti dalle teorie della complessità.

Enterprise implica una notevole complessità della struttura; Agile, dal canto suo, rappresenta invece un modo più comunitario e meno strutturato per gestire i progetti. Enterprise ha procedure, ruoli, vincoli che spesso costringono alla non collaborazione, alla non trasparenza. Enterprise è un modello organizzativo che deriva da quello della fabbrica: una scala gerarchica, dei gruppi ristretti che fanno le strategie, il paradigma command and control. Nelle università e nei corsi MBA si insegna ancora questo sistema: gerarchia, controllo, tradizione del  “si è sempre fatto così”.

Il Manifesto Agile è l’esatto contrario. Per introdurre un pensiero diverso all’interno del mondo Enterprise è necessario identificare le strutture e le “aree di potere” che frenano il cambiamento dei vari principi del manifesto agile. In definitiva non è possibile avere dei cambiamenti? Non è possibile avere dei progetti “agili” in senso lato anche in ambito Enterprise? La risposta è che ciò è possibile, ma a patto di adottare certi comportamenti.

• Collaborazione: spesso c’è la guerra fra i vari dipartimenti, che porta a fallimenti, sprechi e, in definitiva, fa ottenere risultati molto inferiori a quelli che sarebbero garantiti da una serena collaborazione.
• No rigidità: abbandonare i piani prefissati rigidamente che non si adattano alla realtà; questi non funzionano, nella maggior parte dei casi, proprio a causa del fatto che sono stati prestabiliti quando si aveva una visione solo parziale dell’intero progetto.
• Economia della conoscenza: la fabbrica organizzava il lavoro in gran parte fisico, ma fare software è una cosa diversa in cui sono le conoscenze a fare economia.
• Reti di persone: una “economia della conoscenza” si basa sulle persone. Le persone hanno ruoli diversi che vanno riconosciuti e valorizzati. Grande è, ad esempio, il ruolo degli innovatori, ma sono necessari anche i cosiddetti attivatori, vale a dire coloro che sono capaci di organizzare la struttura e i processi; però, senza implementatori, ossia le persone che sanno fare e portano a termine le attività, nessun progetto può stare in piedi; ma occorrono anche motivatori ossia chi concentra maggiormente l’attenzione alle persone, alle loro esigenze, ai loro obiettivi, poichè una struttura di persone si tiene in piedi solo se, appunto, le persone condividono una visione e sono motivate nel condurre le attività per realizzarla.
• Delega delle responsabilità: un conto è dirlo, un conto è farlo… Occorre impiegare un modello sensato anche per la delega delle responsabilità.

Viene pertanto presentato un  “modello di ingaggio” sulla base del quale è possibile capire quale tipo di team è adeguato a un determinato progetto, in maniera da effettuare una delega nel modo più fondato. Questo “modello di ingaggio” si basa su quattro aspetti fondamentali ai quali viene attribuito un valore da 1 a 5: trust, risk, skill, engage.

• trust è il livello di fiducia da parte del delegante nelle persone che compongono il team e tra di esse;
• risk rappresenta il livello di rischio percepito per la riuscita del progetto;
• skill indica quanto sono adeguate nel complesso le competenze tecnologiche (e non solo) all’interno del team;
• engage valuta quanto il coinvolgimento del team condiziona il risultato.

Sulla base dei valori ottenuti e del valore minimo richiesto per la delega di quel determinato progetto, è possibile individuare un team che sia adatto a condurlo a termine. Si tratta di tematiche trattate da vari specialisti dell’organizzazione aziendale in senso agile, come Jurgen Appelo che affronta i diversi modelli di delega.

Tra i vari limiti che esistono nell’introdurre un management agile all’interno di una struttura Enterprise c’è quello del budget: l’abilità sta nell’adattarsi al futuro e non tanto nel prevederlo rigidamente. Si tratta pertanto di superare i budget fissi, il che non significa affatto sprecare o spendere sconsideratamente: si tratta invece di superare anche concettualmente l’idea di budget, secondo la “filosofia” del beyond budgeting, il che in definitiva vuol dire “oltre il command & control”.

Svariate aziende estere, anche di grande successo commerciale e di notevole importanza industriale, hanno negli ultimi anni intrapreso un percorso che ha portato al loro interno l’adozione di metodologie agili e di una filosofia innovativa di gestione dei progetti. Nel panorama italiano la rigidità delle strutture Enterprise sembra ancora più forte, ma è comunque possibile seguire qualche strategia per introdurre il cambiamento e il nuovo approccio anche all’interno di aziende molto ancorate al vecchio modello. Si tratta di creare delle “zone franche” all’interno di una struttura Enterprise, in cui comunque si possono fare queste cose: un esempio tratto dal mondo reale è quello di un progetto che realizzava il diagramma di Gantt da passare all’area esterna di controllo, ma che usava al proprio interno metodologie e strumenti di tipo Scrum.

La conclusione è che, per quanto resistano certe rigidità e per quanto certi meccanismi frenanti continuino ad essere perpetuati all’interno di molte aziende Enterprise, è comunque possibile cominciare a introdurre nuovi paradigmi di pensiero e nuovi metodi di lavoro almeno in determinate aree o in particolari progetti.

Carlo Beschi, “The power of analogies: what trains, bars, kitchens and highways can tell you about your work(flow)”

Carlo Beschi [18] ha presentato una riflessione in libertà, la quale, partendo da alcuni esempi tratti dalla vita quotidiana, e apparentemente slegati dal mondo della progettazione e produzione di software, ha invece tratto degli spunti molto concreti da applicare al proprio processo di lavoro, con particolare attenzione al tema dei flussi.

Il tema portante di questa riflessione è rappresentato dalle analogie: attraverso un paragone con qualcosa che si comprende più facilmente, si spiega qualcosa di meno conosciuto. È lo strumento della similitudine (che è un paragone esplicitato) e della metafora (che invece è implicita), usato comunemente da quasi tutti proprio per il suo potere esplicativo. Le analogie infatti ci aiutano a vedere il quadro generale e a esplorarlo, anche con un maggior coinvolgimento emotivo.

La prima metafora affrontata è quella della cucina, partendo dai programmi TV tipo “Cucine da incubo” o “Hell’s Kitchen”: da un’analisi neanche troppo attenta di queste trasmissioni emerge che gran parte dei problemi che si verificano sono causati dalla mancanza di comunicazione, dalla disfunzione nei rapporti fra collaboratori, e dalla incapacità delle persone di comprendere il proprio livello corrente.

La seconda metafora è quella del bar: Carlo Beschi racconta che, per ragioni di lavoro e di spostamenti, frequenta abbastanza usualmente tre bar e può assistere a comportamenti e dinamiche molto diverse. In un caso, non appena il numero degli avventori sia appena maggiore di tre o quattro, ci sono sempre situazioni disfunzionali: accumulo di piattini e tazze da lavare, tensione e arrabbiature fra i baristi, rimproveri reciproci, errori nell’evadere gli ordini e, cosa piuttosto evidente con il passare dei mesi, continuo turn-over di personale. C’è però un altro caso in cui le cose funzionano, anche nei momenti di massimo afflusso: perchè? In questa situazione si nota che i baristi comunicano tra loro continuamente, si aiutano vicendevolmente e, con ogni probabilità hanno un loro sistema di segnali che indica il tipo di caffè da preparare in base al modo in cui il cucchiaino viene messo sul piattino.

La terza metafora è quella dei treni: al relatore è capitato per un certo periodo di fare il pendolare e, in virtù di un accordo tra i gestori dei treni, gli era possibile viaggiare anche su un treno ad alta velocità ma senza avere la possibilità di prenotare. Alla fine, però, si ritrovava sempre a prendere il treno regionale, nonostante fosse affollato e ci mettesse più tempo, per il semplice motivo che in questo modo si stressava meno nello spiegare perchè fosse su quel treno senza prenotazione. Questo episodio vuole illustrare il fatto che occorre sempre cercare di capire le diversità anche dal punto di vista emotivo per gli utenti e che questi non vanno mai considerati come delle macchine di calcolo, ma come persone che fanno scelte anche sulla base emozioni.

La quarta metafora è quella della coda al supermercato. In alcune nazioni estere è stato messo a punto  un sistema che funziona in questo modo: le casse sono molte, ma non ci si mette in file parallele a una di queste casse; si entra invece in un’unica grande fila, che poi solo all’ultimo momento smista il cliente con il carrello verso la prima cassa libera, in maniera analoga a quello che accade per il check-in in certi aeroporti, o che succedeva negli uffici postali prima dell’introduzione dei numeratori elettronici. Ecco, si è visto che con questo sistema, il cliente è meno stressato poichè non sperimenta quella frustrazione tipica di chi si mette in fila a una cassa e resta in attesa mentre coloro che sono in fila nelle casse adiacenti scorrono rapidamente. Questo può essere un buon punto di partenza per rivalutare in che modo sono organizzati i flussi delle attività da svolgere nel nostro workflow.

Infine una metafora tratta dalle autostrade: quando si lavori su dinamiche di flusso, una corsia di emergenza va mantenuta ed è nient’altro che una “swimlane expedite” che funziona.

Quindi, attenzione al dettaglio, ma sguardo all’insieme.

Stefano Maraspin, “Mental Model Blocks. L’interfaccia utente, il database e la fermata dell’autobus”

Di impianto molto simile al precedente è stata la presentazione di Stefano Maraspin [19], sebbene le tematiche siano state diverse: esaminando da una serie di esempi concreti, la riflessione portata avanti in questo talk sposta l’attenzione sui blocchi mentali che spesso finiscono per compromettere la buona riuscita di un progetto o la qualità di un prodotto. Si arriva al punto in cui si viene frenati da vincoli strutturali inesistenti, ma che sono però radicati nella mente degli sviluppatori e del management.

Un esempio tipico è dato dal caso in cui occorra modellare un’interfaccia utente a partire dai campi preesistenti di database: qui il “blocco mentale” è rappresentato dall’idea che sia necessario riportare sull’interfaccia utente tutte le informazioni presenti in tutti i campi del database. Questo non risponde a verità, dal momento che occorre invece creare l’interfaccia a partire da un attento studio dei casi d’uso e delle interazioni, il che ci porterà con ogni probabilità a ridurre notevolmente la complessità dell’interfaccia rispetto ai campi del database. Del resto questo è ciò che prevede l’approccio User-Centred Design, che è, appunto, un design incentrato sull’utente… e non sul database.

Risolto il dilemma di cosa indichino il database e l’interfaccia utente citati nel titolo, resta ora da capire quale sia il ruolo della fermata dell’autobus. È presto detto: mentre si aspetta il bus, si utilizza il proprio dispositivo mobile per compiere alcune attività, magari ludiche, magari di lavoro. Ed è in queste situazioni che ci si rende conto di come la differenza fra ciò che c’è sul desktop e ciò che c’è sul mobile abbia una sua ragione. Il mobile non può e non deve essere un surrogato del desktop (e viceversa). Ci sono cose che si fanno meglio sul desktop, ad esempio scrivere, e cose che invece funzionano meglio sul mobile, per esempio la localizzazione geografica. Occorre pertanto passare dal principio della coerenza dei dispositivi a quello della complementarietà: in pratica, dal consistent design al complementary design. Non bisogna “rimpicciolire” la realtà, ma ripensarla per un nuovo contesto.

Queste “gabbie mentali”, spesso incarnate da metafore e cristallizate nel nostro linguaggio, finiscono per limitarci nell’attività creativa e nelle soluzioni pratiche proposte. Un esempio che in molti conoscono è quello rappresentato dal gioco dei nove punti dentro il quadrato. Finchè si tenta di risolverlo rimanendo “ingabbiati” dai limiti apparentemente imposti, non si riuscirà a risolvere la questione. È solo quando di “pensa fuori dalla gabbia” che si può trovare una soluzione (figura 16).

E allora diventa importante uscire dagli schemi, non per un insensato ribellismo, ma per trovare soluzioni alternative e sperimentare percorsi che altrimenti non si conoscerebbero. Alcuni consigli che si rivelano utili di questo tipo di situazione sono:

• scherzare cercando di rimuovere certi blocchi e certe seriosità che spesso sono percepite come indice di serietà ma sono in realtà solamente rigidità bloccanti;
• lavorare in coppia o in team, con un proficuo scambio di idee, scoperte, riflessioni, constatazioni sugli errori compiuti, trucchi del mestiere;
• non accontentarsi sempre della prima soluzione che viene in mente, ma proporne anche di alternative, proprio per non fossilizzarsi su un unico modo di vedere il problema;
• accettare il fatto che ogni soluzione richiede un tempo necessario, a volte una vera e propria “decantazione”, per maturare e apparire in tutto il suo valore.

In questo ci viene in aiuto il “pensiero sistemico”: comprendo qualcosa quando analizzo le sue interazione con il resto. Ed è solo con il System Thinking che è possibile affrontare le sfide della complessità che vengono poste dal moderno panorama dello sviluppo e dell’organizzazione dei processi e dei progetti.

Infine, un consiglio molto saggio è quello di non “intestardirsi” sull’Agile al punto tale di non riuscire più a parlare con chi non adotta tali metodologie e non possiede il modello mentale che ne rappresenta la base: in questo modo si finisce per rendere rigido qualcosa che era nato proprio per aumentare l’adattabilità e l’elasticità.

Emmanuele Somma, “Bauhaus programming 21k: il software e la lezione dell’arte applicata”

Chiudo il resoconto con il talk che concludeva il pomeriggio di lunedì e che, tra quelli che ho seguito quest’anno, è stato sicuramente il più divertente con alcuni momenti davvero brillanti che hanno strappato ai presenti delle sonore risate.

Emmanuele Somma [20] ha presentato un intervento semi-serio e apparentemente sgangherato, che però ha avuto il merito di rappresentare una sorta di brevissima retrospettiva basata su metafore che prende in considerazione tre/quattro decenni di programmazione usando il tema dei movimenti artistici moderni e contemporanei per creare dei parallelismi. Anche in questo caso, consiglio ai lettori che non sono stati presenti a Better Software di guardarsi il video non appena disponibile: io mi limiterò a raccontare brevemente alcuni degli spunti emersi da quest’intervento.

Diciamolo subito: alcuni dei parallelismi fra determinati movimenti artistici e determinate impostazioni nello sviluppo del software sono un po’ sforzati, ma è chiaro che ciò che ci interessa non è tanto la perfetta aderenza tra i due mondi o una accurata definizione in termini di storia dell’arte, quanto piuttosto lo stimolo alla riflessione che in diversi casi ha decisamente funzionato.

Uno dei primi concetti esposti è: “il codice sorgente è arte?”. Certo, ci sarebbe da farsi la classica domanda “che cosa è arte?”, Ma di fatto già un primo sguardo a una pagina di codice dovrebbe farci capire se si tratta di qualcosa di “bello e di “buono”. Di fatto, se allarghiamo l’orizzonte, “fare software” è, a tutti gli effetti, una attività creativa tanto che una definizione del Governo britannico inserisce la realizzazione di software tra le attività creative, accanto all’architettura, all’arte, alla realizzazione di film e musica. E allora, in quest’ottica, hanno senso le varie similitudini fra alcuni movimenti artistici e aspetti importanti del mondo dello sviluppo.

Una delle caratteristiche comuni al mondo artistico e al mondo tecnologico dello sviluppo del software sta ad esempio nella adesione a determinati “manifesti“: tutti hanno presente il Manifesto Agile, ma questo non è il primo caso in cui dei programmatori si sono dati da fare per gettare le basi teoriche di una determinata corrente… e a questo punto viene presentato un Manifesto della Programmazione Futurista che strappa più di una risata di approvazione, a cui segue un Manifesto Agile riscritto proprio in senso futurista.

Un altro aspetto che collega arte e programmazione è il rapporto “tradizione vs. innovazione“.  L’esempio fornito è quello degli Impressionisti, i quali hanno rappresentato nella seconda metà dell’Ottocento un elemento di rottura rispetto alla pittura accademica, da parte della quale erano rifiutati. Proprio perchè rifiutati dall’establishment di allora, con gli impressionisti nasce un vero e proprio mercato dell’arte con tutta una serie di nuove figure (galleristi, mercanti d’arte e così via). Oggigiorno, però, i quadri impressionisti, che a fine Ottocento erano rifiutati dal sistema di riferimento dell’arte, sono diventati quelli che raggiungono i prezzi più elevati nelle aste: un tempo “outsider”, gli impressionisti hanno cambiato il modello di bellezza fino a diventare essi stessi punto di riferimento. La domanda posta da Emmanuele è se in questo momento, nel fare software, siamo più degli “accademici” o degli “impressionisti”.

Un altro interessante aspetto è il rapporto tra arte e scienza. Così come alcune correnti artistiche hanno tentato di istituire uno stretto rapporto tra arte e scienza (ad esempio il Divisionismo e il Puntinismo, ispirati dagli studi sulla fisica della luce e del colore, o il Cubismo, influenzato dalle conoscenze di geometria analitica), anche nello sviluppo del software si è puntato a legarsi a determinate impostazioni tecnico-scientifiche. Il rapporto arte-industria e l’idea di design razionale è esemplificato dal Bauhaus, il movimento sviluppatosi in Germania negli anni Venti del secolo scorso. Da questo punto di vista, il Bauhaus è in parte sovrapponibile a quel movimento denominato “ingegneria del software” che è ancora molto presente nel nostro panorama ma che, spingendo il razionalismo all’eccesso, fallisce nel sottovalutare l’atto creativo che è sottinteso tanto nella creazione artistica che nella produzione di software.

Piuttosto che studiare l’ingegneria del software, dovremmo concentrarci sugli errori, sui bug. Ed è in questa affermazione paradossale, e nella presa d’atto che la scienza non è completa, perchè a volte occorre uscirne fuori, che emerge una possibile corrente artistica di riferimento per il relatore: il Surrealismo, per cui l’unico vero atto creativo è inconscio. Viene quindi rivalutata la patafisica, ossia la scienza delle soluzioni immaginarie.

Una presentazione sicuramente non convenzionale, a volte eccessiva nello stirare le metafore, a tratti davvero esilarante, e comunque in grado di fornire qualche valido spunto di meditazione e di approfondimento.

In conclusione

Anche quest’anno la conferenza si è svolta in quel clima rilassato e fattivo che la caratterizza da sempre. Molte facce conosciute, ma anche nuove presenze. Abbiamo già detto all’inizio di questo articolo dei cambiamenti in vista per la prossima edizione, nel senso di un’ulteriore spinta all’internazionalizzazione con l’uso dell’inglese come lingua ufficiale e della riorganizzazione della formula in cui distribuire workshop e talk. Quindi qui vogliamo fare solo poche considerazioni generali.

La prima è relativa agli argomenti trattati: sempre di più in questi ultimi anni Better Software ha consapevolmente dato spazio ai temi dell’organizzazione aziendale innovativa e della gestione di progetto e processo, lasciando una certa importanza comunque agli interventi legati alla progettazione della UX e della interfaccia utente, ma comprimendo sempre più i contributi strettamente tecnici e architetturali. Questa è una scelta sensata, frutto di una precisa strategia; resta però una discrepanza con la parola Software nel titolo della conferenza che continua per molti a evocare solo righe di codice su schermi di computer. Uno dei passi ulteriori che è possibile fare è tentare di “agganciare” un pubblico potenziale che non è composto solo da sviluppatori e coach che già siano pienamente consapevoli di queste tematiche, ma che comprenda invece proprio quelle figure professionali legate all’organizzazione e alla gestione dei progetti e che si muovono all’interno di aziende nelle quali il cambiamento deve ancora avvenire.

La seconda considerazione è che mai come quest’anno si è percepito, nel complesso, il desiderio di andare “oltre l’agile“: per carità, nessuno ha già dismesso metodologie e pratiche che solo ora si stanno affermando (e peraltro, non ancora su larga scala); ma c’è stato, in un gran numero di interventi di tono e argomento diverso, un comune denominatore rappresentato dal desiderio di non rimanere ingabbiati in qualcosa (Lean/Agile malintesi come rigide infrastrutture) che dovrebbe invece liberare dalle precedenti sovrastrutture. Forse è uno slancio in avanti fin troppo spinto, forse è solo la naturale evoluzione di un processo di cambiamento: del resto Beyond Agile è un mantra che inizia a farsi strada.

Infine, in molti casi si è assistito a presentazioni che fanno riferimento a scuole di pensiero, metodi e conoscenze che esulano dal campo informatico e dell’organizzazione aziendale: teorie della complessità, system thinking, antropologia culturale, ecologia… Tra chi si occupa di produzione del software e di gestione dei processi, c’è stato, in questi ultimi cinque anni, un prepotente ritorno di attenzione per visioni e concetti derivanti da scienze sociali e psicologiche, da scienze naturali e discipline umanistiche, che per molti anni erano state tralasciate con sufficienza, e che invece si sono reimposte all’attenzione con il peso che la loro riflessione teorica può avere nella pratica quotidiana delle aziende e dei gruppi di lavoro. Questa commistione di conoscenze e di competenze è cosa buona e proficua, e occorre che si sviluppi in maniera coerente e approfondita anche nelle successive edizioni.

Che dire quindi? Che vi aspettiamo all’edizione 2015 convinti che saprà riservare novità e qualità.