Cosa contiene una "Trasformazione DevOps"?

Alcune società di consulenza stanno promuovendo un servizio chiamato "DevOps Transformation". Molte grandi aziende parlano dell'argomento in occasione di conferenze e incontri in tutto il mondo.

Cosa comporta tale "trasformazione DevOps"? Come appare in termini attuabili, sia per trasformazioni riuscite, sia per fallite.

Devo inserire la mia risposta a questa domanda nel contesto di ciò che è DevOps, più specificamente all'interno delle trasformazioni DevOps di cui ho fatto parte, DevOps è la proprietà dell'intero ciclo di vita dello sviluppo software. Tutte le pratiche nel grafico sono una parte importante della DevOps, e attivare e sostenere sia Pensiero Sistemico e amplificazione dei cicli di feedback .

Tuttavia, il principale fattore di differenziazione tra CI / CD e DevOps è l'effettivo funzionamento del software in un ambiente di produzione, in cui può fornire valore ai propri clienti e al business che serve.

Come consulente che partecipa o guida una trasformazione DevOps ho in mente i seguenti aspetti:

• Cultura : come giustamente sottolineato da Dave, una cultura della sperimentazione e dell'apprendimento continui è fondamentale per il successo di ogni trasformazione. Dal punto di vista di DevOps, ciò si riduce al modo in cui creiamo una cultura che supporta il modello DevOps scelto, questo modello potrebbe essere "Costruiscilo, eseguilo" o potrebbe essere più in linea con la pratica dell'ingegneria dell'affidabilità del sito di Google .

• Modello operativo : questa è la parte della proposta commerciale che articola il modo in cui l'organizzazione fornirà valore, generalmente articolando persone, processi e strumenti utilizzati legati insieme ad alto livello. Senza un modello operativo, non hai un modello per il modo in cui l'organizzazione adotta le pratiche definite dalla cultura, questo, a sua volta, porta a una mancanza di chiarezza e comportamenti divergenti.

• Aircover di livello C : spesso è nostro compito come consulenti che lavorano nell'ambito dei programmi di trasformazione apportare cambiamenti radicali al modo in cui funzionano le imprese. Stai per sconvolgere le persone, e ad alcune persone non piaceranno i cambiamenti - è importante avere una "copertura aerea" dall'alto per cambiare le cose e andare avanti.

Una volta raggiunto l'alto livello, è importante trovare qualcosa che puoi realisticamente offrire:

1. Inizia il più piccolo possibile, idealmente, una volta che hai delle persone che capiscono la cultura, uno schizzo di un modello operativo e il buy-in da parte dei dirigenti creano il "Progetto minimo praticabile", non tentare di far bollire l'oceano introducendo DevOps ad un pubblico di migliaia. Stabilisci un obiettivo raggiungibile:
   • Automatizza la creazione dell'infrastruttura dal Prodotto X.
   • Automatizza la consegna del Prodotto X in Azure in tutti gli ambienti.
   • Supporto di restituzione da parte dell'outsourcer Y a un team di sviluppo a Londra.
   • Crea una serie di test intorno alla nostra funzione più rischiosa ed eseguili in continua integrazione.
2. Fantastico, hai un po 'di successo alle spalle, ora è il momento di iniziare a cuocerlo in più squadre, aggiungere un altro paio di squadre nel mix e metterle in funzione. Non abbiate paura di offrire "Supporto per guanti bianchi" all'inizio per assisterli nella transizione; avranno bisogno di molta mano nelle prossime settimane e mesi.
3. Ora hai diversi utenti adottivi che seguono un nuovo modo di lavorare; hai una massa critica, è tempo di iniziare a evangelizzare il lavoro che stai facendo con un pubblico più vasto:
   • Tieni sessioni di show-and-tell regolari per chiedere ai primi utenti di dimostrare il loro successo.
   • Offri sessioni drop-in per consentire ad altre parti dell'organizzazione di esplorare come possono entrare a far parte del tuo team.
   • Consentire la creazione di comunità di pratica incentrate su discipline specifiche: implementazione continua, test automatizzati, comunicazione aziendale, gestione dei rischi, monitoraggio e allerta, ecc.

4. Mantieni il corso e chiudi la trasformazione onboarding il resto dell'organizzazione. Comprendi la relazione tra il ciclo di hype di Gartner e il ciclo di vita dell'adozione . Preparati al programma di trasformazione per cadere nella "depressione della disillusione", mantieni la rotta e tieni in vista l'obiettivo finale.

   

Per un'esplorazione più approfondita del punto finale leggi Geoffrey A. Moore's Crossing the Chasm . Potrei letteralmente scrivere un libro su come consegnare una trasformazione DevOps, tuttavia, una volta terminata, probabilmente non ci sarebbe più nessun lavoro di trasformazione DevOps da svolgere.

DevOps tende a dividersi in tre dimensioni principali:

Cultura La
cultura di DevOps enfatizza alti livelli di fiducia, collaborazione e comunicazione tra tutte le parti interessate, in particolare Dev, Ops e Security. La naturale tensione e competizione tra questi gruppi crea attrito e spesso disfunzione. DevOps si occupa (probabilmente) innanzitutto di allineare gli sforzi tra questi team.

I processi di
sviluppo DevOps si allineano strettamente ai processi Agile. Ops è incoraggiato ad adottare pratiche simili ad Agile per allinearsi meglio agli sforzi del Dev. I processi allineati a DevOps sono progettati per supportare cicli ad alta velocità e feedback rapidi durante i cicli di vita di sviluppo / consegna. L'integrazione continua, la consegna continua e il miglioramento continuo (kaizen) sono aree di interesse del processo DevOps.

La tecnologia
DevOps non è uno strumento, ma è supportato da strumenti. Esistono intere famiglie di strumenti che supportano una vasta gamma di settori, tra cui l'integrazione continua, il controllo del codice sorgente e la gestione del ciclo di vita delle applicazioni.

Una "Trasformazione DevOps" deve indirizzare gli elementi di tutti e tre, ma non necessariamente tutti allo stesso tempo allo stesso tempo. Esiste una progressione naturale e un "percorso critico" per la trasformazione. L'argomento potrebbe essere avanzato, ad esempio, DevOps dipende da una qualche forma di pratica Agile, almeno all'interno del team / team di sviluppo. Potrebbe essere necessario affrontare i problemi relativi alla cultura prima di effettuare investimenti in attrezzature.

Riferimenti:
Cultura: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
Tecnologia: https://xebialabs.com/periodic-table-of-devops-tools/