{"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\/pl\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Siedem archetyp\u00f3w transformacji wed\u0142ug zasad DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pytanie \u201ejak wdro\u017cy\u0107 DevOps w swoim zespole\u201d pojawia si\u0119 od wielu lat, ale nie ma zbyt wielu dobrych materia\u0142\u00f3w na ten temat. Czasami stajemy si\u0119 ofiarami reklam nieodpowiedzialnych konsultant\u00f3w, kt\u00f3rzy pr\u00f3buj\u0105 sprzeda\u0107 sw\u00f3j czas, niezale\u017cnie od tego, jak. Czasami s\u0105 to niejasne, bardzo og\u00f3lne s\u0142owa na temat tego, jak statki megakorporacji przemycaj\u0105 si\u0119 przez bezkres wszech\u015bwiata. Pojawia si\u0119 pytanie: co z tego mamy my? Szanowny autorze, czy mo\u017cesz w jasny spos\u00f3b przedstawi\u0107 swoje pomys\u0142y w formie listy?<\/p>\n

Wszystko to wynika z faktu, \u017ce rzeczywistej praktyki i zrozumienia wynik\u00f3w transformacji kultury w firmach jest jak na lekarstwo. Zmiany w kulturze s\u0105 procesem d\u0142ugofalowym, efekty kt\u00f3rych nie pojawi\u0105 si\u0119 w ci\u0105gu tygodnia ani miesi\u0105ca. Potrzebujemy kogo\u015b wystarczaj\u0105co do\u015bwiadczonego, kto widzia\u0142, jak przez lata powstawa\u0142y i upada\u0142y firmy.<\/p>\n

\"Siedem
\n
\nJohn Willis<\/b> jest jednym z ojc\u00f3w DevOps. Ma za sob\u0105 dziesi\u0105tki lat pracy z ogromn\u0105 liczb\u0105 firm. W ostatnim czasie John zacz\u0105\u0142 dostrzega\u0107 specyficzne wzorce, kt\u00f3re wyst\u0119puj\u0105 w pracy z ka\u017cd\u0105 z nich. Wykorzystuj\u0105c te archetypy, John prowadzi firmy na w\u0142a\u015bciw\u0105 drog\u0119 do transformacji DevOps. Wi\u0119cej o tych archetypach znajdziecie w t\u0142umaczeniu jego prezentacji z konferencji DevOops 2018.
\n<\/a><\/noindex>
\n

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

O prelegencie:<\/b><\/p>\n

Ponad 35 lat w zarz\u0105dzaniu IT, uczestniczy\u0142 w tworzeniu poprzednika OpenCloud w Canonical, bra\u0142 udzia\u0142 w 10 startupach, z kt\u00f3rych dwa sprzeda\u0142 Dellowi i Dockerowi. Obecnie jest wiceprezydentem ds. DevOps i praktyk cyfrowych w SJ Technologies.<\/p>\n

Przechodzimy teraz do narracji z perspektywy Johna.<\/b><\/p>\n

Nazywam si\u0119 John Willis i \u0142atwiej mnie znale\u017a\u0107 na Twitterze, @botchagalupe<\/a><\/noindex>. Taki sam pseudonim mam na Gmailu i GitHubie. A w tym linku<\/a><\/noindex> mo\u017cecie znale\u017a\u0107 nagrania moich wyst\u0105pie\u0144 oraz prezentacje do nich.<\/p>\n

Mam wiele spotka\u0144 z CIO r\u00f3\u017cnych du\u017cych firm. Bardzo cz\u0119sto narzekaj\u0105, \u017ce nie rozumiej\u0105, czym jest DevOps, a ka\u017cdy, kto pr\u00f3buje im to wyja\u015bni\u0107, m\u00f3wi o czym\u015b swoim. Innym cz\u0119stym narzekaniem jest to, \u017ce DevOps nie dzia\u0142a, chocia\u017c wydaje si\u0119, \u017ce dyrektorzy robi\u0105 wszystko zgodnie z wytycznymi. M\u00f3wimy o du\u017cych firmach, kt\u00f3re maj\u0105 ponad sto lat. Rozmawiaj\u0105c z nimi, doszed\u0142em do wniosku, \u017ce dla wielu problem\u00f3w lepiej pasuj\u0105 nie zaawansowane technologie, a bardziej niskottechnologiczne rozwi\u0105zania. Przez tygodnie po prostu rozmawia\u0142em z lud\u017ami z r\u00f3\u017cnych dzia\u0142\u00f3w. To, co widzicie na pierwszym obrazku w po\u015bcie \u2014 to m\u00f3j ostatni projekt, pok\u00f3j wygl\u0105da\u0142 tak po trzech dniach pracy.<\/p>\n

Czym jest DevOps?<\/h2>\n

\nRzeczywi\u015bcie, je\u015bli zapytasz 10 r\u00f3\u017cnych os\u00f3b, dadz\u0105 ci 10 r\u00f3\u017cnych odpowiedzi. Ale co ciekawe: wszystkie te dziesi\u0119\u0107 odpowiedzi b\u0119dzie poprawnych. Nie ma tutaj z\u0142ej odpowiedzi. Od oko\u0142o 10 lat zajmuj\u0119 si\u0119 DevOps, by\u0142em pierwszym Amerykaninem na pierwszym DevOpsDay. Nie powiem, \u017ce jestem m\u0105drzejszy od wszystkich, kt\u00f3rzy zajmuj\u0105 si\u0119 DevOps, ale trudno znale\u017a\u0107 kogo\u015b, kto po\u015bwi\u0119ci\u0142 na to tyle samo si\u0142. Uwa\u017cam, \u017ce DevOps powstaje wtedy, gdy \u0142\u0105cz\u0105 si\u0119 kapita\u0142 ludzki i technologia. Cz\u0119sto zapominamy o ludzkim wymiarze, chocia\u017c du\u017co m\u00f3wimy o r\u00f3\u017cnego rodzaju kulturach. <\/p>\n

\"Siedem
\n
\nObecnie posiadamy wiele danych, pi\u0119\u0107 lat bada\u0144 akademickich, weryfikacja teorii jest ju\u017c ustanowiona w skali przemys\u0142owej. Te badania m\u00f3wi\u0105 nam, \u017ce je\u015bli w kulturze organizacyjnej po\u0142\u0105czy si\u0119 pewne wzorce zachowa\u0144, mo\u017cna osi\u0105gn\u0105\u0107 przyspieszenie do 2000 razy. Temu przyspieszeniu odpowiada podobna poprawa odporno\u015bci. To ilo\u015bciowy pomiar tego, jakie korzy\u015bci mo\u017ce przynie\u015b\u0107 DevOps ka\u017cdej firmie. Kilka lat temu opowiada\u0142em o DevOps dyrektorowi generalnemu firmy z listy Fortune 5000. Gdy przygotowywa\u0142em si\u0119 do prezentacji, bardzo si\u0119 stresowa\u0142em, poniewa\u017c musia\u0142em w 5 minut przedstawi\u0107 swoje wieloletnie do\u015bwiadczenie. <\/p>\n

W rezultacie poda\u0142em nast\u0119puj\u0105ce definicj\u0119 DevOps<\/b>: to zestaw praktyk i wzorc\u00f3w, kt\u00f3re pozwalaj\u0105 przekszta\u0142ci\u0107 kapita\u0142 ludzki w wysoko wydajny kapita\u0142 organizacyjny. Przyk\u0142ad \u2014 spos\u00f3b, w jaki Toyota dzia\u0142a przez ostatnie 50 lub 60 lat.<\/p>\n

\"Siedem
\n
\n(Schemes like this are not provided as reference material, but as illustrations. Their content will differ for each new company. Nevertheless, the image can be viewed separately and enlarged) (through this link.)<\/a><\/noindex><\/i><\/p>\n

One of the most successful practices is value stream mapping<\/b>. Several good books have been written about this, with the most successful author being Karen Martin. However, over the past year, I've concluded that even this approach is too high-tech. It certainly has many advantages, which I have used extensively. But when the CEO asks you why his company can't switch to new systems, it's still too early to talk about value stream mapping. There are many significantly more fundamental questions that need to be answered first. <\/p>\n

I feel that a mistake many of my colleagues make is that they simply give the company a five-point guide and then return after six months to see what happened. Even a good scheme like value stream mapping has, so to speak, blind spots. After hundreds of interviews with directors from various companies, I've developed a certain pattern that allows me to break the problem down into components, and we will now discuss each of these components in order. Before applying any technological solutions, I use this pattern, and as a result, all my walls end up covered with diagrams. Recently, I worked with a mutual fund, and I ended up with 100-150 such diagrams.<\/p>\n

A bad culture eats good approaches for breakfast<\/h2>\n

\nThe main idea is this: no Lean, Agile, SAFE, or DevOps will help if the organization's culture is poor. It's like diving to depth without a diving suit or operating without an X-ray. In other words, paraphrasing Drucker and Deming: a poor organizational culture will consume any good system and not choke on it. <\/p>\n

To address this main problem, the following steps need to be taken:<\/p>\n

    \n
  1. Make All Work Visible:<\/b> it is necessary to make all work visible. Not in the sense that it must necessarily be displayed on some screen, but in the sense that it should be observable.<\/li>\n
  2. Consolidate Work Management Systems:<\/b> Nale\u017cy skonsolidowa\u0107 systemy zarz\u0105dzania. W problemie \u201eplemiennej\u201d wiedzy i wiedzy instytucjonalnej w 9 na 10 przypadk\u00f3w w\u0105skim gard\u0142em s\u0105 ludzie. W ksi\u0105\u017cce \u201ePhoenix Project\u201d<\/a><\/noindex> problem by\u0142 jednocze\u015bnie zwi\u0105zany z jednym cz\u0142owiekiem, Brentem, przez kt\u00f3rego projekt mia\u0142 trzy lata op\u00f3\u017anienia. Na takich \u201eBrent\u00f3w\u201d natykam si\u0119 wsz\u0119dzie. Aby rozwi\u0105za\u0107 te w\u0105skie gard\u0142a, stosuj\u0119 dwa punkty z naszego wykazu. <\/li>\n
  3. Metodologia Teorii Ogranicze\u0144:<\/b> teoria ogranicze\u0144.<\/li>\n
  4. Zarz\u0105dzanie wsp\u00f3\u0142prac\u0105:<\/b> hakowanie wsp\u00f3\u0142pracy. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> o Toyota Kata nie b\u0119d\u0119 du\u017co m\u00f3wi\u0142. Je\u015bli to interesuj\u0105ce, na moim GitHubie s\u0105 prezentacje<\/a><\/noindex> niemal na ka\u017cdy z tych temat\u00f3w. <\/li>\n
  6. Organizacja zorientowana na rynek:<\/b> organizacja zorientowana na rynek.<\/li>\n
  7. Audyty wczesnego etapu:<\/b> audyt na wczesnych etapach cyklu.<\/li>\n<\/ol>\n

    \"Siedem
    \n
    \nZaczynam prac\u0119 z organizacj\u0105 w bardzo prosty spos\u00f3b: id\u0119 do firmy i rozmawiam z pracownikami. Jak wida\u0107, \u017cadnej nowoczesnej technologii. Wszystko, co potrzebne, to co\u015b, na czym mo\u017cna pisa\u0107. Zbieram kilka zespo\u0142\u00f3w w jednym pomieszczeniu i analizuj\u0119 to, co m\u00f3wi\u0105, z perspektywy moich 7 archetyp\u00f3w. A potem daj\u0119 im marker i prosz\u0119, aby spisali na tablicy wszystko, co do tej pory m\u00f3wili na g\u0142os. Zazwyczaj na takich spotkaniach jest jedna osoba, kt\u00f3ra wszystko zapisuje, i w najlepszym przypadku udaje jej si\u0119 zanotowa\u0107 10% dyskusji. Moja metoda pozwala podnie\u015b\u0107 ten wska\u017anik do oko\u0142o 40%. <\/p>\n

    \"Siedem
    \n
    \n(T\u0119 ilustracj\u0119 mo\u017cna osobno     obejrze\u0107 pod tym linkiem<\/a><\/noindex>)<\/i><\/p>\n

    Moje podej\u015bcie opiera si\u0119 na pracy Williama Schneidera (William Schneider, The Reengineering Alternative<\/a><\/noindex>). W centrum podej\u015bcia le\u017cy my\u015bl, \u017ce ka\u017cd\u0105 organizacj\u0119 mo\u017cna roz\u0142o\u017cy\u0107 na cztery kwadraty. Ta schemat jest zwykle wynikiem pracy z setkami innych schemat\u00f3w, kt\u00f3re pojawiaj\u0105 si\u0119 podczas analizy organizacji. Za\u0142\u00f3\u017cmy, \u017ce mamy organizacj\u0119 z wysokim poziomem kontroli, ale z nisk\u0105 kompetencj\u0105. To niezwykle niepo\u017c\u0105dana sytuacja: gdy wszyscy chodz\u0105 w rytmie, ale nikt nie wie, co nale\u017cy robi\u0107. <\/p>\n

    Nieco lepsza opcja z wysokim poziomem zar\u00f3wno kontroli, jak i kompetencji. Je\u015bli taka firma przynosi zyski, to by\u0107 mo\u017ce DevOps nie jest jej potrzebny. Najciekawiej jest pracowa\u0107 z firm\u0105, kt\u00f3ra ma wysoki poziom kontroli, nisk\u0105 kompetencj\u0119 i wsp\u00f3\u0142prac\u0119, ale jednocze\u015bnie wysok\u0105 kultur\u0119 (cultivation). Oznacza to, \u017ce w firmie jest wielu ludzi, kt\u00f3rzy lubi\u0105 tam pracowa\u0107, a rotacja pracownik\u00f3w jest niska. <\/p>\n

    \"Siedem
    \n
    \n(T\u0119 ilustracj\u0119 mo\u017cna osobno     obejrze\u0107 pod tym linkiem<\/a><\/noindex>)<\/i><\/p>\n

    Wydaje mi si\u0119, \u017ce metody z sztywno okre\u015blonymi wytycznymi ostatecznie utrudniaj\u0105 osi\u0105gni\u0119cie prawdy. W szczeg\u00f3lno\u015bci, w mapowaniu strumienia warto\u015bci jest wiele zasad dotycz\u0105cych tego, jak nale\u017cy strukturalizowa\u0107 informacje. Na wczesnych etapach pracy, o kt\u00f3rych m\u00f3wi\u0119, te zasady nikomu nie s\u0105 potrzebne. Gdy osoba z markerem w r\u0119ku opisuje na tablicy rzeczywist\u0105 sytuacj\u0119 w firmie \u2014 to najlepszy spos\u00f3b, aby zrozumie\u0107 stan rzeczy. Tego rodzaju informacje nie docieraj\u0105 do dyrektor\u00f3w. W tym momencie g\u0142upot\u0105 jest przerywanie i m\u00f3wienie, \u017ce kto\u015b niew\u0142a\u015bciwie narysowa\u0142 jak\u0105\u015b strza\u0142k\u0119. Na tym etapie lepiej stosowa\u0107 proste zasady, na przyk\u0142ad: wielopoziomow\u0105 abstrakcj\u0119 mo\u017cna stworzy\u0107, u\u017cywaj\u0105c po prostu kolorowych marker\u00f3w. <\/p>\n

    Powtarzam, \u017cadnych wysokich technologii. Czarnym markerem przedstawiana jest obiektywna rzeczywisto\u015b\u0107, jak wszystko dzia\u0142a. Czerwonym markerem ludzie zaznaczaj\u0105, co dok\u0142adnie im nie odpowiada w obecnym stanie rzeczy. Wa\u017cne jest, \u017ce to oni to pisz\u0105, a nie ja. Kiedy po spotkaniu id\u0119 do dyrektora ds. technologii informacyjnej, nie przedk\u0142adam listy 10 rzeczy, kt\u00f3re trzeba poprawi\u0107. D\u0105\u017c\u0119 do znalezienia powi\u0105za\u0144 mi\u0119dzy tym, co m\u00f3wi\u0105 ludzie z firmy, a istniej\u0105cymi sprawdzonymi wzorcami. W ko\u0144cu, niebieskim markerem proponowane s\u0105 mo\u017cliwe rozwi\u0105zania problemu. <\/p>\n

    \"Siedem
    \n
    \n(T\u0119 ilustracj\u0119 mo\u017cna osobno     obejrze\u0107 pod tym linkiem<\/a><\/noindex>)<\/i><\/p>\n

    Przyk\u0142ad takiego podej\u015bcia jest teraz przedstawiony powy\u017cej. Na pocz\u0105tku tego roku pracowa\u0142em z jednym bankiem. Pracownicy z dzia\u0142u bezpiecze\u0144stwa byli przekonani, \u017ce nie mog\u0105 uczestniczy\u0107 w przegl\u0105dach wymaga\u0144 i projektowania (design and requirement reviews). <\/p>\n

    \"Siedem
    \n
    \n(T\u0119 ilustracj\u0119 mo\u017cna osobno     obejrze\u0107 pod tym linkiem<\/a><\/noindex>)<\/i><\/p>\n

    A potem rozmawiali\u015bmy z lud\u017ami z innych dzia\u0142\u00f3w i okaza\u0142o si\u0119, \u017ce oko\u0142o 8 lat temu programi\u015bci oprogramowania wyeliminowali pracownik\u00f3w bezpiecze\u0144stwa, poniewa\u017c spowalniali prac\u0119. A potem to przekszta\u0142ci\u0142o si\u0119 w zakaz, kt\u00f3ry by\u0142 postrzegany jako fakt. Chocia\u017c tak naprawd\u0119 \u017cadnego zakazu nie by\u0142o. <\/p>\n

    Nasze spotkanie mia\u0142o niezwykle skomplikowany przebieg: przez oko\u0142o trzy godziny pi\u0119\u0107 r\u00f3\u017cnych zespo\u0142\u00f3w nie mog\u0142o mi wyja\u015bni\u0107, co si\u0119 dzieje mi\u0119dzy kodem a kompilacj\u0105. A to wydawa\u0142a si\u0119 najprostsza rzecz. Wi\u0119kszo\u015b\u0107 konsultant\u00f3w DevOps zak\u0142ada z g\u00f3ry, \u017ce to ju\u017c jest wszystkim znane. <\/p>\n

    Potem osoba odpowiedzialna za zarz\u0105dzanie IT (IT governance), milcza\u0142a przez cztery godziny, nagle si\u0119 o\u017cywi\u0142a, gdy dotarli\u015bmy do jej tematu, i zaj\u0119\u0142a nas jeszcze na do\u015b\u0107 d\u0142ugi czas. Na koniec zapyta\u0142em j\u0105, co my\u015bli o spotkaniu, i nigdy nie zapomn\u0119 jej odpowiedzi. Powiedzia\u0142a: 'Dawniej my\u015bla\u0142em, \u017ce w naszym banku s\u0105 tylko dwa sposoby dostarczania oprogramowania, a teraz wiem, \u017ce jest ich ca\u0142ych pi\u0119\u0107, a o trzech nawet nie mia\u0142em poj\u0119cia.' <\/p>\n

    \"Siedem
    \n
    \n(T\u0119 ilustracj\u0119 mo\u017cna osobno     obejrze\u0107 pod tym linkiem<\/a><\/noindex>)<\/i><\/p>\n

    Ostatnie spotkanie w tym banku odby\u0142o si\u0119 z zespo\u0142em zajmuj\u0105cym si\u0119 oprogramowaniem dla inwestycji. To w\u0142a\u015bnie z nim okaza\u0142o si\u0119, \u017ce lepiej pisa\u0107 schematy markerem na kartce ni\u017c na tablicy, a nawet lepiej ni\u017c na smartboardzie. <\/p>\n

    \"Siedem
    \n
    \nZdj\u0119cia, kt\u00f3re widzicie, przedstawiaj\u0105 to, jak wygl\u0105da\u0142a sala konferencyjna hotelu w czwarty dzie\u0144 naszego spotkania. I te schematy wykorzystali\u015bmy do poszukiwania wzorc\u00f3w, czyli archetyp\u00f3w. <\/p>\n

    Tak wi\u0119c, zadaj\u0119 pytania pracownikom, oni zapisuj\u0105 odpowiedzi markerami trzech kolor\u00f3w (czarnym, czerwonym i niebieskim). Analizuj\u0119 ich odpowiedzi pod k\u0105tem archetyp\u00f3w. Teraz porozmawiajmy o wszystkich archetypach w kolejno\u015bci. <\/p>\n

    1. Make All Work Visible: Uczyni\u0107 prac\u0119 widoczn\u0105<\/h3>\n

    \nW wi\u0119kszo\u015bci firm, z kt\u00f3rymi pracuj\u0119, wyst\u0119puje bardzo wysoki procent niezaplanowanej pracy. Na przyk\u0142ad, kiedy jeden pracownik przychodzi do drugiego i po prostu prosi o zrobienie czego\u015b. W du\u017cych organizacjach mo\u017ce to by\u0107 a\u017c 60% niezaplanowanej pracy. A\u017c do 40% pracy nie jest dokumentowane w \u017caden spos\u00f3b. Gdyby to by\u0142 Boeing, to nigdy wi\u0119cej bym nie wsiad\u0142 do ich samolotu. Je\u015bli dokumentowana jest tylko po\u0142owa pracy, to nie wiadomo, czy ta praca jest wykonywana poprawnie. Wszystkie inne metody okazuj\u0105 si\u0119 bezu\u017cyteczne \u2014 nie ma sensu pr\u00f3bowa\u0107 cokolwiek zautomatyzowa\u0107, poniewa\u017c znane 50% mo\u017ce by\u0107 najbardziej zorganizowan\u0105 i klarown\u0105 cz\u0119\u015bci\u0105 pracy, kt\u00f3ra nie przyniesie du\u017cych rezultat\u00f3w, a to, co najgorsze, znajduje si\u0119 w tej niewidocznej po\u0142owie. W przypadku braku dokumentacji niemo\u017cliwe jest znalezienie r\u00f3\u017cnego rodzaju hack\u00f3w i ukrytej pracy, a tak\u017ce identyfikacja w\u0105skich garde\u0142, tych \u201eBrent\u00f3w\u201d, o kt\u00f3rych ju\u017c wspomnia\u0142em. Jest \u015bwietna ksi\u0105\u017cka autorstwa Dominiki DeGrandis. \u201eMaking Work Visible\u201d<\/a><\/noindex>. Odkrywa pi\u0119\u0107 r\u00f3\u017cnych \u201euchwyty czasu\u201d<\/b> (thieves of time):<\/p>\n