Hur man påbörjar en DevOps-transformation

Om du inte förstår vad DevOps är, här är en kort sammanfattning. DevOps är en uppsättning metoder som minskar ingenjörers rädsla och minskar antalet driftstörningar i mjukvaruproduktion. I regel förkortar de också tiden till marknaden — perioden från idé till leverans av den slutliga produkten till kunderna, vilket möjliggör snabba businessexperiment.

Hur påbörjar man en DevOps-transformation? Kort sagt: vi väljer en tjänst som vi börjar med, identifierar dem som är relaterade till tjänsten, skapar en Value Stream Map, sätter ihop ett tillfälligt team som kommer att hantera transformationen under en tid och ger dem en uppgift. Vi upprepar cykeln så många gånger som behövs.

En detaljerad plan för DevOps-transformationen med exempel och instruktioner finns under länken presentationen Andrey Alexandrov — ingenjör vid företaget Express42, som ger råd om DevOps-förbättringar och påskyndar denna process eftersom de redan har kartlagt fallgroparna. Om du tror att en transformation inte är nödvändig för dig, eller om din specifik gör att DevOps-praktiker inte passar, — använd presentationen som en vägledning för att identifiera och åtgärda begränsningar.

Om du oroar dig för frågan om DevOps-transformation, innebär det att du har ett stort företag och att du behöver skala denna process över hela strukturen steg för steg. Så länge det finns ett behov av att transformera teamet eller åtgärda någon begränsning kan algoritmen nedan upprepas.

Val av tjänst

Planen är tydlig, låt oss börja med första steget — val av tjänst. Den första kriteriet är livslängd: det finns gamla tjänster — legacy, och nya. Man kan börja med både och.

Att välja en ung tjänst är logiskt. Den är ny, det finns ännu ingen etablerad arbetsprocess i teamet som hanterar den. Det finns ingen enorm teknisk skuld runt den, och det krävs inte att den ständigt repareras. Vi kan göra vad vi vill med den.

När det gäller en gammal tjänst finns det problem relaterade till att förändra är alltid svårt. Det finns redan ett antal allvarliga begränsningar, men kanske hanteras de av människor som redan är redo att göra en förändring — de är trötta och vill göra något annorlunda för att det gör ont.

Arbetet med en gammal tjänst skapar en kraftfull prejudikat det finns alltid något som går att förändra i ert företag. Om ni har infört en ny tjänst som körs 100 gånger i timmen utan problem kan folk i företaget säga:

— Men det här är ju en ny tjänst! Det var ju så enkelt tidigare, prova att göra något med vår trasiga gamla grej.

Legacy-tjänster är värda att omvandla när ni gör det tillsammans med någon, till exempel om ni har bjudit in en extern konsult. Låt oss vara ärliga, transformationen kommer att skaka om allt möjligt.. Ni experimenterar och vet inte vart ni kommer att hamna, vilka teknologier ni ska använda och vilka fallgropar som kan uppstå i processerna. Därför är det lättare att byta ut det nya.

Om ni gör allt själva och företaget saknar seriös kompetens — välj en ny tjänst. Om ni känner en extern konsult och har resurser — välj den gamla.

Det finns tjänster som bara är ett gränssnitt för användarna, till exempel en enkel webbplats eller mobilapp. Men det finns också mer komplexa saker som fakturering. Om något går fel med faktureringen kan det bli svårt att reda upp. Här har vi också ett val.

Vi arbetar antingen med en kritisk tjänst, men på grund av den lider vi redan, den skapar begränsningar, eller så arbetar vi med ett gränssnitt. Detta är det andra urvalskriteriet. På liknande sätt kan vi anlita en erfaren konsult — vi jobbar med den tunga varianten.

Men även i det här fallet skulle jag inte rekommendera att göra så, eftersom det, så länge det inte finns förståelse för vad man ska arbeta med och i vilken riktning man ska transformera, inte är en bra idé att ta något kritiskt och börja riva i det. Därför föredrar vi att arbeta med ett gränssnitt vars krossande inte är kritiskt.

