{"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\/no\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Syv arketyper for transformasjon basert p\u00e5 DevOps-prinsipper","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sp\u00f8rsm\u00e5let om \u00abhvordan implementere DevOps selv\u00bb har v\u00e6rt aktuelt i mange \u00e5r, men gode ressurser er ikke s\u00e5 mange. Noen ganger blir man offer for reklame fra mindre kloke konsulenter som bare \u00f8nsker \u00e5 selge sin tid, uansett hvordan. Av og til er det uklare og sv\u00e6rt generelle utsagn om hvordan megaselskapenes skip krysser universets rom. Det reiser sp\u00f8rsm\u00e5let: hva f\u00e5r vi ut av dette? Kj\u00e6re forfatter, kan du formulere dine ideer p\u00e5 en klar liste?<\/p>\n

Alt dette skyldes at det ikke har samlet seg s\u00e5 mye reell erfaring og forst\u00e5else av utfallene av kulturtransformasjoner. Endringer i kulturen er langsiktige prosesser, hvis resultater ikke vil vise seg p\u00e5 en uke eller en m\u00e5ned. Vi trenger noen som er tilstrekkelig erfaren, som har sett hvordan selskaper har blitt til og blitt \u00f8delagt gjennom mange \u00e5r.<\/p>\n

\"Syv
\n
\nJohn Willis<\/b> \u2014 en av fedrene til DevOps. John har mange \u00e5r med erfaring fra et stort antall selskaper. P\u00e5 det siste har John lagt merke til spesifikke m\u00f8nstre som er til stede i arbeidet med hver av dem. Ved \u00e5 bruke disse arketypene guider John selskaper p\u00e5 den riktige veien for DevOps-transformasjon. Mer om disse arketypene finner du i oversettelsen av hans foredrag fra DevOops-konferansen i 2018.
\n<\/a><\/noindex>
\n

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

Om foredragsholderen:<\/b><\/p>\n

Over 35 \u00e5r innen IT-ledelse, deltatt i utviklingen av forgjengeren til OpenCloud i Canonical, v\u00e6rt med i 10 oppstartsselskaper, to av dem solgt til Dell og Docker. N\u00e5v\u00e6rende Vice President of DevOps and Digital Practices i SJ Technologies.<\/p>\n

Deretter f\u00f8lger en beretning fra John.<\/b><\/p>\n

Mitt navn er John Willis, og jeg er lett \u00e5 finne p\u00e5 Twitter, @botchagalupe<\/a><\/noindex>. Jeg bruker samme pseudonym p\u00e5 Gmail og GitHub. Og ved denne linken<\/a><\/noindex> kan du finne videoopptak av mine foredrag og presentasjoner.<\/p>\n

Jeg har mange m\u00f8ter med CIO-er i forskjellige store selskaper. De klager veldig ofte p\u00e5 at de ikke forst\u00e5r hva DevOps er, og alle som pr\u00f8ver \u00e5 forklare det for dem, snakker om noe helt annet. En annen vanlig klage er at DevOps ikke fungerer, selv om direkt\u00f8rene tilsynelatende gj\u00f8r alt som de har f\u00e5tt forklart. Dette gjelder store selskaper som har eksisterte i over hundre \u00e5r. Etter \u00e5 ha snakket med dem, konkluderte jeg med at l\u00f8sningen p\u00e5 mange problemer best oppn\u00e5s med relativt lavteknologiske l\u00f8sninger, snarere enn h\u00f8yteknologiske. I uker snakket jeg bare med folk fra forskjellige avdelinger. Det du ser p\u00e5 det aller f\u00f8rste bildet i innlegget \u2013 dette var mitt siste prosjekt, rommet s\u00e5 slik ut etter tre dagers arbeid.<\/p>\n

Hva er DevOps?<\/h2>\n

\nDet er sant at hvis du sp\u00f8r ti forskjellige mennesker, vil de gi ti forskjellige svar. Men det interessante er at alle disse ti svarene vil v\u00e6re riktige. Det finnes ikke noe galt svar her. Jeg har jobbet dypt med DevOps i omtrent ti \u00e5r, var den f\u00f8rste amerikaneren p\u00e5 den f\u00f8rste DevOpsDay. Jeg vil ikke si at jeg er smartere enn alle som jobber med DevOps, men det er neppe noen som har investert like mye tid og krefter som jeg har. Jeg mener at DevOps oppst\u00e5r n\u00e5r menneskelig kapital og teknologi m\u00f8tes. Vi glemmer ofte den menneskelige dimensjonen, selv om vi snakker mye om alle slags kulturer. <\/p>\n

\"Syv
\n
\nN\u00e5 har vi mye data, fem \u00e5rs akademisk forskning, og teoriene er blitt testet i stor skala. Denne forskningen forteller oss f\u00f8lgende: hvis man i organisasjonskulturen forener visse atferdsm\u00f8nstre, kan man oppn\u00e5 en effektivitets\u00f8kning p\u00e5 2000 ganger. Denne \u00f8kningen tilsvarer en tilsvarende forbedring i robusthet. Dette er en kvantitativ m\u00e5ling av den fordelen DevOps kan gi enhver bedrift. For et par \u00e5r siden snakket jeg om DevOps med administrerende direkt\u00f8r i et Fortune 5000-selskap. Da jeg forberedte meg til presentasjonen, var jeg veldig nerv\u00f8s, fordi jeg m\u00e5tte oppsummere mange \u00e5rs erfaring p\u00e5 fem minutter. <\/p>\n

Til slutt gav jeg f\u00f8lgende definisjon av DevOps<\/b>: det er et sett med praksiser og m\u00f8nstre som gj\u00f8r det mulig \u00e5 omdanne menneskelig kapital til h\u00f8yytelses organisasjonskapital. Et eksempel er m\u00e5ten Toyota har operert p\u00e5 de siste 50 eller 60 \u00e5rene.<\/p>\n

\"Syv
\n
\n(Her og videre er s\u00e5danne skemaer ikke blot til reference, men som illustration. Indholdet vil variere for hver ny virksomhed. Dog kan billedet ses separat og forst\u00f8rres via dette link.)<\/a><\/noindex><\/i><\/p>\n

En af de mest succesfulde praksisser er value stream mapping<\/b>. Der er skrevet flere gode b\u00f8ger om dette emne, hvor den mest succesfulde forfatter er Karen Martin. Men i l\u00f8bet af det sidste \u00e5r er jeg kommet til den konklusion, at selv denne tilgang er for h\u00f8jteknologisk. Den har bestemt mange fordele, og jeg har haft stor gavn af den. Men n\u00e5r administrerende direkt\u00f8r sp\u00f8rger dig, hvorfor hans virksomhed ikke kan skifte til nye spor, er det for tidligt at tale om value stream mapping. Der er mange betydeligt mere fundamentale sp\u00f8rgsm\u00e5l, som man f\u00f8rst skal finde svar p\u00e5. <\/p>\n

Jeg mener, at mange af mine kollegaers fejl er, at de blot giver virksomheden en vejledning i fem punkter, og s\u00e5 vender de tilbage om seks m\u00e5neder for at se, hvad der er sket. Selv med et godt skema som value stream mapping er der, lad os sige, blinde omr\u00e5der. Efter hundredevis af interviews med direkt\u00f8rer i forskellige virksomheder har jeg udviklet et bestemt m\u00f8nster, der g\u00f8r det muligt at opdele problemet i komponenter, og nu vil vi systematisk diskutere hver af disse komponenter. F\u00f8r jeg anvender nogen teknologiske l\u00f8sninger, bruger jeg dette m\u00f8nster, og resultatet er, at alle mine v\u00e6gge ender med at v\u00e6re d\u00e6kket af skemaer. For nylig arbejdede jeg med en investeringsfond, og jeg endte med 100-150 s\u00e5danne skemaer.<\/p>\n

D\u00e5rlig kultur spiser gode tilgange til morgenmad<\/h2>\n

\nHovedideen er, at ingen Lean, Agile, SAFE og DevOps vil hj\u00e6lpe, hvis selve kulturen i organisationen er d\u00e5rlig. Det er ligesom at dykke ned uden iltflaske eller operere uden r\u00f8ntgenbillede. Med andre ord, parafraserende Drucker og Deming: en d\u00e5rlig organisationskultur vil opsluge ethvert godt system og ikke kv\u00e6le sig. <\/p>\n

For at l\u00f8se dette hovedproblem er det n\u00f8dvendigt at tage f\u00f8lgende skridt:<\/p>\n

    \n
  1. G\u00f8r alt arbejde synligt:<\/b> man skal g\u00f8re alt arbejde synligt. Ikke i den forstand, at det n\u00f8dvendigvis skal vises p\u00e5 en sk\u00e6rm, men at det skal v\u00e6re observerbart.<\/li>\n
  2. Konsolider arbejdsstyringssystemer:<\/b> det er n\u00f8dvendig \u00e5 konsolidere systemene for ledelse. I problematikken med \u00abstamme\u00bb-kunnskap og institusjonell kunnskap er mennesker ofte flaskehalsen i 9 av 10 tilfeller. I boken \u00abPhoenix Project\u00bb<\/a><\/noindex> l\u00e5 problemet i en enkelt person, Brent, som for\u00e5rsaket at prosjektet ble forsinket med tre \u00e5r. Og slike \u00abBrent\u00bb m\u00f8ter jeg overalt. For \u00e5 l\u00f8se disse flaskehalsene bruker jeg f\u00f8lgende to punkter fra v\u00e5r liste. <\/li>\n
  3. Theory of Constraints Methodology:<\/b> teorien om begrensninger.<\/li>\n
  4. Collaboration hacks:<\/b> samarbeidstriks. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> jeg skal ikke ha mye \u00e5 si om Toyota Kata. Hvis du er interessert, har jeg p\u00e5 min GitHub presentasjoner<\/a><\/noindex> nesten om hvert av disse emnene. <\/li>\n
  6. Market Oriented Organization:<\/b> markedsorientert organisasjon.<\/li>\n
  7. Shift-left auditors:<\/b> revisjoner i tidlige faser av syklusen.<\/li>\n<\/ol>\n

    \"Syv
    \n
    \nJeg begynner arbeidet med organisasjonen p\u00e5 en veldig enkel m\u00e5te: jeg g\u00e5r inn i selskapet og snakker med de ansatte. Som vi ser, ingen h\u00f8yteknologi. Alt som trengs, er \u00e5 ha noe \u00e5 skrive p\u00e5. Jeg samler flere team i et rom og analyserer det de sier, ut fra mine 7 arketypene. S\u00e5 gir jeg dem en tusj og ber dem skrive ned p\u00e5 tavlen alt de s\u00e5 langt har sagt h\u00f8yt. Vanligvis er det en person p\u00e5 slike m\u00f8ter som skriver alt ned, og i beste fall klarer han \u00e5 notere 10 % av diskusjonen. Med metoden min klarer vi \u00e5 heve den prosentandelen til rundt 40%. <\/p>\n

    \"Syv
    \n
    \n(Denne illustrasjonen kan     sees p\u00e5 linken<\/a><\/noindex>)<\/i><\/p>\n

    Min tiln\u00e6rming er basert p\u00e5 arbeidet til William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Grunnideen i tiln\u00e6rmingen er at enhver organisasjon kan deles opp i fire kvadranter. Dette diagrammet blir vanligvis resultatet av arbeidet med de hundrevis av andre diagrammene som oppst\u00e5r n\u00e5r man analyserer organisasjonen. La oss anta at vi har en organisasjon med h\u00f8y kontroll, men samtidig lav kompetanse. Dette er et ekstremt u\u00f8nsket scenario: n\u00e5r alle f\u00f8lger reglene, men ingen vet hva de skal gj\u00f8re. <\/p>\n

    En bedre variant med h\u00f8yt niv\u00e5 av b\u00e5de kontroll og kompetanse. Hvis et slikt selskap har fortjeneste, er det kanskje ikke n\u00f8dvendig med DevOps. Det mest interessante er \u00e5 jobbe med et selskap som har h\u00f8yt niv\u00e5 av kontroll, lav kompetanse og samarbeid, men samtidig h\u00f8y grad av kultur (cultivation). Dette betyr at det er mange ansatte i selskapet som trives med \u00e5 jobbe der, og omsetningen av arbeidskraft er lav. <\/p>\n

    \"Syv
    \n
    \n(Denne illustrasjonen kan     sees p\u00e5 linken<\/a><\/noindex>)<\/i><\/p>\n

    Jeg mener at metoder med strengt definerte anbefalinger i siste instans hindrer oss i \u00e5 oppn\u00e5 sannheten. Spesielt innen value stream mapping er det mange regler om hvordan informasjon skal struktureres. I de tidlige arbeidsfaser, som jeg snakker om, er disse reglene ikke n\u00f8dvendige for noen. Hvis en person med en marker i h\u00e5nden beskriver den faktiske situasjonen i selskapet p\u00e5 en tavle, er dette den beste m\u00e5ten \u00e5 forst\u00e5 situasjonen p\u00e5. Denne informasjonen n\u00e5r ikke direkt\u00f8rene. P\u00e5 dette tidspunktet er det dumt \u00e5 avbryte vedkommende og si at de har tegnet en feil pil. P\u00e5 dette stadiet b\u00f8r en bruke enkle regler, for eksempel at man kan skape et flerniv\u00e5-konsept ved kun \u00e5 bruke merkestifter med forskjellige farger. <\/p>\n

    Jeg gjentar, ingen h\u00f8yteknologi. Med svart markeravbildes den objektive virkeligheten, hvordan alt fungerer. Med r\u00f8d marker markerer folk hva de misliker med den n\u00e5v\u00e6rende situasjonen. Det er viktig at det er dem som skriver dette, og ikke jeg. N\u00e5r jeg etter m\u00f8tet g\u00e5r til IT-direkt\u00f8ren, tilbyr jeg ikke en liste med 10 ting som m\u00e5 endres. Jeg pr\u00f8ver \u00e5 finne forbindelser mellom det folk i selskapet sier og eksisterende, velpr\u00f8vde m\u00f8nstre. Til slutt foresl\u00e5r bl\u00e5 marker mulige l\u00f8sninger p\u00e5 problemet. <\/p>\n

    \"Syv
    \n
    \n(Denne illustrasjonen kan     sees p\u00e5 linken<\/a><\/noindex>)<\/i><\/p>\n

    Eksempelet p\u00e5 slik tiln\u00e6rming er vist over. Tidlig i \u00e5r jobbet jeg med en bank. Ansatte fra sikkerhetsavdelingen var overbevist om at de ikke kunne delta p\u00e5 krav- og designgjennomganger (design and requirement reviews). <\/p>\n

    \"Syv
    \n
    \n(Denne illustrasjonen kan     sees p\u00e5 linken<\/a><\/noindex>)<\/i><\/p>\n

    S\u00e5 snakket vi med folk fra andre avdelinger og fant ut at for rundt 8 \u00e5r siden hadde programvareutviklerne presset ut sikkerhetsansvarlige fordi de sinket arbeidet. Og s\u00e5 ble dette en forbudt praksis som ble oppfattet som en gitt sannhet. Selv om det i virkeligheten ikke var noe forbud. <\/p>\n

    M\u00f8tet v\u00e5rt utviklet seg p\u00e5 en sv\u00e6rt forvirrende m\u00e5te: I l\u00f8pet av omtrent tre timer klarte fem forskjellige team ikke \u00e5 forklare meg hva som skjer mellom koden og byggingen. Og dette, tilsynelatende, er den enkleste tingen. De fleste DevOps-konsulenter antar p\u00e5 forh\u00e5nd at det allerede er noe alle vet. <\/p>\n

    Deretter, personen som ansvarte for IT-styring, som hadde v\u00e6rt stille i fire timer, blomstret plutselig opp da vi kom til hans tema, og holdt oss opptatt i betydelig tid. P\u00e5 slutten spurte jeg ham hva han syntes om m\u00f8tet, og jeg vil aldri glemme svaret hans. Han sa: \u00abTidligere trodde jeg at det var to m\u00e5ter \u00e5 levere programvare p\u00e5 i banken v\u00e5r, men n\u00e5 vet jeg at det er hele fem, og jeg var ikke engang klar over tre av dem\u00bb. <\/p>\n

    \"Syv
    \n
    \n(Denne illustrasjonen kan     sees p\u00e5 linken<\/a><\/noindex>)<\/i><\/p>\n

    Det siste m\u00f8tet i denne banken var med teamet som jobber med programvare for investeringer. Det ble klart at det er bedre \u00e5 tegne diagrammer med tusj p\u00e5 papir enn p\u00e5 en tavle, og til og med bedre enn p\u00e5 en smarttavle. <\/p>\n

    \"Syv
    \n
    \nBildene dere ser \u2014 dette er hvordan konferanserommet p\u00e5 hotellet s\u00e5 ut den fjerde dagen av m\u00f8tet v\u00e5rt. Og disse diagrammene brukte vi til \u00e5 lete etter m\u00f8nstre, alts\u00e5 arketypene. <\/p>\n

    S\u00e5 jeg stiller sp\u00f8rsm\u00e5l til de ansatte, de noterer svarene med tusjer i tre farger (svart, r\u00f8dt og bl\u00e5tt). Jeg analyserer svarene deres for arketypene. N\u00e5 la oss diskutere alle arketypene i rekkef\u00f8lge. <\/p>\n

    1. Make All Work Visible: Gj\u00f8r alt arbeid synlig<\/h3>\n

    \nI de fleste selskaper jeg jobber med, er det en veldig h\u00f8y prosentandel av ukjent arbeid. For eksempel n\u00e5r en ansatt ber en annen om \u00e5 gj\u00f8re noe. I store organisasjoner kan det v\u00e6re 60% uplanlagt arbeid. Og opp til 40% av arbeidet er aldri dokumentert. Hvis det var Boeing, ville jeg aldri mer satt foten i et av deres fly. Hvis bare halvparten av arbeidet dokumenteres, er det uklart om arbeidet utf\u00f8res riktig eller ikke. Alle andre metoder blir unyttige \u2014 det gir ikke mening \u00e5 pr\u00f8ve \u00e5 automatisere noe, fordi de kjente 50% kan v\u00e6re den mest koordinerte og presise delen av arbeidet, automatisering av som ikke gir store resultater, mens alt det mest grufulle ligger i den usynlige halvdelen. Uten dokumentasjon er det umulig \u00e5 finne alle slags hacks og skjult arbeid, \u00e5 identifisere flaskehalser, de s\u00e5kalte \u00abBrentene\u00bb jeg allerede har nevnt. Det er en flott bok av Dominica DeGrandis. \u00abMaking Work Visible\u00bb<\/a><\/noindex>. Den avdekker fem forskjellige \u00abtidstyver\u00bb<\/b> (thieves of time):<\/p>\n