{"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\/sv\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sju arketyper av transformation enligt DevOps-principer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Fr\u00e5gan om \"hur man implementerar DevOps\" har st\u00e4llts under m\u00e5nga \u00e5r, men det finns inte s\u00e5 m\u00e5nga bra material. Ibland blir man ett offer f\u00f6r reklamen fr\u00e5n inte s\u00e5 smarta konsulter, vars enda m\u00e5l \u00e4r att s\u00e4lja sin tid, oavsett hur. Ibland handlar det om otydliga, extremt generella p\u00e5st\u00e5enden om hur megaf\u00f6retagens fartyg navigerar genom universum. Fr\u00e5gan uppst\u00e5r: vad har vi att vinna p\u00e5 det? B\u00e4ste f\u00f6rfattare, kan du tydligt lista dina id\u00e9er?<\/p>\n

Allt detta beror p\u00e5 att det inte finns s\u00e5 mycket verklig praktik och f\u00f6rst\u00e5else f\u00f6r resultatet av f\u00f6retagskulturens transformation. F\u00f6r\u00e4ndringar i kulturen \u00e4r l\u00e5ngsiktiga processer vars resultat inte visar sig om en vecka eller en m\u00e5nad. Vi beh\u00f6ver n\u00e5gon som \u00e4r tillr\u00e4ckligt gammal och har sett hur f\u00f6retag har skapats och kollapsat under m\u00e5nga \u00e5r.<\/p>\n

\"Sju
\n
\nJohn Willis<\/b> \u00e4r en av f\u00e4derna till DevOps. John har hundratals \u00e5rs erfarenhet av att arbeta med ett stort antal f\u00f6retag. P\u00e5 senare tid har John b\u00f6rjat m\u00e4rka specifika m\u00f6nster som f\u00f6rekommer i arbetet med var och en av dem. Genom att anv\u00e4nda dessa arketypier v\u00e4gleder John f\u00f6retag mot den sanna v\u00e4gen f\u00f6r DevOps-transformation. Mer om dessa arketypier finns i \u00f6vers\u00e4ttningen av hans f\u00f6rel\u00e4sning fr\u00e5n konferensen DevOops 2018.
\n<\/a><\/noindex>
\n

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

Om f\u00f6rel\u00e4saren:<\/b><\/p>\n

Mer \u00e4n 35 \u00e5rs erfarenhet inom IT-ledarskap, deltog i skapandet av f\u00f6reg\u00e5ngaren till OpenCloud p\u00e5 Canonical, har varit involverad i 10 startups, tv\u00e5 av dem s\u00e5lda till Dell och Docker. Just nu \u00e4r han Vice President of DevOps and Digital Practices p\u00e5 SJ Technologies.<\/p>\n

H\u00e4rn\u00e4st \u2013 en ber\u00e4ttelse fr\u00e5n Johns perspektiv.<\/b><\/p>\n

Jag heter John Willis och det enklaste s\u00e4ttet att n\u00e5 mig p\u00e5 Twitter \u00e4r @botchagalupe<\/a><\/noindex>. Jag anv\u00e4nder samma pseudonym p\u00e5 Gmail och GitHub. Du kan ocks\u00e5 hitta videoinspelningar av mina f\u00f6rel\u00e4sningar och tillh\u00f6rande presentationer. via denna l\u00e4nk<\/a><\/noindex> du kan hitta videoinspelningar av mina f\u00f6rel\u00e4sningar och presentationer till dem.<\/p>\n

Jag har m\u00e5nga m\u00f6ten med CIO:er fr\u00e5n olika stora f\u00f6retag. De klagar ofta p\u00e5 att de inte f\u00f6rst\u00e5r vad DevOps \u00e4r, och alla som f\u00f6rs\u00f6ker f\u00f6rklara det pratar om n\u00e5got helt annat. En annan vanlig klagom\u00e5l \u00e4r att DevOps inte fungerar, \u00e4ven om direkt\u00f6rerna verkar f\u00f6lja instruktionerna. Det handlar om stora f\u00f6retag som har funnits i \u00f6ver hundra \u00e5r. Efter att ha pratat med dem har jag kommit fram till att f\u00f6r m\u00e5nga problem \u00e4r det inte h\u00f6gteknologiska l\u00f6sningar som passar b\u00e4st, utan relativt l\u00e5gteknologiska. Jag har i veckor bara pratat med folk fr\u00e5n olika avdelningar. Det som ni ser p\u00e5 den f\u00f6rsta bilden i inl\u00e4gget \u00e4r mitt senaste projekt; rummet s\u00e5g ut s\u00e5 h\u00e4r efter tre dagars arbete.<\/p>\n

Vad \u00e4r DevOps?<\/h2>\n

\nVerkligen, om man fr\u00e5gar 10 olika personer kommer de att ge 10 olika svar. Men h\u00e4r \u00e4r det intressanta: alla dessa tio svar \u00e4r korrekta. Det finns inget fel svar h\u00e4r. Jag har sysslat djupt med DevOps i ungef\u00e4r 10 \u00e5r och var den f\u00f6rsta amerikanen p\u00e5 den f\u00f6rsta DevOps Day. Jag skulle inte s\u00e4ga att jag \u00e4r smartare \u00e4n alla som arbetar med DevOps, men det finns nog ingen som har lagt ner lika mycket tid och energi. Jag anser att DevOps uppst\u00e5r n\u00e4r m\u00e4nniskokapital och teknologi f\u00f6renas. Vi gl\u00f6mmer ofta det m\u00e4nskliga perspektivet, \u00e4ven om vi pratar mycket om olika kulturer. <\/p>\n

\"Sju
\n
\nNu har vi mycket data, fem \u00e5rs akademisk forskning, och teorierna har testats i industriell skala. Denna forskning s\u00e4ger oss f\u00f6ljande: om man kopplar samman vissa beteendem\u00f6nster i organisationskulturen kan man f\u00e5 en acceleration p\u00e5 2000 g\u00e5nger. Denna acceleration \u00e5terspeglar en motsvarande f\u00f6rb\u00e4ttring i h\u00e5llbarhet. Det \u00e4r en kvantitativ m\u00e4tning av den f\u00f6rdel som DevOps kan ge vilket f\u00f6retag som helst. F\u00f6r ett par \u00e5r sedan ber\u00e4ttade jag om DevOps f\u00f6r VD:n i ett f\u00f6retag p\u00e5 Fortune 5000-listan. N\u00e4r jag f\u00f6rberedde mig f\u00f6r presentationen var jag oerh\u00f6rt nerv\u00f6s, eftersom jag beh\u00f6vde sammanfatta mina m\u00e5nga \u00e5rs erfarenhet p\u00e5 fem minuter. <\/p>\n

Som ett resultat gav jag f\u00f6ljande definition av DevOps<\/b>: det \u00e4r en upps\u00e4ttning praktiker och m\u00f6nster som g\u00f6r det m\u00f6jligt att omvandla m\u00e4nniskokapital till h\u00f6gpresterande organisatoriskt kapital. Ett exempel \u00e4r hur Toyota har arbetat de senaste 50 eller 60 \u00e5ren.<\/p>\n

\"Sju
\n
\n(H\u00e4r och vidare ges s\u00e5dana scheman inte som referensmaterial, utan som illustration. Inneh\u00e5llet kommer att skilja sig \u00e5t f\u00f6r varje ny f\u00f6retag. \u00c4nd\u00e5 kan man titta p\u00e5 bilden separat och f\u00f6rstora den. via denna l\u00e4nk.)<\/a><\/noindex><\/i><\/p>\n

En av de mest framg\u00e5ngsrika s\u00e5dana praktiker \u00e4r value stream mapping<\/b>. Det har skrivits flera bra b\u00f6cker om detta, den mest framg\u00e5ngsrika av dem \u00e4r av Karen Martin. Men under det senaste \u00e5ret har jag kommit fram till att \u00e4ven denna metod \u00e4r f\u00f6r h\u00f6gteknologisk. Den har utan tvekan m\u00e5nga f\u00f6rdelar, och jag har anv\u00e4nt den mycket. Men n\u00e4r VD:n fr\u00e5gar dig varf\u00f6r hans f\u00f6retag inte kan g\u00e5 \u00f6ver till nya sp\u00e5r, \u00e4r det f\u00f6r tidigt att prata om value stream mapping. Det finns m\u00e5nga betydligt mer grundl\u00e4ggande fr\u00e5gor som m\u00e5ste besvaras f\u00f6rst. <\/p>\n

Jag tror att felet hos m\u00e5nga av mina kollegor \u00e4r att de helt enkelt ger f\u00f6retaget en v\u00e4gledning med fem punkter och sedan kommer tillbaka efter sex m\u00e5nader f\u00f6r att se vad som har h\u00e4nt. \u00c4ven med ett bra schema som value stream mapping finns det, f\u00f6r att s\u00e4ga s\u00e5, d\u00f6da zoner (blind spots). Efter hundratals intervjuer med direkt\u00f6rer fr\u00e5n olika f\u00f6retag har jag utvecklat ett visst m\u00f6nster som g\u00f6r att jag kan bryta ner problemet i dess best\u00e5ndsdelar, och nu kommer vi att diskutera var och en av dessa best\u00e5ndsdelar i tur och ordning. Innan jag till\u00e4mpar n\u00e5gra tekniska l\u00f6sningar anv\u00e4nder jag detta m\u00f6nster, och i resultatet visar sig alla mina v\u00e4ggar vara fulla av scheman. Nyligen arbetade jag med en viss fond, och jag slutade med 100-150 s\u00e5dana scheman.<\/p>\n

D\u00e5lig kultur \u00e4ter bra metoder till frukost<\/h2>\n

\nHuvudtanken \u00e4r: inga Lean, Agile, SAFE och DevOps kommer att hj\u00e4lpa om sj\u00e4lva kulturen i organisationen \u00e4r d\u00e5lig. Det \u00e4r som att dyka p\u00e5 djupet utan dykardr\u00e4kt eller operera utan r\u00f6ntgenbild. Med andra ord, f\u00f6r att omformulera Drucker och Deming: d\u00e5lig organisationskultur kommer att sluka vilket bra system som helst och inte kv\u00e4vas. <\/p>\n

F\u00f6r att l\u00f6sa detta huvudproblem m\u00e5ste f\u00f6ljande steg vidtas:<\/p>\n

    \n
  1. Make All Work Visible:<\/b> man m\u00e5ste g\u00f6ra allt arbete synligt. Inte i den meningen att det n\u00f6dv\u00e4ndigtvis m\u00e5ste visas p\u00e5 n\u00e5gon sk\u00e4rm, utan i den meningen att det m\u00e5ste vara observerbart.<\/li>\n
  2. Consolidate Work Management Systems:<\/b> det \u00e4r n\u00f6dv\u00e4ndigt att konsolidera ledningssystemen. I fr\u00e5gan om \"stam\" kunskap och institutionell kunskap \u00e4r det i 9 av 10 fall de m\u00e4nniskor som utg\u00f6r flaskhalsen. I boken \"Phoenix Project\"<\/a><\/noindex> handlade problemet om en enda person, Brent, som gjorde att projektet var tre \u00e5r f\u00f6rsenat. Och jag st\u00f6ter p\u00e5 s\u00e5dana \"Brent\" \u00f6verallt. F\u00f6r att l\u00f6sa dessa flaskhalsar anv\u00e4nder jag f\u00f6ljande tv\u00e5 punkter i v\u00e5r lista. <\/li>\n
  3. Theory of Constraints Methodology:<\/b> teorin om begr\u00e4nsningar.<\/li>\n
  4. Collaboration hacks:<\/b> samarbete hacks. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> jag kommer inte att prata mycket om Toyota Kata. Om du \u00e4r intresserad, p\u00e5 min github finns presentationer<\/a><\/noindex> n\u00e4stan om varje av dessa \u00e4mnen. <\/li>\n
  6. Market Oriented Organization:<\/b> marknadsorienterad organisation.<\/li>\n
  7. Shift-left auditors:<\/b> revision i tidiga skeden av cykeln.<\/li>\n<\/ol>\n

    \"Sju
    \n
    \nJag b\u00f6rjar arbeta med organisationen ganska enkelt: jag g\u00e5r in i f\u00f6retaget och pratar med medarbetarna. Som vi ser, inga h\u00f6gteknologiska l\u00f6sningar. Allt som beh\u00f6vs \u00e4r n\u00e5got att skriva p\u00e5. Jag samlar flera team i ett rum och analyserar vad de s\u00e4ger utifr\u00e5n mina 7 arketyper. Och sen ger jag dem en marker och ber dem skriva ner allt de hittills har sagt h\u00f6gt p\u00e5 tavlan. Vanligtvis \u00e4r det en person p\u00e5 s\u00e5dana m\u00f6ten som skriver ner allt, och i b\u00e4sta fall lyckas han f\u00e5nga 10% av diskussionen. Med min metod kan den siffran h\u00f6jas till omkring 40%. <\/p>\n

    \"Sju
    \n
    \n(Den h\u00e4r illustrationen kan     ses via l\u00e4nken<\/a><\/noindex>)<\/i><\/p>\n

    Min metod bygger p\u00e5 arbetet av William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Grunden f\u00f6r metoden \u00e4r tanken att varje organisation kan delas upp i fyra kvadranter. Denna modell \u00e4r ofta resultatet av arbetet med de hundratals andra modeller som uppst\u00e5r vid analysen av organisationen. Anta att vi har en organisation med h\u00f6g kontrollniv\u00e5, men samtidigt l\u00e5g kompetens. Detta \u00e4r en extremt o\u00f6nskad variant: d\u00e4r alla f\u00f6ljer reglerna, men ingen vet vad de ska g\u00f6ra. <\/p>\n

    Ett n\u00e5got b\u00e4ttre alternativ med h\u00f6g niv\u00e5 av b\u00e5de kontroll och kompetens. Om ett s\u00e5dant f\u00f6retag \u00e4r l\u00f6nsamt, kanske DevOps inte ens beh\u00f6vs. Mest intressant \u00e4r det att arbeta med ett f\u00f6retag som har h\u00f6g kontroll, l\u00e5g kompetens och samarbete, men samtidigt en h\u00f6g niv\u00e5 av kultur. Det betyder att det finns m\u00e5nga m\u00e4nniskor i f\u00f6retaget som trivs d\u00e4r och att personaloms\u00e4ttningen \u00e4r l\u00e5g. <\/p>\n

    \"Sju
    \n
    \n(Den h\u00e4r illustrationen kan     ses via l\u00e4nken<\/a><\/noindex>)<\/i><\/p>\n

    Jag tror att metoder med fastst\u00e4llda rekommendationer i slut\u00e4ndan f\u00f6rhindrar att man n\u00e5r sanningen. Specifikt i value stream mapping finns det m\u00e5nga regler f\u00f6r hur information ska struktureras. I de tidiga faser av arbetet, som jag pratar om nu, beh\u00f6vs dessa regler inte. Om n\u00e5gon med en markeringspenna beskriver den verkliga situationen p\u00e5 en tavla \u00e4r det det b\u00e4sta s\u00e4ttet att f\u00f6rst\u00e5 l\u00e4get. Den informationen n\u00e5r inte direkt\u00f6rerna. Just d\u00e5 \u00e4r det dumt att avbryta personen och s\u00e4ga att de har ritat en pil fel. I det h\u00e4r skedet \u00e4r det b\u00e4ttre att anv\u00e4nda enkla regler, till exempel: en flerniv\u00e5abstraktion kan skapas genom att bara anv\u00e4nda f\u00e4rgglada mark\u00f6rer. <\/p>\n

    Jag upprepar, inga h\u00f6gteknologiska l\u00f6sningar. Med en svart markeringspenna avbildas den objektiva verkligheten, hur allt fungerar. Med en r\u00f6d markeringspenna markerar folk vad de inte gillar med den aktuella situationen. Det viktiga \u00e4r att det \u00e4r de som skriver det, inte jag. N\u00e4r jag efter m\u00f6tet g\u00e5r till IT-chefen f\u00f6resl\u00e5r jag inte en lista med 10 saker som m\u00e5ste \u00e5tg\u00e4rdas. Jag f\u00f6rs\u00f6ker hitta samband mellan vad f\u00f6retagsmedlemmarna s\u00e4ger och de befintliga bepr\u00f6vade m\u00f6nstren. Slutligen f\u00f6resl\u00e5s trevliga l\u00f6sningar p\u00e5 problemet med en bl\u00e5 markeringspenna. <\/p>\n

    \"Sju
    \n
    \n(Den h\u00e4r illustrationen kan     ses via l\u00e4nken<\/a><\/noindex>)<\/i><\/p>\n

    Ett exempel p\u00e5 ett s\u00e5dant tillv\u00e4gag\u00e5ngss\u00e4tt visas ovan. I b\u00f6rjan av \u00e5ret arbetade jag med en bank. Anst\u00e4llda fr\u00e5n s\u00e4kerhetsavdelningen var \u00f6vertygade om att de inte fick delta i kontroller av krav och design (design and requirement reviews). <\/p>\n

    \"Sju
    \n
    \n(Den h\u00e4r illustrationen kan     ses via l\u00e4nken<\/a><\/noindex>)<\/i><\/p>\n

    Sedan pratade vi med m\u00e4nniskor fr\u00e5n andra avdelningar och det visade sig att f\u00f6r ungef\u00e4r 8 \u00e5r sedan hade mjukvaruutvecklarna st\u00e4ngt ute s\u00e4kerhetsanst\u00e4llda eftersom de f\u00f6rdr\u00f6jde arbetet. Och sedan utvecklades det till ett f\u00f6rbud som uppfattades som en sj\u00e4lvklarhet. \u00c4ven om det egentligen inte fanns n\u00e5got f\u00f6rbud. <\/p>\n

    V\u00e5r m\u00f6te fortskred p\u00e5 en mycket f\u00f6rvirrad v\u00e4g: under ungef\u00e4r tre timmar kunde fem olika team inte f\u00f6rklara f\u00f6r mig vad som h\u00e4nder mellan koden och byggandet. Det borde vara den enklaste saken. M\u00e5nga DevOps-konsulter f\u00f6ruts\u00e4tter i f\u00f6rv\u00e4g att detta redan \u00e4r allm\u00e4ngiltig kunskap. <\/p>\n

    Sedan vaknade personen som ansvarade f\u00f6r IT-styrning, och som varit tyst i fyra timmar, pl\u00f6tsligt till liv n\u00e4r vi n\u00e5dde hans \u00e4mne och h\u00f6ll oss sysselsatta under en ganska l\u00e5ng tid. Mot slutet fr\u00e5gade jag honom vad han tyckte om m\u00f6tet, och jag kommer aldrig att gl\u00f6mma hans svar. Han sa: \"Tidigare trodde jag att det fanns tv\u00e5 s\u00e4tt att leverera mjukvara i v\u00e5r bank, men nu vet jag att det finns hela fem, och jag hade ingen aning om tre av dem.\" <\/p>\n

    \"Sju
    \n
    \n(Den h\u00e4r illustrationen kan     ses via l\u00e4nken<\/a><\/noindex>)<\/i><\/p>\n

    Det sista m\u00f6tet i denna bank var med ett team som arbetar med investeringprogramvara. Just med dem blev det tydligt att det \u00e4r b\u00e4ttre att skriva scheman med en penna p\u00e5 papper \u00e4n p\u00e5 en tavla, och till och med b\u00e4ttre \u00e4n p\u00e5 en smartboard. <\/p>\n

    \"Sju
    \n
    \nFoton som ni ser \u00e4r hur konferensrummet p\u00e5 hotellet s\u00e5g ut den fj\u00e4rde dagen av v\u00e5rt m\u00f6te. Dessa scheman anv\u00e4nde vi f\u00f6r att identifiera m\u00f6nster, det vill s\u00e4ga arketyper. <\/p>\n

    S\u00e5 jag st\u00e4ller fr\u00e5gor till medarbetarna, och de skriver ner svaren med tre olika f\u00e4rger (svart, r\u00f6d och bl\u00e5). Jag analyserar deras svar efter arketyper. Nu ska vi diskutera alla arketyper i ordning. <\/p>\n

    1. Make All Work Visible: G\u00f6ra allt arbete synligt<\/h3>\n

    \nI de flesta f\u00f6retag jag arbetar med \u00e4r en stor andel av arbetet oklart. Till exempel n\u00e4r en anst\u00e4lld ber en annan om n\u00e5got. I stora organisationer kan upp till 60% av arbetet vara oplanerat. \u00c4ven s\u00e5 mycket som 40% av arbetet \u00e4r p\u00e5 n\u00e5got s\u00e4tt icke-dokumenterat. Om det var Boeing skulle jag aldrig v\u00e5ga flyga med dem igen. Om bara h\u00e4lften av arbetet dokumenteras vet man inte om det g\u00f6rs r\u00e4tt. Alla andra metoder visar sig vara v\u00e4rdel\u00f6sa - det finns inget syfte med att f\u00f6rs\u00f6ka automatisera n\u00e5gonting, eftersom de k\u00e4nda 50% kan vara just den mest strukturerade och tydliga delen av arbetet, automatisering av vilket inte ger stora resultat, medan allt som \u00e4r problematiskt finns i den osynliga h\u00e4lften. Utan dokumentation \u00e4r det om\u00f6jligt att hitta olika knep och dolda arbeten, att identifiera flaskhalsar, de s\u00e5 kallade \"Brentarna\" som jag redan har n\u00e4mnt. Det finns en utm\u00e4rkt bok av Dominica DeGrandis. \u00abMaking Work Visible\u00bb<\/a><\/noindex>. Den identifierar fem olika \"tjuvar av tid\"<\/b> (thieves of time):<\/p>\n