{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Hur man p\u00e5b\u00f6rjar en DevOps-transformation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Om du inte f\u00f6rst\u00e5r vad DevOps \u00e4r, h\u00e4r \u00e4r en kort sammanfattning. DevOps \u00e4r en upps\u00e4ttning metoder som minskar ingenj\u00f6rers r\u00e4dsla<\/strong> och minskar antalet driftst\u00f6rningar i mjukvaruproduktion. I regel f\u00f6rkortar de ocks\u00e5 tiden till marknaden<\/strong> \u2014 perioden fr\u00e5n id\u00e9 till leverans av den slutliga produkten till kunderna, vilket m\u00f6jligg\u00f6r snabba businessexperiment<\/strong>.<\/p>\n

Hur p\u00e5b\u00f6rjar man en DevOps-transformation? Kort sagt: vi v\u00e4ljer en tj\u00e4nst som vi b\u00f6rjar med, identifierar dem som \u00e4r relaterade till tj\u00e4nsten, skapar en Value Stream Map, s\u00e4tter ihop ett tillf\u00e4lligt team som kommer att hantera transformationen under en tid och ger dem en uppgift. Vi upprepar cykeln s\u00e5 m\u00e5nga g\u00e5nger som beh\u00f6vs.<\/p>\n

\"Hur<\/p>\n

En detaljerad plan f\u00f6r DevOps-transformationen med exempel och instruktioner finns under l\u00e4nken presentationen<\/a><\/noindex> Andrey Alexandrov<\/b> \u2014 ingenj\u00f6r vid f\u00f6retaget Express42, som ger r\u00e5d om DevOps-f\u00f6rb\u00e4ttringar och p\u00e5skyndar denna process eftersom de redan har kartlagt fallgroparna. Om du tror att en transformation inte \u00e4r n\u00f6dv\u00e4ndig f\u00f6r dig, eller om din specifik g\u00f6r att DevOps-praktiker inte passar, \u2014 anv\u00e4nd presentationen som en v\u00e4gledning f\u00f6r att identifiera och \u00e5tg\u00e4rda begr\u00e4nsningar.
\n<\/a><\/noindex>
\nOm du oroar dig f\u00f6r fr\u00e5gan om DevOps-transformation, inneb\u00e4r det att du har ett stort f\u00f6retag och att du beh\u00f6ver skala denna process \u00f6ver hela strukturen steg f\u00f6r steg. S\u00e5 l\u00e4nge det finns ett behov av att transformera teamet eller \u00e5tg\u00e4rda n\u00e5gon begr\u00e4nsning kan algoritmen nedan upprepas.<\/p>\n

Val av tj\u00e4nst<\/h2>\n

\nPlanen \u00e4r tydlig, l\u00e5t oss b\u00f6rja med f\u00f6rsta steget \u2014 val av tj\u00e4nst. Den f\u00f6rsta kriteriet \u00e4r livsl\u00e4ngd<\/strong>: det finns gamla tj\u00e4nster \u2014 legacy, och nya. Man kan b\u00f6rja med b\u00e5de och.<\/p>\n

Att v\u00e4lja en ung tj\u00e4nst \u00e4r logiskt<\/strong>. Den \u00e4r ny, det finns \u00e4nnu ingen etablerad arbetsprocess i teamet som hanterar den. Det finns ingen enorm teknisk skuld runt den, och det kr\u00e4vs inte att den st\u00e4ndigt repareras. Vi kan g\u00f6ra vad vi vill med den.<\/p>\n

N\u00e4r det g\u00e4ller en gammal tj\u00e4nst finns det problem relaterade till att f\u00f6r\u00e4ndra \u00e4r alltid sv\u00e5rt<\/strong>. Det finns redan ett antal allvarliga begr\u00e4nsningar, men kanske hanteras de av m\u00e4nniskor som redan \u00e4r redo att g\u00f6ra en f\u00f6r\u00e4ndring \u2014 de \u00e4r tr\u00f6tta och vill g\u00f6ra n\u00e5got annorlunda f\u00f6r att det g\u00f6r ont.<\/p>\n

Arbetet med en gammal tj\u00e4nst skapar en kraftfull prejudikat<\/strong> det finns alltid n\u00e5got som g\u00e5r att f\u00f6r\u00e4ndra i ert f\u00f6retag. Om ni har inf\u00f6rt en ny tj\u00e4nst som k\u00f6rs 100 g\u00e5nger i timmen utan problem kan folk i f\u00f6retaget s\u00e4ga:<\/p>\n

\u2014 Men det h\u00e4r \u00e4r ju en ny tj\u00e4nst! Det var ju s\u00e5 enkelt tidigare, prova att g\u00f6ra n\u00e5got med v\u00e5r trasiga gamla grej.<\/em><\/p>\n

Legacy-tj\u00e4nster \u00e4r v\u00e4rda att omvandla n\u00e4r ni g\u00f6r det tillsammans med n\u00e5gon, till exempel om ni har bjudit in en extern konsult. L\u00e5t oss vara \u00e4rliga, transformationen kommer att skaka om allt m\u00f6jligt.<\/strong>. Ni experimenterar och vet inte vart ni kommer att hamna, vilka teknologier ni ska anv\u00e4nda och vilka fallgropar som kan uppst\u00e5 i processerna. D\u00e4rf\u00f6r \u00e4r det l\u00e4ttare att byta ut det nya.<\/p>\n

Om ni g\u00f6r allt sj\u00e4lva och f\u00f6retaget saknar seri\u00f6s kompetens \u2014 v\u00e4lj en ny tj\u00e4nst. Om ni k\u00e4nner en extern konsult och har resurser \u2014 v\u00e4lj den gamla.<\/p><\/blockquote>\n

\nDet finns tj\u00e4nster som bara \u00e4r ett gr\u00e4nssnitt f\u00f6r anv\u00e4ndarna, till exempel en enkel webbplats eller mobilapp. Men det finns ocks\u00e5 mer komplexa saker som fakturering. Om n\u00e5got g\u00e5r fel med faktureringen kan det bli sv\u00e5rt att reda upp. H\u00e4r har vi ocks\u00e5 ett val.<\/p>\n

Vi arbetar antingen med en kritisk tj\u00e4nst<\/strong>, men p\u00e5 grund av den lider vi redan, den skapar begr\u00e4nsningar, eller s\u00e5 arbetar vi med ett gr\u00e4nssnitt<\/strong>. Detta \u00e4r det andra urvalskriteriet. P\u00e5 liknande s\u00e4tt kan vi anlita en erfaren konsult \u2014 vi jobbar med den tunga varianten.<\/p>\n

Men \u00e4ven i det h\u00e4r fallet skulle jag inte rekommendera att g\u00f6ra s\u00e5, eftersom det, s\u00e5 l\u00e4nge det inte finns f\u00f6rst\u00e5else f\u00f6r vad man ska arbeta med och i vilken riktning man ska transformera, inte \u00e4r en bra id\u00e9 att ta n\u00e5got kritiskt och b\u00f6rja riva i det. D\u00e4rf\u00f6r f\u00f6redrar vi att arbeta med ett gr\u00e4nssnitt vars krossande inte \u00e4r kritiskt.<\/p>\n

L\u00e5t oss g\u00e5 vidare och titta p\u00e5 serviceteamet<\/b>. Med dem som arbetar med denna tj\u00e4nst kommer vi att beh\u00f6va ha ett n\u00e4ra och kontinuerligt samarbete.<\/p>\n

M\u00e4nniskorna i teamet delas grovt in i tv\u00e5 kategorier: konservativa<\/strong> \u2014 de lever i den gamla v\u00e4rlden eller vet helt enkelt inget om DevOps, och innovativa<\/strong>, som drar med sig alla moderna metoder. De senare f\u00f6rst\u00e5r inte alltid \u00e4mnet, men de \u00e4r \u00e5tminstone \u00f6ppna f\u00f6r det.<\/p>\n

\u00c5 ena sidan \u00e4r konservativa personer erfarna: de har varit l\u00e4nge i f\u00f6retaget och f\u00f6rst\u00e5r det p\u00e5 djupet, men de k\u00e4nner inte alltid till de senaste metoderna. \u00c5 andra sidan har vi innovat\u00f6rer som kanske har h\u00f6rt talas om trender, men troligen \u00e4r relativt nya i f\u00f6retaget. Vem av dem \u00e4r det b\u00e4st att samarbeta med?<\/p>\n

Vi m\u00e5ste p\u00e5 n\u00e5got s\u00e4tt samarbeta med konservativa, eftersom det \u00e4r deras tj\u00e4nst. Vi m\u00e5ste kommunicera med dem, klarg\u00f6ra tj\u00e4nstens specifikationer, vad som kan g\u00f6ras och vad som inte kan g\u00f6ras. Vi \u00e4r beroende av deras r\u00e5d. Vi kommer s\u00e4kert att beh\u00f6va ge dem uppgifter, eftersom de k\u00e4nner sin tj\u00e4nst b\u00e4ttre. D\u00e4rf\u00f6r \u00e4r det viktigt vilken grupp vi slutligen kommer att ha kontakt med.<\/p>\n

Det \u00e4r logiskt att v\u00e4lja innovat\u00f6rer i teamet, eftersom konservativa kan st\u00e4lla till med problem.\n<\/p><\/blockquote>\n

\nI praktiken h\u00e4nder det ofta att konservativa har mycket erfarenhet men saknar en f\u00f6rst\u00e5else f\u00f6r hur de ska g\u00e5 vidare. De \u00e4r helt enkelt r\u00e4dda f\u00f6r att bli avskedade efter transformationen och omstruktureringen av tj\u00e4nsten. Ibland, bara p\u00e5 grund av att de inte f\u00f6rst\u00e5r vad som h\u00e4nder, saboterar de arbetet.<\/p>\n

Jag har varit med om ett fall d\u00e4r en kille i teamet reparerade allt m\u00f6jligt, f\u00f6r att det tydligen var viktigare \u00e4n det vi gjorde just nu. Vi gav en uppgift: att implementera den h\u00e4r delen idag \u2014 nej, p\u00e5 andra sidan v\u00e4rlden brinner det, s\u00e5 vi g\u00e5r dit f\u00f6r att fixa det. Det \u00e4r sv\u00e5rt att arbeta med s\u00e5dana m\u00e4nniskor.<\/p>\n

Folk fr\u00e5n det konservativa teamet skjuter ofta upp uppgifter eller ignorerar dem helt. Och om, Gud f\u00f6rbjude, du har gjort ett misstag och inf\u00f6rt KPI:er f\u00f6r antal genomf\u00f6rda uppgifter, och en del av dem av n\u00e5gon anledning inte \u00e4r inkluderade i KPI:erna, s\u00e5 kommer de verkligen inte att g\u00f6ra n\u00e5got. De skulle i egentlig mening ha r\u00e4tt, eftersom de d\u00e5 f\u00f6rlorar sin bonus.<\/p>\n

Det \u00e4r enklare att arbeta med innovat\u00f6rer \u2014 de \u00e4r mer lojala.<\/strong>De har redan h\u00f6rt n\u00e5got, de vill fram\u00e5t, s\u00e5 de kommer att hj\u00e4lpa till. Vi beh\u00f6ver m\u00e4nniskor som \u00e4r villiga att k\u00e4mpa inledningsvis: om tj\u00e4nsten f\u00f6r\u00e4ndras kommer alla motg\u00e5ngar och fallgropar att upplevas av innovat\u00f6rerna som pionj\u00e4rer. Innovat\u00f6rer vill ha det senaste och mest moderna, \u00e4ven om det inneb\u00e4r att de f\u00e5r lida.<\/p>\n

Konservativa kan senare omv\u00e4ndas till v\u00e5r tro. N\u00e4r ni visar att ni har f\u00f6r\u00e4ndrat en del och allt fungerar bra, kommer de sannolikt ocks\u00e5 vilja prova och anta den nya DevOps-religionen.<\/p>\n

\"Hur
\n<\/p>\n

Sammanfattningsvis, om vi genomf\u00f6r hela transformationen internt i v\u00e5rt f\u00f6retag v\u00e4ljer vi: en ny tj\u00e4nst, helst med ett enkelt gr\u00e4nssnitt f\u00f6r att undvika stora problem vid eventuella fel, samt ett team av innovat\u00f6rer.<\/p><\/blockquote>\n

\nOm det finns m\u00f6jlighet att anlita en extern konsult, ist\u00e4llet f\u00f6r en ny tj\u00e4nst \u2013 tar vi den gamla tj\u00e4nsten som vi redan har problem med. M\u00e4nniskor som har arbetat med transformationer under en l\u00e4ngre tid i olika f\u00f6retag har sett olika fall och f\u00f6rst\u00e5r hur man b\u00f6r g\u00f6ra r\u00e4tt, samt vilken v\u00e4g man b\u00f6r g\u00e5.<\/p>\n

Vem \u00e4r inblandad?<\/h2>\n

\nVi beh\u00f6ver hitta alla som har n\u00e5gon koppling till tj\u00e4nsten: utvecklare, testare, administrat\u00f6rer, s\u00e4kerhetsexperter, chefer och eventuellt Product Owners. Trots att Product Owners inte \u00e4r tekniska specialister, har de en relation till tj\u00e4nsten: de fattar beslut och s\u00e4tter upp uppgifter.<\/p>\n

\"Hur
\n<\/p>\n

Alla som fattar beslut och p\u00e5verkar vad som sker med tj\u00e4nsten beh\u00f6ver vi hitta, l\u00e4ra k\u00e4nna och prata med.<\/p><\/blockquote>\n

\nVad beh\u00f6ver vi dem till? F\u00f6r att veta vem vi ska f\u00f6rhandla med<\/strong>. Under transformationen, n\u00e4r det vanliga arbetss\u00e4ttet med tj\u00e4nsten f\u00f6r\u00e4ndras, kommer det att ske st\u00f6rningar. Under en tid kommer det att uppst\u00e5 problem \u00e4r vi testar nya tillv\u00e4gag\u00e5ngss\u00e4tt. M\u00e4nniskorna m\u00e5ste vara beredda p\u00e5 detta och vara \u00f6verens.<\/p>\n

D\u00e4refter m\u00e5ste vi bygga en Value Stream Map och utan dessa m\u00e4nniskor g\u00e5r det inte, eftersom endast de tillsammans vet hela bilden av vad som h\u00e4nder. Ingen individ har hela kollen p\u00e5 vad som sker med tj\u00e4nsten.<\/p>\n

De kommer att rekommendera m\u00e4nniskor till teamet. Vi kommer senare att diskutera varf\u00f6r ett separat team beh\u00f6vs. Det kommer att beh\u00f6vas personer fr\u00e5n nuvarande avdelningar. De som har kunskap om tj\u00e4nsten kan rekommendera kollegor som t\u00e4nker i v\u00e5r riktning och som kan hj\u00e4lpa oss och har den kompetens vi beh\u00f6ver.<\/p>\n

D\u00e4refter samlar vi alla dessa personer fr\u00e5n olika avdelningar i samma rum och b\u00f6rjar bygga en Value Stream Map.<\/p>\n

Bygg Value Stream Map<\/h2>\n

\nValue Stream Map \u00e4r en schematisk representation som visar v\u00e4rdefl\u00f6det till kunden<\/strong>. Det \u00e4r hela processen fr\u00e5n id\u00e9 till implementering, inklusive alla mellanliggande steg och hur v\u00e4rdet slutligen n\u00e5r v\u00e5ra kunder.<\/p>\n

Value Stream Map beh\u00f6vs f\u00f6r att visualisera alla utvecklingssteg<\/strong>, lokalisera problem genom att m\u00e4ta som finns i den nuvarande processen och b\u00f6rja \u00e5tg\u00e4rda dessa problem, samt s\u00e4tta ett initialt m\u00e5l<\/strong>. Det h\u00e4r \u00e4r platsen d\u00e4r vi faktiskt b\u00f6rjar g\u00f6ra n\u00e5got.<\/p>\n

M\u00e4tv\u00e4rden<\/h3>\n

\nI litteraturen om Value Stream Map beskrivs m\u00e5nga olika metoder, men f\u00f6r b\u00f6rjan r\u00e4cker det med tre.<\/p>\n

Lead Time \u2014 f\u00f6rdr\u00f6jning\/v\u00e4ntan<\/strong> \u2014 den tid vi v\u00e4ntar p\u00e5 n\u00e5got. Till exempel v\u00e4ntar testaren p\u00e5 att en testmilj\u00f6 ska bli ledig, och under den tiden kan de inte g\u00f6ra n\u00e5got.<\/p>\n

Value Added Time \u2014 tid f\u00f6r v\u00e4rdeskapande arbete<\/strong> \u2014 det som vi har lagt tid p\u00e5 i ett visst steg f\u00f6r att skapa slutligt v\u00e4rde f\u00f6r anv\u00e4ndaren. Till exempel har testaren k\u00f6rt sina tester och b\u00f6rjat kontrollera n\u00e5got. Det \u00e4r tiden f\u00f6r v\u00e4rdeskapande arbete, n\u00e4r vi faktiskt g\u00f6r n\u00e5got f\u00f6r produkten. Det \u00e4r det kunderna betalar f\u00f6r \u2014 kvalitetsprogramvara.<\/p>\n

%C\/A \u2014 procent av godtagbart arbete. <\/strong>Vi har ett steg \u2014 utveckling, det andra steget \u2014 testning. Hur m\u00e5nga funktioner har testarna godtagit fr\u00e5n utvecklarna, och det finns denna procent.<\/p>\n

S\u00e5 h\u00e4r ser v\u00e5r karta ut.<\/p>\n

\"Hur
\n
\nDen kan se annorlunda ut beroende p\u00e5 organisationsstruktur, antal avdelningar och vad ni sysslar med. Men i allm\u00e4nhet kommer kartan att ha tv\u00e5 steg: id\u00e9 <\/strong>och analys<\/strong>. I detta steg f\u00f6rv\u00e4ntas data, till exempel Lead Time 2 veckor och Value Added Time 2 dagar.<\/p>\n

Vi t\u00e4cker absolut alla steg med m\u00e4tv\u00e4rden.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 hur m\u00e5nga uppgifter som l\u00e5g efter att analytikerna kommit p\u00e5 dem.<\/p>\n

Utveckling<\/strong> \u2014 hur m\u00e5nga veckor utvecklarna v\u00e4ntade p\u00e5 avklarande av uppgifter, milj\u00f6er eller utrustning \u2014 oavsett, men de v\u00e4ntar p\u00e5 n\u00e5got. Till exempel, 4 dagar implementerar de en funktion. H\u00e4r kommer m\u00e4tv\u00e4rdet %C\/A fram. Utvecklarna har tagit fr\u00e5n Backlog endast 80% av uppgifterna. De anser att de \u00e5terst\u00e5ende 20% har otydliga specifikationer och har skickat tillbaka dem f\u00f6r revidering.<\/p>\n

Testning<\/strong>. P\u00e5 schemat \u00e4r LT angivet till 4 dagar. Till exempel v\u00e4ntade testarna p\u00e5 att testmilj\u00f6n skulle bli ledig, VA 2 dagar testade de verkligen n\u00e5got, och %C\/A = 40 %. \u2014 endast 40 % av koden eller funktionerna som skickades av utvecklarna ans\u00e5gs av testarna vara adekvata. Allt annat gillade de inte av n\u00e5gon anledning.<\/p>\n

Jag kommer inte att g\u00e5 in p\u00e5 detaljer om hur man m\u00e4ter detta; i slutet av artikeln kommer jag att rekommendera litteratur d\u00e4r man kan l\u00e4ra sig mer.<\/p>\n

Det enda jag rekommenderar \u2014 lita inte p\u00e5 personer som kommer att g\u00f6ra en Value Stream Map med dig. De uppskattar hur mycket tid olika processer tar, men dessa uppskattningar \u00e4r inte alltid korrekta, s\u00e5 det \u00e4r b\u00e4ttre att m\u00e4ta sj\u00e4lv.<\/p>\n

Vi hade ett fall d\u00e4r vi kom till Operations-avdelningen och fr\u00e5gade hur l\u00e5ng tid det tar att f\u00e5 en ny funktion till produktion. Vi fick svaret att det tar 10 minuter, och vi undrade varf\u00f6r vi ens kom till det h\u00e4r f\u00f6retaget. Det visade sig att 10 minuter \u00e4r tiden f\u00f6r ett skript som tar koden och levererar den till servern. Men innan det ligger releasen i tre dagar p\u00e5 servern och samlar damm \u2014 det finns en uppgift i Backlogen som beh\u00f6ver deployas. S\u00e5 det finns en v\u00e4ntesteg f\u00f6re sj\u00e4lva deploy-stadiet, n\u00e4r projektet bara ligger stilla. Om vi inte hade g\u00e5tt med v\u00e5rt anteckningsblock, inte fastnat med blicken p\u00e5 uppgiften i Jira och inte b\u00f6rjat f\u00f6lja den steg f\u00f6r steg, skulle vi trott att allt var utm\u00e4rkt och att det inte fanns n\u00e5gra problem.<\/p>\n

D\u00e4rf\u00f6r m\u00e5ste m\u00e4tningarna \u00e4nd\u00e5 g\u00f6ras av dig sj\u00e4lv, helst inte bara en g\u00e5ng, f\u00f6r att f\u00e5 en verklighetstrogen bild. Beroende p\u00e5 Value Stream Map kommer du att fatta beslut om var du ska b\u00f6rja och vad som ska \u00e5tg\u00e4rdas f\u00f6rst.<\/p>\n

Tillf\u00e4llig team<\/h2>\n

\nM\u00e5nga f\u00f6retag som har beslutat sig f\u00f6r att inf\u00f6ra DevOps skapar ett team, men inte ett tillf\u00e4lligt utan ett som har funnits i flera \u00e5r. Om du kontaktar DevOps-tj\u00e4nsten f\u00f6r urs\u00e4kter, d\u00e4r olika m\u00f6nster f\u00f6r att bygga organisationsstrukturer inom DevOps beskrivs, kommer du att f\u00f6rst\u00e5 att detta \u00e4r ett antipattern.<\/p>\n

N\u00e4r ett DevOps-team existerar konstant under flera \u00e5r \u2014 det \u00e4r ett stort misstag, eftersom DevOps handlar om kommunikation mellan avdelningar, om hastighet och effektivitet.<\/p><\/blockquote>\n

\nOm teamet finns mellan avdelningar bara f\u00f6r att g\u00f6ra n\u00e5got separat och har existerat l\u00e4nge, s\u00e5 skapar det en on\u00f6dig barri\u00e4r. Nu m\u00e5ste programmeraren ist\u00e4llet f\u00f6r att direkt g\u00e5 till administrat\u00f6ren f\u00f6r att l\u00f6sa ett problem, f\u00f6rst v\u00e4nda sig till DevOps-avdelningen, som sedan tar det vidare.<\/p>\n

D\u00e4rf\u00f6r, f\u00f6r att b\u00f6rja, beh\u00f6ver vi skapa ett tillf\u00e4lligt team.<\/strong>. Den kommer att existera i cirka ett halvt \u00e5r, max ett \u00e5r, beroende p\u00e5 den uppgift vi har st\u00e4llt upp, bara f\u00f6r att l\u00f6sa en begr\u00e4nsning som vi har valt. Efter det kommer den att d\u00f6 ut. Om vi v\u00e4ljer n\u00e4sta punkt d\u00e4r vi har s\u00e4rskilt ont, och inser att vi ocks\u00e5 beh\u00f6ver ett separat team f\u00f6r det, d\u00e5 kommer vi att skapa det igen. Men p\u00e5 en \"permanent\" basis ska s\u00e5dana team inte existera - d\u00e5 st\u00f6r de bara kommunikationen och tar p\u00e5 sig helt orelaterade uppgifter, bara f\u00f6r att g\u00f6ra n\u00e5got. Dessa uppgifter beh\u00f6ver inte alls ha n\u00e5got att g\u00f6ra med DevOps och transformation. Varf\u00f6r skulle vi inte \u00f6verl\u00e5ta denna uppgift till befintliga avdelningar?<\/p>\n

Varf\u00f6r beh\u00f6vs ett tempor\u00e4rt team<\/h3>\n

\nKonflikt med nuvarande processer<\/strong>. DevOps-transformation \u00e4r en f\u00f6r\u00e4ndring av inte bara teknologier och verktyg som vi anv\u00e4nder, utan \u00e4ven av arbetsprocessen, t\u00e4nkes\u00e4ttet och v\u00e4rderingarna. Om teamet arbetar som de alltid har gjort, kommer de inte att kunna prova andra tillv\u00e4gag\u00e5ngss\u00e4tt.<\/p>\n

Dessa m\u00e4nniskor m\u00e5ste leva enligt andra regler: ignorera alla KPI:er i f\u00f6retaget, eftersom de f\u00f6rs\u00f6ker arbeta p\u00e5 ett annat s\u00e4tt. Tempor\u00e4ra team kommer inte att fylla i beg\u00e4rningar f\u00f6r att f\u00e5 en server, utan kommer direkt att g\u00e5 till avdelningen som hanterar dem med krav p\u00e5 att f\u00e5 det de beh\u00f6ver som en f\u00f6rsta prioritet, eftersom det \u00e4r en prioriterad uppgift och eftersom de f\u00f6rs\u00f6ker leva annorlunda. Teamet har en fullst\u00e4ndig konflikt med alla nuvarande processer. F\u00f6r att existerande arbetsmetoder inte ska st\u00f6ra dem nu, och att de inte ska st\u00f6ra andra, isolerar vi dessa m\u00e4nniskor genom att bilda ett separat team.<\/p>\n

Undvikande av byr\u00e5krati i experiment<\/strong>. I tempor\u00e4ra team finns det ingen byr\u00e5krati, de fyller inte i arbetsrapporter och rapporterar inte till chefer. Detta \u00e4r en helt separat v\u00e4rld d\u00e4r m\u00e4nniskor lever och t\u00e4nker annorlunda, och sysslar med helt andra saker. De beh\u00f6ver inte st\u00f6ras mer \u00e4n n\u00f6dv\u00e4ndigt.<\/p>\n

Oavbrutet arbete med tj\u00e4nsten<\/strong>. I det f\u00f6rsta steget valde vi n\u00e5got som vi ska experimentera med. Experiment och s\u00f6kande efter b\u00e4ttre arbetsmetoder \u00e4r bra, men vi vill ocks\u00e5 g\u00f6ra funktioner. Om hela teamet ist\u00e4llet f\u00f6r funktioner sysslar med transformation kommer vi att b\u00f6rja f\u00f6rlora int\u00e4kter, buggar kommer att h\u00e4nga l\u00e4nge - det \u00e4r inget vi beh\u00f6ver. Att skapa ett tempor\u00e4rt team g\u00f6r det m\u00f6jligt att experimentera utan att stoppa arbetet med produkten.<\/p>\n

Att spara tid p\u00e5 arbetsuppgifter<\/strong>. Det handlar \u00e5terigen om produkten. Det tar mycket tid f\u00f6r teamet att pr\u00f6va andra verktyg och liknande. Att f\u00e5 folk att beh\u00e4rska verktygen, b\u00f6rja implementera dem och anv\u00e4nda dem korrekt tar minst ett halv\u00e5r. Om de ocks\u00e5 ska h\u00e5lla p\u00e5 med produkten kommer det halv\u00e5ret att bli o\u00e4ndligt. Om folk sysslar med produkten, arbetar de \u00e5terigen med gamla processer \u2014 det beh\u00f6ver vi inte.<\/p>\n

D\u00e4rf\u00f6r avs\u00e4tter vi personer fr\u00e5n olika avdelningar till ett eget team som ska arbeta med transformeringen av tj\u00e4nsten. Resultatet blir att tj\u00e4nsten fungerar, forts\u00e4tter att utvecklas och samtidigt genomf\u00f6r vi n\u00e5gra experiment.<\/p>\n

Det tempor\u00e4ra teamet sysslar bara med DevOps-transformeringen \u2014 att ta bort de begr\u00e4nsningar vi har uppt\u00e4ckt, och inget annat.<\/p><\/blockquote>\n

\nTeamet best\u00e5r av m\u00e5ngsidiga personer<\/strong>. Det betyder att vi har tagit inte bara utvecklare. Vi kom inte till tj\u00e4nsten och tog d\u00e4rifr\u00e5n halva teamet \u2014 nej, vi tog personer fr\u00e5n olika avdelningar<\/strong>. F\u00f6r n\u00e5gra punkter sedan fann vi olika avdelningar och olika anst\u00e4llda som har en relation till den tj\u00e4nst som transformeras. Fr\u00e5n dem bygger vi ett team, eftersom det m\u00e5ste vara m\u00e5ngsidigt \u2014 vi kommer att \u00e4ndra b\u00e5de testprocessen, utvecklingsprocessen och tj\u00e4nsteunderh\u00e5llsprocessen. Olika kompetenser beh\u00f6vs.<\/p>\n

Normalt sett tar vi i princip en utvecklare, en testare och en ingenj\u00f6r \u2014 varje av dem en, och tillsammans med dem hittar vi en l\u00f6sning som g\u00f6r det m\u00f6jligt att leva annorlunda.<\/p>\n

Det \u00e4r \u00f6nskv\u00e4rt att dessa personer har auktoritet i organisationen<\/strong>. Kanske beh\u00f6vs en konservativ, \u00e4ven om vi helst vill undvika det. Om vi har ett stort f\u00f6retag kommer l\u00e5ngt ifr\u00e5n alla att tro p\u00e5 v\u00e5rt projekt, och n\u00e5gon kan st\u00e4lla till problem, till exempel genom att inte avs\u00e4tta en testmilj\u00f6. H\u00e4r beh\u00f6vs just \"auktoritet\" \u2014 en respekterad person med stor erfarenhet som har f\u00f6rtj\u00e4nat kollegers goda inst\u00e4llning. En anst\u00e4llds auktoritet i teamet kommer att f\u00f6renkla uppgiften och arbetet f\u00f6r det tempor\u00e4ra teamet. Folk kommer att t\u00e4nka:<\/p>\n

\u2014 Aha, den h\u00e4r coola killen som vi alla k\u00e4nner och \u00e4lskar har skrivit sig in \u2014 uppenbarligen finns det n\u00e5got i DevOps som \u00e4r v\u00e4rt att se n\u00e4rmare p\u00e5!<\/em><\/p>\n

S\u00e4tter m\u00e5l<\/h2>\n

\nVi har samlat folk, valt en tj\u00e4nst, tittat p\u00e5 begr\u00e4nsningarna och definierat vilka m\u00e4nniskor vi p\u00e5verkar. Nu beh\u00f6ver vi s\u00e4tta ett m\u00e5l, och det m\u00e5ste vara helt enligt SMART<\/strong> \u2014 allt, precis som vi gillar.<\/p>\n

Specific \u2014 specifik<\/strong>.<\/p>\n

Measurable \u2014 m\u00e4tbar<\/strong>. Detta \u00e4r en mycket viktig punkt i SMART. Om du inte kan m\u00e4ta n\u00e5got, kan du inte f\u00f6r\u00e4ndra det eller f\u00f6rst\u00e5 vad du har gjort b\u00e4ttre eller s\u00e4mre.<\/p>\n

Achievable \u2014 uppn\u00e5elig<\/strong>. Ta h\u00e4nsyn till din specifika situation. Om du \u00e4r ett storf\u00f6retag med l\u00e5ng historia och stora \u00e5taganden, som sl\u00e4pper en version av produkten per \u00e5r, kan du inte p\u00e5 sex m\u00e5nader n\u00e5 att sl\u00e4ppa nya versioner av produkten varje timme. S\u00e5 fungerar det inte. S\u00e4tt d\u00e4rf\u00f6r ett realistiskt m\u00e5l som \u00e4r uppn\u00e5eligt inom en rimlig tidsram.<\/p>\n

Relevant \u2014 relevant. <\/strong>Vi eliminerar endast det begr\u00e4nsning som verkligen p\u00e5verkar v\u00e5ra nuvarande m\u00e5l.<\/p>\n

Time Limited \u2014 tidsbegr\u00e4nsad<\/strong>. Utan deadlin \u00e4r teamet ben\u00e4get att syssla med vad som helst: prova 15 teknologier ist\u00e4llet f\u00f6r 3, skriva stora rapporter, genomf\u00f6ra meningsl\u00f6sa unders\u00f6kningar, polera sin implementation till perfektion n\u00e4r m\u00e5let redan har uppn\u00e5tts.<\/p>\n

M\u00e5let formulera vi med hj\u00e4lp av Value Stream Map \u2014 vi samlar \u00e5terigen alla personer och ritar. Men den h\u00e4r g\u00e5ngen, baserat p\u00e5 den tidigare Value Stream Map, ritar vi vad vi vill uppn\u00e5.<\/p>\n

\"Hur
\n
\nVi identifierar en begr\u00e4nsning som vi ska eliminera just nu \u2014 det kommer teamet att syssla med. Till exempel har jag valt v\u00e4ntan fr\u00e5n f\u00e4rdig release till dess distribution i produktion \u2014 detta \u00e4r den vanligaste begr\u00e4nsningen som folk v\u00e4nder sig till konsulter med.<\/p>\n

Baserat p\u00e5 detta formulerar vi en uppgift: vi vill att v\u00e4ntan mellan f\u00e4rdig release och att g\u00e5 live ska vara max en timme.<\/p>\n

Exempel p\u00e5 uppgifter.<\/p>\n