Scopri DevOps e Agile: la tua azienda può funzionare meglio

Da dove nasce il movimento DevOps. Dal movimento Agile

La realizzazione di qualsiasi tipo di bene o servizio è fatta di una serie di passi produttivi. Un modo di fare software diffuso prevede degli esperti del problema che studiano le funzionalità, programmatori che le codificano, tester che controllano la qualità e alla fine ci sono i sistemisti, che mettono il tutto in funzione. È così che chi deve usare veramente il programma, lo può fare.

C’è una cultura piuttosto diffusa tra le aziende che dice di organizzare le persone per dipartimenti e aree di competenza molto specifiche, a volte con ampie gerarchie in mezzo. L’idea alla base è che se io sono molto bravo a fare il mio piccolo pezzettino, posso lavorare in autonomia fino ad arrivare a qualcosa di perfetto. Poi, quando ritengo di aver finito, passo la palla a chi viene dopo di me, che farà altrettanto per il suo, mentre io posso iniziare a fare una cosa nuova.

Questo modo di lavorare forse funziona bene in qualche contesto, ad esempio quando gli incastri sono semplici e sappiamo esattamente cosa dobbiamo fare. Il problema è che il lavoro di chi realizza software è fatto in gran parte di cose da imparare. Così quel modo di lavorare per produrre risultati, quando funziona, richiede sforzi eroici e una grande quantità di risorse per arrivare a qualcosa di accettabile.

Questo problema da superare in realtà era anche un po’ l’intento dei metodi Agile per lo sviluppo del software, che sono i progenitori di DevOps. Le mosse da compiere, nella forma più embrionale, sono da attribuire a un consulente di nome Patrick Debois, che alla Agile Conference 2008 di Toronto presentò un intervento chiamato Agile Infrastructure & Operations. Questo tipo di conferenze però in genere è fatto di un gran numero di persone con idee brillanti e che non stanno mai ferme, per cui il movimento si è evoluto, e di molto. Prima migliorando ciò che accadeva tra programmatori e sistemisti, poi includendo un po’ tutta l’azienda.

I metodi Agile sono un pezzettino del puzzle che spiega come fare bene il software da un punto di vista qualitativo. Per me le tecniche DevOps sono una evoluzione quantitativa del tutto, e quindi più legata ai numeri e i dati; in DevOps trovo ci siano tante lezioni della cultura Lean (di Toyota) e parecchia attenzione in più all’economia d’impresa.

Come funziona DevOps sul campo: i 5 pilastri CALMS

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 collaborazione passa per dare la possibilità alle persone di lavorare assieme per raggiungere un obiettivo condiviso; questa cosa si chiama team. Inoltre devono disporre delle competenze per realizzarlo, quella che si chiama cross-funzionalità. Quindi un team non è un team se non collabora anche alla tastiera o alla lavagna, ma torna piuttosto ad 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. le specialità individuali sono rarissime oramai.
• Automation: l’idea qui è sfruttare l’automazione in più possibile, perché le macchine sono più precise e più brave a eseguire compiti ripetitivi o rischiosi. Inoltre costano meno delle persone: non vuol dire che le persone non servano ovviamente, ma che debbano spendere bene il loro tempo.
• Lean: Toyota è un’azienda giapponese che ha inventato una filosofia di management innovativa e che coinvolge organizzazione, strategia, tattica, operatività: l’insieme di lean production e 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é e 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.

Da dove partire per implementare una configurazione DevOps

Si tratta di cercare un processo di lavorazione che già esiste, magari che è ripetitivo e si potrebbe automatizzare, oppure che fa soffrire… e trovare un modo per migliorarlo un pochino. Prima va misurato e poi occorre stabilire 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.

DevOps e Agile si sono evoluti. E con loro il lavoro in azienda

Si è visto negli anni che applicare i metodi Agile all’infrastruttura funzionava e allora sono nate un sacco di tecniche precise per farlo. Poi a suon di conferenze, letteratura e via dicendo è nato il movimento.

Nelle aziende medio/grandi c’era prima una netta separazione tra il lavoro del sistemista e quello del programmatore. Il sistemista aveva la responsabilità di tenere stabili e funzionanti i sistemi, il programmatore di inserire nuove funzionalità: e questa cosa è in tensione perchè di solito più tocchi una cosa, più c’è il rischio di destabilizzarla. DevOps supera questo limite, da sempre.

Ma il panorama è molto ampio, e oggi c’è grande impegno ad esempio sugli aspetti di sicurezza, oltre che nell’uscire da una sorta di schizofrenia dei cloud e trovare degli standard interoperabili per le infrastrutture; usando i cloud si pagano svariati compromessi, come quello del vendor lock-in o la riservatezza.

C’è una cosa che però mi fa sorridere, è che queste idee non sono nuovissime a dire il vero: i professionisti più navigati possono obiettare che in passato la figura che programmava lavorava a stretto contatto con chi metteva in opera il software, o ancora meglio, ne condivideva le competenze.

Con il boom dei linguaggi web molte persone hanno iniziando imparando sia a programmare che a configurare un server. Anche se magari preferivano un aspetto oppure l’altro, ma per loro i due temi non sono mai stati completamente estranei. Era necessario per fare un buon lavoro e portarlo a termine. Non c’è alcuna novità in questo. È la stessa idea, su una scala incredibilmente più ampia. L’idea che ha portato DevOps e Agile all’importanza che hanno oggi e li ha fatti nascere anni fa.