Home
DevOps: il lavoro delle persone, e delle aziende, non è più quello di una volta

27 Gennaio 2020

DevOps: il lavoro delle persone, e delle aziende, non è più quello di una volta

di

Come cambiano, o almeno dovrebbero cambiare, il lavoro e il mindset dove le vecchie culture tradizionali di organizzazione e sviluppo trovano il coraggio di fare posto a quelle più evolute.

C’erano una volta gerarchie e reparti

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.

Una cultura piuttosto diffusa tra le aziende vuole 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. 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.

Da dove arriva DevOps

Superare il problema era in realtà 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. Da allora il movimento si è evoluto, 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, quindi più legata ai numeri e ai dati; in DevOps trovo ci siano tante lezioni della cultura Lean (di Toyota) e parecchia attenzione in piu all’economia d’impresa.

Mindset che cambiano, di chi lavora e anche dei manager

Il management non è una scienza esatta, rigida, e ogni azienda ha la sua storia, difficilmente comparabile con le altre. Provo però a enunciare in questo articolo tre temi che sono importanti rispetto alle difficoltà ricorrenti delle aziende che provano ad adottare DevOps:

Il primo tema è il più difficile e riguarda una forte eredità culturale. È presente soprattutto nelle aziende in cui c’è tanta burocrazia. l’attività di management di un flusso produttivo (gestirlo) non porta alcun valore aggiunto nei confronti del cliente finale. Mi spiego: quando un cliente scarica una app sul suo telefono, non ha alcun interesse a sapere come internamente l’azienda si è organizzata a fare quel prodotto (eccetto rare nicchie di mercato).

Come si è evoluto DevOps nelle aziende e attraverso le persone

Le idee DevOps si sono evolute, sì. Si è visto 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 vero e proprio.

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

C’è una cosa che però mi fa sorridere, è che queste idee a dire il vero non sono nuovissime: 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.

La ragione di (non) esistere del management

Il management potrebbe anche non esistere. Pensa a un artigiano individuale che realizza un piccolo sito; è quando la dimensione produttiva diventa maggiore, o il problema più complesso da risolvere, che servono metodi più sofisticati di gestione del lavoro. Al cliente però interessa che il prodotto funzioni correttamente e alla fine, per funzionare, il codice qualcuno lo deve pur scrivere: la mano di uno o più programmatori. Il software in funzione è il risultato del processo produttivo, ed è la pasta di questa ricetta. Tutto ciò che succede in mezzo e che non concorre all’impastare, non aggiunge alcun valore diretto alla soluzione.

Il management è una infrastruttura che serve affinché questo processo funzioni bene e in maniera efficiente. per cui è un costo che il cliente sostiene perché noi abbiamo deciso di produrre in quel modo, ma non aggiunge valore alla soluzione finale. Questo cambio di mentalità è importante: il management serve la produzione, non il contrario. Deve far sì che chi produce possa lavorare al massimo delle sue capacità e possa prendere decisioni quando serve.

Nel lavoro intellettuale, chi ha la quantità di conoscenza più completa e interessante sono proprio gli operativi (passatemi il termine), coloro che hanno le mani in pasta nelle attività di realizzazione della soluzione. In queste culture c’è molta delega e responsabilità a tutti i livelli: la vecchia economia pensa un manager gestisce 100 risorse, nel Lean si dice che un manager lavora per 100 persone. È un cambio di prospettiva notevole.

Non c’è DevOps se ci si limita a cominciare

Il secondo tema sulle difficoltà dell’adozione di DevOps riguarda il partire bene e poi fermarsi lì. Spesso copiando esperienze altrui (come Scrum o come il modello Spotify); 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 a Scrum ad esempio è lunga poco più di una ventina di pagine. Si possono leggere velocemente, no? e poi si passa a fare esperimenti enormi, iniziare grandi trasformazioni miracolose. Non funziona così. In Italia c’è una grande quantità di aziende che viene dal mito più cose fai contemporaneamente più sei bravo, e questo, in particolare con il software, è quasi sempre antieconomico.

Se faccio lavorare le mie persone con Scrum, ma in cinque o sei team diversi nello stesso momento, torno a fare quello che facevo prima (o peggio) anche se chiamo le riunioni in un modo diverso. Non c’è nessuna magia nei metodi Agile e in DevOps. Scalfita la superficie di valori, ritmi e principi c’è da studiare: nessuna metodologia sostituisce anni di studio personale e individuale.

Il terzo tema, parlando di adozioni difficili di DevOps, ha a che fare con il software. I metodi Agile 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 processo. Ovvero, il come organizziamo la gestione degli X passi produttivi previsti. Il bello dei metodi Agile è che sono un modo ragionevole di lavorare per processi in generale, a prescindere che si faccia software o no.

