Agile Venture Prato 2018

Agile Venture Prato: sessione mattutina

Una bellissima giornata di sole ha fatto da cornice alla conferenza, così organizzata:

Keynote “Agile pro nobis”

Questo keynote non si farà, nè oggi nè mai, per parafrasare una battuta di un famoso romanzo.
Perché scrivo questo? Perché non fosse stato per l’intervento del buon Fabio, che alle prime luci dell’alba è corso in direzione Pisa per recuperare il povero Jacopo al quale avevano dirottato il volo (tranquilli, niente terroristi: solo normalissimo caos), avremmo perso davvero tanto di questa giornata.
Il perché lo capirete leggendo 🙂
Tornando a noi, l’aula era gremita in ogni ordine di posto, e Jacopo ha potuto finalmente cominciare la sua lectio divina.

Jacopo non ha portato teorie, dimostrazioni, dati, bensì sue opinioni sull’evoluzione del pensiero agile portando come termine di paragone le dinamiche di pensiero agnostiche per capire, in questa evoluzione, gli scontri tra diversi credo e pensieri.

Si pensi alla chiesa ortodossa, al buddhismo, a quante ramificazioni si sono create e fortificate in millenni di storia dell’uomo…tutte nate fondamentalmente da un credo comune, da un’idea principale.
Il concetto è: questa cosa (nel caso, religione) esiste, me ne creo una nuova.

Lo stesso vale per le pratiche agili. Le seguiamo, in maniera più o meno diligente, ma tendiamo poi a creare un qualcosa di nuovo, che non c’è.
Secondo Jacopo, esistono agilisti di varia natura, dai puristi, e cioè coloro che mettono in pratica i principi e metodologie agili in maniera rigida e rigorosa (qualcuno di voi lettori avrà riconosciuto lo zio Brando Alberto Brandolini 🙂 )

Altri agilisti invece si focalizzano su altri aspetti, come ad esempio la crescita della persona…i famosi tree hugger 🙂

La lectio di Jacopo è proseguita su un’altra riflessione, e cioè che tra chi pratica agile, si tende ad essere ossessivi e compulsivi, o più semplicemente schiavi della forma con il quale si compiono gesti. Pensiamo a quando dobbiamo chiudere la portiera di un’auto, sappiamo che dobbiamo compiere quella determinata azione.

Nella sua esperienza Jacopo ha notato che molte aziende vedono l’agile coach come un oncologo. Nella loro disperazione, vedono questa figura come qualcuno che ti propina una cura, nella speranza che possa reagire al meglio.
Questo succede perché tali aziende non si sono mosse per tempo, quando chi praticava agile veniva visto come “un matto, un figlio dei fiori”…ora invece pregano affinché questa sorta di santone risolva loro i problemi. Qualunque tipo di cura va bene, l’importante è che sia agile…ma occhio ai furboni!
Eh sì, perché secondo Jacopo, molte aziende, persone si spacciano per agilisti quando di agile hanno solo una certificazione…bisogna stare attenti ai mago Otelma del caso 🙂 che ti illudono di diventare come per magia agile magari semplicemente propinandoti dei software… agile non è uno strumento!

Agile è un modello, il Manifesto Agile lo è, è una traccia. Va sì consultato, compreso, ma non preso come verità assoluta. Per molti è come la Bibbia, ma alla fine…STA A TE!

Prima di salutarci, Jacopo ha concluso come mai mi era capitato di assistere…con una preghiera!
Per chi è cristiano praticante, tenga in mente la Preghiera dei fedeli…per chi è ateo o di un altro credo, il momento in cui, ad ogni preghiera letta dal sacerdote, si risponde Ascoltaci o signore.
Invitando tutti i presenti in sala a rispondere Perdonaci, o Kent Beck!, Jacopo ci ha letto una serie di “preghiere” relative a situazioni paradossali, comiche in cui le buone pratiche e concetti agili sono andati a farsi benedire 🙂
Risate contenute e consensi in sala, che hanno concluso un keynote tanto originale quanto ricco di spunti.

Grazie Jacopo!

Morte da mille ferite – Refactoring workshop

Alcuni di noi (Damiano, Gianni Bombelli e Ferdinando Santacroce) hanno partecipato al workshop del toscanissimo Matteo Baglini, che giocava praticamente in casa.

Dopo un’ottima introduzione teorica sui diversi code smell e su alcune tecniche di refactoring (lettura consigliata: il libro “Refactoring” di Martin Fowler), Matteo ci ha spiegato come molti dei problemi che si riscontrano nel codice siano riconducibili alla primitive obsession, ovvero l’utilizzo diffuso di tipi di dati primitivi del linguaggio, usati anche dove sarebbe più opportuna una modellazione specifica per il proprio dominio.