Låt oss gå vidare och titta på serviceteamet. Med dem som arbetar med denna tjänst kommer vi att behöva ha ett nära och kontinuerligt samarbete.

Människorna i teamet delas grovt in i två kategorier: konservativa — de lever i den gamla världen eller vet helt enkelt inget om DevOps, och innovativa, som drar med sig alla moderna metoder. De senare förstår inte alltid ämnet, men de är åtminstone öppna för det.

Å ena sidan är konservativa personer erfarna: de har varit länge i företaget och förstår det på djupet, men de känner inte alltid till de senaste metoderna. Å andra sidan har vi innovatörer som kanske har hört talas om trender, men troligen är relativt nya i företaget. Vem av dem är det bäst att samarbeta med?

Vi måste på något sätt samarbeta med konservativa, eftersom det är deras tjänst. Vi måste kommunicera med dem, klargöra tjänstens specifikationer, vad som kan göras och vad som inte kan göras. Vi är beroende av deras råd. Vi kommer säkert att behöva ge dem uppgifter, eftersom de känner sin tjänst bättre. Därför är det viktigt vilken grupp vi slutligen kommer att ha kontakt med.

Det är logiskt att välja innovatörer i teamet, eftersom konservativa kan ställa till med problem.

I praktiken händer det ofta att konservativa har mycket erfarenhet men saknar en förståelse för hur de ska gå vidare. De är helt enkelt rädda för att bli avskedade efter transformationen och omstruktureringen av tjänsten. Ibland, bara på grund av att de inte förstår vad som händer, saboterar de arbetet.

Jag har varit med om ett fall där en kille i teamet reparerade allt möjligt, för att det tydligen var viktigare än det vi gjorde just nu. Vi gav en uppgift: att implementera den här delen idag — nej, på andra sidan världen brinner det, så vi går dit för att fixa det. Det är svårt att arbeta med sådana människor.

Folk från det konservativa teamet skjuter ofta upp uppgifter eller ignorerar dem helt. Och om, Gud förbjude, du har gjort ett misstag och infört KPI:er för antal genomförda uppgifter, och en del av dem av någon anledning inte är inkluderade i KPI:erna, så kommer de verkligen inte att göra något. De skulle i egentlig mening ha rätt, eftersom de då förlorar sin bonus.

Det är enklare att arbeta med innovatörer — de är mer lojala.De har redan hört något, de vill framåt, så de kommer att hjälpa till. Vi behöver människor som är villiga att kämpa inledningsvis: om tjänsten förändras kommer alla motgångar och fallgropar att upplevas av innovatörerna som pionjärer. Innovatörer vill ha det senaste och mest moderna, även om det innebär att de får lida.

Konservativa kan senare omvändas till vår tro. När ni visar att ni har förändrat en del och allt fungerar bra, kommer de sannolikt också vilja prova och anta den nya DevOps-religionen.

Sammanfattningsvis, om vi genomför hela transformationen internt i vårt företag väljer vi: en ny tjänst, helst med ett enkelt gränssnitt för att undvika stora problem vid eventuella fel, samt ett team av innovatörer.

Om det finns möjlighet att anlita en extern konsult, istället för en ny tjänst – tar vi den gamla tjänsten som vi redan har problem med. Människor som har arbetat med transformationer under en längre tid i olika företag har sett olika fall och förstår hur man bör göra rätt, samt vilken väg man bör gå.

Vem är inblandad?

Vi behöver hitta alla som har någon koppling till tjänsten: utvecklare, testare, administratörer, säkerhetsexperter, chefer och eventuellt Product Owners. Trots att Product Owners inte är tekniska specialister, har de en relation till tjänsten: de fattar beslut och sätter upp uppgifter.

Alla som fattar beslut och påverkar vad som sker med tjänsten behöver vi hitta, lära känna och prata med.

