{"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\/da\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Syv arketyper af transformation baseret p\u00e5 DevOps-principper","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sp\u00f8rgsm\u00e5let \"hvordan man implementerer DevOps\" har v\u00e6ret aktuelt i flere \u00e5r, men der er ikke mange gode materialer. Nogle gange bliver du offer for reklamer fra ikke s\u00e6rlig kloge konsulenter, der skal s\u00e6lge deres tid, ligegyldigt hvordan. Nogle gange er det uklare, meget generelle ord om, hvordan k\u00e6mpeselskabers skibe sejler p\u00e5 universets vande. Sp\u00f8rgsm\u00e5let opst\u00e5r: hvad har vi egentlig ud af det? K\u00e6re forfatter, kan du tydeligt formulere dine id\u00e9er i en liste?<\/p>\n

Alt dette skyldes, at der ikke er samlet meget reel praksis og forst\u00e5else af udfaldet af virksomhedskulturens transformationer. \u00c6ndringer i kulturen er langsigtede ting, hvis resultater ikke vil vise sig p\u00e5 en uge eller en m\u00e5ned. Vi har brug for nogen, der er tilpas gammeldags, som har set virksomheder blive skabt og nedlagt over mange \u00e5r.<\/p>\n

\"Syv
\n
\nJohn Willis<\/b> \u2014 en af f\u00e6drene til DevOps. John har mange \u00e5rs erfaring med at arbejde med et stort antal virksomheder. P\u00e5 det seneste har John bem\u00e6rket specifikke m\u00f8nstre, der opst\u00e5r i arbejdet med hver enkelt af dem. Ved at bruge disse arketyper vejleder John virksomhederne p\u00e5 den rigtige vej til DevOps-transformation. L\u00e6s mere om disse arketyper i overs\u00e6ttelsen af hans pr\u00e6sentation fra DevOops 2018-konferencen.
\n<\/a><\/noindex>
\n

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

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

Over 35 \u00e5rs erfaring inden for IT-ledelse, deltager i udviklingen af en forg\u00e6nger til OpenCloud i Canonical, har v\u00e6ret involveret i 10 startups, hvoraf to blev solgt til Dell og Docker. I \u00f8jeblikket er han Vice President of DevOps and Digital Practices hos SJ Technologies.<\/p>\n

Dern\u00e6st \u2014 en fort\u00e6lling fra Johns synspunkt.<\/b><\/p>\n

Mit navn er John Willis, og du kan nemmest finde mig p\u00e5 Twitter, @botchagalupe<\/a><\/noindex>. Det er ogs\u00e5 mit pseudonym p\u00e5 Gmail og GitHub. Og p\u00e5 dette link<\/a><\/noindex> kan du finde optagelser af mine foredrag og tilh\u00f8rende pr\u00e6sentationer.<\/p>\n

Jeg har mange m\u00f8der med CIO'er fra forskellige store virksomheder. De klager ofte over, at de ikke forst\u00e5r, hvad DevOps er, og at alle, der fors\u00f8ger at forklare det, taler om noget helt anderledes. En anden hyppig klage er, at DevOps ikke fungerer, selvom direkt\u00f8rerne tilsyneladende g\u00f8r alt, som de har f\u00e5et at vide. Det drejer sig om store virksomheder, der har eksisteret i hundrede \u00e5r eller mere. Efter at have talt med dem, konkluderede jeg, at mange problemer bedst l\u00f8ses med forholdsvis lavteknologiske l\u00f8sninger snarere end avancerede teknologier. I ugevis talte jeg simpelthen med folk fra forskellige afdelinger. Det, du ser p\u00e5 det allerf\u00f8rste billede i indl\u00e6gget, er mit seneste projekt; rummet s\u00e5 s\u00e5dan ud efter tre dages arbejde.<\/p>\n

Hvad er DevOps?<\/h2>\n

\nHvis du sp\u00f8rger ti forskellige personer, vil de give ti forskellige svar. Men det interessante er, at alle disse ti svar vil v\u00e6re rigtige. Der er ikke noget forkert svar her. Jeg har arbejdet dybt med DevOps i cirka ti \u00e5r og var den f\u00f8rste amerikaner til den f\u00f8rste DevOpsDay. Jeg vil ikke p\u00e5st\u00e5, at jeg er klogere end alle andre, der besk\u00e6ftiger sig med DevOps, men jeg tvivler p\u00e5, at der er nogen, der har brugt s\u00e5 meget energi p\u00e5 det. Jeg mener, at DevOps opst\u00e5r, n\u00e5r menneskelig kapital og teknologi m\u00f8des. Vi glemmer ofte den menneskelige dimension, selvom vi taler meget om alle mulige kulturer. <\/p>\n

\"Syv
\n
\nNu har vi mange data, fem \u00e5rs akademisk forskning og en afpr\u00f8vning af teorier p\u00e5 industriel skala. Denne forskning viser os f\u00f8lgende: hvis visse adf\u00e6rdsm\u00f8nstre kombineres i organisationskulturen, kan man opn\u00e5 en acceleration p\u00e5 2000 gange. Denne acceleration svarer til en tilsvarende forbedring i robusthed. Det er en kvantitativ m\u00e5ling af den fordel, som DevOps kan give enhver virksomhed. For et par \u00e5r siden talte jeg om DevOps til en administrerende direkt\u00f8r fra en Fortune 5000-virksomhed. Da jeg forberedte mig til pr\u00e6sentationen, var jeg meget nerv\u00f8s, fordi jeg skulle opsummere mine mange \u00e5rs erfaring p\u00e5 fem minutter. <\/p>\n

Som resultat gav jeg f\u00f8lgende definition af DevOps<\/b>: det er et s\u00e6t praksisser og m\u00f8nstre, der muligg\u00f8r at omdanne menneskelig kapital til h\u00f8jtydende organisatorisk kapital. Et eksempel er, hvordan Toyota har arbejdet de sidste 50 eller 60 \u00e5r.<\/p>\n

\"Syv
\n
\n(Disse skemaer pr\u00e6senteres ikke som referencemateriale, men som illustration. Deres indhold vil variere for hver ny virksomhed. Alligevel kan billedet ses individuelt og forst\u00f8rres via dette link.)<\/a><\/noindex><\/i><\/p>\n

En af de mest succesfulde s\u00e5danne praksisser er value stream mapping<\/b>. Der er skrevet flere gode b\u00f8ger om dette, og forfatteren af de mest succesfulde af dem er Karen Martin. Men 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 brugt den meget. Men n\u00e5r en 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 langt mere fundamentale sp\u00f8rgsm\u00e5l, der f\u00f8rst skal besvares. <\/p>\n

Jeg mener, at fejlen hos mange af mine kolleger er, at de blot giver virksomheden en vejledning p\u00e5 fem punkter, og derefter vender de tilbage efter et halvt \u00e5r for at se, hvad der er sket. Selv med et godt skema som value stream mapping er der, s\u00e5 at sige, blinde zoner. Efter hundreder af interviews med direkt\u00f8rer for forskellige virksomheder har jeg udviklet et bestemt m\u00f8nster, der g\u00f8r det muligt at opdele problemet i komponenter, og nu vil vi diskutere hver af disse komponenter i r\u00e6kkef\u00f8lge. F\u00f8r jeg anvender nogen teknologiske l\u00f8sninger, bruger jeg dette m\u00f8nster, og resultatet er, at alle v\u00e6gge ender med at v\u00e6re fyldt med skemaer. For nylig arbejdede jeg med en gensidig fond, og jeg endte med 100-150 s\u00e5danne skemaer.<\/p>\n

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

\nHovedtanken er denne: intet Lean, Agile, SAFE eller DevOps vil hj\u00e6lpe, hvis virksomhedens kultur er d\u00e5rlig. Det er som at dykke i dybden uden dykkerudstyr eller operere uden r\u00f8ntgenbillede. Med andre ord, for at parafrasere Drucker og Deming: en d\u00e5rlig organisationskultur vil opsluge ethvert godt system og ikke kv\u00e6les. <\/p>\n

For at l\u00f8se dette hovedproblem skal f\u00f8lgende skridt tages:<\/p>\n

    \n
  1. G\u00f8r alt arbejde synligt:<\/b> du skal g\u00f8re alt arbejde synligt. Ikke i den forstand, at det n\u00f8dvendigvis skal vises p\u00e5 en sk\u00e6rm, men i den forstand, at det skal kunne observeres.<\/li>\n
  2. Konsolider arbejdsh\u00e5ndteringssystemer:<\/b> det er n\u00f8dvendigt at konsolidere ledelsessystemerne. I problemet med \u00abstammekendskab\u00bb og institutionelt kendskab er menneskene i 9 ud af 10 tilf\u00e6lde flaskehalsene. I bogen \u00abPhoenix Project\u00bb<\/a><\/noindex> var problemet i \u00e9n enkelt person, Brent, som fik projektet til at blive tre \u00e5r forsinket. Og jeg st\u00f8der p\u00e5 s\u00e5danne \u00abBrent\u00bb overalt. For at l\u00f8se disse flaskehalse anvender jeg f\u00f8lgende to punkter p\u00e5 vores liste. <\/li>\n
  3. Theory of Constraints Methodology:<\/b> teori om begr\u00e6nsninger.<\/li>\n
  4. Collaboration hacks:<\/b> samarbejdshacks. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> jeg vil ikke tale meget om Toyota Kata. Hvis du er interesseret, har jeg p\u00e5 min GitHub pr\u00e6sentationer<\/a><\/noindex> om n\u00e6rmest hver af disse emner. <\/li>\n
  6. Market Oriented Organization:<\/b> markedsorienteret organisation.<\/li>\n
  7. Shift-left auditors:<\/b> revision i de tidlige faser af cyklussen.<\/li>\n<\/ol>\n

    \"Syv
    \n
    \nJeg starter arbejdet med organisationen meget simpelt: jeg g\u00e5r ind i virksomheden og taler med medarbejderne. Som vi ser, er der ingen h\u00f8j teknologi. Alt der kr\u00e6ves er, at der er noget at skrive med. Jeg samler flere teams i et rum og analyserer, hvad de fort\u00e6ller mig, ud fra mine 7 arketyper. S\u00e5 giver jeg dem selv en mark\u00f8r og beder dem udtrykke alt det, de indtil nu har sagt h\u00f8jt, skriftligt p\u00e5 tavlen. Normalt er der \u00e9n person til stede p\u00e5 s\u00e5danne m\u00f8der, der skriver alt ned, og i bedste fald f\u00e5r han indfanger 10% af diskussionen. Ved min metode lykkes det at h\u00e6ve denne procentdel til omkring 40%. <\/p>\n

    \"Syv
    \n
    \n(Separat kan denne illustration     ses via linket<\/a><\/noindex>)<\/i><\/p>\n

    Mit tilgang er baseret p\u00e5 arbejde af William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Grundtanken i tilgangen er, at enhver organisation kan opdeles i fire kvadrater. Dette diagram er typisk resultatet af mit arbejde med de hundredvis af andre diagrammer, der opst\u00e5r under analysen af organisationen. Antag, at vi har en organisation med h\u00f8j kontrol, men samtidig med lav kompetence. Dette er en yderst u\u00f8nsket situation: n\u00e5r alle g\u00e5r efter reglerne, men ingen ved, hvad der skal g\u00f8res. <\/p>\n

    En bedre mulighed med h\u00f8jt niveau af b\u00e5de kontrol og kompetence. Hvis en virksomhed er profitabel, er DevOps m\u00e5ske ikke n\u00f8dvendigt for dem. Det mest interessante er at arbejde med en virksomhed, som har h\u00f8jt niveau af kontrol, lav kompetence og samarbejde, men samtidig en h\u00f8j kultur (cultivation). Det betyder, at der er mange mennesker i virksomheden, som nyder at arbejde der, og medarbejderoms\u00e6tningen er lav. <\/p>\n

    \"Syv
    \n
    \n(Separat kan denne illustration     ses via linket<\/a><\/noindex>)<\/i><\/p>\n

    Jeg tror, at metoder med strenge retningslinjer i sidste ende hindrer os i at n\u00e5 sandheden. Is\u00e6r i value stream mapping er der mange regler om, hvordan information skal struktureres. I de tidlige faser, som jeg taler om nu, er disse regler un\u00f8dvendige. Hvis en person med en marker i h\u00e5nden beskriver den reelle situation i virksomheden p\u00e5 en tavle, er det den bedste m\u00e5de at f\u00e5 indsigt i situationen. Den information n\u00e5r aldrig op til lederne. I det \u00f8jeblik er det dumt at afbryde personen og sige, at de har tegnet en pil forkert. I denne fase er det bedre at bruge enkle regler, for eksempel kan man skabe en flerlagdet abstraktion ved bare at bruge farverige mark\u00f8rer. <\/p>\n

    Jeg gentager, ingen h\u00f8jteknologi. Den objektive virkelighed, hvordan alt fungerer, tegnes med sort marker. Med r\u00f8d marker angiver folk, hvad de ikke kan lide ved den nuv\u00e6rende situation. Det er vigtigt, at det er dem, der skriver det, og ikke mig. N\u00e5r jeg efter m\u00f8det g\u00e5r til IT-direkt\u00f8ren, pr\u00e6senterer jeg ikke en liste med 10 ting, der skal rettes. Jeg fors\u00f8ger at finde forbindelser mellem det, som folk siger i virksomheden, og eksisterende bekr\u00e6ftede m\u00f8nstre. Til sidst foresl\u00e5r man mulige l\u00f8sninger p\u00e5 problemet med den bl\u00e5 marker. <\/p>\n

    \"Syv
    \n
    \n(Separat kan denne illustration     ses via linket<\/a><\/noindex>)<\/i><\/p>\n

    Et eksempel p\u00e5 denne tilgang er vist ovenfor. I begyndelsen af dette \u00e5r arbejdede jeg med en bank. Medarbejdere fra sikkerhedsafdelingen der var overbeviste om, at de ikke m\u00e5tte deltage i krav- og designgennemgange (design and requirement reviews). <\/p>\n

    \"Syv
    \n
    \n(Separat kan denne illustration     ses via linket<\/a><\/noindex>)<\/i><\/p>\n

    Og s\u00e5 talte vi med folk fra andre afdelinger og fandt ud af, at for omkring 8 \u00e5r siden havde softwareudviklerne ekskluderet sikkerhedsmedarbejderne, fordi de forsinkede arbejdet. Og s\u00e5 blev det til et forbud, der blev opfattet som en given ting. Selvom der reelt ikke var noget forbud. <\/p>\n

    Vores m\u00f8de forl\u00f8b p\u00e5 en ekstremt forvirrende m\u00e5de: i omkring tre timer kunne fem forskellige teams slet ikke forklare mig, hvad der sker mellem koden og bygningen. Og det burde egentlig v\u00e6re den enkleste ting. De fleste DevOps-konsulenter antager p\u00e5 forh\u00e5nd, at alle allerede kender dette. <\/p>\n

    S\u00e5 pludselig gik personen, der stod for IT-reguleringen (IT governance), der havde v\u00e6ret tavs i fire timer, i gang, da vi n\u00e5ede til hans emne, og han optog os i lang tid. Til sidst spurgte jeg ham, hvad han t\u00e6nkte om m\u00f8det, og jeg vil aldrig glemme hans svar. Han sagde: \u201eTidligere troede jeg, at der kun var to metoder til at levere software i vores bank, men nu ved jeg, at der er hele fem, og at jeg ikke engang anede, at der var tre af dem.\u201d <\/p>\n

    \"Syv
    \n
    \n(Separat kan denne illustration     ses via linket<\/a><\/noindex>)<\/i><\/p>\n

    Det sidste m\u00f8de i denne bank var med teamet, der arbejdede med software til investeringer. Det viste sig, at det er bedre at skrive diagrammer med en tusch p\u00e5 papir end p\u00e5 en tavle, og endda bedre end p\u00e5 en smartboard. <\/p>\n

    \"Syv
    \n
    \nBillederne, du ser, er hvordan konferencerummet i hotellet s\u00e5 ud p\u00e5 den fjerde dag af vores m\u00f8de. Og disse diagrammer brugte vi til at finde m\u00f8nstre, det vil sige archetyper. <\/p>\n

    S\u00e5 jeg stiller sp\u00f8rgsm\u00e5l til medarbejderne, de skriver deres svar med tuscher i tre farver (sort, r\u00f8d og bl\u00e5). Jeg analyserer deres svar for archetyper. Lad os nu diskutere alle archetyperne i r\u00e6kkef\u00f8lge. <\/p>\n

    1. Make All Work Visible: G\u00f8re al arbejde synligt<\/h3>\n

    \nI de fleste virksomheder, jeg arbejder med, er der en meget h\u00f8j procentdel af ukendt arbejde. For eksempel n\u00e5r en medarbejder g\u00e5r til en anden og bare beder om at f\u00e5 noget gjort. I store organisationer kan op til 60% af arbejdet v\u00e6re uplanlagt. Og op til 40% af arbejdet er slet ikke dokumenteret. Hvis det var Boeing, ville jeg aldrig s\u00e6tte mig ind i deres fly igen. Hvis kun halvdelen af arbejdet bliver dokumenteret, er det uklart, om dette arbejde bliver udf\u00f8rt korrekt eller ej. Alle andre metoder viser sig at v\u00e6re ubrugelige - der er ikke nogen mening i at fors\u00f8ge at automatisere noget, fordi de kendte 50% muligvis er den mest velkoordinerede og pr\u00e6cise del af arbejdet, hvor automatisering ikke vil give store resultater, mens det v\u00e6rste findes i den usynlige halvdel. Uden dokumentation er det umuligt at finde forskellige hacks og skjult arbejde, samt identificere flaskehalse og de s\u00e5kaldte 'Brent's', som jeg allerede har n\u00e6vnt. Der er en fremragende bog skrevet af Dominica DeGrandis. \u00abMaking Work Visible\u00bb<\/a><\/noindex>. Den identificerer fem forskellige 'tidstyve'<\/b> (thieves of time):<\/p>\n