Ad esempio, nel gestire i dati degli utenti, potremmo avere una stringa per il codice fiscale ed una semplice data per la data di nascita… ma questo ci costringerà a controlli diffusi sulla validità dei dati (il codice fiscale ha la lunghezza giusta? e il formato? la data è nel passato o nel futuro?). Racchiudere ogni dato significativo in un oggetto ben modellato permette di centralizzare i controlli e garantirne la correttezza nel resto dell’applicazione, avviando un circolo virtuoso con numerose conseguenze positive, fra cui: la facilità di scrivere test, la riduzione del numero di test necessari e la creazione di behaviour attractors che favoriscono una corretta suddivisione del codice nei giusti componenti.

Matteo ha poi mostrato con un esempio pratico di live coding come attuare alcuni dei suggerimenti appena spiegati, dopodiché ha passato la palla a noi, lasciandoci liberi di sperimentare le tecniche appena apprese su un progettino pensato ad-hoc (il repository task-list che vedete nell’immagine).

Pensare alle modifiche da fare ed iniziare a “sporcarsi le mani” è stata la parte più stimolante del workshop: tenendo a bada la classica frustrazione da refactoring (“ma qui bisogna cambiare tutto, non ce la farò mai”), sapendo che l’obiettivo del kata non è sistemare tutto ma fare pratica in un ambiente sicuro e senza pressioni, abbiamo trovato molto interessante sia il lavoro fatto da soli sia le discussioni che ne sono nate, prima durante il workshop per chi ha lavorato in coppia, e successivamente confrontando i diversi approcci seguiti.

Grazie Matteo, hai rinnovato la nostra voglia di tenere sempre allenate le nostre skill di programmazione.

Agile goes to Hollywood: portare agile all’interno di una grande azienda

Giovanni Puliti, aiutato da suo figlio Mattia, ha raccontato della sua esperienza di coaching agile per Agile Reloaded in diverse aziende del mondo Enel, focalizzando il discorso nei seguenti punti:

• Perché
• Dove
• Come
• Quindi

Perchè questo titolo? …goes to Hollywood è semplicemente un richiamo al periodo in cui il leggendario Frank Sinatra iniziò a cogliere i primi successi ed insediarsi nello star system hollywoodiano. Come Sinatra, anche l’agilità entra, anzi sta piano piano entrando ed affermandosi nelle grandi aziende.
E quale modo migliore di introdurre l’agilità se non andando direttamente in campo e vedere con i propri occhi “come si fa quella tal cosa?”. Dal giapponese, Genchi Genbutsu, ossia appunto Va e Vedi, Go and See.

Dove è andato, e andrà Giovanni?
In diverse aziende della galassia Enel dove (Enel Italy, Enel Green Power) ha potuto dapprima vedere come e dove effettivamente veniva svolto il lavoro (centrale idroelettrica, officina per la ristrutturazione di strutture fotovoltaiche) dopodiché ha lavorato con il team applicando tecniche agili come:

• affiancamento
• formazione
• setup del team
• story mapping,
• clustering,
• classificazione attività,
• Kanban board con definizione di WIP limit

al fine di migliorare l’organizzazione del lavoro (magari anche per svolgere attività entro pochi giorni).
Ma non solo lavoro con il team, anche attività con il management (agile for managers):

• mappatura valore
• scaling
• agile human resources

Giovanni ha trovato molto interessante e di buon auspicio per il futuro il fatto di poter parlare con tutti i livelli dell’organizzazione (ad esclusione dell’amministratore delegato).

Come? In che maniera Giovanni ha svolto tutte queste attività? Come agile coach. Ma chi è, cosa fa un agile coach? E’ colui che spiega le metodologie, gli strumenti, cerca di capire che cosa si vuol fare, l’obiettivo che si vuole raggiungere e di conseguenza ti affianca e stimola affinché tu possa fare le scelte migliori. Ma attenzione, poi sta a te, le scelte le devi prendere tu azienda, o team (riprendendo una riflessione dal keynote di Iacopo).

Quindi? Giovanni ha condiviso le sue considerazioni sulle esperienze svolte, le realtà e i modelli organizzativi con il quale si è misurato. Ha avuto a che fare con organizzazioni miste che ad esempio avevano il reparto IT interno ma fornitori esterni, con fastidiose situazioni dovute a frizione tra le 2 parti. Ma come sempre bisogna ricordare, ci si deve venire incontro, trovare un accordo. Si vince e si perde, ma assieme.
In altre casi Giovanni si è trovato di fronte ad aziende che adottavano un approccio ibrido non tanto nell’organizzazione delle risorse quanto nei processi: agile più waterfall per intenderci. Si può fare certo, ma solo se si ha ben chiaro l’obiettivo, dove si vuole arrivare.

