{"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 DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La questione \u00abcome implementare DevOps\u00bb \u00e8 in circolazione da anni, ma le risorse valide non sono molte. A volte si diventa vittime della pubblicit\u00e0 di consulenti non particolarmente intelligenti, che cercano di vendere il loro tempo, indipendentemente da come. Talvolta si tratta di discorsi vaghi e estremamente generali su come le navi delle mega-corporazioni solcano l'universo. Nasce la domanda: e a noi che importa? Stimato autore, potrebbe elencare chiaramente le sue idee?<\/p>\n

Tutto ci\u00f2 deriva dal fatto che non c'\u00e8 molta pratica reale e comprensione dei risultati delle trasformazioni culturali aziendali. I cambiamenti nella cultura richiedono tempo, e i risultati non si vedranno n\u00e9 dopo una settimana n\u00e9 dopo un mese. Abbiamo bisogno di qualcuno abbastanza esperto, che abbia visto come sono nate e cadute le aziende nel corso degli anni.<\/p>\n

\"Sette
\n
\nJohn Willis<\/b> \u00e8 uno dei padri fondatori di DevOps. John ha alle spalle decenni di lavoro con un numero enorme di aziende. Recentemente, ha iniziato a notare modelli specifici che emergono nel lavoro con ciascuna di esse. Utilizzando questi archetipi, John guida le aziende verso un'autentica trasformazione DevOps. Maggiori dettagli su questi archetipi sono disponibili nella traduzione del suo intervento alla conferenza DevOops 2018.
\n<\/a><\/noindex>
\n

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

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

Oltre 35 anni di esperienza nella gestione IT, ha contribuito alla creazione del predecessore di OpenCloud in Canonical, ha partecipato 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, la narrazione da parte di John.<\/b><\/p>\n

Mi chiamo John Willis, e il modo pi\u00f9 semplice per trovarmi \u00e8 su Twitter, @botchagalupe<\/a><\/noindex>. Ho lo stesso pseudonimo anche su Gmail e GitHub. A questo link<\/a><\/noindex> puoi trovare le registrazioni video delle mie presentazioni e le diapositive associate.<\/p>\n

Ho molte conversazioni con CIO di grandi aziende. Spesso si lamentano di non capire cosa sia DevOps, mentre chi cerca di spiegarlo parla di argomenti estranei. Un'altra lamentela comune \u00e8 che DevOps non funziona, anche se i direttori seguono le istruzioni. Si parla di grandi aziende, con oltre cento anni di storia. Dopo aver parlato con loro, ho concluso che per molti problemi, le soluzioni pi\u00f9 appropriate sono le meno tecnologiche. Ho passato settimane semplicemente parlando con persone di diversi reparti. Quello che vedi nell'immagine all'inizio del post \u00e8 il mio ultimo progetto, la stanza aveva questo aspetto dopo tre giorni di lavoro.<\/p>\n

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

\nInfatti, se chiedi a 10 persone diverse, ognuna dar\u00e0 una risposta diversa. Ma c'\u00e8 una cosa interessante: tutte queste dieci risposte saranno corrette. Non esiste una risposta sbagliata. Mi sono immerso nel DevOps per circa 10 anni, sono stato il primo americano al primo DevOpsDay. Non dir\u00f2 di essere pi\u00f9 intelligente di tutti gli altri che lavorano nel DevOps, ma \u00e8 difficile trovare qualcuno che abbia dedicato cos\u00ec tanto impegno. Credo che il DevOps emerga quando si combinano capitale umano e tecnologia. Spesso dimentichiamo il fattore umano, anche se parliamo tanto di vari tipi di cultura. <\/p>\n

\"Sette
\n
\nOra abbiamo una grande quantit\u00e0 di dati, cinque anni di studi accademici, e la verifica delle teorie \u00e8 diventata una pratica scalabile. Questi studi ci dicono che se in una cultura organizzativa si combinano alcuni modelli comportamentali, si pu\u00f2 ottenere un'accelerazione di 2000 volte. Questa accelerazione corrisponde a un miglioramento equivalente della stabilit\u00e0. Questa \u00e8 una misurazione quantitativa del vantaggio che DevOps pu\u00f2 offrire a qualsiasi azienda. Alcuni anni fa, ho parlato di DevOps con il CEO di una societ\u00e0 della lista Fortune 5000. Quando mi stavo preparando per la presentazione, ero molto nervoso, perch\u00e9 dovevo riassumere anni di esperienza in 5 minuti. <\/p>\n

Alla fine ho dato la seguente definizione di DevOps<\/b>: \u00e8 un insieme di pratiche e modelli che consentono di trasformare il capitale umano in capitale organizzativo altamente produttivo. Un esempio \u00e8 come Toyota lavora da ultimo 50 o 60 anni.<\/p>\n

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

Una delle pratiche di maggior successo \u00e8 la value stream mapping<\/b>. Sono stati scritti diversi buoni libri su questo argomento, il pi\u00f9 famoso dei quali \u00e8 di Karen Martin. Tuttavia, nell'ultimo anno ho concluso che persino questo approccio \u00e8 troppo tecnologico. Ha indubbiamente molti vantaggi, di cui ho beneficiato ampiamente. Ma quando l'amministratore delegato ti chiede perch\u00e9 la sua azienda non riesca a passare a nuove ferrovie, \u00e8 ancora presto per parlare di value stream mapping. Ci sono molte domande molto pi\u00f9 fondamentali a cui \u00e8 necessario rispondere in anticipo. <\/p>\n

A mio avviso, l'errore di molti dei miei colleghi \u00e8 che forniscono semplicemente all'azienda una guida in cinque punti e poi tornano dopo sei mesi per vedere cosa \u00e8 successo. Anche uno schema buono come il value stream mapping ha, diciamo cos\u00ec, zone morte (blind spots). Dopo centinaia di interviste con direttori di diverse aziende, ho sviluppato un certo schema che consente di suddividere il problema in componenti, e ora discuteremo ciascuna di queste componenti in ordine. Prima di applicare qualsiasi soluzione tecnologica, utilizzo questo schema, e alla fine ho le pareti coperte di diagrammi. Di recente ho lavorato con un fondo comune e alla fine ho avuto 100-150 di questi diagrammi.<\/p>\n

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

\nIl concetto principale \u00e8 questo: nessun Lean, Agile, SAFE o DevOps funzioner\u00e0 se la cultura stessa dell'organizzazione \u00e8 scarsa. \u00c8 come tuffarsi in profondit\u00e0 senza un respiratore o operare senza una radiografia. In altre parole, parafrasando Drucker e Deming: una cattiva cultura organizzativa inghiottir\u00e0 qualsiasi buon sistema e non si soffermer\u00e0. <\/p>\n

Per risolvere questo problema principale, \u00e8 necessario compiere i seguenti passi:<\/p>\n

    \n
  1. Rendere tutto il lavoro visibile:<\/b> \u00e8 necessario rendere visibile tutto il lavoro. Non nel senso che debba necessariamente essere visualizzato su uno schermo, ma nel senso che deve essere osservabile.<\/li>\n
  2. Consolidare i sistemi di gestione del lavoro:<\/b> \u00e8 necessario consolidare i sistemi di management. Nel problema della conoscenza 'tribale' e della conoscenza istituzionale, nel 9 casi su 10 il collo di bottiglia sono le persone. Nel libro \u00abPhoenix Project\u00bb<\/a><\/noindex> la questione riguardava una sola persona, Brent, che ha causato un ritardo nel progetto di tre anni. E persone come questo \u2018Brent\u2019 le incontro ovunque. Per risolvere questi colli di bottiglia, utilizzo i seguenti due punti nella nostra lista. <\/li>\n
  3. Metodologia della Teoria dei Vincoli:<\/b> teoria dei vincoli.<\/li>\n
  4. Trucchi di collaborazione:<\/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> su quasi ciascuno di questi temi. <\/li>\n
  6. Organizzazione orientata al mercato:<\/b> organizzazione orientata al mercato.<\/li>\n
  7. Auditor sinistra:<\/b> audit nelle fasi iniziali del ciclo.<\/li>\n<\/ol>\n

    \"Sette
    \n
    \nInizio il lavoro con un'organizzazione in modo molto semplice: vado in azienda e parlo con i dipendenti. Come si pu\u00f2 vedere, nessuna alta tecnologia. Tutto ci\u00f2 che serve \u00e8 avere qualcosa su cui scrivere. Riunisco alcune squadre in una stanza e analizzo ci\u00f2 che mi dicono, dal punto di vista dei miei 7 archetipi. Poi do loro un marcatore e chiedo di esporre sulla lavagna tutto ci\u00f2 che hanno detto finora ad alta voce. Di solito in questi incontri c'\u00e8 una persona che prende appunti, e nel migliore dei casi riesce a registrare il 10% della discussione. Con il mio metodo, riesco a far salire questa cifra a circa il 40%. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     vista tramite il link<\/a><\/noindex>)<\/i><\/p>\n

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

    Una situazione leggermente migliore \u00e8 quella con un alto livello sia di controllo che di competenza. Se un'azienda di questo tipo \u00e8 profittevole, potrebbe darsi che non abbia nemmeno bisogno di DevOps. \u00c8 molto pi\u00f9 interessante lavorare con un'azienda che ha un alto livello di controllo, bassa competenza e collaborazione, ma con un alto livello di cultura (cultivation). Questo significa che in azienda ci sono molte persone che amano lavorare l\u00ec, e il turnover del personale \u00e8 basso. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     vista tramite il link<\/a><\/noindex>)<\/i><\/p>\n

    Ritengo che i metodi con linee guida rigide 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 del lavoro, di cui parlo ora, queste regole non servono a nessuno. Se una persona con un evidenziatore in mano descrive la situazione reale di un'azienda su una lavagna, questo \u00e8 il miglior modo per capire lo stato delle cose. Queste informazioni non arrivano ai direttori. In quel momento, sarebbe sciocco interrompere qualcuno dicendo che ha disegnato male una freccia. In questa fase, \u00e8 meglio seguire semplici regole, come: \u00e8 possibile creare un'astrazione multilivello usando semplicemente evidenziatori di colori diversi. <\/p>\n

    Ripeto, niente tecnologie avanzate. La realt\u00e0 oggettiva viene rappresentata con un evidenziatore nero, come funziona tutto. Con un evidenziatore rosso le persone segnalano 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 legami tra ci\u00f2 che dicono le persone dell'azienda e i modelli consolidati esistenti. Infine, con un evidenziatore blu vengono suggerite possibili soluzioni ai problemi. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     vista tramite il link<\/a><\/noindex>)<\/i><\/p>\n

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

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     vista tramite il link<\/a><\/noindex>)<\/i><\/p>\n

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

    La nostra riunione ha preso un percorso estremamente confuso: per circa tre ore cinque team diversi non sono riusciti a spiegarmi cosa stesse succedendo tra il codice e la build. E questa, a prima vista, sembrerebbe la cosa pi\u00f9 semplice. La maggior parte dei consulenti DevOps presume in anticipo 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, si \u00e8 improvvisamente animata quando abbiamo toccato il suo argomento, e ci ha tenuto occupati per un periodo piuttosto lungo. Alla fine, gli ho chiesto cosa pensasse dell'incontro, e non dimenticher\u00f2 mai la sua risposta. Ha detto: \u00abPrima pensavo che nella nostra banca ci fossero solo due modi di consegna del software, ma ora so che ce ne sono cinque, e di tre nemmeno sospettavo\u00bb. <\/p>\n

    \"Sette
    \n
    \n(Questa illustrazione pu\u00f2 essere     vista tramite il link<\/a><\/noindex>)<\/i><\/p>\n

    L'ultima riunione in questa banca \u00e8 stata con il team che si occupa del software per gli investimenti. \u00c8 proprio con loro che si \u00e8 scoperto che scrivere schemi con un evidenziatore su un foglio \u00e8 meglio che farlo su una lavagna, e persino meglio che su una smartboard. <\/p>\n

    \"Sette
    \n
    \nLe foto che vedete mostrano come appariva la sala conferenze dell'hotel nel quarto giorno della nostra riunione. E questi schemi li abbiamo utilizzati per cercare modelli, ovvero archetipi. <\/p>\n

    Quindi, faccio domande ai dipendenti, e loro annotano le risposte con evidenziatori di tre colori (nero, rosso e blu). Analizzo le loro risposte in cerca 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, esiste una percentuale molto alta di lavoro sconosciuto. Ad esempio, quando un dipendente si avvicina a un altro e gli chiede semplicemente di fare qualcosa. Nelle grandi organizzazioni, pu\u00f2 arrivare fino al 60% del lavoro non pianificato. E fino al 40% del lavoro non \u00e8 documentato in alcun modo. Se fosse Boeing, non prendere pi\u00f9 mai un loro aereo. Se viene documentata solo met\u00e0 del lavoro, non si sa se quel lavoro venga eseguito correttamente o meno. Tutti gli altri metodi si rivelano inutili: non ha senso cercare di automatizzare qualcosa, perch\u00e9 il 50% noto potrebbe essere proprio la parte pi\u00f9 coordinata e chiara del lavoro, la cui automazione non porta grandi risultati, mentre la parte peggiore \u00e8 nella met\u00e0 invisibile. Senza documentazione, \u00e8 impossibile scoprire vari tipi di hack e lavoro nascosto, individuare colli di bottiglia, quei famosi \u00abBrent\u00bb di cui ho gi\u00e0 parlato. C'\u00e8 un ottimo libro di Dominica DeGrandis \u00abMaking Work Visible\u00bb<\/a><\/noindex>. Identifica cinque diverse \u00abfughe di tempo\u00bb<\/b> (thieves of time):<\/p>\n