Se non capisci cos'è 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 di software. Di solito, esse ridurranno il tempo di immissione sul mercato — il periodo dall'idea alla consegna del prodotto finale ai clienti, consentendo di eseguire rapidamente esperimenti aziendali.
Come iniziare una trasformazione DevOps? In breve: selezioniamo il servizio con cui iniziare il processo, identifichiamo chi è coinvolto nel servizio, costruiamo una Value Stream Map, creiamo un team temporaneo che si occuperà della trasformazione inizialmente e diamo loro un compito. Ripetiamo il ciclo il numero di volte necessario.
Un piano dettagliato per la trasformazione DevOps con esempi e istruzioni è disponibile nel documento Andrey Alexandrov — di un ingegnere dell'azienda Express42, che fornisce consulenze per sviluppare DevOps, accelerando questo processo poiché ha già costruito una mappa degli ostacoli. Se pensi che la trasformazione non ti possa servire, o se la tua specificità è tale che le pratiche DevOps non si applicano, utilizza la relazione come una guida per identificare e rimuovere i vincoli.
Se hai domande sulla trasformazione DevOps, significa che hai una grande azienda e devi gradualmente scalare questo processo in tutta la struttura. Finché c'è necessità di trasformare un team o rimuovere un vincolo, puoi ripetere l'algoritmo qui sotto.
Scelta del servizio
Il piano è stato impostato, iniziamo dal primo passo: la scelta del servizio. Il primo criterio è la vita utile: ci sono servizi obsoleti — legacy, e nuovi. Puoi iniziare con entrambi.
Scegliere un servizio giovane è logico. È fresco, non ci sono ancora processi di lavoro consolidati nel team che lo gestisce. Non c'è un accumulo di debito tecnico, non è necessario ripararlo continuamente. Possiamo farne ciò che vogliamo.
Nel caso di un servizio vecchio, ci sono problemi legati al fatto che cambiare è sempre difficile. Ci sono già serie limitazioni, ma potrebbero esserci persone pronte a rivoluzionare tutto — sono stufe e vogliono fare qualcosa in modo diverso, perché è doloroso per loro.
Lavorare con un servizio vecchio crea un forte precedente nella tua azienda — si possono apportare modifiche. Se hai modificato un nuovo servizio, che viene lanciato in produzione 100 volte all'ora, e tutto funziona bene, allora le persone nella tua azienda possono dire:
— Questo è un nuovo servizio! Era tutto così semplice, provate a fare qualcosa con la nostra vecchia carcassa.
Ha senso prendere un servizio legacy per la trasformazione quando lo fate con qualcuno, per esempio, se avete invitato un consulente esterno. Siamo onesti, la trasformazione metterà sotto pressione tutto ciò che è possibile.. Sperimentate e non sapete dove arriverete, quali tecnologie e perché utilizzerete, dove e quali insidie si presenteranno nei processi. Pertanto, è più facile cambiare il nuovo.
Se fate tutto da soli e in azienda non ci sono competenze serie — prendete il nuovo servizio. Se conoscete un consulente esterno e ci sono fondi — scegliete il vecchio.
Ci sono servizi che sono semplicemente interfacce per gli 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à difficile risolvere. Qui abbiamo anche una scelta.
Lavoriamo o con un servizio critico, ma già a causa di esso soffriamo, crea vincoli, oppure lavoriamo con un'interfaccia. Questo è il secondo criterio di scelta. Analogamente, c'è la possibilità di coinvolgere un consulente esperto — lavoriamo con la variante pesante.
Ma anche in questo caso non consiglio di procedere in questo modo, perché, finché non c'è comprensione di cosa lavorare e in quale direzione trasformare, prendere qualcosa di critico e ristrutturalo — non è una buona idea. Pertanto, in questo caso, preferiamo lavorare con un'interfaccia, il cui malfunzionamento non è critico.
Passiamo a il team del servizio. Con coloro che si occupano di questo servizio, ci tocca lavorare costantemente e interagire in un contatto molto stretto.
Le persone nel team sono convenzionalmente divise in due categorie: conservatori — vivono nel vecchio mondo, oppure non sanno niente di DevOps, e innovatori, che portano tutte le pratiche alla moda. I secondi non sempre comprendono a fondo la materia, ma almeno sono pronti ad affrontarla.
Da un lato, i conservatori sono persone esperte: sono in azienda da molto tempo, capiscono tutto, ma non conoscono le pratiche. Dall'altro lato, gli innovatori hanno sentito parlare di qualcosa, ma probabilmente lavorano in azienda da non molto tempo. Con chi è meglio lavorare?
I conservatori dovranno essere coinvolti in ogni caso, poiché questo è il loro servizio. Dovremo comunicare con loro, capire la specificità del servizio, cosa si può fare in un modo e cosa in un altro. Siamo dipendenti dai loro consigli. Sicuramente dovremo affidare loro qualche compito, perché conoscono meglio il loro servizio. È quindi importante con quale squadra avremo contatto alla fine.
È logico scegliere innovatori per il team, poiché i conservatori potrebbero fare cose sbagliate.
Nella pratica, spesso accade che le persone conservative abbiano un'esperienza significativa, ma non capiscano come andare avanti. Hanno semplicemente paura che dopo la trasformazione e la revisione del servizio, saranno licenziati per mancata necessità. A volte, a causa della mancanza di comprensione di ciò che sta succedendo, boicottano il lavoro.
Ho avuto un caso in cui un ragazzo del team riparava qualsiasi cosa, perché sosteneva che fosse più critico rispetto a quello che stavamo facendo. Impostiamo un compito: completare questo pezzo oggi — no, dall'altra parte del mondo c'è un incendio, andiamo a sistemarlo. Lavorare con persone così è difficile.
Le persone nel team dei conservatori spesso ignorano i compiti o li rimandano all'ultimo minuto. E se, Dio non voglia, commettete un errore e assegnate loro KPI per il numero di compiti completati, e una parte di essi non è inclusa nel KPI, non faranno nulla. In realtà, avrebbero ragione, perché allora perderebbero il bonus.
Con gli innovatori è più facile — sono più leali.Hanno già sentito qualcosa, vogliono andare da qualche parte, quindi aiuteranno. Abbiamo bisogno di persone pronte a soffrire per un po': se il servizio cambia, tutte le difficoltà e i problemi li affronteranno gli innovatori come pionieri. Gli innovatori desiderano tutto ciò che è nuovo e alla moda, e sono disposti a soffrire.
I conservatori possono essere convertiti in seguito. Quando mostrerete che avete cambiato un pezzo e tutto funziona bene, probabilmente vorranno provare anche loro e accetteranno la nuova religione DevOps.
In sintesi. Se facciamo tutta la trasformazione nella nostra azienda da soli, scegliamo: un nuovo servizio, preferibilmente con un'interfaccia semplice, per non soffrire troppo a causa dei suoi guasti, e un team di innovatori.
Se c'è la possibilità di chiamare un consulente esterno, invece di uno nuovo, prendiamo il vecchio servizio, che ci causa già problemi. Le persone che si sono occupate di trasformazioni piuttosto a lungo in diverse aziende hanno visto casi diversi e già comprendono come fare le cose nel modo giusto e in quale direzione andare.
Chi è coinvolto?
Dobbiamo trovare tutti coloro che hanno anche solo un qualche rapporto con il servizio: sviluppatori, tester, amministratori, esperti di sicurezza, manager e, forse, Product Owners. Nonostante i Product Owners non siano tecnici, hanno un legame con il servizio: prendono decisioni e definiscono compiti.
Dobbiamo trovare, conoscere e interagire con tutti coloro che prendono decisioni e influenzano ciò che accade al servizio.
A cosa ci servono? Per sapere con chi trattare.. Durante la trasformazione, quando il modo abituale di lavorare con il servizio cambia, ci saranno comunque delle turbolenze. Ci saranno interruzioni finché testiamo nuovi approcci. Le persone devono essere pronte e concordare su questo.
In seguito dovremo costruire la Value Stream Map e senza queste persone non potremo farlo, perché solo insieme conoscono l'intera situazione. Una sola persona non sa mai tutto ciò che accade con il servizio.
Loro consiglieranno persone per il team. Più avanti discuteremo perché è necessaria un'équipe separata. Dovremo coinvolgere persone dai reparti esistenti. Chi ha un rapporto con il servizio potrà raccomandare colleghi che pensano nella nostra direzione, utili e competenti in ciò di cui abbiamo bisogno.
Dopo raccoglieremo tutte queste persone da reparti diversi 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 valori fino al cliente.. Si tratta di tutto il processo dalla generazione dell'idea fino alla sua realizzazione, 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 esistenti nel processo attuale e iniziare a risolverli, e stabilire un obiettivo iniziale. Questo è il punto in cui inizieremo a fare qualcosa di concreto.
Metriche
La letteratura sulla Value Stream Map descrive molte metriche diverse, ma per iniziare ci bastano tre.
Lead Time — ritardo/attesa — tempo in cui aspettiamo qualcosa. Ad esempio, un tester aspetta che un banco di test diventi libero e in quel momento non può fare nulla.
Value Added Time — tempo di lavoro utile — quello che abbiamo impiegato in una certa fase per creare un valore finale per l'utente. Ad esempio, il tester ha avviato il suo test e ha iniziato a controllare qualcosa. Questo è il tempo di lavoro utile, quando facciamo realmente qualcosa per il prodotto. È ciò per cui i clienti pagano — per software di qualità.
%C/A — percentuale di lavoro accettato. Abbiamo una fase — sviluppo, la seconda fase — collaudo. Quante funzionalità sono state accettate dai tester 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 vi occupate. Ma in generale sulla mappa ci saranno due fasi: un'idea e analisi. In questa fase si attendono dati, ad esempio, Lead Time 2 settimane e Value Added Time 2 giorni.
Le metriche coprono assolutamente tutte le fasi.
Backlog — quante attività erano in attesa dopo che gli analisti le hanno concepite.
Sviluppo — quante settimane gli sviluppatori hanno aspettato chiarimenti sulle attività, banchi di prova o attrezzature — non importa, ma stanno aspettando qualcosa. Ad esempio, implementano una funzionalità per 4 giorni. Qui entra in gioco la metrica %C/A. Gli sviluppatori hanno preso dal backlog solo l'80% delle attività. Ritengono che per il restante 20% non ci siano requisiti sufficientemente chiari e li hanno inviati per revisione.
Test. Nello schema LT è impostato a 4 giorni. Ad esempio, i tester hanno aspettato la liberazione del banco di prova, VA 2 giorni in cui realizzano effettivamente dei test, e %C/A = 40%. — solo il 40% del codice o delle funzionalità che gli sviluppatori hanno inviato è stato considerato adeguato dai tester. Tutto il resto non è piaciuto per qualche motivo.
Non mi soffermerò a lungo su come effettuare queste misurazioni; alla fine dell'articolo consiglierò della letteratura da cui è possibile trarre informazioni.
L'unica cosa che consiglio è di non fidarvi delle persone che compileranno con voi la Value Stream Map. Rappresentano quanto tempo ci vogliono diversi processi, ma queste valutazioni non sono sempre corrette, quindi è meglio misurare voi stessi.
Ci sono stati casi in cui siamo entrati nel reparto Operations e abbiamo chiesto quanto tempo ci vuole per consegnare una nuova funzionalità in produzione. Ci hanno risposto che ci vogliono 10 minuti e ci siamo detti: perché siamo venuti in questa azienda? È emerso che 10 minuti è il tempo di esecuzione di uno script che prende il codice e lo consegna al server. Ma prima di questo, il rilascio rimane sul server per tre giorni e semplicemente rimane inutilizzato — c'è un compito nel Backlog che deve essere implementato. Risultato: prima della fase di deploy c'è una fase di attesa in cui il progetto rimane in sospeso. Se non avessimo portato un bloc-notes, non avessimo notato il compito in Jira e non avessimo iniziato a monitorarlo passo passo, avremmo pensato che tutto andasse bene e che non ci fossero problemi.
Pertanto, sarà necessario effettuare le misurazioni da soli, preferibilmente non solo una volta, per avere un'idea vicina alla realtà. In base alla 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 team, ma non temporanei, bensì esistenti da diversi anni. Se consultate il servizio DevOps apologize, che descrive vari schemi per la costruzione della struttura organizzativa in DevOps, capirete che si tratta di un antipattern.
Quando un team DevOps esiste costantemente per diversi anni, è un grande errore, perché DevOps riguarda la comunicazione tra i reparti, velocità ed efficienza.
Se il team esiste tra i reparti solo per fare qualcos'altro di separato e esiste a lungo, crea un ulteriore ostacolo. Ora il programmatore, invece di andare direttamente all'amministratore per risolvere il problema, deve prima contattare il reparto DevOps, e questo poi andrà avanti.
Pertanto, per iniziare, è necessario creare un team temporaneo. Durerà convenzionalmente sei mesi, al massimo un anno, a seconda dell'obiettivo stabilito, solo per eliminare un vincolo che abbiamo scelto. Dopo, morirà. Se scegliamo il prossimo punto in cui ci fa molto male e capiamo che anche per questo abbiamo bisogno di un team separato, allora lo creeremo di nuovo. Ma in modo permanente, tali team non dovrebbero esistere — altrimenti interrompono la comunicazione e assumono compiti del tutto separati, solo per fare qualcosa. Questi compiti potrebbero non essere affatto correlati a DevOps e alla trasformazione. Perché non possiamo affidare questo compito ai reparti esistenti?
Perché è necessario un team temporaneo
Conflitto con i processi attuali. La trasformazione DevOps è un cambiamento non solo delle tecnologie e degli strumenti che utilizziamo, ma anche del processo di lavoro, della mentalità e dei valori. Se il team lavora come è già abituato, non riuscirà a provare approcci diversi.
Queste persone devono vivere secondo altre regole: ignorare tutti i KPI in azienda, perché stanno cercando di lavorare in modo diverso. I team temporanei non presenteranno richieste per ottenere un server, ma andranno direttamente al dipartimento che se ne occupa, chiedendo di avere 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. Affinché i metodi di lavoro esistenti non interferiscano ora con loro e loro non interferiscano con gli altri, isolemo queste persone, costituendo 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. Questo è un mondo completamente separato, in cui le persone vivono e pensano in modo diverso, e si dedicano a cose completamente diverse. Non devono essere disturbati inutilmente.
Lavoro incessante sul servizio. Nel primo punto abbiamo scelto qualcosa su cui sperimentare. Gli esperimenti e la ricerca di modi migliori per lavorare sono utili, ma vogliamo anche realizzare delle funzionalità. Se l'intero team si dedica alla trasformazione invece che alle funzionalità, iniziamo a perdere entrate, i bug rimarranno a lungo — non è ciò di cui abbiamo bisogno. Creare un team temporaneo consente di sperimentare, senza fermare il lavoro sul prodotto.
Non perdere tempo con i compiti lavorativi. Si tratta di nuovo del prodotto. Ci vuole molto tempo affinché il team provi altri strumenti e altro ancora. Per permettere alle persone di apprendere gli strumenti, iniziare a implementarli e usarli correttamente, passerà almeno mezzo anno. Se si occupano anche del prodotto, quel mezzo anno si allungherà in modo esponenziale. Se le persone si occupano del prodotto, lavorano di nuovo con i vecchi processi — non ne abbiamo bisogno.
Ecco perché selezioniamo persone da diversi reparti per creare un team separato, che si occuperà della trasformazione del servizio. Di conseguenza, il servizio funziona, continua a evolversi e nel contempo facciamo esperimenti su di esso.
Il team temporaneo si occupa solo della trasformazione DevOps — eliminando quelle limitazioni che abbiamo trovato, e nient'altro.
Il team è composto da persone versatili. Questo significa che non abbiamo preso solo sviluppatori. Non siamo entrati nel servizio per portare via metà del team — no, abbiamo preso persone da diversi reparti. Alcuni punti fa abbiamo identificato diversi reparti e impiegati coinvolti nel servizio che stiamo trasformando. Da loro formiamo un team perché deve essere versatile — cambieremo sia il processo di test, sia il processo di sviluppo che il processo di gestione del servizio. Sono necessarie diverse competenze.
Di solito prendiamo un sviluppatore, un tester e un ingegnere — uno ciascuno, e insieme a loro inventiamo una soluzione che ci permette di vivere diversamente.
È preferibile che queste persone abbiano autorità all'interno dell'organizzazione. Potrebbe essere necessario prendere un conservatore, anche se non ci piace. Se abbiamo una grande azienda, non tutti crederanno nella nostra iniziativa, e qualcuno potrebbe ostacolarci, ad esempio non assegnando un ambiente di prova. Qui ci vuole un «autorevole» — una persona rispettata con molta esperienza, che ha guadagnato la stima dei colleghi. L'autorità di un membro del team semplificherà il compito e il lavoro del team temporaneo. Le persone penseranno:
— Ah, questo tizio è fantastico, lo conosciamo e lo amiamo, si è unito a noi — evidentemente c'è qualcosa nel DevOps che merita attenzione!
Poniamo un obiettivo
Abbiamo raccolto le persone, scelto il servizio, esaminato le limitazioni, identificato le persone su cui avremo un impatto. Ora dobbiamo fissare un obiettivo e deve essere chiaro secondo il metodo SMART — tutto come ci piace.
Specifico — specifica.
Misurabile — misurabile. Questo è un punto molto importante dello SMART. Se non puoi misurare qualcosa, non puoi cambiarlo e capire cosa hai fatto meglio o peggio.
Realizzabile — realizzabile. Fai una considerazione sulla tua specificità. Se sei un'impresa con una lunga storia e un grande carico di responsabilità, che rilascia una versione di prodotto all'anno, non potrai raggiungere una versione ogni ora in sei mesi. Non è possibile. Pertanto, fissa un obiettivo realistico, che possa essere raggiunto in un tempo accettabile.
Rilevante — rilevante. Eliminiamo solo quella limitazione che perseguita realmente i nostri obiettivi attuali.
Limitato nel tempo — limitato nel tempo. Se non c'è una scadenza, il team si occuperà di qualsiasi cosa: provare 15 tecnologie invece di 3, scrivere enormi rapporti, condurre ricerche inutili, rifinire la propria implementazione fino alla perfezione, quando l'obiettivo è già stato raggiunto.
L'obiettivo lo prendiamo proprio con l'aiuto della Value Stream Map — raccogliamo nuovamente tutte le persone e disegniamo. Ma ora, sulla base della precedente Value Stream Map, disegniamo ciò che vogliamo ottenere.
Isoliamo una limitazione che andremo ad eliminare subito, che sarà il compito del team. Ad esempio, ho preso l'attesa tra il rilascio pronto e il suo deployment in produzione: è la limitazione più comune per cui le persone si rivolgono ai consulenti.
Sulla base di questo, poniamo un compito: vogliamo che l'attesa tra il rilascio pronto e l'uscita in azione, sia massimo di un'ora.
Esempi di compiti.
- Ridurre il Lead Time del test da 4 giorni a 1 ora.
- Ridurre il Value Added Time per il test da 2 giorni a 3 ore.
- Ridurre il Lead Time di deployment da 5 ore a 10 minuti.
- Aumentare il C/A dal 50% al 95%, ossia aumentare il numero di funzioni che vengono accettate dai tester, in altre parole, migliorare la qualità del lavoro degli sviluppatori.
Esempi di compiti non presi a caso: sono basati su misurazioni che abbiamo effettuato quando abbiamo sviluppato la Value Stream Map.
Poniamo un compito simile al nostro team e una limitazione di tempo. A seconda di quanto bene vanno le cose nella tua azienda, puoi stabilire scadenze diverse. In media, per eliminare una limitazione, se le persone se ne occupano per la prima volta e non sanno ancora con quali tecnologie e come esattamente risolveranno il problema, ci vogliono di solito sei mesi.
Pianificazione breve
Quindi, la nostra squadra è stata creata, ha un obiettivo e le persone iniziano a lavorare. Un aspetto 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, usiamo spesso l'approccio moving-moving, quando tutta la squadra si riunisce all'inizio di ogni settimana, annota in un file cosa farà ciascuno. Dopo una settimana, controlliamo: cosa è stato fatto, cosa no, se no, perché, e pensiamo a cosa fare dopo.
Gli sprint consentono di correggere il corso in tempo.
Una o due settimane proviamo qualcosa: tecnologie, approcci, modi di lavorare, dopo di che misuriamo di nuovo e vediamo — con questo approccio è andata meglio o peggio? Se è peggio, significa che stiamo andando nella direzione sbagliata, dobbiamo correggere il corso: impostare un altro compito, adottare un'altra tecnologia o fare qualcos'altro. Gli sprint brevi di 1-2 settimane permettono di navigare e ritirarsi in tempo da decisioni sbagliate.
Condividiamo i successi
La squadra raggiunge alcuni successi, piccoli o grandi — non importa, c'è sempre un risultato. Di questo risultato devono essere a conoscenza tutti: sia quelli coinvolti nel DevOps sia i dipartimenti vicini. In un mondo ideale, sarebbe auspicabile che questo arrivasse a tutte le persone dell'azienda.
Perché? Se vogliamo trasformare non una parte dell'azienda, eliminare un solo vincolo, ma tutto, affinché l'azienda diventi agile, il codice venga spedito rapidamente al cliente e nulla si rompa, è necessario che tutti siano leali all'idea del DevOps. Non si può applicare questo approccio ai servizi e ai team che sono categoricamente contrari.
Per creare lealtà, dobbiamo raccontare a tutti che abbiamo provato questo — abbiamo un risultato, provate anche voi! Questo aumenterà l'interesse e la lealtà verso ciò che facciamo, le persone inizieranno a provare a fare qualcosa subito. Come dimostra l'esperienza, quando raccontiamo cosa abbiamo provato e quali risultati abbiamo ottenuto, altri team iniziano a chiedere come e cosa abbiamo fatto. Guardano le implementazioni, il codice, la documentazione, si avvicinano con domande e cercano di cambiare qualcosa nel loro.
Raccontare ciò che hai ottenuto è importante. In questo modo convincerai a passare nel tuo campo i conservatori che volevano fare tutto come prima e li trasformerai in innovatori.
Totale
Scegliamo un servizio, come punto di partenza — il luogo dove inizieremo i cambiamenti nell'azienda. Identifichiamo tutti coloro che hanno qualche relazione con il servizio e insieme a loro costruiamo la Value Stream Map, misuriamo e osserviamo dove e quali sono le limitazioni.
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 la limitazione che andremo a risolvere. Sulla base di questa limitazione fissiamo un obiettivo, su cui si occuperà il team. L'obiettivo deve essere necessariamente SMART — specifico, misurabile, rilevante per i compiti attuali e limitato nel tempo.
Ripetiamo il processo, finché non trasformiamo tutti i nostri servizi nella forma richiesta e non eliminiamo tutte le limitazioni.
Bonus. Materiali utili
Per coloro che hanno deciso di occuparsi di DevOps autonomamente.
Progetto «Fenice»
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 impiegato sia diventato responsabile di un dipartimento, sempre in difficoltà. Al nuovo responsabile è stato assegnato il compito:
— Hai alcuni anni per risolvere tutto, affinché possiamo finalmente fornire il nostro prodotto ai nostri clienti in modo rapido ed efficace.
«Progetto “Fenice”. Romanzo su come DevOps cambi la vita in meglio» — un libro per tutti i dirigenti, perché sono proprio queste persone a prendere decisioni su cosa accade in azienda. Se sei un ingegnere o un programmatore e desideri che la tua azienda inizi un movimento e una trasformazione, acquista il libro e regalalo alla direzione. Questo romanzo spiega tutto, ed è facile e veloce da leggere.
Guida a DevOps
Il libro è un po' più complesso. È uscito 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 è già disponibile in russo. È un vero manuale — una guida pratica: come effettuare le misurazioni, cos'è la Value Stream Map e a cosa serve, quale direzione seguire, in quale ordine. È un libro pensato per coloro che vogliono fare tutto da soli. La cosa più importante è che contiene esempi dall'esperienza di altre aziende.
Ad esempio, lì si racconta come un'azienda ha costruito una Value Stream Map e ha capito che la sua limitazione non era nel prodotto, ma nel fatto che la cassiera andava dal negozio all'ufficio vicino per utilizzare quel prodotto. Invece di risolvere il problema con un software, hanno semplicemente acquistato tablet per i loro venditori, e ora nessuno si muove più, ma tutte le operazioni vengono eseguite sul posto di lavoro. Risultato: la Value Stream Map può essere applicata non solo al software, ma a tutti i processi all'interno dell'organizzazione.
Accelerare
Titolo completo: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». Questo è il livello successivo — hardcore. Il libro è uscito lo scorso anno, al momento solo in inglese ed è incentrato su ricerche. Gli autori — Nicole Forsgren, Jez Humble e Gene Kim — hanno applicato diverse pratiche in molte aziende e hanno studiato quali pratiche, come e su cosa influenzano.
Nel secondo capitolo, dedicato alle misurazioni, si menzionano le Value Stream Map, le metriche che ho citato e molte altre, e viene descritto in dettaglio il processo di misurazione. Gli autori effettuano misurazioni utilizzando questionari e monitoraggio autonomo delle attività. Viene spiegato in dettaglio quali metriche misurare correttamente, quali non dovrebbero essere misurate, e gli errori umani nelle misurazioni. Se hai difficoltà con le misurazioni, fai riferimento al secondo capitolo del libro «Accelerate». Se nel tuo team ci sono molte pratiche, ma non è chiaro quali applicare ora, quali dopo, quali funzionano realmente e quali no — leggi, nel libro c'è tutto.
La trasformazione è una questione al confine tra DevOps e gestione. In quella stessa area di intersezione tra sviluppo, operatività e testing si trovano temi che cerchiamo di discutere su , anche l'integrazione è necessaria per creare un prodotto di qualità – il tema principale . La gestione al festival sono presenti — significa che tutte le idee per la trasformazione convergono lì. Unisciti a noi il 27 e 28 maggio, ci integreremo e ci trasformeremo.
Fonte: habr.com