Come predicato da Iacopo nel suo keynote, agile non è uno strumento,bensì un insieme di principi e pratiche…e valori. Va bene fare scrum, fare extreme programming, adottare la Kanban board…ma ricordiamoci anche che essere agili vuol dire anche migliorarsi continuamente, produrre valore.

Ma qual’è l’approccio dell’agile coach Giovanni in azienda?
Su inizia con l’organizzare i team, la formazione e il setup iniziale del progetto. Durante il lavoro poi, si monitorano i risultati del team, senza dimenticarsi di lavorare anche con il management. Portare quindi team e management a prendere decisioni, magari piccole, ma con spirito critico e con il fine quindi di rilasciare valore e migliorarsi continuamente.

Giovanni, come anche Agile Reloaded, adottano delle metriche per monitorare, valutare e ovviamente migliorarsi nel loro lavoro

Dopotutto non si è agili se non si è predisposti al miglioramento continuo.

Grazie Giovanni e Matteo, è stato un talk piacevole ed interessante, ulteriore conferma che agile non è più una “roba da figlio dei fiori” bensì una realtà sempre più consolidata.

Agile è chi agile fa

Marco Fracassi, al pari di Dimitri Favre, vincono il premio del talk dal titolo più originali 🙂

Chi è agile? Chiunque può dirlo, è semplice definirsi agili, ma molto difficile esserlo.

Nel tempo a sua disposizione, Marco ha raccontato la sua esperienza da quando ha cambiato approccio lavorativo passando al mondo agile.

Sin dal lontano 2009, cioè dai suoi primi tentativi TDD per intenderci, Marco ha percepito di essere visto come un figlio dei fiori, un folle, “ma che diavolo stai facendo” e compagnia cantante…oggi tutto ciò è diventato mainstream.

Qual è quindi la situazione oggi?
Facendo ricerche su Google, Marco ha notato una sempre più presenza della parola agile e tutto ciò che concerne suoi principi o pratiche. Ha però anche notato che in nome di agile si vendono tool e  framework, dimenticandoci che prima arrivano principi e metodologie! Come ricordato da Giovanni o Iacopo, agile non è uno strumento, non è un insieme di tool!
Alla stessa maniera, non basta esibire una certificazione per definirsi agili…ma molte persone lo fanno, semplicemente perché è figo.

Secondo Marco, che è un sviluppatore software, non sei agile se:

• Adotti scrum ma lo applichi male. Effetto scatola vuota perché non si entra nel merito delle pratiche di natura tecnica (perdita di focus sul software)
• Intendi gli sprint come promesse: inserisco più story possibile facendo sì il cliente contento ma oberandomi di lavoro, e probabilmente lavorare sotto pressione durante i giorni della durata dello sprint
• fai parte di team deresponsabilizzato: tendenza di alcune figure del team a demandare lavori su lavori allo sviluppatore, lavandosene quindi le mani. In tutto ciò, la collaborazione che fine fa?Non viene meno? In questa configurazione, che senso può avere la figura dello scrum master? Rischia di essere inutile.
• gestisci le certificazioni in maniera poco chiara: è facile certificare una hard skill, ma come la mettiamo con le soft skill? Per capirci, come si certifica la capacità che un buon scrum master dovrebbe avere? Queste sono qualità umane. Per queste figure magari si dovrebbe far pesare l’esperienza rispetto alla formazione. Quanti neolaureati sono scrum master, product owner, per poi scoprire magari che hanno seguito solo un corso.

Nella sua esperienza lavorativa Marco ha potuto notare come la transizione ad agile non sempre è un bene per l’azienda. Si devono riciclare manager, perché serve un product owner, o uno scrum master. Ciò porta a disfunzioni organizzative.
Quando questa riorganizzazione va bene, si è tutti contenti, altrimenti si rischia di vivere una sorta di “teatrino dell’agile”,e cioè ripetere quotidianamente azioni agili (daily scrum ad esempio)…ma stiamo andando bene? Ci crediamo in ciò che facciamo?
E lo stesso vale dal punto di vista tecnico.
Per imposizioni dal management o altri motivi, si adottano specifici tool\framework ma poi solo chi li deve usare si rende conto che non vanno bene…
Ancora una volta, non sei agile se ad esempio sai impostare una board ma poi non la mantieni. Idem per il backlog, non basta considerarlo solo come contenitore di nuove story o bug…va mantenuto.
O fare sì i daily scrum ma OGNI 3 GIORNI…non ha senso.

Ma ci sono anche disfunzioni tecniche.

