Formazione scritta DevOps

Come introdurre DevOps nella tua organizzazione?

Il modo in cui avvii il percorso DevOps nella tua organizzazione determinerà il successo dell'iniziativa. Conviene quindi sfruttare al meglio la prima occasione, che potrebbe essere anche l'unica.

Eviti il big bang e parti in piccolo

Come sai, non puoi stravolgere la situazione in un colpo solo e annunciare una trasformazione DevOps dell'organizzazione il primo giorno. Individua innanzitutto i team che si confrontano di continuo con problemi e obiettivi mancati, che riconoscono la necessità di migliorare e che sono più aperti a un modo di lavorare diverso. Cerca team pienamente disposti a servire l'organizzazione e i clienti.

Mostra subito risultati concreti

Il tuo compito è mostrare risultati positivi fin dalle prime fasi dell'iniziativa DevOps e dimostrare a chi è scettico o contrario quali problemi risolvi e quale valore crei con DevOps. Poi replicherai gradualmente i miglioramenti nelle altre aree dell'organizzazione.

È più o meno così che un produttore tedesco leader nel settore ERP, CRM e SaaS ha iniziato il percorso DevOps. Il team di manutenzione faceva un solo rilascio l'anno. Questo portava rapidamente ad accumulare codice non rilasciato in diversi rami dedicati agli incidenti. Integrare il codice e pubblicare aggiornamenti di manutenzione affidabili e completamente testati diventava estremamente difficile.

Per prima cosa, il team di sviluppo della manutenzione è stato unito ai team di pianificazione dei rilasci di manutenzione, assicurazione della qualità e gestione degli ambienti operativi. Hanno anche iniziato a usare un sistema comune per gestire attività e ticket, semplificando coordinamento e comunicazione. Poi hanno introdotto rilasci mensili e, poco dopo, quindicinali.

Nel primo anno della nuova pratica, il team di manutenzione è riuscito a risolvere 6 volte più incidenti rispetto all'anno precedente. Altrettanto importante, la percentuale di incidenti riaperti e del relativo lavoro da rifare è scesa dal 39% al 4%.

Grazie a questo miglioramento significativo e alle metriche che lo dimostravano, una piccola iniziativa DevOps ha guadagnato sostegno e credibilità nell'organizzazione e l'appoggio della direzione per estendersi ad altri team di prodotto e servizio.

Individua un prodotto e servizio greenfield o brownfield adatto

Quando avvii un'iniziativa DevOps, valuta anche se scegliere un prodotto e servizio greenfield o brownfield.

Un prodotto e servizio greenfield è nuovo per l'organizzazione. Ti conviene creare un nuovo team separato che lavori in autonomia, soprattutto all'inizio. Grazie a questa separazione, il team potrà più facilmente cambiare le abitudini e pensare in modo originale. Si spera inoltre che le responsabilità precedenti causino meno interruzioni. Assegna al nuovo team DevOps metriche di prestazione IT e aziendali e risultati concreti, come un aumento delle vendite, un maggiore coinvolgimento dei clienti o tempi di rilascio ridotti. Poiché l'iniziativa greenfield non dipende da codice e dipendenze legacy, partire con successo comporta meno rischi per te e il team. Tuttavia, il successo avrà un impatto minore nell'organizzazione, perché l'iniziativa non dimostrerà se DevOps può risolvere problemi esistenti o se i risultati sono replicabili in altre aree.

Puoi anche iniziare con un prodotto e servizio brownfield. Molti prodotti e servizi brownfield sono già operativi in produzione e servono l'azienda e i clienti. Se anche tu vivi sul nostro stesso pianeta, è molto probabile che l'applicazione abbia un debito tecnico significativo e pochi test automatizzati affidabili. Per questo avviare DevOps con un prodotto e servizio brownfield può essere più difficile, ma i risultati positivi saranno più gratificanti, convincenti e incisivi nell'organizzazione.

DevOps è adatto anche alle grandi organizzazioni con molti sistemi legacy in funzione