Vad behöver vi dem till? För att veta vem vi ska förhandla med. Under transformationen, när det vanliga arbetssättet med tjänsten förändras, kommer det att ske störningar. Under en tid kommer det att uppstå problem är vi testar nya tillvägagångssätt. Människorna måste vara beredda på detta och vara överens.

Därefter måste vi bygga en Value Stream Map och utan dessa människor går det inte, eftersom endast de tillsammans vet hela bilden av vad som händer. Ingen individ har hela kollen på vad som sker med tjänsten.

De kommer att rekommendera människor till teamet. Vi kommer senare att diskutera varför ett separat team behövs. Det kommer att behövas personer från nuvarande avdelningar. De som har kunskap om tjänsten kan rekommendera kollegor som tänker i vår riktning och som kan hjälpa oss och har den kompetens vi behöver.

Därefter samlar vi alla dessa personer från olika avdelningar i samma rum och börjar bygga en Value Stream Map.

Bygg Value Stream Map

Value Stream Map är en schematisk representation som visar värdeflödet till kunden. Det är hela processen från idé till implementering, inklusive alla mellanliggande steg och hur värdet slutligen når våra kunder.

Value Stream Map behövs för att visualisera alla utvecklingssteg, lokalisera problem genom att mäta som finns i den nuvarande processen och börja åtgärda dessa problem, samt sätta ett initialt mål. Det här är platsen där vi faktiskt börjar göra något.

Mätvärden

I litteraturen om Value Stream Map beskrivs många olika metoder, men för början räcker det med tre.

Lead Time — fördröjning/väntan — den tid vi väntar på något. Till exempel väntar testaren på att en testmiljö ska bli ledig, och under den tiden kan de inte göra något.

Value Added Time — tid för värdeskapande arbete — det som vi har lagt tid på i ett visst steg för att skapa slutligt värde för användaren. Till exempel har testaren kört sina tester och börjat kontrollera något. Det är tiden för värdeskapande arbete, när vi faktiskt gör något för produkten. Det är det kunderna betalar för — kvalitetsprogramvara.

%C/A — procent av godtagbart arbete. Vi har ett steg — utveckling, det andra steget — testning. Hur många funktioner har testarna godtagit från utvecklarna, och det finns denna procent.

Så här ser vår karta ut.

Den kan se annorlunda ut beroende på organisationsstruktur, antal avdelningar och vad ni sysslar med. Men i allmänhet kommer kartan att ha två steg: idé och analys. I detta steg förväntas data, till exempel Lead Time 2 veckor och Value Added Time 2 dagar.

Vi täcker absolut alla steg med mätvärden.

Backlog — hur många uppgifter som låg efter att analytikerna kommit på dem.

Utveckling — hur många veckor utvecklarna väntade på avklarande av uppgifter, miljöer eller utrustning — oavsett, men de väntar på något. Till exempel, 4 dagar implementerar de en funktion. Här kommer mätvärdet %C/A fram. Utvecklarna har tagit från Backlog endast 80% av uppgifterna. De anser att de återstående 20% har otydliga specifikationer och har skickat tillbaka dem för revidering.

Testning. På schemat är LT angivet till 4 dagar. Till exempel väntade testarna på att testmiljön skulle bli ledig, VA 2 dagar testade de verkligen något, och %C/A = 40 %. — endast 40 % av koden eller funktionerna som skickades av utvecklarna ansågs av testarna vara adekvata. Allt annat gillade de inte av någon anledning.

Jag kommer inte att gå in på detaljer om hur man mäter detta; i slutet av artikeln kommer jag att rekommendera litteratur där man kan lära sig mer.

Det enda jag rekommenderar — lita inte på personer som kommer att göra en Value Stream Map med dig. De uppskattar hur mycket tid olika processer tar, men dessa uppskattningar är inte alltid korrekta, så det är bättre att mäta själv.