• Marco si è trovato a lavorare con team architetturali. “Uao”è stato il suo primo pensiero, c’è chi si occupa esclusivamente di pensare alle architetture, ma poi vanno bene per tutti i team coinvolti?
• Team autonomi..solo sulla carta dal momento che non è loro concesso di fare recruiting o scegliere le tecnologie più adeguate.
• Il team leader: a che serve? Se faccio parte di un team, non è meglio dare voce a tutti?
• No alle pratiche tecniche
• No allo studio: non si dedica spazio a delle attività di studio per migliorarci e puntare all’eccellenza

Cosa propone quindi Marco? Quale è la sua ricetta per tornare ad essere veramente agili?
Torniamo alle basi, studiamo. Diamo importanza alle pratiche tecniche. Diamo importanza a noi stessi, assegnando i ruoli alle persone più adatte. Non affezioniamoci al tool X che magari ci viene imposto per il nostro lavoro. Spingiamo per la ricerca di un tool migliore, una versione più aggiornata.
Identifichiamo i nostri valori, cerchiamo di essere felici nella quotidianità del nostro lavoro, è importante per il nostro percorso di crescita.

Marco alla fine non è un pessimista, è anzi come tanti una persona sì delusa ma sì pronta a trasformare questa delusione in spinta per migliorare e andare avanti. Da bravo agilista.
Grazie!

Bias cognitivi e SCRUM

Prendendo spunto dal libro Thinking, Fast and Slow di Daniel Kahneman, nel quale si descrivono una serie di esperienze cognitive, Stefano ha portato in tavola un bell’argomento di discussione, i bias cognitivi, e come si possono ricollegare al mondo ed alle pratiche agili.

Ma cos’è un bias? Ammetto la mia ignoranza, mai ne avevo sentito parlare.
Ma andiamo con ordine.

In ogni persona convivono 2 sistemi, 2 attori ognuno dei quali recita una parte:

Cerchiamo di capire meglio:

• Sistema 1: E’ il sistema che opera più velocemente, automaticamente. sonda l’ambiente circostante e lo elabora. Data la sua rapidità di esecuzione, consuma poca energia, dato che lavora sulla memoria associativa. Per intenderci, è il sistema 1 che ci permette di capire quando un’espressione è di disgusto, o anche di guidare in un’autostrada sgombra piuttosto che trafficata.
• Sistema 2: E’ il sistema più lento, la razionalità prende il sopravvento. Tanto logico quanto lento ed indeciso. Basti pensare ad ogni volta che qualcuno ci chiede di risolvere una qualunque operazione…non rispondiamo subito. Perché il sistema 2 sta elaborando e lavorando.

In sintesi, il Sistema 1 lavora su intuito ed istinto, il sistema 2 si basa sul pensiero razionale. Entrambi i sistemi lavorano e ci portano ad una sorta di indecisioni, conflitti.

Diamo un’occhiata alla seguente immagine:

Qual è  dei 3 è il segmento più lungo? Nessuno! Sebbene ad un primo sguardo (sistema 1) siamo portati a dire “il segmento centrale”, osservando e ragionandoci un attimino (sistema 2) ci accorgiamo che le linee hanno tutte la stessa  lunghezza, ma le direzioni degli estremi confondono i nostri sistemi e quindi le nostre conclusioni.

Ecco, i bias quindi sono quegli automatismi mentali che ci guidano per prendere le decisioni nella vita di tutti i giorni.

I bias cognitivi ci tendono continuamente trappole che pregiudicano l’efficacia delle nostre decisioni o delle dinamiche di comunicazione tra noi e gli altri.
Partendo da diversi ambiti lavorativi, Stefano ha discusso assieme a noi partecipanti di alcuni esempi riguardanti il mondo Scrum e la manifestazione dei principali bias e come poter creare le condizioni necessarie (attraverso pratiche) per limitarne gli effetti indesiderati.

Di seguito, alcuni esempi tratti dalle slide del talk.

Fluidità cognitiva:

Priming:

WYSIATI (What You See Is All There Is):

Come potremmo quindi limitare l’effetto di questi bias? Stefano ha proposto una sua “ricetta”

Vedete l’immagine del cucciolo sullo sfondo di quest’ultima slide? Stefano a più riprese ha proposto tale immagine ma in un’altra slide

Lo ammetto, da questo talk molto ho imparato e molte nozioni, concetti sono stati nominati per la prima volta.

Da 1 a 5? Lo reputo figo 10 (grazie Stefano per ingannarci mettendo in evidenza quel 5 🙂 ), ma da approfondire ne ho 100 🙂

Qui le slide dell’intervento.

Pranzo

Dedico qualche parola alla pausa pranzo, dove ci siamo trovati particolarmente bene, respirando un clima disteso e chiacchierando dei talk e quant’altro, il tutto ovviamente accompagnato da ottimo cibo

