Che cosa succede quando inseriamo DevOps in azienda

Aziende o individui: DevOps si applica a tutti

DevOps è una parola-cappello che racchiude un compendio di discipline e ramificazioni molto ampio. Non è una ricetta predefinita, ha tante sfaccettature e la definizione stessa è spesso plasmata dalle aspettative di chi osserva, dal suo lato.

Sistemisti e programmatori probabilmente saranno interessati a come costruire o usare le infrastrutture nel cloud e le applicazioni cloud-native, oltre ai metodi Agile, così come gli altri tecnici (tester, data scientist eccetera). Un product owner (responsabile di prodotto) potrebbe trovare interessanti gli aspetti iterativi e incrementali del lavoro, un manager quelli del Lean, strategici ed economici. Anche molti coach potrebbero essere interessati a espandere le loro competenze in sfere affini all’Agile che ben si incastrano in DevOps.

Ma anche un professionista individuale che fa software o lo personalizza è parte di questo mondo. Certamente, se non siamo inseriti in un’organizzazione, ci sono una serie di aspetti a cui saremo meno interessati. Ma è molto difficile che oggi si riesca a stare lontano dall’interazione con ecosistemi tecnologici moderni, che hanno regole di funzionamento, processi e piattaforme specifiche; si pensi a come viene distribuito oggi il codice, a GitHub o a Docker per esempio.

Per cui la comprensione di alcune pratiche ingegneristiche che sono in DevOps (già molte derivate dai metodi Agile) è certamente un investimento che viene ripagato incredibilmente in fretta. Direi di imparare bene la gestione del codice sorgente (con git ad esempio), le pratiche di test automatico del codice e il test-driven development, studiare un po’ cosa sono le cloud e come funzionano, i sistemi operativi (Linux prima di tutto) e che cosa vuol dire progettare un’applicazione cloud-native (nata per il cloud).

Ti direi però che il valore di DevOps è proprio la visione orizzontale di insieme che essa fornisce su una serie di tecniche e modi di lavorare, da cui poi siamo in grado di pescare gli spunti necessari. Poi indubbiamente tutti possono imparare qualcosa di più verticale: gli aspetti sono strategici, tattici e operativi.

Per avere il cambiamento bisogna accettare il rischio

Tempo fa Apogeonline ha pubblicato un intervento di Matt LeMay che lamentava una percentuale troppo ampia di aziende che abbracciano Agile solo a parole, per ritrovarsi alla fine dei conti con gli stessi problemi di partenza, irrisolti.

Vi è un rischio concreto che possa accadere così anche per DevOps. Ma una percentuale è rischiosa da azzardare, i dati con vera significatività statistica sono pochi e men che meno quelli che riguardano il panorama italiano nello specifico. Esistono degli indicatori statistici e dei report: i più famosi sono quello di Puppet e Splunk (State of DevOps) e il suo cugino di DORA e Google Cloud (Accelerate: State of DevOps); queste indagini però sono report realizzati in prevalenza da organizzazioni private (e c’è sempre un po’ quel bias di fondo… come quando si chiede all’oste se il vino è buono).

Un passo interessante e con un approccio molto più vicino a qualcosa di quantitativo e scientifico l’hanno compiuto dei ricercatori diretti dalla Ph.D. Nicole Forsgren, con uno studio i cui risultati sono illustrati in un libro che si intitola Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

Il peso dell’esistente nell’adozione di DevOps

A prescindere dalle percentuali però, sicuramente i processi di cambiamento (o transformation, come si diceva nella vecchia economia) sono sempre rischiosi. Mi spiego meglio: c’è una grande differenza a monte tra chi abbraccia questi modi di fare dal nascere e chi no, magari perché l’azienda è nata prima dei metodi stessi.

Per le aziende nuove e piccole di solito è più facile costruire qualcosa. Sono prive di sovrastrutture e creare da zero permette di partire da una pagina bianca. Le aziende giovani inoltre, spesso, hanno la necessità di dimostrare di essere in grado di produrre risultati tangibili, in tempi stretti, con pochi fondi e tassi di errore da contenere. Esigenze che spesso si trasformano in vincoli e anche in motivazione per chi accetta la sfida. I processi e le pratiche che propongono questi metodi nuovi sono un modo più economico ed efficiente per fronteggiare la complessità e abbattono una serie di miopie del passato.

Poi ci sono le aziende esistenti. Magari grandi, che hanno già conosciuto periodi di splendore passati, che sono nate con divisioni nette, gerarchiche, burocratiche in climi economici più semplici e meno frenetici. In questi casi l’organizzazione può avere molto da disimparare rispetto a quello che faceva prima. Il che ci frega 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 svolgere (i cosiddetti lavoratori della conoscenza).

Agile e DevOps solo se e dove serve

E poi ci sono moltissimi casi in cui Agile non è un cambiamento desiderato o motivato da un’esigenza specifica che ci ricompensi. In realtà questo accade per tutti i fenomeni in cui c’è un cambiamento da sostenere: andiamo dal dietologo e poi ci facciamo gli spuntini fuori pasto, ci iscriviamo al mensile della palestra e poi ci andiamo una volta sola… non è sbagliato fare così, se ci appaga, per carità, però si può dire che è irrazionale pagare il dietologo o l’abbonamento in palestra se non ci interessa il risultato.

Ci sono delle aziende che si affacciano su mercati non ancora frenetici (quelli regolate da norme e certificazioni ad esempio), dove il vero motivo di una trasformazione potrebbe non essere così afferrabile o comprensibile da crederci davvero. Magari perché ci sono miglioramenti differenti da raggiungere in altri ambiti aziendali più urgenti. In questo c’è anche una responsabilità di chi fa formazione e consiglia: molti consulenti propongono Agile come se fosse un proiettile d’argento e la soluzione a ogni male, a volte perché va di moda; ma bisogna dire che Agile non è la risposta a tutto. Sarebbe come se un farmacista fornisse a tutti il paracetamolo perché ne ha lo scaffale pieno.

Immagine di Austin Distel