Vi hade ett fall där vi kom till Operations-avdelningen och frågade hur lång tid det tar att få en ny funktion till produktion. Vi fick svaret att det tar 10 minuter, och vi undrade varför vi ens kom till det här företaget. Det visade sig att 10 minuter är tiden för ett skript som tar koden och levererar den till servern. Men innan det ligger releasen i tre dagar på servern och samlar damm — det finns en uppgift i Backlogen som behöver deployas. Så det finns en väntesteg före själva deploy-stadiet, när projektet bara ligger stilla. Om vi inte hade gått med vårt anteckningsblock, inte fastnat med blicken på uppgiften i Jira och inte börjat följa den steg för steg, skulle vi trott att allt var utmärkt och att det inte fanns några problem.

Därför måste mätningarna ändå göras av dig själv, helst inte bara en gång, för att få en verklighetstrogen bild. Beroende på Value Stream Map kommer du att fatta beslut om var du ska börja och vad som ska åtgärdas först.

Tillfällig team

Många företag som har beslutat sig för att införa DevOps skapar ett team, men inte ett tillfälligt utan ett som har funnits i flera år. Om du kontaktar DevOps-tjänsten för ursäkter, där olika mönster för att bygga organisationsstrukturer inom DevOps beskrivs, kommer du att förstå att detta är ett antipattern.

När ett DevOps-team existerar konstant under flera år — det är ett stort misstag, eftersom DevOps handlar om kommunikation mellan avdelningar, om hastighet och effektivitet.

Om teamet finns mellan avdelningar bara för att göra något separat och har existerat länge, så skapar det en onödig barriär. Nu måste programmeraren istället för att direkt gå till administratören för att lösa ett problem, först vända sig till DevOps-avdelningen, som sedan tar det vidare.

Därför, för att börja, behöver vi skapa ett tillfälligt team.. Den kommer att existera i cirka ett halvt år, max ett år, beroende på den uppgift vi har ställt upp, bara för att lösa en begränsning som vi har valt. Efter det kommer den att dö ut. Om vi väljer nästa punkt där vi har särskilt ont, och inser att vi också behöver ett separat team för det, då kommer vi att skapa det igen. Men på en "permanent" basis ska sådana team inte existera - då stör de bara kommunikationen och tar på sig helt orelaterade uppgifter, bara för att göra något. Dessa uppgifter behöver inte alls ha något att göra med DevOps och transformation. Varför skulle vi inte överlåta denna uppgift till befintliga avdelningar?

Varför behövs ett temporärt team

Konflikt med nuvarande processer. DevOps-transformation är en förändring av inte bara teknologier och verktyg som vi använder, utan även av arbetsprocessen, tänkesättet och värderingarna. Om teamet arbetar som de alltid har gjort, kommer de inte att kunna prova andra tillvägagångssätt.

Dessa människor måste leva enligt andra regler: ignorera alla KPI:er i företaget, eftersom de försöker arbeta på ett annat sätt. Temporära team kommer inte att fylla i begärningar för att få en server, utan kommer direkt att gå till avdelningen som hanterar dem med krav på att få det de behöver som en första prioritet, eftersom det är en prioriterad uppgift och eftersom de försöker leva annorlunda. Teamet har en fullständig konflikt med alla nuvarande processer. För att existerande arbetsmetoder inte ska störa dem nu, och att de inte ska störa andra, isolerar vi dessa människor genom att bilda ett separat team.

Undvikande av byråkrati i experiment. I temporära team finns det ingen byråkrati, de fyller inte i arbetsrapporter och rapporterar inte till chefer. Detta är en helt separat värld där människor lever och tänker annorlunda, och sysslar med helt andra saker. De behöver inte störas mer än nödvändigt.