Agile Venture Prato: sessione pomeridiana

Eccoci alla seconda parte della giornata, così organizzata

SOLID principles in practice: the clean architecture

Fabio Collini ci ha spiegato quali siano i benefici del mettere in pratica i principi S.O.L.I.D. e come sviluppare un progetto con un’architettura clean sia uno dei modi per “costringersi” a metterli in pratica, il tutto portando come esempio una piccola applicazione di previsioni meteo scritta in Kotlin.

Nella prima parte del suo talk, Fabio ha mostrato un pò di sintassi Kotlin soffermandosi su sintassi e alcuni punti:

• async-await
• dependency injection
• lazy loading

Come rendere quindi la nostra architettura clean S.O.L.I.D. compliant?

Ma che vuol dire S.O.L.I.D.? Capiamo quali sono i 5 princìpi rappresentati da ognuna di queste lettere:

• S: single responsibility: una classe dovrebbe avere 1 e 1 sola ragione per cambiare, cioè deve avere 1 sola responsabilità
• O: open closed: dovresti essere in grado di estendere il comportamento di una classe, senza modificarla, ma tramite l’ereditarietà
• L: Liskov substitution
• I: interface segregation : fare interfacce specifiche (tante, ma piccole) piuttosto che una interfaccia con molti metodi
• D: dependency inversion: dipendere da astrazioni e non da classi concrete.
  Meglio: i moduli di alto livello non dovrebbero dipendere da moduli di basso livello. Entrambi dovrebbero dipendere da interfacce

Fabio ha rimarcato che, per far sì che si rispettino questi principi, le interfacce sono fondamentali nel nostro codice del progetto.

Adottare un’archittetura clean, che rispetti i principi S.O.L.I.D., porta ai seguenti vantaggi:

• framework independence: logica di dominio indipendente da specifiche tecnologiche. Prendiamo il caso della UI: si può cambiare UI (ad es. una app mobile anziché un programma desktop con una finestra di edit) e lasciare inalterato il resto
• architecture vs code conventions: ogni classe di moduli di alto livello non ha nel classpath le classi di basso livelli e quindi le violazioni della dependency inversion sono impedite a priori
• T.D.D.: se devo eseguire unit test del domain, lo posso fare senza dover eseguire tutta l’applicazione

L’unico svantaggio sottolineato da Fabio è sulla quantità di codice prodotto, maggiore rispetto ad altre soluzioni architetturali.

Grazie Fabio, talk tanto tecnico quanto ben condotto.

Creare un’organizzazione che apprende in quattro mosse

Fabio Ghislandi ha condotto un talk suddiviso in 2 parti:

• quali sono gli elementi che intervengono nel processo di miglioramento\innovazione?
• caso reale di un’azienda che apprende in 4 mosse

Ma che vuol dire idea? E innovazione?

Nel 1093, nacque l’idea con il primo prototipo di aereo dei fratelli Wright. Dimostrarono come una pensata potesse essere trasformata in un’invenzione.
Nel 1935 (McDonnel Douglas), nacque il primo aereo commerciale. Un’innovazione della precendente idea dei fratelli Wright,
Il termine “innovazione” si può quindi definire come applicazione affidabile e sostenibile di un’invenzione.
Proseguendo con gli esempi di innovazione, cosa ha il DC3 di innovativo rispetto ad un Boeing di qualche anno prima?
5 componenti, tra cui il carrello retrattile, che garantiscono applicabilità concreta ed economica.

Senge nel suo libro spiega che ci sono 5 tipologie di elementi che intervengono nel trasformare le innovazioni in organizzazioni che apprendono. Per Senge, apprendere per un’azienda significa migliorare continuamente la propria capacità di realizzare le aspirazioni più elevate.
Vediamo queste 5 discipline:

1. Modelli mentali
   Modi di pensare, di vivere radicati nella quotidianità lavorativa.
   Allenarci continuamente per sottoporre queste convinzioni ad una costante critica, altrimenti rischiano di diventare una gabbia mentale. Attivare quindi conversazioni ricche di apprendimento, di modo tale da mettere in discussione questi modelli mentali.
   Ricostruire il bilanciamento tra cosa pensiamo e cosa diciamo, e chi siamo.
   Guardiamoci dentro, comprendere chi e dove siamo, e metterlo continuamente in discussione.
2. Costruire una visione condivisa
   Far emergere dai componenti dell’azienda l’obiettivo, la visione: non solo condivisa all’interno del management e quindi imposta, ma co-costruita. Non vivere questo obiettivo come imposto dall’alto ma esserne il più possibile consapevoli e determinati nel perseguirlo. Inoltre è necessario definire pratiche concrete per realizzare tale visione.
