{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sette archetipi di trasformazione secondo i principi del DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La questione di come implementare DevOps non \u00e8 nuova, ma ci sono pochi materiali di qualit\u00e0. A volte si diventa vittime della pubblicit\u00e0 di consulenti poco brillanti, che cercano solo di vendere il loro tempo, senza preoccuparsi di come. A volte si tratta di parole vaghe e generiche su come le mega-corporazioni solcano gli spazi dell'universo. Sorge la domanda: e a noi che importa? Gentile autore, potresti elencare le tue idee in modo chiaro?<\/p>\n

Tutto ci\u00f2 deriva dal fatto che la reale pratica e comprensione delle trasformazioni culturali nelle aziende non \u00e8 cos\u00ec diffusa. I cambiamenti culturali sono processi a lungo termine, i cui risultati non si manifesteranno n\u00e9 nella settimana n\u00e9 nel mese successivo. Abbiamo bisogno di qualcuno con una certa esperienza, che abbia visto come si siano create e distrutte aziende nel corso degli anni.<\/p>\n

\"Sette
\n
\nJohn Willis<\/b> \u00e8 uno dei padri del DevOps. John ha un'esperienza di decenni con un gran numero di aziende. Negli ultimi tempi, ha iniziato a notare schemi specifici che emergono nel lavoro con ciascuna di esse. Utilizzando questi archetipi, John guida le aziende verso il vero percorso di trasformazione DevOps. Maggiori dettagli su questi archetipi possono essere trovati nella traduzione del suo intervento alla conferenza DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Informazioni sul relatore:<\/b><\/p>\n

Con oltre 35 anni di esperienza nella gestione IT, ha partecipato alla creazione del predecessore di OpenCloud in Canonical, e ha preso parte a 10 startup, due delle quali sono state vendute a Dell e Docker. Attualmente \u00e8 Vice President of DevOps and Digital Practices in SJ Technologies.<\/p>\n

Di seguito, il racconto di John.<\/b><\/p>\n

Mi chiamo John Willis e puoi trovarmi facilmente su Twitter, @botchagalupe<\/a><\/noindex>. Lo stesso pseudonimo che uso su Gmail e GitHub. Inoltre, a questo link<\/a><\/noindex> puoi trovare registrazioni video delle mie presentazioni e le relative slide.<\/p>\n

Ho molte riunioni con CIO di grandi aziende. Spesso si lamentano di non capire cosa sia il DevOps, mentre chi cerca di spiegarglielo parla di argomenti completamente diversi. Un'altra lamentela frequente \u00e8 che il DevOps non funziona, anche se sembra che i direttori seguano correttamente le istruzioni ricevute. Si tratta di aziende enormi, alcune delle quali hanno pi\u00f9 di cento anni. Parlando con loro, sono giunto alla conclusione che per molte problematiche sono pi\u00f9 adatte soluzioni relativamente low-tech piuttosto che tecnologie avanzate. Ho passato settimane a parlare con persone di vari dipartimenti. Quello che vedete nella prima immagine del post \u00e8 il risultato del mio ultimo progetto, la stanza era cos\u00ec dopo tre giorni di lavoro.<\/p>\n

Che cos'\u00e8 DevOps?<\/h2>\n

\nIn effetti, se chiedi a dieci persone diverse, riceverai dieci risposte diverse. Ma ci\u00f2 che \u00e8 interessante \u00e8 che tutte e dieci le risposte saranno corrette. Non esiste una risposta sbagliata. Mi sono occupato di DevOps in modo abbastanza approfondito per circa dieci anni, sono stato il primo americano al primo DevOpsDay. Non dir\u00f2 che sono pi\u00f9 intelligente di chiunque altro si occupi di DevOps, ma \u00e8 difficile trovare qualcuno che abbia investito altrettanta determinazione. Credo che il DevOps emerga quando si connettono capitale umano e tecnologia. Spesso dimentichiamo la dimensione umana, anche se parliamo molto di varie culture. <\/p>\n

\"Sette
\n
\nOra abbiamo molti dati, cinque anni di ricerca accademica, e la verifica delle teorie \u00e8 stata stabilita su scala industriale. Questi studi ci dicono che, se nella cultura organizzativa si uniscono certi modelli comportamentali, si pu\u00f2 ottenere un'accelerazione di 2000 volte. Questa accelerazione corrisponde a un miglioramento analogo nella stabilit\u00e0. Questa \u00e8 una misura quantitativa del vantaggio che il DevOps pu\u00f2 offrire a qualsiasi azienda. Un paio di anni fa, ho presentato il DevOps a un CEO di una delle aziende nella lista Fortune 5000. Quando mi sono preparato per la presentazione, ero molto nervoso perch\u00e9 dovevo riassumere la mia esperienza pluriennale in cinque minuti. <\/p>\n

Alla fine ho fornito la seguente definizione di DevOps<\/b>: \u00e8 un insieme di pratiche e modelli che permettono di trasformare il capitale umano in capitale organizzativo ad alte prestazioni. Un esempio \u00e8 il modo in cui Toyota lavora da circa 50 o 60 anni.<\/p>\n

\"Sette
\n
\n(Qui e oltre, tali schemi sono presentati non come materiale di riferimento, ma come illustrazione. Il loro contenuto varier\u00e0 per ogni nuova azienda. Tuttavia, puoi visualizzare e ingrandire l'immagine separatamente a questo link.)<\/a><\/noindex><\/i><\/p>\n

Una delle pratiche pi\u00f9 riuscite \u00e8 value stream mapping<\/b>. A questo riguardo sono stati scritti diversi buoni libri, il principale autore dei quali \u00e8 Karen Martin. Tuttavia, nell'ultimo anno, sono giunto alla conclusione che anche questo approccio \u00e8 troppo tecnologico. Certamente ha molti pregi e io l'ho usato molto. Ma quando il CEO ti chiede perch\u00e9 la sua azienda non pu\u00f2 passare a nuovi binari, \u00e8 ancora troppo presto per parlare di value stream mapping. Ci sono molte domande molto pi\u00f9 fondamentali alle quali \u00e8 necessario trovare risposta prima. <\/p>\n

Ritengo che l'errore di molti dei miei colleghi sia che forniscono semplicemente all'azienda una guida in cinque punti e poi tornano dopo sei mesi per vedere cosa \u00e8 successo. Anche un buon schema come il value stream mapping ha, per cos\u00ec dire, delle zone morte (blind spots). Dopo centinaia di interviste con direttori di varie aziende, ho sviluppato un certo modello che consente di scomporre il problema in componenti, e ora discuteremo ciascuno di questi componenti in ordine. Prima di applicare qualsiasi soluzione tecnologica, utilizzo questo modello, e di conseguenza tutte le mie pareti finiscono per essere coperte di schemi. Recentemente ho lavorato con un fondo comune e alla fine avevo da 100 a 150 di tali schemi.<\/p>\n

Una cattiva cultura divora buoni approcci a colazione<\/h2>\n

\nIl messaggio principale \u00e8 il seguente: nessun Lean, Agile, SAFE o DevOps aiuter\u00e0 se la cultura organizzativa \u00e8 scadente. \u00c8 come immergersi in profondit\u00e0 senza un respiratore o operare senza una radiografia. In altre parole, parafrasando Drucker e Deming: una cattiva cultura organizzativa consumer\u00e0 qualsiasi buon sistema e non si soffermer\u00e0. <\/p>\n

Per affrontare questo problema principale, \u00e8 necessario intraprendere i seguenti passaggi:<\/p>\n

    \n
  1. Rendi tutto il lavoro visibile:<\/b> devi rendere tutto il lavoro visibile. Non nel senso che debba necessariamente apparire su qualche schermo, ma nel senso che deve essere osservabile.<\/li>\n
  2. Consolida i sistemi di gestione del lavoro:<\/b> \u00e8 necessario consolidare i sistemi di gestione. Nel problema della conoscenza \u00abtribale\u00bb e della conoscenza istituzionale, nel 9 casi su 10 il collo di bottiglia \u00e8 rappresentato dalle persone. Nel libro \u00abPhoenix Project\u00bb<\/a><\/noindex> il problema era un'unica persona, Brent, che ha causato un ritardo di tre anni nel progetto. E incontro \u00abBrent\u00bb ovunque. Per risolvere questi collo di bottiglia, utilizzo i seguenti due punti nella nostra lista. <\/li>\n
  3. Teoria dei Vincoli:<\/b> teoria dei vincoli.<\/li>\n
  4. Collaborative hacks:<\/b> hack della collaborazione. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> non parler\u00f2 molto di Toyota Kata. Se sei interessato, sul mio GitHub ci sono presentazioni<\/a><\/noindex> quasi su ciascuno di questi argomenti. <\/li>\n
  6. Organizzazione Orientata al Mercato:<\/b> organizzazione orientata al mercato.<\/li>\n
  7. Auditori Shift-left:<\/b> audit nelle fasi iniziali del ciclo.<\/li>\n<\/ol>\n

    \"Sette
    \n
    \nInizio il lavoro con l'organizzazione in modo molto semplice: vado in azienda e parlo con i dipendenti. Come vediamo, non c'\u00e8 nulla di tecnologico avanzato. Tutto ci\u00f2 di cui ho bisogno \u00e8 avere qualcosa su cui scrivere. Raduno diversi team in una stanza e analizzo ci\u00f2 che mi dicono, in base ai miei 7 archetipi. Poi do loro un marcatore e chiedo di scrivere sulla lavagna tutto ci\u00f2 che hanno detto finora a voce alta. Di solito, in questo tipo di riunioni, c'\u00e8 una persona che scrive tutto, e nel miglior dei casi riesce a registrare il 10% della discussione. Con il mio metodo, riusciamo ad aumentare questa percentuale a circa il 40%. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     visibile al link<\/a><\/noindex>)<\/i><\/p>\n

    Il mio approccio si basa sul lavoro di William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Alla base dell'approccio c'\u00e8 l'idea che qualsiasi organizzazione possa essere suddivisa in quattro quadranti. Questo schema di solito rappresenta il risultato del lavoro con le centinaia di altri schemi che emergono durante l'analisi dell'organizzazione. Supponiamo di avere un'organizzazione con un alto livello di controllo, ma con una bassa competenza. Questa \u00e8 una situazione estremamente indesiderabile: quando tutti seguono le regole, ma nessuno sa cosa fare. <\/p>\n

    Un'opzione leggermente migliore con un alto livello di controllo e competenza. Se un'azienda ha profitto, potrebbe non avere nemmeno bisogno di DevOps. \u00c8 pi\u00f9 interessante lavorare con una compagnia che ha un alto livello di controllo, bassa competenza e collaborazione, ma allo stesso tempo un alto livello di cultura (cultivation). Questo significa che ci sono molte persone in azienda che apprezzano lavorare l\u00ec, e il turnover \u00e8 basso. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     visibile al link<\/a><\/noindex>)<\/i><\/p>\n

    Credo che i metodi con raccomandazioni rigorosamente definite finiscano per ostacolare il raggiungimento della verit\u00e0. In particolare, nel value stream mapping ci sono molte regole su come strutturare le informazioni. Nelle fasi iniziali di lavoro, di cui parlo ora, queste regole non servono a nessuno. Se una persona con un marcatore in mano descrive su una lavagna la situazione reale dell'azienda, questo \u00e8 il miglior modo per comprendere lo stato delle cose. Tale informazione non arriva ai direttori. In quel momento \u00e8 ridicolo interrompere la persona e dire che ha disegnato male qualche freccia. In questa fase \u00e8 meglio seguire regole semplici, ad esempio: si pu\u00f2 creare un'astrazione multilivello usando semplicemente marcatori di diversi colori. <\/p>\n

    Ripeto, niente tecnologie avanzate. Con il marcatore nero si rappresenta la realt\u00e0 oggettiva, come funziona tutto. Con il marcatore rosso le persone evidenziano cosa non gli piace della situazione attuale. \u00c8 importante che lo scrivano loro e non io. Quando dopo la riunione mi reco dal direttore IT, non propongo un elenco di 10 cose da correggere. Cerco di trovare connessioni tra ci\u00f2 che dicono le persone dell'azienda e i modelli comprovati esistenti. Infine, con il marcatore blu vengono suggerite possibili soluzioni al problema. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     visibile al link<\/a><\/noindex>)<\/i><\/p>\n

    Un esempio di tale approccio \u00e8 mostrato sopra. All'inizio di quest'anno ho lavorato con una banca. I dipendenti del dipartimento di sicurezza erano convinti di non dover partecipare alle revisioni di requisiti e progettazione (design and requirement reviews). <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     visibile al link<\/a><\/noindex>)<\/i><\/p>\n

    Poi abbiamo parlato con persone di altri dipartimenti e abbiamo scoperto che circa 8 anni fa gli sviluppatori di software avevano escluso i dipendenti della sicurezza poich\u00e9 rallentavano il lavoro. E poi questo si \u00e8 trasformato in un divieto che \u00e8 stato percepito come un dato di fatto. Anche se in realt\u00e0 non c'era alcun divieto. <\/p>\n

    Il nostro incontro si \u00e8 svolto in un modo estremamente confuso: per circa tre ore cinque diversi team non sono riusciti a spiegarmi cosa stesse succedendo tra il codice e la build. E questo dovrebbe essere, a dire il vero, la cosa pi\u00f9 semplice. La maggior parte dei consulenti DevOps presume che questo sia gi\u00e0 noto a tutti. <\/p>\n

    Poi, la persona responsabile della governance IT, che era rimasta in silenzio per quattro ore, ha preso la parola quando siamo arrivati al suo argomento e ci ha intrattenuto per un bel po'. Alla fine, gli ho chiesto cosa pensasse dell'incontro e non dimenticher\u00f2 mai la sua risposta. Ha detto: \u2018In precedenza pensavo che nella nostra banca ci fossero solo due modi di fornire software, ora so che ci sono ben cinque metodi, e di tre non avevo nemmeno idea\u2019. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     visibile al link<\/a><\/noindex>)<\/i><\/p>\n

    L'ultimo incontro in questa banca \u00e8 stato con il team che si occupa del software per gli investimenti. Con loro ho scoperto che \u00e8 meglio scrivere schemi con un evidenziatore su un foglio piuttosto che su una lavagna, e anche meglio che su una smartboard. <\/p>\n

    \"Sette
    \n
    \nLe foto che vedete sono di come appariva la sala conferenze dell'hotel il quarto giorno del nostro incontro. E questi schemi li abbiamo utilizzati per cercare modelli, ovvero archetipi. <\/p>\n

    Quindi, faccio domande ai dipendenti, loro annotano le risposte con evidenziatori di tre colori (nero, rosso e blu). Analizzo le loro risposte alla ricerca di archetipi. Adesso discutiamo tutti gli archetipi in ordine. <\/p>\n

    1. Make All Work Visible: Rendere il lavoro visibile<\/h3>\n

    \nNella maggior parte delle aziende con cui lavoro, c'\u00e8 una percentuale molto alta di lavoro non noto. Ad esempio, quando un dipendente si avvicina a un altro e chiede semplicemente di fare qualcosa. Nelle grandi organizzazioni, pu\u00f2 trattarsi del 60% di lavoro non pianificato. Fino al 40% del lavoro non \u00e8 affatto documentato. Se fosse Boeing, non prenderei mai pi\u00f9 un loro aereo. Se solo met\u00e0 del lavoro \u00e8 documentato, non si sa se questo lavoro venga svolto correttamente o meno. Tutti gli altri metodi risultano inutili: non ha senso cercare di automatizzare qualcosa, perch\u00e9 il 50% noto potrebbe essere proprio la parte pi\u00f9 coordinata e precisa del lavoro, la cui automazione non porterebbe grandi risultati, mentre il peggio si cela nella met\u00e0 invisibile. Senza documentazione, \u00e8 impossibile scoprire vari hack e lavori occulti, non trovare colli di bottiglia, i famosi 'Brent' di cui ho gi\u00e0 parlato. C'\u00e8 un ottimo libro di Dominica DeGrandis \u00abMaking Work Visible\u00bb<\/a><\/noindex>. Essa identifica cinque diversi \u00abladri di tempo\u00bb<\/b> (thieves of time):<\/p>\n