di Nicole Forsgren & Abi Noda
Quando Nicole Forsgren pubblica una ricerca, un libro o un articolo, io mi aspetto un libro ricco, con dati, tabelle e ispirazione. Frictionless non ha disatteso le mie aspettative, ma non aspettatevi un libro AI-centrico, i soggetti sono le frizioni e la developer experience. Non scappate, arrivate alla fine perché — spoiler — questo libro merita lo stesso la vostra attenzione.
Dietro questo libro ci sono due persone con credenziali difficili da ignorare:
Nicole Forsgren, sicuramente una delle menti più importanti e autorevoli nel campo DevOps e della produttività degli sviluppatori. È autrice del libro “Accelerate: The Science of Lean Software and DevOps”, a parer mio uno di quei libri assolutamente da leggere e comprendere. Oltre a questo, è anche la mente dietro le DORA.
Abi Noda, sviluppatore e imprenditore concentrato nell’aiutare le organizzazioni a migliorare la produttività degli sviluppatori.
E in Frictionless analizzeranno il vero significato della DevEx e perché sia fondamentale smettere di misurare la produttività con le solite metriche e guardare a qualcosa di più profondo.
Frictionless nasce da una collaborazione con centinaia di team di sviluppo, alcuni con ampio uso di AI e altri no. Il risultato? Le organizzazioni ad alte prestazioni, quelle con deploy frequente, tempi di rilascio brevi e bassi tassi di failure, si distinguono per un fattore: una solida DevEx.
La DevEx è la realtà quotidiana dello sviluppo software: le difficoltà che gli sviluppatori affrontano, i flussi di lavoro che gestiscono e il supporto che ricevono. Quando la DevEx è scadente, anche gli strumenti e i processi migliori risultano inadeguati. Ma quando viene misurata e migliorata intenzionalmente, le organizzazioni liberano il pieno potenziale dei loro sviluppatori. Con l’avvento dell’AI la DevEx diventa ancora più critica e importante.
Il libro è diviso in sei parti:
- la prima, vi consiglio di non saltare queste pagine che fanno da fondamento all’intero libro, è dedicata alla DevEx e l’obiettivo è chiaro: avere un’idea ben precisa di che cosa sia. La definizione viene affrontata attraverso la “riduzione delle frizioni”, perché è un vantaggio competitivo, ed esamina quali sono le tipiche frizioni che rallentano la software delivery.
- la seconda mette a disposizione un framework per capire come rimuovere le frizioni che che impattano sul business: gli sviluppatori non possono spendere le proprie energie combattendo gli strumenti, nell’attesa di feedback o cercando di capire processi complessi, lasciandoli di fatto senza energie per innovare o risolvere problemi.
- la terza spiega come molte iniziative DevEx non falliscono per mancanza tecnica, ma per incapacità di comunicare che una DevEx migliore significa un business migliore; qui si trovano gli strumenti per farlo.
- la quarta, la presentazione della “7-step methodology for implementation”: migliorare la DevEx non è una cosa che capita per caso, ma un processo sistematico.
- nella quinta parte, l’attenzione si sposta dal processo sistematico al renderlo sostenibile, perché le iniziative per migliorare la DevEx hanno tre caratteristiche: garantiscono e blindano le risorse necessarie per crescere, creano assetti organizzativi capaci di sostenere l’evoluzione continua e sviluppa soluzioni tecnologiche con una visione di prodotto che punta alla sostenibilità nel tempo.
- una sesta parte — in realtà qui troverete un link che rimanda al materiale online — dedicata a un workbook che include template, strumenti di valutazione ed esercizi pratici. Viene citata spesso nel libro; il mio consiglio è di averla sotto mano durante la lettura.
Cos’è la Developer Experience e perché è importante?
La DevEx non è solo rendere gli sviluppatori felici, ma è rimuovere le frizioni che rallentano l’intero business; cattura la qualità delle interazioni che gli sviluppatori hanno con gli strumenti, i processi e le persone con cui hanno a che fare per poter svolgere il loro lavoro. Una buona DevEx è la rimozione sistematica delle frizioni affinché gli sviluppatori possano creare valore e avere impatto.
Le fondamenta della DevEx sono: la gestione del carico cognitivo, l’ottimizzazione del feedback loop e la preservazione del flow state.
Per carico cognitivo si intende la quantità di processi mentali richiesti da uno sviluppatore per portare a termine un task. Un carico cognitivo eccessivo non permette di generare valore.
Un feedback loop veloce aiuta a capire se il codice funziona e se l’idea è buona, soprattutto preserva il processo di sviluppo evitando frustrazione e ritardi, rischiando scorciatoie pericolose come review frettolose o integrazione di nuovo codice senza test.
Il flow state è quello stato di concentrazione e produttività che ti fa perdere il senso del tempo. Stare “nel flow” il più possibile è cruciale per risolvere problemi, debuggare o attivare la creatività.
Gli autori sottolineano come le fondamenta siano importanti separatamente, ma allo stesso tempo si rinforzino a vicenda: un feedback loop efficace permette di mantenere lo stato di flow, ridurre il carico cognitivo aiuta ad entrare nel flow state.
Attenzione: queste sono caratteristiche ancora più importanti quando abbiamo a che fare con le AI generative.
La DevEx non è solo un tema di produttività, ma anche un problema di impatto sull’azienda, perché un problema in produzione può nascondere un ambiente di sviluppo che non aiuta nel rilevare gli errori, processi manuali o mancanza di test. Quando gli sviluppatori riescono a generare codice in pochi minuti ma i deployment richiedono ore, o quando l’IA suggerisce decine di soluzioni che l’infrastruttura di test non è in grado di validare tempestivamente, il collo di bottiglia si sposta: il problema non è più creare, ma validare e rilasciare.
Cosa sono le frizioni?
Le frizioni sono qualsiasi cosa che rallenta o si frappone al completamento di un lavoro. Possono essere processi poco chiari, documentazione mancante, strumenti complicati e mancanza di automazione. Le frizioni possono uccidere la produttività, l’efficienza e qualsiasi tipo di miglioria portata dall’AI. Nel libro vengono elencate le frizioni più comuni — sono sicura che le abbiate provate almeno una volta nella vostra vita lavorativa — come: attrito nella fase di onboarding, mancanza di sufficiente astrazione nel codice, processi che richiedono troppe approvazioni o troppe iterazioni, code review che durano giorni, test suite inaffidabili, build interminabili e automazioni incomplete.
Gli autori sono chiari: eliminare queste frizioni crea immediato valore di business, e i tre fondamenti della DevEx sono la bussola per trovarle.
7-step methodology for implementation
Nel libro vengono citati diversi framework, ma a questo in particolare sono dedicate molte pagine, spiegazioni, esempi e chiarimenti.
Il processo è un cammino di 7 passi. I primi due spiegano come cominciare: piccole cose, quick wins, frizioni che impattano sul carico cognitivo, il flow state e il feedback loop. Il terzo e il quarto spiegano come usare i dati per misurare il peso delle frizioni e costruire un piano che parta da quelle più critiche. Nel quinto e nel sesto troveremo un piccolo trattato di come comunicare e collegare la DevEx ad un impatto di business. Infine nell’ultimo passo troviamo gli strumenti per valutare i progressi.
Le cose che mi sono piaciute di questo libro:
- l’incipit presente in ogni capitolo: autorevole, chiaro, sintetico ed efficace. Messi insieme costituirebbero un manifesto.
- Nel libro la sensazione è di non essere mai soli: informazioni, esempi e spunti concreti accompagnano ogni passo del percorso. Il workbook finale è la ciliegina sulla torta.
- esempi da “fatti realmente accaduti” che ti fanno sentire le cose più vicine di quello che sembrano
È un libro pensato principalmente per chi lavora nel campo dello sviluppo software, ma anche per chiunque voglia capire cosa si nasconde dietro un team che funziona bene.
Non abbiate fretta: è un libro denso di informazioni, domande, esempi, proposte, ha bisogno di tempo per essere letto e soprattutto per essere capito e assimilato; questo è uno di quei libri in cui tornare più e più volte, ma che comunque ogni volta ti aggiungerà un “aha” ai precedenti, che vi farà dire “ma certo, ovvio”, ma anche “ma perché non ci ho pensato prima?”.
Se siete arrivati fin qui, credo che abbiate già capito che questo libro merita un posto nella vostra libreria: intraprendere questo percorso giova agli sviluppatori, ma anche al business.
