Recentemente abbiamo intervistato Fabio Mora, esperto DevOps ed autore del libro “DevOps. Guida per integrare Development e Operations e produrre software di qualità”. In questa seconda parte dell’intervista Fabio ci spiega quali sono le difficoltà per le organizzazioni che vogliono usare DevOps e quali sono le sfide che DevOps può aiutare ad affrontare.
Quali sono secondo te le difficoltà più grandi per le organizzazioni che vogliono utilizzare DevOps?
Ogni organizzazione ha una storia a sé ed è difficile paragonarle, provo però a dirti qualcosa che vedo frequente, in particolare modo in Italia.
- Una forte eredità culturale. Questo riguarda in particolare le aziende esistenti, soprattutto quelle in cui c’è tanta burocrazia. Ma ci sono anche casi in cui un’azienda nasce e il management cerca di riapplicare modelli della vecchia economia. Le aziende esistenti, magari grandi, che hanno già conosciuto periodi di splendore passati, sono nate con divisioni nette, gerarchiche, burocratiche e stagioni di mercato più semplici e meno frenetiche. In questi casi l’organizzazione può avere molto da “disimparare” rispetto a quello che faceva prima. Il che ci mette in difficoltà piuttosto spesso, perché smettere di fare una cosa che fino a ieri funzionava per iniziarne una nuova, di cui siamo sospettosi, che non sappiamo bene, è molto molto faticoso e stressante, a volte genera timore. Ha molto poco a che fare con il software e tantissimo con riconoscere che le persone sono centrali in qualsiasi discorso dove c’è del lavoro immateriale da fare (i c.d. lavoratori della conoscenza).
- riguarda il “partire bene” e… poi fermarsi lì – spesso copiando esperienze altrui (come SCRUM, come il “modello Spotify” o i framework come SAFe eccetera). Non c’è niente di male a imitare all’inizio, anzi è una buona partenza, ma poi bisogna andare oltre e imparare a camminare da soli e perseverare continuamente, facendo esperimenti piccoli. La guida di SCRUM ad esempio sono una ventina di pagine, si possono leggere velocemente 20 pagine, no? E poi si passa a fare esperimenti enormi, iniziare grandi trasformazioni miracolose. Non c’è nessuna magia nei metodi agili e in devops – scalfita la superficie di valori, ritmi e principi c’è da studiare e impegnarsi: nessuna metodologia sostituisce anni di studio personale e individuale.
- Ha a che fare con il software (visto che parliamo di software). I metodi Agili sono nati per fare il software e questo tante volte ce lo dimentichiamo perché nel calderone c’è un elemento che può essere trasportato un po’ ovunque: il miglioramento dei processi. Il bello dei metodi Agili è che sono un modo ragionevole di lavorare in generale, a prescindere che si faccia software o no. Questa cosa, siccome generalmente funziona meglio di altre, contamina virtuosamente un po’ tutti gli ambiti aziendali e si diffonde la voce che lavorare con certe pratiche e valori sia più conveniente… e tutti lo vogliono imparare. Ma quando il processo diventa accettabile emergono i problemi tecnici. A quel punto servono professionisti eccellenti e che sappiano programmare bene e che “spacchino il bit in quattro”, per fare DevOps. Non è raro infatti vedere usati i metodi agili in gruppi a grande componente gestionale, di controllo, strategica, di marketing, ma con un numero ridotto di tecnici (programmatori, sistemisti…). In Italia in particolare c’è una grande parte di aziende che ha prosperato in altre epoche, e che ha sempre fatto in modo di disinteressarsi e lasciar fuori dalle proprie mura aziendali coloro che scrivono codice come programmatori, sistemisti e analisti, magari affidandosi a società di consulenza e “gestendo” da lontano il loro software per “progetti”. È il risultato di una cultura in cui il valore produttivo del software non è mai stato davvero considerato come un asset strategico in senso economico (capitale produttivo), ma solo come una mera voce di costo. Invece è un investimento eccome, dalla vita assai complessa e dalla salute fragile, difficilmente rimpiazzabile quando mescolato nei processi produttivi aziendali. Se ci fate caso nel “dna” di molte dot-com (che ancora oggi dominano il mercato) c’è una gran presenza di dipendenti tecnici, mentre la consulenza ha un ruolo quasi marginale. In italia è il contrario da tempo e ci siamo già un po’ scottati, gli insegnamenti dei tempi di Olivetti sono scivolati via.
Però fortunatamente c’è un trend in controtendenza: anche la “vecchia economia” e le grosse aziende oggi si vedono, timidamente, cercare tecnici e programmatori da assumere. È positivo, ma bisogna far presto, perchè è un po’ come se si iniziasse a investire su quelle competenze da oggi, mentre concorrenti hanno già percorso diversi giri di pista e i buoi hanno iniziato a scappare da un bel pezzo.
Quali invece le sfide che DevOps può aiutare ad affrontare?
I processi produttivi del software tradizionali prevedono (in genere) che per una certa data, magari lontana mesi, ci impegniamo a fissare il numero di funzionalità (requisiti) da realizzare, stimando i tempi e le risorse necessarie a farlo. Spesso però le previsioni sono inesatte, allora per consegnare iniziamo a ridurre la qualità, facciamo dei pasticci con il codice sorgente, oppure sforiamo i tempi o le risorse. I metodi Agili, di cui DevOps è naturale evoluzione, girano la questione e dicono: facciamo il massimo possibile di cose con un piccolo quantitativo di risorse e tempo a disposizione fisso. Non ci promettiamo di fare tutto quello che vorremmo in un unico grande passo; ordiniamo per importanza le funzionalità da realizzare, riducendo la lunghezza dei passi da fare e completando una cosa alla volta. In questo modo il software si può vedere in funzione da subito, non alla fine di diversi mesi. Se parliamo solo di infrastrutture e sistemi invece l’obiettivo fondamentale di devops è accorciare il tempo che trascorre dall’idea di realizzare qualcosa al suo arrivo al cliente. Quante volte rilasci alla settimana? Quale percentuale di rilasci ha successo? Se queste due metriche migliorano, allora state facendo DevOps.