3. Apprendimento di gruppo
   E’ necessario l’apporto di tutti in un’organizzazione, non può capitare che ci sia una sola persona con determinate competenze e quindi essere l’unica a potersi prendere carico determinate mansioni.
   Le unità basilari di apprendimento non sono i singoli bensì i gruppi.
   Questa disciplina è un elemento decisivo per il successo: l’organizzazione non apprende se non apprendono i gruppi.
4. Padronanza personale
   La padronanza personale si realizza quando una persona esegue un mestiere che è allineato con la visione di sé.
   Quando ciò avviene la persona è in grado concentrare pienamente l’attenzione su ciò che ha veramente valore.
   L’azienda che riesce ad avere persone dotate di padronanza personale è come se facesse … Bingo.
   La padronanza personale è però una disciplina da allenare continuamente, e l’allenamento è il continuo apprendimento.
   E’ molto importante per una persona avere padronanza personale per vivere pienamente il periodo della vita più lungo, quello della maturità.
5. Pensiero sistemico
   Capacità di vedere il tutto nella sua complessità. Se vediamo le parti separate, rischiamo di non capire cosa stia succedendo.
   E’ la sintesi delle precedenti 4 discipline, basate sull’apprendimento.
   Il pensiero sistemico ci permette di vederci non separati dal mondo come organizzazione.
   Ci restituisce il nostro destino, che rimane ancorato nelle nostre mani.

Cosa ci impedisce di apprendere secondo Senge?

• La propria posizione nell’azienda. Ognuno di noi, alla domanda “Di cosa ti occupi nell’azienda per il quale lavori?”, risponde dando informazioni sul proprio ruolo, nulla di più, nulla di meno.
• Il nemico è la fuori. La colpa è sempre di qualcuno, esterno a noi. Non siamo mai noi.
• L’illusione di farsi carico di qualcosa. Proattività vs Reattività. Proattività è, ad esempio per uno sviluppatore software, fare unit test, non reagire al bug di produzione. Quest’ultima è reattività.
  Quindi non farsi guidare dalla reattività.
• L’eccesso di concentrazione sugli eventi.
  Si è occupati ad affrontare continue “emergenze” e perseguire obiettivi breve termine risolvendo di volta in volta la minaccia del momento, ma spesso si perdono di vista i processi più importanti, che si sviluppano in modo graduale su tempi lunghi, perdendo la capacità di affrontarli nel modo giusto. Come esempio, Fabio ha portato la parabola della rana bollita: se mettiamo una rana in una pentola di acqua bollente, salterà fuori immediatamente, ma se la mettiamo nell’acqua fredda e la scaldiamo piano piano, la rana farà una pessima fine senza nemmeno accorgersi di cosa le sta capitando.
• L’illusione di apprendere dall’esperienza.
  Apprendere dall’esperienza è possibile, ma molte volte è illusorio: come posso valutare le conseguenze delle mie azioni se queste conseguenze non si sviluppano qui e ora ma magari a migliaia di chilometri di distanza oppure fra anni?
• Il mito del management team.
  Pensiamo che questo gruppo sia composto da super-uomini capaci di risolvere problemi…ma spesso queste persone tendono a proteggersi o comunque a proteggere la loro area.

Legame tra “la quinta disciplina” e agile?
Il primo legame è nella parola “uncovering” del manifesto agile: come facciamo a scoprire se non esploriamo e se non apprendiamo? L’altro legame è sul primo valore agile “Individuals and interaction”: se basiamo l nostro lavoro sulle persone queste devono essere messe nelle condizioni di apprendere con riferimento alla padronanza personale.

Eccoci quindi arrivati alla seconda parte del talk, un esempio.

Fabio, che oltre ad essere presidente di Italian Agile Movement è anche partner di Intré, ha spiegato come Intré ha fatto, fa e continuerà a fare per creare un’organizzazione che apprende.
Semplice (a dirsi 🙂 ), ci siamo concentrati su Apprendimento di gruppo e Padronanza personale.

• Mossa 0: Lavoro in team, vissuto in dimensione di team cross-funzionale ed auto-organizzato
• Mossa 1: Accrescere le proprie conoscenze in attività di gruppo: le GILDE.
  Una gilda è un team di studio relativo ad una proposta fatta durante un camp aziendale, proposta che ottiene più voti (post-it, dot voting) rispetto ad altre. Ha una durata di 4 mesi, durante i quali il team si trova 4 ore a settimana per portare avanti lo studio. I risultati di questo studio verranno presentati al successivo camp.
  Per approfondimenti, date un’occhiata alla nuova sezione del nostro sito dedicata alle gilde.
