Home
Le aziende devono cambiare per approfittare di DevOps, ma ne vale la pena

19 Novembre 2019

Le aziende devono cambiare per approfittare di DevOps, ma ne vale la pena

di

Vantaggi, avvertenze, conseguenze dell’adozione di una logica produttiva nuova e capace di portare competitività e produttività sorprendenti quando la si affronta con un approccio consapevole.

I pilastri CALMS di DevOps come pezzo di una strategia aziendale

L’obiettivo principale di DevOps è ridurre una metrica che si chiama time to market, il tempo che passa da quando abbiamo l’idea di voler realizzare un pezzettino di software per ottenere un determinato risultato, al momento in cui il tutto è stato consegnato nelle mani di chi deve lo deve usare.

Ci sono altre metriche, ma questa è la più importante e che si trascina dietro una serie di implicazioni non banali, e funge da catalizzatore per migliorare un gran numero di altri parametri: se siamo in grado di rilasciare (confezionare) un prodotto per il cliente molto velocemente e con pochi costi, saremo portati a farlo più spesso e con meno fatica; il che è un ottimo esercizio per migliorare e applicare interventi meno rischiosi. La definizione di fondamentali che mi piace di DevOps è quella dei pilastri CALMS, ovvero:

  • Collaboration: la possibilità per le persone di lavorare assieme verso un obiettivo condiviso; questa cosa si chiama team. Le persone devono disporre delle competenze per realizzarlo, ciò che si chiama cross-funzionalità. Quindi un vero team collabora anche alla tastiera o alla lavagna, oppure torna piuttosto a essere un gruppo di persone che lavora al suo compito, su cose simili. Fare software nel 2019 è un affare più di squadra che altro, non è più uno sport individuale da anni.
  • Automation: Va sfruttata il più possibile, perché le macchine sono più precise e più brave a eseguire compiti ripetitivi o rischiosi. Inoltre costano meno delle persone: ovviamente non vuol dire che le persone non servano, ma che devono spendere bene il loro tempo.
  • Lean: Toyota è un’azienda giapponese che ha inventato una filosofia di management innovativa e che coinvolge tutta l’organizzazione, la strategia, la tattica, l’operatività: la lean production e il Toyota Production System. Si può riassumere come un modo di costruire un’azienda che impara continuamente, e per questo dura negli anni. Si basa sulla riduzione di ciò che è spreco e sul miglioramento continuo: sul lavoro, quando si presenta un problema ci fermiamo a risolverlo e capiamo perché è successo così che piano piano, con il tempo, gli errori stessi siano meno frequenti.
  • Measurement: basare le decisioni sui dati è estremamente importante per valutare se quello che sto facendo funziona oppure no. Questa non è una novità, ovviamente. La novità è che diamo priorità e attenzione alle metriche che ci permettono di guardare i fenomeni nel loro insieme generale, appunto come se fossero un sistema. Non a caso prima abbiamo citato il time-to-market, che è una metrica estremamente larga.
  • Sharing: la condivisione importante da fare riguarda sia le responsabilità, che le conoscenze. I programmatori collaborano con i sistemisti, perché quello che è stato fatto funzioni; per anni la responsabilità di tenere in funzione le infrastrutture e i programmi è sempre stata solo di sistemisti. Questo modo di fare nasconde un sacco di insidie. Poi metriche e lezioni sul campo si possono condividere, così da migliorare e fare meno fatica come team. È il motivo per il quale gli atteggiamenti di protezione dei propri interessi non sono mai utili.

Se mi si chiedesse da dove partire per implementare una configurazione DevOps, risponderei di cercare un processo di lavorazione che già esiste, magari ripetitivo e automatizzabile, oppure che fa soffrire… e trovare un modo per migliorarlo un pochino. Prima va misurato e poi stabilito un obiettivo di miglioramento che deve essere ragionevole e raggiungibile. C’è sempre tempo per incrementare la difficoltà a posteriori. Fare poche cose alla volta, bene e piccole è molto lean. Può trattarsi di software da subito, oppure no. Alla fine il software risolve un problema. Se il problema a monte non vale il gioco, non servirà a molto risolverlo.