Il pericolo di non assumere i tecnici e i programmatori

Questa cosa, siccome generalmente funziona meglio di altre, contamina virtuosamente un po’ tutti gli ambiti aziendali e la voce che lavorare con certe pratiche e valori sia più conveniente si diffonde, così che tutti lo vogliono imparare. Ma quando il processo diventa accettabile emergono i problemi tecnici. A quel punto servono professionisti eccellenti, che sappiano programmare bene e che spacchino il bit in quattro, per fare DevOps. Non è raro infatti vedere usati i metodi Agile in gruppi a grande componente gestionale, di controllo, strategica, di marketing, ma con un numero ridotto di tecnici (programmatori, sistemisti…).

In Italia c’è una grande parte di aziende che ha prosperato in altre epoche e ha sempre lasciato fuori dalle proprie mura 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 con la salute fragile, difficilmente rimpiazzabile quando mescolato nei processi produttivi aziendali. Se ci fai 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.

Nuove figure professionali e nuovi skill in quelle tradizionali, grazie a DevOps

Nel DNA del lavoro dell’informatico c’è l’imparare continuamente. Però da qualche anno si vedono titoli di lavoro come DevOps Engineer e alcuni, forse un po’ cinicamente, dicono che questa figura non esiste; forse è vero perchè non c’è una definizione precisa da dare (fa molto marketing però).

Job title e scherzi a parte, il programmatore che sposa i principi di DevOps oggi è in grado sia di costruire software in modo iterativo e incrementale, sia di modificarlo in tempi rapidi (minuti, ore), cosa che risolve problemi di efficacia del business e fornisce dati per prendere decisioni ulteriori.

Dal punto di vista del sistemista che si becca il software da eseguire, c’è la capacità di comporre infrastrutture che portino il codice al cliente (in produzione si dice). Si chiama pipeline di rilascio e sta a metà tra la programmazione di software e quella dei sistemi.

Dal punto di vista tecnologico, oggi questo è rappresentato dalla conoscenza di tecnologie considerate moderne come flussi leggeri di controllo del codice, automazione dei rilasci, gestione automatica della qualità, orchestrazione e gestione dei cloud, linguaggi di programmazione moderni (oltre l’object-oriented) e via dicendo.

Come lavorano programmatore e sistemista su una applicazione per il cloud

Detta approssimativamente, disegnare un’applicazione per il cloud significa poterla trasportare da un’infrastruttura all’altra e poterla eseguire potenzialmente su una scala infinita e non manovrabile a mano centinaia, migliaia di istanze. Il programmatore si concentra quindi a risolvere i problemi del cliente, ma potenzialmente ciò che realizza potrebbe andare ovunque: è una bella semplificazione del lavoro. Il ruolo del sistemista poi è di abilitare questa risoluzione mettendo in funzione le cose.

C’è corresponsabilità ovviamente tra le due parti, però direi che il lavoro del sistemista oggi si è fatto più difficile, spostandosi verso il software engineering vero e proprio. Usare una piccola infrastruttura oppure un cloud pubblico è una cosa, costruire pezzi di un cloud invece è un lavoro molto complesso, che richiede conoscenze di dettaglio molto ampie.

unsplash-logoImmagine di apertura di Tim Marshall

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.

Iscriviti alla newsletter

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
Mora-Agile_Sviluppo_e_Management-home2 Corso In aula

Agile, sviluppo e management: iniziare bene

con Fabio Mora

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.

corso-data-governance Simone Aliprandi Corso Online

Data governance: diritti, licenze e privacy

con Simone Aliprandi

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 paura di prendere la decisione sbagliata, il corso di Simone Aliprandi fa per te.

Comunicazione-digitale-food-wine-cover Corso Online

Comunicazione digitale Food & Wine - Iniziare Bene

con Barbara Sgarzi

Per il settore enogastronomico le reti sociali sono una grande opportunità per raccontarsi e trasmettere la qualità di un prodotto o di un locale. Se vuoi capire come farlo al meglio, il corso di Barbara Sgarzi può aiutarti.


Libri che potrebbero interessarti

Tutti i libri

DevOps

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

34,90

49,89€ -30%

28,41

29,90€ -5%

19,99

di Fabio Mora

L'arte del Rilascio

Progettazione e deploy di software che funziona

41,15

59,89€ -31%

33,16

34,90€ -5%

24,99

di Michael Nygard

Clean Agile

Guida per riscoprire i principi cardine dello sviluppo agile di software

27,15

39,89€ -32%

21,76

22,90€ -5%

16,99

di Robert C. Martin


Articoli che potrebbero interessarti

Tutti gli articoli