Oavbrutet arbete med tjänsten. I det första steget valde vi något som vi ska experimentera med. Experiment och sökande efter bättre arbetsmetoder är bra, men vi vill också göra funktioner. Om hela teamet istället för funktioner sysslar med transformation kommer vi att börja förlora intäkter, buggar kommer att hänga länge - det är inget vi behöver. Att skapa ett temporärt team gör det möjligt att experimentera utan att stoppa arbetet med produkten.

Att spara tid på arbetsuppgifter. Det handlar återigen om produkten. Det tar mycket tid för teamet att pröva andra verktyg och liknande. Att få folk att behärska verktygen, börja implementera dem och använda dem korrekt tar minst ett halvår. Om de också ska hålla på med produkten kommer det halvåret att bli oändligt. Om folk sysslar med produkten, arbetar de återigen med gamla processer — det behöver vi inte.

Därför avsätter vi personer från olika avdelningar till ett eget team som ska arbeta med transformeringen av tjänsten. Resultatet blir att tjänsten fungerar, fortsätter att utvecklas och samtidigt genomför vi några experiment.

Det temporära teamet sysslar bara med DevOps-transformeringen — att ta bort de begränsningar vi har upptäckt, och inget annat.

Teamet består av mångsidiga personer. Det betyder att vi har tagit inte bara utvecklare. Vi kom inte till tjänsten och tog därifrån halva teamet — nej, vi tog personer från olika avdelningar. För några punkter sedan fann vi olika avdelningar och olika anställda som har en relation till den tjänst som transformeras. Från dem bygger vi ett team, eftersom det måste vara mångsidigt — vi kommer att ändra både testprocessen, utvecklingsprocessen och tjänsteunderhållsprocessen. Olika kompetenser behövs.

Normalt sett tar vi i princip en utvecklare, en testare och en ingenjör — varje av dem en, och tillsammans med dem hittar vi en lösning som gör det möjligt att leva annorlunda.

Det är önskvärt att dessa personer har auktoritet i organisationen. Kanske behövs en konservativ, även om vi helst vill undvika det. Om vi har ett stort företag kommer långt ifrån alla att tro på vårt projekt, och någon kan ställa till problem, till exempel genom att inte avsätta en testmiljö. Här behövs just "auktoritet" — en respekterad person med stor erfarenhet som har förtjänat kollegers goda inställning. En anställds auktoritet i teamet kommer att förenkla uppgiften och arbetet för det temporära teamet. Folk kommer att tänka:

— Aha, den här coola killen som vi alla känner och älskar har skrivit sig in — uppenbarligen finns det något i DevOps som är värt att se närmare på!

Sätter mål

Vi har samlat folk, valt en tjänst, tittat på begränsningarna och definierat vilka människor vi påverkar. Nu behöver vi sätta ett mål, och det måste vara helt enligt SMART — allt, precis som vi gillar.

Specific — specifik.

Measurable — mätbar. Detta är en mycket viktig punkt i SMART. Om du inte kan mäta något, kan du inte förändra det eller förstå vad du har gjort bättre eller sämre.

Achievable — uppnåelig. Ta hänsyn till din specifika situation. Om du är ett storföretag med lång historia och stora åtaganden, som släpper en version av produkten per år, kan du inte på sex månader nå att släppa nya versioner av produkten varje timme. Så fungerar det inte. Sätt därför ett realistiskt mål som är uppnåeligt inom en rimlig tidsram.

Relevant — relevant. Vi eliminerar endast det begränsning som verkligen påverkar våra nuvarande mål.

Time Limited — tidsbegränsad. Utan deadlin är teamet benäget att syssla med vad som helst: prova 15 teknologier istället för 3, skriva stora rapporter, genomföra meningslösa undersökningar, polera sin implementation till perfektion när målet redan har uppnåtts.

Målet formulera vi med hjälp av Value Stream Map — vi samlar återigen alla personer och ritar. Men den här gången, baserat på den tidigare Value Stream Map, ritar vi vad vi vill uppnå.