Guai ad adottare DevOps senza farlo veramente e nel profondo

Qualche 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.

C’è il rischio concreto che questa accada anche con DevOps, anche se è difficile stimare quanto frequentemente si verifichi. 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, a cui capo c’è la 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.

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.

Il tipo di azienda a volte fa la differenza anche se non dovrebbe

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 faticoso e stressante. A volte genera timore. Ha molto poco a che fare con il software e tantissimo con il riconoscere che le persone sono centrali in qualsiasi discorso dove c’è del lavoro immateriale da svolgere (i cosiddetti lavoratori della conoscenza).

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 regolati 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 non è la risposta a tutto, sarebbe come se un farmacista fornisse a tutti il paracetamolo perché ne ha lo scaffale pieno.

DevOps deve rassicurare le persone che se lo ritrovano in azienda

Ogniqualvolta si cerca di cambiare qualcosa ci sono rischi e resistenze e il rischio principale è di spaventare le persone. Motivazione e centralità delle persone sono a monte di tutto.

Rispetto alle ricompense, sono l’intento stesso ad esserlo. I processi tradizionali prevedono in genere che per una certa data, magari lontana mesi, ci si impegni a fissare il numero di funzionalità da realizzare, stimando i tempi e le risorse. Spesso però le previsioni sono inesatte e allora per finire in tempo tagliamo la qualità, oppure sforiamo i tempi o le risorse.

Agile e DevOps capovolgono la questione e dicono: facciamo il massimo possibile di cose con un piccolo quantitativo di risorse e tempo a disposizione fisso. Non ci intestardiamo a fare tutto quello che vorremmo, ma ordiniamo per importanza, riducendo la lunghezza dei passi da compiere. Le funzionalità devono essere pronte ogni settimana poco alla volta, non dopo mesi. Quindi il software si può vedere in funzione da subito.

Se parliamo solo di software e infrastrutture, poi, l’obiettivo fondamentale di DevOps è accorciare il tempo che trascorre dall’idea di realizzare qualcosa al suo arrivo al cliente. Quante volte alla settimana rilasci? Quale percentuale di rilasci ha successo? se queste due metriche migliorano, allora stai facendo DevOps.

Le migliori esperienze DevOps in Italia e all’estero

In Italia abbiamo realtà DevOps di tutto rispetto legate ad esempio al mondo dell’ecommerce, del gaming, dell’automotive, della sicurezza informatica, tra i grandi. Scendendo di dimensioni poi ci sono qualche piccola società di consulenza e un bel po’ di startup che provano a partire in questa direzione. A fare più fatica sono le aziende nei mercati in cui la velocità la dettano le norme e la burocrazia, come istituzioni, assicurazioni, banche e telecomunicazioni.

Ma più che le aziende in italia, direi che sono forti gli individui. abbiamo una community molto attiva, curiosa e interessata. I due gruppi di livello professionale più grandi sono GrUSP e Italian Agile Movement; ne potrei citare altri altrettanto eccellenti, ma questi due hanno un’attenzione incredibilmente elevata rispetto ai nostri temi.

Invece all’estero direi che le top-tier di prodotto hanno tutte una cultura DevOps, declinata in vari modi. L’esperienza di Google è quella che fa scuola, il loro modo di fare DevOps si chiama SRE (Site Reliability Engineering); hanno non solo miliardi di utenti, ma addirittura prodotti da miliardi di utenti. Chi invece proprio di DevOps ne vuole sapere, anzi, ma mette un punto fermo su alcune cose è Netflix: ha una cultura estremamente DevOps in realtà, ma si ferma solo allo sviluppo applicativo.

In seguito a un incendio in uno dei loro datacenter hanno deciso che non era il loro mestiere, loro volevano concentrarsi su altre cose, così hanno delegato la gestione delle infrastrutture ad aziende esterne (che a loro volta sono molto DevOps) oppure a operatori di telecomunicazioni cercando strategie innovative. Se interessa approfondire, c’è un bell’intervento in proposito di Dave Hahn, si chiama How Netflix Thinks of DevOps.