• Mossa 2: Camp, una giornata durante la quale si fa il punto della situazione (chi siamo, dove siamo, dove vorremmo arrivare), dove si condividono i risultati del lavoro di gilda e si definiscono nuove gilde. La mattinata tipicamente è dedicata all’open conference.
  Se vi incuriosisce, guardate foto ed articoli relativi agli scorsi camp.
• Mossa 3: Partecipazione alla community: apprendere dagli altri, ispirare e farsi contagiare; partecipare alle conferenze, anche come speaker.
• Mossa 4: Coaching tecnico: tramite supporto di professionisti esterni, apprendere durante il lavoro quotidiano.

Grazie Fabio, meglio non potevi far arrivare tutti questi messaggi ed insegnamenti 🙂 in cui tutti noi ci rispecchiamo.

#noprojects: Modern software development focus on teams (and products)

Dimitri Favre ha condotto un talk dal titolo, o meglio hashtag, un po’ forte.
No projects?
Che vorrà dire, forse di smetterla di lavorare con progetti? O forse, come è più plausibile pensare, iniziare a smettere di utilizzare questa parola, progetto, sempre più inflazionata e parte delle nostre vite.
Scopriamolo

Ispirato dal lavoro e dal libro #noprojects: A Culture of Continuous Value di Evan Leybourn e Shane Hastie, e  da questo #noprojects sempre più presente su Twitter, Dimitri ha voluto mostrarci il suo pensiero in merito a questo particolare quesito.

La parola progetto si porta dietro tante cose, che tu sia cliente, fornitore…c’è sempre qualcosa che non funziona.
Dal manifesto agile, stiamo ancora scoprendo modi per fare software. Perché dobbiamo portarci dietro questa parola…innoviamo, scrolliamocela di dosso.
Anche Martin Fowler ha detto che dobbiamo liberarci dal concetto di progetti software, pensando anzi al prodotto ed organizzare di conseguenza i team.
Non è il progetto ad essere errato, ma il modello del progetto.
Usiamo la parola progetto spesso, quasi sempre…anche il matrimonio è un progetto.

Dimitri ha quindi mostrato e spiegato la sua “Superclassifica” dei 5 problemi, dal meno al più importante:

• I progetti e il potere del team
  Secondo il modello di Tuckman, team che vince non si cambia (team stabili quindi lungo tutta la durata di un progetto). Ma che succede alla fine del progetto? Il team e tutto il suo valore che fine fa?
• I prodotti sono per sempre, più longevi dei progetti che li generano
  Il PMI definisce il progetto come un qualcosa di temporaneo utile a creare un prodotto, servizio.
  Il progetto ha un inizio e forse una fine, e il suo successo si misura considerando:
  • TEMPO
  • BUDGET
  • FUNZIONALITA’ (SCOPE)

Ma dove finisce il valore? La qualità? Anche con i progetti agili si ricade in questa stima, perché si vanno a vedere se le stime iniziali sono state rispettate.

• Cosa succede quando un progetto finisce?
  2 scelte:
  • Il progetto viene esteso: si riesce ad ottenere, magari pregando :), un po’ di extra budget
  • Passaggio di consegna: passaggio di conoscenza. o peggio si decide di portare il progetto in fase di manutenzione (ams), considerata da Dimitri la casa di riposo di un progetto. Fintantoché non viene chiuso, dismesso, un progetto se ne sta buono buono in manutenzione.
    Attenzione al conflitto di interesse tra sviluppatori e ams: più male scrivi il tuo software, più lavoro di manutenzione ti generi. Il che può essere visto come un bene, perché il team X verrà pagato per mantenere tale progetto. Ciò che può capitare però è ritrovarsi in team di serie A e team di serie B, dove per B si intende il team composto dalle riserve, da “quelli più scarsi” o magari da figure junior. Quindi, in caso di progetto in ams, non c’è problema, se ne occuperanno le riserve.
• Progetti costruiti attorno a silos: la strutturazione in reparti nelle grandi aziende, a ricordare appunto i silos, sono secondo Dimitri una delle maggiori barriere da superare quando si cerca di essere agili. Si tende infatti a pensare e sviluppare progetti ottimizzati per le risorse dello specifico silos, creando ridondanza, complessità anziché valore.
  Progetti pensati per un certo settore, per una certa tecnologia…non va bene.
• L’ambito di un progetto è definito per un unico scopo, che molto spesso si traduce in una bella lista della spesa, dove al posto dei prodotti da acquistare troviamo una lista di storie, task da portare a termine stando entro un certo costo.

E in un mondo #noprojects? Si potrebbe vivere tutti meglio.
Si parla e conosciamo le terminologie continuos integration, continuos delivery…e perché no continuous project?
Questa parola progetto andrebbe abbandonata, perché adottandola ci fa automaticamente adottare determinati schemi mentali.