Vi identifierar en begränsning som vi ska eliminera just nu — det kommer teamet att syssla med. Till exempel har jag valt väntan från färdig release till dess distribution i produktion — detta är den vanligaste begränsningen som folk vänder sig till konsulter med.

Baserat på detta formulerar vi en uppgift: vi vill att väntan mellan färdig release och att gå live ska vara max en timme.

Exempel på uppgifter.

• Minska ledtiden för testning från 4 dagar till 1 timme.
• Minska den värdefulla tiden för testning från 2 dagar till 3 timmar.
• Minska ledtiden för distribution från 5 timmar till 10 minuter.
• Öka C/A från 50% till 95%, det vill säga öka antalet funktioner som accepteras av testarna, med andra ord, förbättra kvaliteten på utvecklarnas arbete.

Exemplen på uppgifter är inte tagna ur luften — de baseras på mätningar vi gjorde när vi utvecklade Value Stream Map.

Formulera en liknande uppgift till vårt team och en begränsning i tid. Beroende på hur bra allt går i ditt företag, sätter du olika tidsramar. I genomsnitt tar det, om människor sysslar med detta för första gången och inte vet vilka teknologier de ska använda och hur de specifikt kommer att lösa problemet, vanligtvis ett halvår.

Kortsiktigt planerande

Så, vårt team är bildat, det har ett mål, människor börjar arbeta. En viktig punkt är den korta planeringen av arbetet: sprintar som varar en eller två veckoroch, inte mer, mätbara förbättringar varje vecka och kurskorrigering.

Till exempel använder vi ofta tillvägagångssättet moving-moving, när hela teamet samlas i början av varje vecka, skisserar i en fil vad varje person ska göra. Efter en vecka noterar vi: vad som har gjorts och vad som inte har gjorts, om något inte har gjorts, varför, och tänker på vad vi ska göra härnäst.

Sprintarna gör att vi i tid kan justera vår kurs.

Vi har provat något i en eller två veckor: teknologier, metoder, arbetsformer, efter det mäter vi igen och ser – har det blivit bättre eller sämre med detta tillvägagångssätt? Ifall det har blivit sämre, så går vi inte i rätt riktning, vi måste justera kursen: sätta en annan uppgift, använda en annan teknologi eller göra något annat. Korta sprintar på 1-2 veckor gör det möjligt att manövrera och snabbt bortse från dåliga beslut.

Vi delar med oss av framgångar

Teamet uppnår vissa framgångar, små eller stora – det spelar ingen roll, det finns alltid något resultat. Alla bör veta om denna framgång: både de som är involverade i DevOps och de angränsande avdelningarna. I en ideal värld skulle det vara önskvärt att detta nådde alla i företaget.

Varför? Om vi vill att hela företaget ska transformeras, ta bort alla begränsningar så att företaget blir flexibelt, att koden snabbt når kunden och ingenting går sönder, måste alla vara lojala till DevOps-idén. Du kan inte tillämpa tillvägagångssättet på tjänster och team som är kategoriskt emot.

För att lojalitet ska uppstå, måste vi berätta för alla vad vi har provat – vi har ett resultat, prova gärna också! Det kommer öka intresset och lojaliteten till vad vi gör, människor kommer börja testa saker direkt. Som erfarenheten visar, när vi berättar vad vi har provat och vad vi har uppnått, börjar andra team fråga hur och vad vi gjorde. De ser på genomföranden, koden, dokumentationen, kommer med frågor och försöker förändra något i sina egna processer.

Att berätta om vad ni har lyckats åstadkomma – är viktigt. På så sätt övertygar ni de konservativa att gå över till er sida, de som ville göra allt på det gamla sättet och förvandlar dem till innovatörer.

Sammanfattningsvis

Vi väljer tjänsten, som utgångspunkt – den plats där vi börjar förändringar i företaget. Vi identifierar alla som har någon form av relation till tjänsten och tillsammans med dem bygger vi en Value Stream Map, mäter och ser var och vilka begränsningar som finns.