Quando un’azienda è fatta per DevOps e quando, invece, non ragiona sul lungo periodo

Che aziende si giovano maggiormente di DevOps? Sembra scontato dirlo, ma la prima prima caratteristica è che l’azienda faccia software, ovvero tra gli asset di produzione ci sia codice sorgente da qualche parte. Tutte quelle aziende che subiscono shock di mercato, incertezza su cosa realizzare, fluttuazioni di domanda, risorse disponibili, cambiamenti da fare in corsa possono sicuramente dare un’occhiata. Anche coloro che sono interessati a fare automazione.

Chi non se ne giova invece… beh, DevOps (come Lean) è nato per generare aziende sane e profitti nel lungo periodo, convenienti per tutti i coinvolti: clienti, investitori, lavoratori. Se non siamo interessati all’efficienza e alla salute nel lungo periodo di un’organizzazione, allora DevOps probabilmente non serve.

Un altro caso in cui può non servire è quando i problemi in gioco sono molto piccoli e già risolti; allora potrebbe essere antieconomico mettere in piedi tutta una serie di pratiche ingegneristiche di base e dei team. Se ad esempio sono un imprenditore che ha bisogno di creare un piccolo software di gestione di un piccolo magazzino, può essere che la soluzione migliore sia delegare tutto a una singola persona che si occupa di quello. C’è però sempre da ricordare che il software è modificabile nella misura in cui conosco come è fatto dentro: questo problema si chiama debito tecnico (o asimmetria informativa, in senso economico), per cui se quella persona abbandona improvvisamente il lavoro, magari sarà molto difficile modificare il software.

unsplash-logoImmagine di Ross Findon

L'autore

  • Fabio Mora
    Fabio Mora è un programmatore e Agile coach freelance entusiasta di Extreme Programming e Linux. Appassionato di open source, di economia e di tutto quello che riguarda la matematica e la scienza dei dati, ha prima fondato una web agency e poi lavorato in eBay come Software Engineer. Ama la musica, l’ingegneria del suono e la divulgazione scientifica.

Vuoi rimanere aggiornato?
Iscriviti alla nostra newletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.

Corsi che potrebbero interessarti

Tutti i corsi
big-_data_executive-home Corso In aula

Big Data Executive: business e strategie

Vuoi capire se e come la tua azienda può ottenere un vantaggio di business investendo in una strategia di creazione e analisi di Big Data? Il corso di Andrea De Mauro è quello che ti serve.

con Andrea De Mauro

Mora-Agile_Sviluppo_e_Management-home2 Corso In aula

Agile, sviluppo e management: iniziare bene

Non sei soddisfatto delle gestione dei tuoi progetti software? Vuoi scoprire come i metodi agili possono cambiare il tuo modo di lavorare? Il corso di Fabio Mora è quello che ti serve.

con Fabio Mora

corso-data-governance Simone Aliprandi Corso In aula

Data governance: diritti, licenze e privacy

I dati sono ovunque intorno a noi ma per poterli utilizzare in sicurezza bisogna confrontarsi con temi complessi che riguardano licenze, proprietà intellettuale e privacy. Se non ti senti sicuro o hai paure di prendere la decisione sbagliata, il corso di Simone Aliprandi fa per te.

249,00

Milano - 31/1/2020

con Simone Aliprandi


Libri che potrebbero interessarti

Tutti i libri

Agile per tutti

Creare organizzazioni snelle, flessibili e centrate sul cliente

22,50

32,89€ -32%

16,92

19,90€ -15%

12,99

di Matt LeMay

DevOps

Guida per integrare Development e Operations e produrre software di qualità

33,90

49,89€ -32%

25,42

29,90€ -15%

19,99

di Fabio Mora

Clean Code

Guida per diventare bravi artigiani nello sviluppo agile di software

44,00

63,99€ -31%

33,15

39,00€ -15%

24,99

di Robert C. Martin


Articoli che potrebbero interessarti

Tutti gli articoli