Partiamo dal focus quindi: non pensiamo al progetto bensì al portfolio prodotti.
Portiamo lavoro ai team, e non l’inverso. Facciamo ruotare le persone, basta team stabili.

Tornando sul primo dei problemi, e cioè un team che lavora su più progetti è un bene, Dimitri suggerisce invece di gestire un team backlog (magari non servirà più la figura del product owner, ma un team product owner). Dopotutto il modello di Tuckman ci dice che ogni volta che cambiano un team si sperpera del denaro.

Anziché domandarci Ma quanto costerebbe adottare questa azione X?, domandiamoci Tale azione X potrebbe portare valore alla nostra azienda?
Forse non abbiamo la visione corretta del mondo, delle cose.

Grazie Dimitri, sei stato davvero illuminante, per quanto all’inizio del tuo talk fossi un po’ perplesso. Nella mia testa pensavo “Chissà che PROGETTI ha in mente Dimitri per noi :)”.

Qui le slide del talk.

Object Calisthenics

Punto di vista differente in questa occasione.

Nel pomeriggio Ferdinando Santacroce ha facilitato il workshop Object Calisthenics, dove i partecipanti hanno potuto esercitarsi e riflettere sui temi classici della programmazione ad oggetti.

Il workshop è basato sul lavoro di Jeff Bay, che qualche tempo fa ha proposto una serie di regole da rispettare per scrivere del buon codice OOP.
L’articolo (ora fuori stampa) è incluso nella ThoughtWorks Anthology , una raccolta di essay curata dalla celebre azienda di Chicago.

La sfida, perché è di questo che si tratta, prevede il rispetto di queste “semplici” norme:

1. Only one level of indentation per method
2. Don’t use the else keyword
3. Wrap all primitives and strings
4. First class collections
5. One dot per line
6. Don’t abbreviate
7. Keep all entities small
8. No classes with more than two instance variables
9. No getters/setters/properties

Usando il celebre TennisKata di Emily Bache, i partecipanti si sono messi alla prova sfidando l’implementazione del kata già fornita nel repository.
L’implementazione, “scritta male” di proposito, ha fornito una buona base per mettere in pratica diverse tecniche di refactoring, e a giudicare dall’interesse manifestato dai partecipanti possiamo senz’altro affermare che questo genere di esercizi risultano davvero un buon allenamento per un programmatore.

Abbiamo lavorato a coppie, seguendo il più possibile i dettami del Pair Programming classico; alcuni partecipanti erano nuovi a questo modo di lavorare, ma tutti hanno alla fine apprezzato quale sia il valore del feedback continuo, della discussione aperta e del confronto con un altra persona del mestiere: non era questo il focus del workshop, ma crediamo di aver gettato qualche seme XP in un terreno fertile 🙂

Il pomeriggio è volato, e dopo 3 pomodori ed un “pachino” abbiamo riflettuto a ruota libera su quanto sperimentato.

Semplici esercizi su una codebase “legacy” (non troppo rara da scovare anche nel lavoro quotidiano…) ci hanno permesso di toccare diversi argomenti, scoprendo o ri-scoprendo princìpi, “leggi“, code smells e design patterns che troppo spesso ci dimentichiamo di rispettare.

E’ stata una bellissima giornata, ricca di soddisfazioni, e speriamo che questo nostro piccolo contributo possa in qualche modo tornare utile a chi ha partecipato con tanto entusiasmo.

Conclusioni

Prima di tornare ognuno alle proprie case, Fabio ha ringraziato gli sponsor che hanno reso possibile la realizzazione di questa conferenza.
Dopo un breve spazio lasciato per la condivisione di quanto appreso in questa giornata, Fabio ha ricordato i prossimi appuntamenti:

• Italian Agile Days 2018, che si terranno a Brescia il 9 e 10 Novembre.
• La conferenza DevOps Heroes, che si terrà  il 20 Ottobre a Parma, ora nell’insieme degli eventi di Agile Venture. Evento prettamente tecnico, dove il nostro Gianni terrà un workshop :).

Bene, direi che è tutto, quindi alla pros…ehi, fermi. Se questo primo Agile Venture a Prato è riuscito bene (e fidatevi, lo è stato davvero), è grazie all’impegno e la simpatia di tutto lo staff perciò, ancora una volta, diamo spazio alle immagini 🙂

Grazie davvero Prato, appuntamento al prossimo Italian Agile Days!

Io e i miei colleghi ci saremo, sempre pronti all’avventura e a qualche brindisi 🙂

Colgo l’occasione per ringraziare Damiano, Nando (detto Ferdinando 🙂 ) e Fabio per i loro contributi alla stesura di questo articolo.

Ciao!