Vi skapar ett nytt tillfälligt team, som ska lösa den uppsatta uppgiften. Baserat på mätningarna och Value Stream Map ritar vi en ny karta, där vi markerar den begränsning vi kommer att fokusera på. Baserat på denna begränsning sätter vi en uppgift, som teamet ska arbeta med. Uppgiften måste vara definitivt SMART — specifik, mätbar, relevant för de aktuella uppgifterna och tidsbegränsad.

Vi upprepar processen, tills vi har transformerat alla våra tjänster till det önskade tillståndet och eliminerat alla begränsningar.

Bonus. Användbara material

För de som har bestämt sig för att börja med DevOps på egen hand.

Projektet "Phoenix"

Det ursprungliga namnet är "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win". Det är en roman om DevOps - en historia om hur en anställd blev chef för en avdelning som alltid var i brand. Den nya chefen fick en uppgift:

— Du har några år på dig att rätta till allt så att vi äntligen kan leverera vår produkt snabbt och effektivt till våra kunder.

"Projekt 'Phoenix'. En roman om hur DevOps förändrar livet till det bättre" — en bok för alla ledare, eftersom det just är dessa personer som fattar beslut om vad som händer i företaget. Om du är ingenjör eller programmerare och vill få fart på transformationen i ditt företag — köp boken och ge den i present till ledningen. Denna roman förklarar allt och är lätt att läsa.

Guide till DevOps

En mer komplex bok. Den gavs ut för flera år sedan på engelska under namnet "The DevOps Handbook How to create world-class agility, reliability, and security in Technology organizations", men finns nu även på ryska. Det är en riktig handbok — en praktisk guide: hur man genomför mätningar, vad en Value Stream Map är och varför den behövs, vilken väg man bör ta och i vilken ordning. Boken är just för dem som vill göra allt själva. Det viktigaste är att den innehåller exempel på erfarenheter från andra företag.

Till exempel beskriver det hur ett företag byggde en Value Stream Map och insåg att begränsningen inte låg i produkten, utan i att kassapersonalen gick från butiken till det intilliggande kontoret för att använda produkten. Istället för att lösa problemet med programmet köpte de surfplattor till sina säljare, och nu går ingen någonstans, utan alla aktiviteter utförs på arbetsplatsen. Slutsats: Value Stream Map kan tillämpas inte bara på programvara, utan även på alla processer i organisationen.

Accelerera

Hela titeln är: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations". Detta är nästa nivå - hardcore. Boken släpptes förra året, hittills bara på engelska och handlar om forskning. Författarna - Nicole Forsgren, Jez Humble och Gene Kim - har under många år tillämpat olika metoder i olika företag och undersökt vilka metoder som påverkar och hur.

I det andra kapitlet, som handlar om mätningar, nämns Value Stream Map, de metriker jag tidigare nämnt och många andra, samt en detaljerad beskrivning av mätprocesserna. Författarna genomför mätningar med hjälp av enkäter och självövervakning av uppgifter. Det förklaras noggrant vilka metriker som bör mätas, vilka som inte bör göra det, samt mänskliga fel i mätningarna. Om du har problem med mätningar, titta på det andra kapitlet i boken "Accelerate". Om ditt team har många metoder men det är oklart vilka metoder som ska tillämpas nu, vilka senare, vilka som verkligen fungerar och vilka som inte gör det - läs, boken förklarar allt.

Transformation är en fråga i skärningspunkten mellan DevOps och ledning. Någonstans i samma område av korsningen mellan utveckling, drift och testning finns ämnen som vi försöker diskutera på DevOpsConf, samma integration behövs för att skapa en kvalitetsprodukt – huvudtemat för QualityConf. Ledning på festivalen RIT++ presenteras Whale Rider – innebär att alla idéer för transformation finns där. Gå med 27 och 28 maj, vi ska integrera och transformera.

Källa: habr.com