Se non sai cosa sia il DevOps, ecco un breve promemoria. DevOps è un insieme di pratiche che riduce le paure degli ingegneri e diminuisce il numero di guasti nella produzione software. Di norma, esse riducono il time-to-market — il periodo che va dall'idea alla consegna del prodotto finale ai clienti, permettendo di condurre rapidamente esperimenti aziendali..
Come avviare una trasformazione DevOps? In breve: scegliamo il servizio da cui iniziare il processo, identifichiamo le persone coinvolte nel servizio, costruiamo una Value Stream Map, creiamo un team temporaneo che si occuperà della trasformazione per il primo periodo e assegnamo loro un compito. Ripetiamo il ciclo il numero necessario di volte.
Un piano dettagliato per la trasformazione DevOps con esempi e istruzioni è disponibile nell'articolo a seguire Andrei Alexandrov — di un ingegnere della compagnia Express42, che offre consulenze per implementare DevOps, accelerando questo processo grazie alla mappatura delle difficoltà. Se pensi che la trasformazione non ti riguardi o che le pratiche DevOps non siano adatte alla tua specificità, utilizza il rapporto come guida per identificare e risolvere i vincoli.
Se hai preoccupazioni riguardo alla trasformazione DevOps, significa che hai una grande azienda e devi scalare gradualmente questo processo in tutta la struttura. Fintanto che c'è la necessità di trasformare il team o di risolvere qualche limitazione, l'algoritmo qui sotto può essere ripetuto.
Scelta del servizio
Piano definito, iniziamo con il primo passo: la scelta del servizio. Il primo criterio è la durata: ci sono servizi obsoleti - legacy, e nuovi. Si può iniziare sia con i vecchi che con i nuovi.
Scegliere un servizio giovane è logico. È fresco, non c'è ancora un processo di lavoro consolidato nel team che ci lavora. Non c'è un'enorme quantità di debito tecnico, non è necessario ripararlo continuamente. Possiamo fare tutto ciò che vogliamo con esso.
Nel caso di un servizio vecchio ci sono problemi legati al fatto che cambiare è sempre difficile. Ci sono già un certo numero di limitazioni significative, ma potrebbe esserci qualcuno che è già pronto a rivedere tutto — sono stanchi e vogliono fare le cose in modo diverso, perché stanno soffrendo.
Lavorare con un servizio vecchio crea un potente precedente nella vostra azienda - c'è spazio per dei cambiamenti. Se avete introdotto un nuovo servizio, questo va in produzione 100 volte all'ora e funziona bene, le persone nella vostra azienda potrebbero dire:
— Questo è un nuovo servizio! Prima era tutto semplice, provate a fare qualcosa con il nostro cocciuto.
Ha senso prendere in considerazione un servizio legacy per la trasformazione quando la si fa insieme a qualcuno, per esempio se avete invitato un consulente esterno. Siamo onesti, la trasformazione metterà alla prova tutto ciò che è possibile.. Stai sperimentando e non sai dove arriverai, quali tecnologie e perché utilizzerai, dove e quali insidie emergeranno nei processi. Quindi è più facile cambiare se è nuovo.
Se fai tutto tu stesso e in azienda non ci sono competenze solide, scegli un nuovo servizio. Se conosci un consulente esterno e hai i fondi - opta per quello vecchio.
Ci sono servizi che sono semplicemente un'interfaccia per utenti, come un sito semplice o un'app mobile. Ma ci sono anche cose serie come la fatturazione. Se qualcosa va storto con la fatturazione, sarà complicato risolvere il problema. Qui abbiamo anche una scelta.
Lavoriamo o con un servizio critico, ma già a causa di questo stiamo soffrendo, crea vincoli, o lavoriamo con l'interfaccia. Questo è il secondo criterio di scelta. Allo stesso modo, c'è la possibilità di coinvolgere un consulente esperto - lavoriamo con la variante complessa.
Ma anche in questo caso non lo consiglierei, perché, finché non c'è comprensione su cosa lavorare e in quale direzione trasformarsi, prendere qualcosa di critico e modificarlo - non è una buona idea. Pertanto, in questo caso preferiamo lavorare con l'interfaccia, il cui malfunzionamento non è critico.
Passiamo oltre al team del servizio. Con coloro che si occupano di questo servizio, dovremo lavorare costantemente e interagire in un contatto molto stretto.
Le persone nel team si dividono convenzionalmente in due categorie: conservatori - vivono nel vecchio mondo, oppure semplicemente non sanno nulla di DevOps, e innovatori, che portano tutte le pratiche alla moda. I secondi non sempre comprendono l'argomento, ma almeno sono pronti ad affrontarlo.
Da un lato ci sono i conservatori: persone esperte che sono in azienda da tempo e conoscono ogni cosa, ma non sanno esattamente come applicare le pratiche. Dall'altro lato ci sono gli innovatori, che hanno sentito parlare di qualcosa, ma probabilmente non lavorano in azienda da molto tempo. Con chi di loro è meglio lavorare?
Dovremo interagire con i conservatori in ogni caso, poiché questo è il loro servizio. Sarà necessario parlare con loro, comprendere la specificità del servizio e capire cosa si può fare e cosa no. Siamo dipendenti dalle loro consulenze. Sicuramente dovremo affidare loro dei compiti, perché conoscono meglio il loro servizio. Pertanto, è importante quale team alla fine avremo modo di contattare.
È logico scegliere gli innovatori per il team, perché i conservatori potrebbero ostacolare il progresso.
In pratica, spesso succede che le persone conservative abbiano una notevole esperienza, ma non comprendano come andare avanti. Hanno solo paura che, dopo la trasformazione e la riprogettazione del servizio, verranno licenziati per superfluità. A volte, semplicemente per mancanza di comprensione di ciò che sta accadendo, sabotano il lavoro.
Ho avuto un caso in cui un ragazzo del team riparava qualunque cosa, perché era suppostamente più critico di ciò che stavamo facendo in quel momento. Assegniamo un compito: implementare oggi questo pezzo - no, dall'altra parte del mondo c'è un incendio, andiamo a ripararlo. Lavorare con queste persone è difficile.
Le persone del team conservatore spesso trascurano i compiti o li rimandano fino all'ultimo. E se, Dio non voglia, commetti un errore e assegni loro KPI basati sul numero di compiti completati, mentre una parte non è inclusa nei KPI, allora non faranno niente. In effetti, avranno ragione perché perderebbero il premio.
Con gli innovatori è più semplice: sono più leali.Hanno già sentito qualcosa, vogliono andare da qualche parte, quindi saranno d'aiuto. Ci servono persone pronte a soffrire all'inizio: se il servizio cambia, tutte le difficoltà e le sfide ricadranno sugli innovatori come pionieri. Gli innovatori vogliono tutto ciò che è nuovo e alla moda, e sono pronti a soffrire.
I conservatori possono essere convertiti più tardi. Quando mostrerai che hai cambiato un pezzo e tutto funziona bene, probabilmente vorranno anche loro provare e accetteranno la nuova religione DevOps.
Riassumiamo. Se facciamo tutta la trasformazione internamente, scegliamo: un nuovo servizio, preferibilmente con un'interfaccia semplice, in modo da non soffrire troppo per eventuali malfunzionamenti, e un team di innovatori.
Se è possibile coinvolgere un consulente esterno, invece di adottare un nuovo servizio, utilizziamo quello vecchio, con cui già abbiamo delle difficoltà. Le persone che si sono occupate di trasformazioni in diverse aziende per un lungo periodo hanno visto casi differenti e comprendono già come procedere in modo corretto e quale direzione prendere.
Chi è coinvolto?
Dobbiamo trovare tutti coloro che hanno anche solo un minimo di relazione con il servizio: sviluppatori, tester, amministratori, professionisti della sicurezza, manager e, forse, Product Owners. Anche se i Product Owners non sono tecnici, hanno un ruolo nel servizio: prendono decisioni e impostano compiti.
Dobbiamo trovare, conoscere e comunicare con tutti coloro che prendono decisioni e influenzano ciò che accade al servizio.
A cosa ci servono? Per sapere con chi negoziare. Durante la trasformazione, quando il consueto modo di lavorare con il servizio cambia, ci saranno comunque delle difficoltà. Per un certo periodo si verificheranno guasti mentre testiamo nuovi approcci. Le persone devono essere pronte e accettare questo.
In seguito sarà necessario costruire la Value Stream Map e senza queste persone non sarà possibile, perché solo loro insieme conoscono il quadro completo. Un singolo individuo non conosce mai tutto ciò che accade con il servizio.
Possono consigliare persone per il team. Più avanti discuteremo del perché sia necessaria una squadra separata. Dobbiamo coinvolgere persone dai reparti esistenti. Coloro che hanno a che fare con il servizio potranno consigliare colleghi che la pensano come noi, in grado di aiutarci e con le competenze necessarie.
Successivamente riuniamo tutte queste persone da diversi reparti in una stanza e iniziamo a costruire la Value Stream Map.
Costruiamo la Value Stream Map
La Value Stream Map è un diagramma o una mappa che mostra il flusso di valore verso il cliente. È l'intero processo dall'ideazione fino all'implementazione, inclusi tutti i passaggi intermedi e come il valore alla fine arriva ai nostri clienti.
La Value Stream Map è necessaria per visualizzare tutte le fasi dello sviluppo, localizzare i problemi attraverso le misurazioni presenti nel processo attuale e iniziare a risolverli, e definire un obiettivo iniziale. È qui che iniziamo a fare qualcosa di concreto.
Metriche
Nella letteratura sul Value Stream Map vengono descritte molte metriche diverse, ma per iniziare ci bastano solo tre.
Lead Time — ritardo/attesa — è il tempo in cui aspettiamo qualcosa. Ad esempio, un tester aspetta che si liberi un banco per i test e in quel tempo non può fare nulla.
Value Added Time — tempo di lavoro utile — è il tempo speso in una certa fase per creare valore finale per l'utente. Ad esempio, il tester avvia il suo test e inizia a controllare qualcosa. Questo è il tempo di lavoro utile, quando stiamo effettivamente facendo qualcosa per il prodotto. È ciò per cui i clienti pagano: per un software di qualità.
%C/A — percentuale di lavoro accettato. Abbiamo una fase — sviluppo, una seconda fase — test. Quante funzioni i tester hanno accettato dagli sviluppatori e c'è questa percentuale.
Circa così appare la nostra mappa.
Può apparire diversa a seconda della struttura dell'organizzazione, del numero di reparti e di cosa si fa. Ma in generale, nella mappa ci saranno due fasi: idea e analisi. In questa fase ci si aspetta di avere dati, ad esempio, Lead Time 2 settimane e Value Added Time 2 giorni.
Copriamo metriche per tutte le fasi.
Backlog — quante attività sono rimaste dopo che gli analisti le hanno generate.
Sviluppo — quante settimane gli sviluppatori hanno atteso chiarimenti su attività, stand o attrezzature: non importa, ma stanno aspettando qualcosa. Ad esempio, per 4 giorni implementano una funzionalità. Qui compare la metrica %C/A. Gli sviluppatori hanno preso dal Backlog solo l'80% delle attività. Ritengono che il 20% rimanente non abbia un chiaro specificatione dei requisiti e lo hanno rimandato per ulteriori lavori.
Test. Nello schema LT sono previsti 4 giorni. Ad esempio, i tester hanno atteso la liberazione dello stand di test, VA 2 giorni stanno realmente testando qualcosa, e %C/A = 40%. — solo il 40% del codice o delle funzionalità che gli sviluppatori hanno inviato è stato ritenuto adeguato dai tester. Tutto il resto non è piaciuto per qualche motivo.
Non approfondirò come eseguire queste misurazioni; alla fine dell'articolo consiglierò della letteratura in cui si può approfondire.
L'unico consiglio che posso darvi è di non fidarvi delle persone che vi aiuteranno a creare una Value Stream Map. Possono indicare quanto tempo impiegano i vari processi, ma queste stime non sono sempre corrette; quindi è meglio misurare voi stessi.
Ci siamo trovati in una situazione in cui siamo andati nel reparto Operations e abbiamo chiesto quanto tempo ci volesse per portare una nuova funzionalità in produzione. Ci hanno risposto che ci volevano 10 minuti, e noi ci siamo chiesti perché fossimo mai entrati in questa azienda. Si è scoperto che i 10 minuti riguardano il tempo necessario allo script per prelevare il codice e inviarlo al server. Ma prima di questo, il rilascio rimane per tre giorni sul server a prendere polvere — c'è un'attività nel Backlog che deve essere distribuita. In pratica, prima della fase di deploy c'è una fase di attesa in cui il progetto rimane fermo. Se non fossimo andati con un taccuino, non avessimo notato l'attività in Jira e non avessimo iniziato a monitorarla passo dopo passo, avremmo pensato che tutto andasse benissimo e che non ci fossero problemi.
Pertanto, sarà necessario effettuare le misurazioni da soli, preferibilmente non una sola volta, per avere un'idea vicina alla realtà. A seconda della Value Stream Map, prenderete decisioni su da dove iniziare e cosa correggere per primo.
Team temporaneo
Molte aziende che hanno deciso di implementare DevOps creano un team che non è temporaneo, ma esiste da diversi anni. Se consultate il servizio DevOps apologize, che descrive diversi modelli di struttura organizzativa in DevOps, capirete che si tratta di un anti-modello.
Quando un team DevOps esiste continuamente per diversi anni, è un grande errore, perché DevOps riguarda la comunicazione tra i reparti, la velocità e l'efficienza.
Se un team esiste tra reparti solo per fare qualcosa di separato e dura a lungo, crea un ulteriore ostacolo. Ora il programmatore, invece di andare direttamente all'amministratore per risolvere un problema, deve prima contattare il reparto DevOps, che poi procederà.
Pertanto, per iniziare, è necessario creare un team temporaneo.. Avrà una durata approssimativa di sei mesi, al massimo un anno, a seconda dell'obiettivo stabilito, solo per rimuovere una limitazione che abbiamo scelto. Poi, terminerà. Se scegliamo il prossimo punto in cui abbiamo un forte dolore e comprendiamo che per quello ci serve un altro team, lo ricreeremo. Ma le squadre non dovrebbero esistere in modo 'permanente' — altrimenti disturbano la comunicazione e assumono compiti a sé stanti, solo per fare qualcosa. Queste attività potrebbero non avere nulla a che fare con DevOps e con la trasformazione. Perché non affidare questo compito ai dipartimenti esistenti?
Perché è necessario un team temporaneo
Conflitto con i processi attuali. La trasformazione DevOps implica un cambiamento non solo delle tecnologie e degli strumenti che utilizziamo, ma anche del processo di lavoro stesso, della mentalità e dei valori. Se il team lavora come è già abituato, non sarà in grado di provare approcci diversi.
Queste persone devono vivere secondo regole diverse: ignorare tutti i KPI dell'azienda, poiché stanno cercando di lavorare in modo differente. I team temporanei non compileranno le richieste per ottenere un server, ma andranno direttamente al dipartimento che se ne occupa, richiedendo di ricevere per primi ciò di cui hanno bisogno, perché è un compito prioritario e perché stanno cercando di vivere in modo diverso. Il team ha un conflitto totale con tutti i processi attuali. Per fare in modo che i metodi di lavoro esistenti non ostacolino loro ora e che loro non ostacolino gli altri, isoliamo queste persone creando un team separato.
Evitare la burocrazia negli esperimenti. Nei team temporanei non c'è burocrazia, non compilano report sulle ore lavorate, non rendono conto ai manager. Questa è assolutamente un'altra dimensione, dove le persone vivono e pensano in modo diverso e si occupano di cose totalmente diverse. Non devono essere disturbati inutilmente.
Lavoro continuo sul servizio. Nel primo punto abbiamo scelto qualcosa su cui sperimentare. Gli esperimenti e la ricerca di modi per lavorare meglio sono importanti, ma vogliamo anche sviluppare funzionalità. Se l'intero team si concentra sulla trasformazione invece che sulle funzionalità, inizieremo a perdere ricavi e i bug rimarranno a lungo irrisolti — questo non è ciò di cui abbiamo bisogno. Creare un team temporaneo consente di sperimentare senza fermare il lavoro sul prodotto.
Non perdere tempo su attività lavorative. Questo riguarda nuovamente il prodotto. Per far sì che il team provi altri strumenti e altro ancora, ci vuole molto tempo. Ci vorranno almeno sei mesi affinché le persone apprendano gli strumenti, inizino a implementarli e li utilizzino correttamente. Se sono anche occupati con il prodotto, sei mesi sembreranno un'eternità. Se le persone si occupano del prodotto, torneranno a lavorare con i vecchi processi — questo non è ciò di cui abbiamo bisogno.
Perciò, selezioniamo persone da diversi reparti per formare un team separato che si occuperà della trasformazione del servizio. Di conseguenza, il servizio continua a funzionare e a evolversi, mentre sperimentiamo con esso.
Il team temporaneo si occupa esclusivamente della trasformazione DevOps, rimuovendo le limitazioni che abbiamo individuato, e nient'altro.
Il team è composto da persone multifunzionali. Questo significa che non abbiamo incluso solo sviluppatori. Non siamo entrati nel servizio e non abbiamo prelevato mezzo team, no, abbiamo scelto persone provenienti da diversi reparti. Pochi punti fa abbiamo identificato vari reparti e diversi dipendenti a cui interessa il servizio in trasformazione. Stiamo formando il team con loro, perché deve essere multifunzionale: cambieremo il processo di testing, il processo di sviluppo e il processo di gestione del servizio. Sono necessarie competenze diverse.
Di solito prendiamo un sviluppatore, un tester e un ingegnere — uno di ciascuno, e insieme a loro sviluppiamo una soluzione che consenta di vivere in modo diverso.
Ideale sarebbe che queste persone avessero autorevolezza all'interno dell'organizzazione. Potrebbe essere necessario coinvolgere un consulente, anche se non ne abbiamo voglia. Se abbiamo una grande azienda, non tutti crederanno nel nostro progetto, e qualcuno potrebbe ostacolarci, ad esempio, non assegnando uno spazio per il nostro stand. Qui servirà un «autorevole» — una persona rispettata con molta esperienza, che ha guadagnato una buona considerazione tra i colleghi. L'autorità di un membro del team faciliterà il compito e il lavoro del team temporaneo. Le persone penseranno:
— Ah, quel tizio fantastico che tutti conosciamo e apprezziamo è coinvolto— evidentemente, in DevOps c’è qualcosa che merita attenzione!
Fissiamo un obiettivo
Abbiamo radunato le persone, scelto il servizio, esaminato i limiti, definito su chi possiamo influenzare. Ora bisogna fissare un obiettivo e deve essere chiaro secondo il metodo SMART — tutto come piace a noi.
Specifico — specifico.
Misurabile — misurabile. Questo è un punto molto importante dello SMART. Se non puoi misurare qualcosa, non puoi cambiarla e non capirai cosa e come hai fatto meglio o peggio.
Raggiungibile — raggiungibile. Fai attenzione alle tue specificità. Se sei un'azienda enterprise con una lunga storia e un grande carico di responsabilità, che rilascia una versione del prodotto una volta all'anno, non potrai raggiungere un rilascio di nuove versioni del prodotto ogni ora in sei mesi. Non è possibile. Quindi, fissa un obiettivo realistico, che sia raggiungibile in un tempo ragionevole.
Rilevante — rilevante. Eliminiamo solo quella restrizione che realmente ostacola i nostri obiettivi attuali.
Limitato nel tempo — limitato nel tempo. Se non c'è scadenza, il team si occuperà di qualsiasi cosa: proverà 15 tecnologie invece di 3, scriverà enormi relazioni, condurrà ricerche inutili, perfezionerà la propria implementazione fino alla lucentezza, quando l'obiettivo è già stato raggiunto.
Definiamo l'obiettivo proprio attraverso la Value Stream Map — riuniamo di nuovo tutte le persone e disegniamo. Ma stavolta, sulla base della Value Stream Map precedente, disegniamo ciò che vogliamo ottenere.
Identifichiamo una restrizione che elimineremo in questo momento, e su questo si concentrerà il team. Per esempio, ho preso l'attesa dal rilascio finale fino alla sua deployment in produzione — questa è la restrizione più comune con cui le persone si rivolgono ai consulenti.
In base a questo, impostiamo un obiettivo: vogliamo che l'attesa tra il rilascio finale e l'entrata in produzione sia al massimo di un'ora.
Esempi di obiettivi.
- Ridurre il Lead Time dei test da 4 giorni a 1 ora.
- Ridurre il Value Added Time per il testing da 2 giorni a 3 ore.
- Ridurre il Lead Time di deploy da 5 ore a 10 minuti.
- Aumentare la C/A dal 50% al 95%, ossia aumentare il numero di funzionalità accettate dai tester, in altre parole, migliorare la qualità del lavoro degli sviluppatori.
Gli esempi di obiettivi non sono inventati - si basano su misurazioni effettuate quando abbiamo sviluppato la Value Stream Map.
Impostiamo un obiettivo simile per il nostro team e un vincolo temporale. A seconda di quanto bene vanno le cose nella vostra azienda, si impostano diversi termini. In media, per rimuovere un vincolo, se le persone affrontano questa sfida per la prima volta e non sanno ancora quali tecnologie e come risolveranno il problema, di solito ci vogliono sei mesi.
Pianificazione breve
Quindi, il nostro team è formato, ha un obiettivo e le persone iniziano a lavorare. Un punto importante è la pianificazione breve del lavoro: sprint di una o due settimanee, non di più, miglioramenti misurabili ogni settimana e correzione del corso.
Ad esempio, utilizziamo spesso un approccio moving-moving, in cui l'intero team si riunisce all'inizio di ogni settimana e scrive in un file cosa farà ciascuno. Una settimana dopo, valutiamo: cosa è stato fatto e cosa no, se no, perché, e riflettiamo su cosa fare in seguito.
Gli sprint permettono di correggere il tiro in tempo.
Proviamo qualcosa per una settimana o due: tecnologie, approcci, modalità di lavoro, dopodiché misuriamo di nuovo e vediamo se questo approccio ha portato a miglioramenti o peggioramenti. Se è peggiorato, significa che stiamo andando nella direzione sbagliata; dobbiamo correggere il tiro: impostare un altro compito, adottare una tecnologia diversa o fare qualcos'altro. Gli sprint brevi di 1-2 settimane consentono di orientarsi e di abbandonare tempestivamente le decisioni sbagliate.
Condividiamo i successi
Il team raggiunge alcuni successi, piccoli o grandi - non importa, c'è sempre un risultato. Di questo risultato devono essere informati tutti: sia coloro che sono coinvolti nel DevOps, sia i reparti adiacenti. In un mondo ideale, sarebbe auspicabile che questo arrivasse a tutte le persone nell'azienda.
Perché? Se vogliamo trasformare non solo una parte dell'azienda, eliminare un singolo vincolo, ma tutti, affinché l'azienda diventi flessibile, il codice arrivi rapidamente al cliente e niente si rompa, è necessario che tutti siano aperti all'idea del DevOps. Non si può applicare un approccio a servizi e team che sono categoricamente contrari.
Per creare fedeltà, dobbiamo raccontare a tutti che abbiamo provato questo e abbiamo ottenuto risultati, provate anche voi! Questo aumenterà l'interesse e la fedeltà verso ciò che facciamo, le persone inizieranno a provare a fare qualcosa immediatamente. Come dimostra la pratica, quando raccontiamo cosa abbiamo provato e quali risultati abbiamo ottenuto, altri team iniziano a chiedere come e cosa abbiamo fatto. Parlano delle implementazioni, del codice, della documentazione, arrivano con domande e cercano di modificare qualcosa nel loro.
Raccontare ciò che hai realizzato è importante. Così convincerai a unirsi al tuo campo coloro che volevano fare tutto come prima, trasformandoli in innovatori.
Totale
Selezioniamo il servizio, come punto di partenza — il luogo da cui inizieremo i cambiamenti nell'azienda. Identifichiamo tutti coloro che hanno qualche rapporto con il servizio e insieme a loro costruiamo la Value Stream Map, misuriamo e osserviamo dove e quali sono i vincoli.
Creiamo un nuovo team temporaneo, che si occuperà del compito assegnato. Sulla base delle misurazioni e della Value Stream Map disegniamo una nuova mappa, evidenziando il vincolo che intendiamo risolvere. Sulla base di questo vincolo stabiliamo l'obiettivo, che il team dovrà affrontare. L'obiettivo deve essere assolutamente SMART — specifico, misurabile, rilevante per le attuali attività e delimitato nel tempo.
Ripetiamo il processo, finché non trasformiamo completamente tutti i nostri servizi nella forma richiesta e non rimuoviamo tutti i vincoli.
Bonus. Materiali utili
Per coloro che hanno deciso di dedicarsi al DevOps in autonomia.
Il Progetto 'Phoenix'
Il titolo originale è 'The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win'. È un romanzo su DevOps — la storia di come un dipendente è diventato capo di un dipartimento che bruciava costantemente. Al nuovo responsabile è stata assegnata la seguente missione:
— Hai alcuni anni per sistemare tutto, affinché possiamo finalmente consegnare il nostro prodotto rapidamente ed efficacemente ai nostri clienti.
«Progetto “Fenice”. Un romanzo su come DevOps trasforma la vita in meglio» — un libro per tutti i dirigenti, poiché sono proprio loro a prendere decisioni su cosa accade nell'azienda. Se invece sei un ingegnere o un programmatore e desideri avviare un cambiamento e una trasformazione nella tua azienda — acquista il libro e regalalo alla direzione. Questo romanzo spiega tutto, ed è veloce e facile da leggere.
Guida a DevOps
Un libro più complesso. Pubblicato alcuni anni fa in inglese con il titolo «The DevOps Handbook: How to create world-class agility, reliability, and security in Technology organizations», ma ora disponibile anche in russo. È un vero e proprio handbook — una guida pratica: su come effettuare misurazioni, cosa sia il Value Stream Map e a cosa serva, quale direzione prendere e in quale ordine. Il libro è pensato proprio per chi vuole fare tutto da solo. La cosa più importante è che contiene esempi delle esperienze di altre aziende.
Ad esempio, viene raccontato come un'azienda abbia costruito una Value Stream Map e abbia capito che il suo limite non era il prodotto, ma il fatto che il cassiere doveva andare dal negozio all'ufficio vicino per utilizzare quel prodotto. Invece di risolvere il problema con il software, hanno semplicemente acquistato tablet per i loro venditori, e ora nessuno deve più andare da nessuna parte, ma tutte le azioni vengono eseguite sul posto di lavoro. Conclusione: la Value Stream Map può essere applicata non solo al software, ma a tutti i processi all'interno dell'organizzazione.
Accelerate
Nome completo: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». Questo è il livello successivo — hardcore. Il libro è uscito l'anno scorso, per ora solo in inglese, ed è basato su ricerche. Gli autori — Nicole Forsgren, Jez Humble e Gene Kim — hanno applicato pratiche diverse in varie aziende per molti anni e hanno studiato quali pratiche, come e su cosa influiscono.
Nel secondo capitolo, dedicato alle misurazioni, si parla del Value Stream Map, delle metriche di cui ho parlato e di molte altre, ed è descritto in dettaglio il processo di misurazione. Gli autori effettuano misurazioni tramite questionari e monitoraggio autonomo delle attività. Viene spiegato in dettaglio quali metriche misurare correttamente, quali evitare e gli errori umani nelle misurazioni. Se hai difficoltà con le misurazioni, consulta il secondo capitolo del libro «Accelerate». Se nel tuo team ci sono semplicemente molte pratiche, ma non è chiaro quali applicare ora, quale dopo, quali funzionano realmente e quali no — leggi, nel libro è tutto spiegato.
La trasformazione è una questione all'incrocio tra DevOps e gestione. In qualche modo nella stessa area d'incrocio tra sviluppo, operazioni e test si trovano temi che cerchiamo di discutere a , l'integrazione è necessaria anche per creare un prodotto di qualità – il tema principale . La gestione al festival disponibili — significa che tutte le idee per la trasformazione vanno lì. Unisciti a noi il 27 e 28 maggio, ci integreremo e trasformeremo.
Fonte: habr.com