Molti credono a torto che DevOps non sia adatto a prodotti e servizi brownfield. Alcuni arrivano a pensare che sia riservato alle startup. Eppure alcune delle iniziative DevOps più esemplari sono nate in aziende con organizzazioni IT enormi e mature, innumerevoli sistemi legacy critici e migliaia di dipendenti. Amazon, Easy e Facebook sono alcuni esempi. Come mostra il caso del produttore SaaS, puoi introdurre DevOps anche in un'organizzazione esistente con prodotti e servizi brownfield. Anzi, poiché per molti di questi prodotti e servizi c'è un divario rilevante tra prestazioni e aspettative dei clienti, sono spesso i candidati ideali per beneficiare della trasformazione. Per avviare un'iniziativa DevOps brownfield, investi prima del tempo per eliminare o almeno ridurre il debito tecnico e poi automatizza i test mancanti delle funzionalità e dei vantaggi esistenti. Altrimenti il prodotto e servizio brownfield non ti permetterà mai di eseguire deployment affidabili in produzione con cicli più brevi.

Individua un sistema di registrazione o di interazione adatto

Per la prima iniziativa DevOps puoi scegliere un sistema di registrazione o di interazione. I sistemi di registrazione sono centralizzati e gestiscono un'unica fonte di verità per l'organizzazione. Si occupano soprattutto dei dati, compresi quelli relativi a clienti, transazioni, sicurezza e privacy. I sistemi di interazione sono applicazioni perlopiù decentralizzate che consentono e incoraggiano clienti e utenti a interagire con l'organizzazione attraverso portali responsivi omnicanale o applicazioni per dispositivi mobili, tablet e computer.

Scegliendo un sistema di registrazione, potrai dimostrare che il team DevOps sa gestire compiti lunghi e molto burocratici, come conformità, sicurezza e privacy. Tu e il team lo fate producendo prove scientifiche e concrete e usando test automatizzati e telemetria per tutto il ciclo di sviluppo e gestione del prodotto e servizio. Un esempio è migrare nel cloud dati distribuiti geograficamente dai server di database locali, garantendo che l'unica fonte di verità resti conforme alle norme e ai regolamenti di legge, di settore, locali e internazionali.

Con un sistema di interazione, invece, dimostrerai quanto rapidamente e affidabilmente riesci a innovare con cicli di rilascio brevi. Oggi gran parte delle innovazioni visibili che portano al successo commerciale nasce infatti da questi sistemi. Un esempio è rendere più intuitiva e semplice la procedura di acquisto nel portale e-commerce, con un aumento delle vendite del 25%. Se ci riesci, i dirigenti apprezzeranno tanto DevOps quanto il tuo contributo.

Come realizzare una trasformazione DevOps di successo

All'inizio del percorso DevOps, non perdere tempo a conquistare i team conservatori. Individua i team più innovativi, aperti, ben collegati e influenti che credono nella necessità della metodologia e dei principi DevOps. Parti in piccolo con uno o due team. Seguendo i suggerimenti precedenti, individua il prodotto e servizio greenfield o brownfield più adatto e il sistema di registrazione o di interazione con cui partire.

Dopo i primi risultati positivi, questi team saranno i tuoi maggiori sostenitori nel diffondere DevOps in tutta l'organizzazione. Poi estenderai la collaborazione ad altri gruppi e aumenterai il numero di casi di successo. I risultati consolideranno la credibilità e la fiducia nell'iniziativa DevOps. Vedendo i vantaggi misurabili, anche la direzione ti darà più sostegno, attenzione e risorse.

Nella fase finale individua chi, pur avendo influenza, ostacola l'iniziativa o vi si oppone fermamente (i Curmudgeon). Puoi probabilmente superarli usando la loro stessa tecnica, cioè diffondere timore e mettere in evidenza i rischi. Spiega loro quanto male appariranno i loro team e prodotti e come diventeranno l'anello debole dell'organizzazione se si rifiutano di imparare e usare DevOps.

CONCLUSIONE

Guidare una trasformazione IT in un'organizzazione è difficile, anche nel caso di DevOps. Partendo in piccolo correrai pochi rischi. Ricorda però che uno dei compiti più importanti di chi guida un team, a inizio carriera o con esperienza, è motivarlo e mobilitarlo per migliorare le prestazioni dell'azienda e assumersi qualche rischio calcolato per la massima soddisfazione professionale.