Slik starter du DevOps-transformasjon

Hvis du ikke forstår hva DevOps er, her er et raskt jukseark. DevOps er et sett med praksis som reduserer ingeniørers frykt og redusere antall feil i programvareproduksjon. Som regel er de like redusere tiden til markedet — perioden fra ideen til levering av det endelige produktet til kundene, som lar deg raskt gjennomføre forretningseksperimenter.

Hvordan starte DevOps-transformasjon? Kort sagt: vi velger tjenesten som skal starte prosessen med, identifiserer de som er relatert til tjenesten, bygger et verdistrømskart, oppretter et midlertidig team som skal håndtere transformasjonen for første gang og sette en oppgave for den. Vi gjentar syklusen det nødvendige antall ganger.

Detaljert DevOps transformasjonsplan med eksempler og instruksjoner under snittet - i transkripsjonen rapportere Andrey Alexandrov - en ingeniør hos Express42, som gir råd om DevOps-spiring, og fremskynder denne prosessen fordi hun allerede har bygget et rakekart. Hvis det ser ut til at du ikke trenger transformasjon, eller hvis dine detaljer er slik at DevOps-praksis ikke er egnet, bruk rapporten som instruksjoner for å finne og eliminere begrensninger.

Hvis du er bekymret for spørsmålet om DevOps-transformasjon, har du et stort selskap, og du må gradvis skalere denne prosessen gjennom hele strukturen. Så lenge det er behov for å transformere kommandoen eller eliminere noen begrensning, kan algoritmen nedenfor gjentas.

Velge en tjeneste

Vi har skissert en plan, la oss starte med det første trinnet - å velge en tjeneste. Det første kriteriet er levetid: det er gamle tjenester - gamle og nye. Du kan begynne med begge deler.

Det er logisk å velge en ung tjeneste. Det er ferskvare, det er ennå ikke en etablert prosess for å jobbe i teamet som behandler det. Det er ingen fjell av teknisk gjeld rundt det, du trenger ikke å fikse det hele tiden. Vi kan gjøre hva vi vil med den.

Når det gjelder den gamle tjenesten er det problemer knyttet til at endring er alltid vanskelig. Det er allerede et sett med noen alvorlige restriksjoner, men kanskje de blir håndtert av folk som er klare til å måke alt - de er slitne og vil gjøre noe annerledes fordi de har det vondt.

Å jobbe med en gammel tjeneste setter en kraftig presedens i din bedrift - du kan endre noe. Hvis du endrer en ny tjeneste, ruller den ned 100 ganger i timen, og alt er bra, kan folk i bedriften din si:

– Dette er en ny tjeneste! Alt var enkelt der, prøv å gjøre noe med vraket vårt.

Det er fornuftig å bruke Legacy-tjenesten til transformasjon når du gjør det med noen, for eksempel hvis du inviterte en ekstern konsulent. La oss være ærlige, forvandlingen vil ryste alt mulig. Du eksperimenterer og vet ikke hvor du ender opp, hvilke teknologier du vil bruke og hvorfor, hvor og hvilke fallgruver som vil oppstå i prosessene. Derfor er det lettere å endre en ny.

Gjør du alt selv, og bedriften ikke har seriøs kompetanse, tar vi en ny tjeneste. Kjenner du en ekstern konsulent og har midlene, velg den gamle.

Det finnes tjenester som ganske enkelt er et grensesnitt for brukere, for eksempel en enkel nettside eller mobilapplikasjon. Men det er alvorlige ting i faktureringens ånd. Hvis noe går galt med fakturering, vil det være vanskelig å finne ut av det. Her har vi også et valg.

Vi jobber heller med kritisk service, men vi lider på grunn av det, det skaper begrensninger, eller vi jobber med grensesnitt. Dette er det andre utvalgskriteriet. På samme måte er det mulig å tiltrekke seg en erfaren konsulent – ​​vi jobber med det vanskelige alternativet.

Men selv i dette tilfellet vil jeg ikke anbefale å gjøre dette, for før det er en forståelse av hva man skal jobbe med og i hvilken retning man skal transformere, er det ikke en veldig god idé å ta en kritisk ting og riste den opp. Derfor, i dette tilfellet, foretrekker vi å jobbe med et grensesnitt hvis feil ikke er kritisk.

La oss se videre serviceteam. Vi må hele tiden jobbe og samhandle veldig tett med de som yter denne tjenesten.

Personer på laget er delt inn i to kategorier: konservative – leve i den gamle verden, eller rett og slett ikke vet noe om DevOps, og innovatører, som drar alle fasjonable praksiser. Sistnevnte forstår ikke alltid temaet, men de er i det minste klare for det.

På den ene siden er konservative erfarne mennesker: de har vært i selskapet lenge, de forstår det innvendig og utvendig, men de vet ikke nøyaktig om praksisen. På den annen side er det innovatører som har hørt noe, men mest sannsynlig ikke har jobbet særlig lenge i selskapet. Hvilken er bedre å jobbe med?

Du må i alle fall samhandle med konservative, siden dette er deres tjeneste. Du må kommunisere med dem, finne ut spesifikasjonene til tjenesten, hva som kan gjøres på denne måten og hva annet. Vi er avhengige av deres råd. Du må nok betro dem noe, fordi de kjenner tjenesten deres bedre. Derfor er det viktig hvilket lag vi ender opp med å ha kontakt med.

Det er logisk å velge innovatører til laget, fordi konservative kan sette en gris i det.

I praksis hender det ofte at konservative har betydelig erfaring, men ikke har forståelse for hvordan de skal leve videre. De er rett og slett redde for at de etter transformasjon og redesign av tjenesten vil bli sparket som unødvendige. Noen ganger, rett og slett fordi de ikke forstår hva som skjer, saboterer de arbeidet.

Jeg hadde et tilfelle der en fyr fra teamet reparerte alt, fordi det visstnok var mer kritisk enn det vi gjør nå. Vi satte oppgaven: å implementere denne brikken i dag - nei, det er en brann på den andre siden av verden, vi skal fikse den. Det er vanskelig å jobbe med slike mennesker.

Folk fra det konservative teamet glemmer ofte oppgaver eller utsetter dem til siste minutt. Og hvis, John Willis forby, du gjorde en feil og tildelte dem en KPI for antall fullførte oppgaver, og av en eller annen grunn var en del ikke inkludert i KPIen, så vil de ikke gjøre noe i det hele tatt. Generelt vil de ha rett, for da mister de bonusen.

Det er enklere med innovatører – de er mer lojale. De har allerede hørt noe, de vil reise et sted, så de hjelper til. Vi trenger folk som er klare til å lide for første gang: Hvis tjenesten endres, vil innovatører fange alle støtene og rakene som pionerer. Innovatører vil ha alt nytt og fasjonabelt, og lider.

Høyre kan senere konverteres. Når du viser at du har endret et stykke og alt fungerer bra, vil de mest sannsynlig prøve det også og vil omfavne den nye DevOps-religionen.

La oss oppsummere. Hvis vi gjør hele transformasjonen i selskapet vårt selv, så velger vi: en ny tjeneste, helst et enkelt grensesnitt for ikke å lide for mye av sammenbruddet, og et team av innovatører.

Hvis det er mulig å ringe en ekstern konsulent, i stedet for en ny, tar vi den gamle tjenesten, som vi allerede lider av. Folk som har vært involvert i transformasjon i lang tid i forskjellige selskaper har sett forskjellige saker og forstår allerede hvordan de skal gjøre det riktig, og hvilken retning de skal gå generelt.

Hvem er involvert?

Vi må finne alle som i det minste har en relasjon til tjenesten: utviklere, testere, administratorer, sikkerhetsspesialister, ledere og, muligens, produkteiere. Til tross for at produkteiere ikke er tekniske spesialister, er de relatert til tjenesten: de tar beslutninger, setter oppgaver.

Alle som i det minste tar noen avgjørelser og påvirker hva som skjer med tjenesten må bli funnet, møtt og kommunisert.

Hva trenger vi dem til? Å vite hvem man skal forhandle med. Under transformasjon, når det vanlige prinsippet om å jobbe med tjenesten endres, vil det fortsatt riste. Det vil være feil en stund mens vi tester nye tilnærminger. Folk må være klare for dette og være enige i det.

Deretter må du bygge et verdistrømskart, og uten disse menneskene vil du ikke kunne bygge det, fordi bare de alle sammen vet det fulle bildet av hva som skjer. Én person vet aldri alt som skjer med tjenesten.

De vil anbefale folk til teamet Senere skal vi diskutere hvorfor det trengs et eget team. Det vil måtte ta folk fra eksisterende avdelinger. De som er involvert i tjenesten vil kunne anbefale kolleger som tenker i vår retning, som kan hjelpe oss og er kompetente på det vi trenger.

Deretter samler vi alle disse menneskene fra forskjellige avdelinger i ett rom og begynner å bygge et verdistrømkart.

Bygge et verdistrømkart

Value Stream Map er et diagram eller kart som viser flyten av verdier til klienten. Dette er hele prosessen fra å komme opp med en idé til implementeringen, inkludert alle mellomstadier og hvordan verdien til slutt kommer til våre kunder.

Value Stream Map er nødvendig for å visualisere alle stadier av utviklingen, lokalisere problemer gjennom målingene som eksisterer i den nåværende prosessen og begynne å eliminere disse problemene, og sette et første mål. Det er her vi faktisk begynner å gjøre noe.

Beregninger

Det er mange forskjellige beregninger beskrevet i litteraturen om verdistrømskart, men bare tre er nok til å komme i gang.

Ledetid - forsinkelse/vente - en tid da vi venter på noe. For eksempel venter en tester til teststativet er ledig, og kan i løpet av denne tiden ikke gjøre noe.

Value Added Time - nyttig arbeidstid - hva vi brukte på et slikt og slikt stadium for å skape den endelige verdien for brukeren. For eksempel startet en tester testen sin og begynte å sjekke noe. Dette er tiden for nyttig arbeid, når vi faktisk gjør noe for produktet. Det er dette kundene betaler for - kvalitetsprogramvare.

%C/A er prosentandelen av akseptert arbeid. Vi har ett trinn - utvikling, det andre trinnet - testing. Hvor mange funksjonstestere som godtas fra utviklere, er denne prosentandelen.

Omtrent slik ser kartet vårt ut.

Det kan se annerledes ut avhengig av strukturen i organisasjonen, antall avdelinger og hva du gjør. Men generelt vil det være to etapper på kartet: ideen и analyser. På dette stadiet forventes data, for eksempel Lead Time 2 uker og Value Added Time 2 dager.

Vi dekker absolutt alle stadier med beregninger.

backlog — hvor mange problemer var det etter at analytikerne kom med dem.

utforming - hvor mange uker utviklerne har ventet på avklaring om oppgaver, stands eller utstyr - det spiller ingen rolle, men de venter på noe. For eksempel tar det 4 dager å implementere en funksjon. Det er her %C/A-beregningen kommer inn. Utviklerne tok bare 80 % av oppgavene fra Backlog. De mener at de resterende 20 % ikke har en klar nok teknisk spesifikasjon, og sendte dem til revisjon.

Testing. LT-diagrammet er satt til 4 dager. For eksempel ventet testere på at testbenken skulle bli fri, VA testet de faktisk noe i 2 dager, og %C/A = 40%. — bare 40 % av koden eller funksjonene sendt av utviklerne ble ansett som tilstrekkelige av testerne. De likte ikke alt annet av en eller annen grunn.

Jeg vil ikke dvele i detalj om hvordan du utfører disse målingene; på slutten av artikkelen vil jeg anbefale litteratur som du kan lære om dem.

Det eneste jeg kan anbefale er at du ikke stoler på personene som vil kompilere et verdistrømskart med deg. De gir en ide om hvor lang tid ulike prosesser tar, men disse estimatene er ikke alltid korrekte, så det er best å måle deg selv.

Vi hadde en sak da vi kom til Driftsavdelingen og spurte hvor lang tid det tok å levere en ny funksjon til produksjon. De fortalte oss at det ville ta 10 minutter, og vi tenkte, hvorfor kom vi i det hele tatt til dette selskapet? Det viste seg at 10 minutter er kjøretiden til skriptet som tar koden og leverer den til serveren. Men før dette sitter utgivelsen på serveren i tre dager og samler rett og slett støv - det er en oppgave i Backlog som må distribueres. Det viser seg at før utplasseringsstadiet er det en ventefase, når prosjektet bare sitter der. Hvis vi ikke hadde gått med en notisblokk, ikke fått øye på oppgaven i Jira og begynt å spore den steg for steg, ville vi trodd at alt var bra og at det ikke var noe problem.

Derfor vil du fortsatt måtte gjøre målingene selv, gjerne mer enn én gang, for å ha en idé nær virkeligheten. Avhengig av verdistrømkartet bestemmer du hvor du skal begynne og hva du skal fikse først.

Midlertidig team

Mange selskaper som bestemmer seg for å implementere DevOps oppretter et team, men ikke et midlertidig, men et som har eksistert i flere år. Hvis du går til DevOps apologize-tjenesten, som beskriver ulike mønstre for å bygge en organisasjonsstruktur i DevOps, vil du forstå at dette er et anti-mønster.

Når et DevOps-team eksisterer kontinuerlig i flere år, er dette en stor feil, fordi DevOps handler om kommunikasjon mellom avdelinger, om hastighet og effektivitet.

Hvis et team eksisterer mellom avdelinger bare for å gjøre noe annet adskilt, og eksisterer i lang tid, så skaper det en unødvendig barriere. Nå må programmereren, i stedet for umiddelbart å gå til administratoren for å løse problemet, først kontakte DevOps-avdelingen, og han vil gå videre.

Derfor, for å komme i gang, må du opprette et midlertidig team. Den vil eksistere betinget i seks måneder, maksimalt et år, avhengig av oppgaven, bare for å eliminere en begrensning vi har valgt. Da vil hun dø. Hvis vi velger neste punkt der vi har mye vondt og innser at vi også trenger et eget lag til det, så vil vi skape det igjen. Men slike team bør ikke eksistere "på permanent basis" - da forstyrrer de kommunikasjonen og tar generelt på seg separate oppgaver bare for å få noe gjort. Disse oppgavene er kanskje ikke relatert til DevOps eller transformasjon i det hele tatt. Hvorfor gir vi ikke denne oppgaven til eksisterende avdelinger?

Hvorfor trengs et midlertidig team?

Konflikt med gjeldende prosesser. DevOps-transformasjon er ikke bare en endring i teknologiene og verktøyene vi bruker, men en endring i selve prosessen med arbeid, tenkning og verdier. Hvis teamet jobber slik det allerede er vant til, vil det ikke kunne prøve andre tilnærminger.

Disse menneskene må leve etter forskjellige regler: ignorer alle KPI-ene i selskapet fordi de prøver å jobbe annerledes. Midlertidige team vil ikke fylle ut søknader om å få server, men gå direkte til avdelingen som administrerer dem, og kreve at de får det de trenger først, fordi det er prioritert og fordi de prøver å leve annerledes. Teamet er i fullstendig konflikt med alle pågående prosesser. For å sikre at eksisterende arbeidspraksis ikke forstyrrer dem nå, og de ikke forstyrrer andre, isolerer vi disse personene i et eget team.

Unngå byråkrati i eksperimenter. Midlertidige team har ikke byråkrati, de lager ikke tidsrapporter, de rapporterer ikke til ledere. Dette er en helt egen verden der folk lever og tenker annerledes og gjør helt andre ting. Det er ingen grunn til å forstyrre dem igjen.

Non-stop arbeid på tjenesten. I det første punktet valgte vi noe som vi skal eksperimentere med. Å eksperimentere og finne måter å jobbe bedre på er bra, men vi ønsker også å lage funksjoner. Hvis hele teamet fokuserer på transformasjon i stedet for funksjoner, vil vi begynne å tape inntekter, feil vil henge rundt i lang tid - vi trenger ikke dette. Ved å opprette et midlertidig team kan du eksperimentere uten å stoppe arbeidet med produktet.

Ikke kast bort tid på arbeidsoppgaver. Det handler om produktet igjen. Det tar mye tid for teamet å prøve andre verktøy og sånt. Det vil ta minst seks måneder før folk mestrer verktøyene, begynner å implementere dem og bruke dem normalt. Fokuserer de i tillegg på produktet, vil seks måneder strekke seg kosmisk ut. Hvis folk jobber med produktet, jobber de igjen med de gamle prosessene - det trenger vi ikke.

Derfor tildeler vi personer fra ulike avdelinger til et eget team som skal transformere tjenesten. Som et resultat fungerer tjenesten, fortsetter å utvikle seg, og samtidig utfører vi noen eksperimenter på den.

Det midlertidige teamet er kun dedikert til DevOps-transformasjon - eliminerer begrensningen vi fant, og ingenting mer.

Teamet består av allsidige mennesker. Det betyr at vi ikke bare ansatte utviklere. Vi kom ikke til servicesenteret og tok halve teamet derfra - nei, vi tok folk fra ulike avdelinger. For noen punkter siden fant vi ulike avdelinger og ulike ansatte som er knyttet til den transformerte tjenesten. Vi rekrutterer et team fra dem, fordi det må være universelt - vi vil endre testprosessen, utviklingsprosessen og tjenestevedlikeholdsprosessen. Det trengs ulik kompetanse.

Vanligvis tar vi en utvikler, en tester og en ingeniør, en om gangen, og sammen med dem kommer vi frem til en løsning som gjør at vi kan leve annerledes.

Det er ønskelig at disse personene har myndighet i organisasjonen. Du må kanskje ta en konservativ, selv om du ikke vil. Hvis vi har et stort selskap, vil ikke alle tro på ideen vår, og noen kan sette en eiker i hjulene våre, for eksempel ved å ikke stille med stativ. Det er her du trenger en "autoritet" - en respektert person med lang erfaring som har fortjent den gode holdningen til sine kolleger. Myndigheten til den ansatte i teamet vil forenkle oppgaven og arbeidet til det midlertidige teamet. Folk vil tenke:

– Ja, denne kule fyren vi alle kjenner og elsker passer inn der – tydeligvis er det noe verdt å se i DevOps!

Sette et mål

Vi samlet folk, valgte en tjeneste, så på restriksjonene og bestemte hvilke personer vi ville påvirke. Nå må du sette et mål, og det skal være rett av SMART - alt vi elsker.

Spesifikt – spesifikt.

Målbart - målbart. Dette er et veldig viktig SMART-punkt. Hvis du ikke kan måle noe, kan du ikke endre det og forstå hva og hvordan du gjorde det bedre eller verre.

Oppnåelig - oppnåelig. Gjør justeringer for å passe dine spesifikke behov. Hvis du er et bedriftsselskap med en lang historie og en stor belastning av ansvar, som gir ut en versjon av produktet en gang i året, vil du ikke kunne oppnå utgivelsen av nye versjoner av produktet hver time i løpet av seks måneder. Det vil ikke fungere på den måten. Sett derfor et realistisk mål som er oppnåelig innenfor en akseptabel tidsramme.

Relevant – relevant. Vi fjerner bare begrensningene som faktisk tjener våre nåværende mål.

Tidsbegrenset - begrenset i tid. Hvis det ikke er noen tidsfrist, vil teamet gjøre hva de vil: prøve 15 teknologier i stedet for 3, skrive enorme rapporter, utføre ubrukelig forskning, polere implementeringen til den skinner når målet allerede er oppnådd.

Vi tar målet ved hjelp av Verdistrømskartet – vi samler alle personene på nytt og tegner dem. Men først nå, basert på forrige verdistrømskart, tegner vi det vi ønsker å få.

Vi fremhever en begrensning som vi vil eliminere akkurat nå - dette er hva laget skal gjøre. Som et eksempel tok jeg ventetiden fra den ferdige utgivelsen til den ble distribuert i produksjonen - dette er den vanligste begrensningen som folk henvender seg til konsulenter med.

Basert på dette setter vi oppgaven: vi ønsker at ventetiden mellom ferdig utgivelse og ut i kamp skal være maksimalt en time.

Eksempler på oppgaver.

• Reduser testtiden fra 4 dager til 1 time.
• Reduser verdiøkende tid for testing fra 2 dager til 3 timer.
• Reduser leveringstiden fra 5 timer til 10 minutter.
• Øk C/A fra 50 % til 95 %, det vil si øk antall funksjoner som testere aksepterer, med andre ord forbedrer kvaliteten på arbeidet til utviklere.

Eksempler på oppgaver er ikke tatt fra hodene våre – de er basert på målinger som vi gjorde da vi utviklet Verdistrømskartet.

Vi setter en lignende oppgave for teamet vårt og en tidsbegrensning. Avhengig av hvor bra bedriften din gjør det, setter du forskjellige tidsfrister. I gjennomsnitt tar det vanligvis seks måneder å eliminere en begrensning, hvis folk gjør dette for første gang og ennå ikke vet med hvilke teknologier og hvordan spesifikt de vil løse problemet.

Kort planlegging

Så laget vårt er opprettet, det har et mål, folk begynner å jobbe. Et viktig poeng er en kort planlegging av arbeidet: sprint en til to ukerog ikke mer, målbare forbedringer hver uke og kurskorrigering.

For eksempel bruker vi ofte tilnærmingen beveger segNår hele teamet samles i begynnelsen av hver uke, noterer de ned i en fil hva alle skal gjøre. Etter en uke noterer vi hva som har blitt gjort og hva som ikke har gjort det, hvis ikke, hvorfor, og vi tenker på hva vi skal gjøre videre.

Sprint lar deg foreta rettidige kurskorrigeringer.

I en uke eller to prøvde du noe: teknologier, tilnærminger, måter å jobbe på, etter det måler du igjen og ser – har det blitt bedre eller verre med denne tilnærmingen? Hvis det er verre, betyr det at vi går i feil retning, vi må rette kursen: sette en annen oppgave, ta en annen teknologi eller gjøre noe annet. Korte spurter på 1-2 uker lar deg manøvrere og unngå dårlige avgjørelser i tide.

Deler suksess

Teamet oppnår en viss suksess, liten eller stor - det spiller ingen rolle, det er alltid et resultat. Alle bør vite om dette resultatet: både de involverte i DevOps og naboavdelinger. I en ideell verden vil det være ønskelig at dette i det hele tatt kommer frem til alle personer i selskapet.

For hva? Hvis vi ønsker å transformere ikke bare en del av selskapet, eliminere ikke bare én begrensning, men alt generelt, slik at selskapet blir fleksibelt, koden raskt når kunden, og ingenting går i stykker, trenger vi at alle er lojale mot ideen av DevOps. Du vil ikke kunne bruke tilnærmingen til tjenester og team som er sterkt imot det.

For at lojalitet skal vises, må vi fortelle alle at vi har prøvd dette - vi har resultater, prøv det også! Dette vil øke interessen og lojaliteten til det vi gjør, folk vil begynne å prøve å gjøre noe akkurat nå. Som praksis viser, når vi forteller deg hva vi prøvde og hva vi oppnådde, begynner andre lag å spørre hvordan og hva vi gjorde. De ser på implementeringer, kode, dokumentasjon, kommer med spørsmål og prøver å endre noe i seg selv.

Det er viktig å snakke om det du har gjort. På denne måten vil du overbevise konservative som ønsket å gjøre alt på den gamle måten for å bli med på leiren din og forvandle dem til innovatører.

Totalt

Velge en tjeneste, som et utgangspunkt - stedet hvor vi skal begynne endringer i selskapet. Vi identifiserer alle som har noe med tjenesten å gjøre og med dem bygge et verdistrømskart, vi måler og ser hvor og hva begrensningene er.

Opprette et nytt midlertidig team, som vil løse problemet. Basert på målinger og verdistrømskart vi tegner et nytt kart, der vi fremhever begrensningen som vi skal løse. Basert på denne begrensningen sette en oppgave, som teamet skal håndtere. Oppgaven skal være nødvendigvis SMART - spesifikk, målbar, relevant for aktuelle oppgaver og begrenset i tid.

Gjenta prosessen, til vi transformerer absolutt alle tjenestene våre til den nødvendige formen og eliminerer alle begrensninger.

Bonus. Nyttige materialer

For de som bestemte seg for å gjøre DevOps på egenhånd.

Prosjekt "Phoenix"

Den originale tittelen er "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win." Dette er en roman om DevOps – historien om hvordan en ansatt ble gjort til leder for en avdeling som alltid sto i brann. Den nye sjefen fikk oppgaven:

"Du har noen år på deg til å få alt riktig, slik at vi endelig kan levere produktet vårt til kundene våre raskt og effektivt."

"Prosjekt Phoenix" En roman om hvordan DevOps forandrer livet til det bedre» er en bok for alle ledere, fordi det er disse menneskene som tar beslutninger om hva som skjer i selskapet. Hvis du er ingeniør eller programmerer og ønsker at bevegelse og transformasjon skal begynne i bedriften din, kjøp en bok og gi den til ledelsen. Denne romanen forklarer alt og er rask og enkel å lese.

DevOps-veiledning

Boken er mer komplisert. Den ble utgitt for flere år siden på engelsk under tittelen «The DevOps Handbook How to create agility, reliability and security i verdensklasse i teknologiorganisasjoner», men nå er den allerede tilgjengelig på russisk. Dette er ekte håndbok - praktisk veiledning: hvordan utføre målinger, hva et verdistrømskart er og hvorfor det trengs, hvor du skal dra, i hvilken rekkefølge. Boken er kun for de som vil gjøre alt selv. Det viktigste er at den inneholder eksempler på erfaringer fra andre selskaper.

For eksempel forteller den hvordan et selskap bygde et verdistrømkart og innså at begrensningene ikke lå i produktet, men i det faktum at kassereren gikk fra butikken til neste kontor for å bruke dette produktet. I stedet for å løse problemet med programmet, kjøpte de rett og slett nettbrett til selgerne sine, og nå går ingen noe sted, og alle handlinger utføres på arbeidsplassen deres. Konklusjon: Value Stream Map kan utvides ikke bare til programvare, men også til alle prosesser i organisasjonen.

Akselerer

Full tittel: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations." Dette er neste nivå - hardcore. Boken ble utgitt i fjor, foreløpig kun på engelsk og den handler om forskning. Forfatterne—Nicole Forsgren, Jez Humble og Gene Kim—har brukt forskjellig praksis i forskjellige selskaper i mange år og undersøkt hvilke praksiser som påvirker hva og hvordan.

Det andre kapittelet, om måling, nevner verdistrømskartet, beregningene jeg nevnte og mange andre, og beskriver også måleprosessen i detalj. Forfatterne måler ved hjelp av spørreskjemaer og selvsporingsoppgaver. Den beskriver i detalj hvilke beregninger som er riktige å måle, hvilke som ikke bør måles, og menneskelige feil i målinger. Hvis du har problemer med målinger, se det andre kapittelet i boken "Accelerate". Hvis teamet ditt rett og slett har mange øvelser, men det ikke er klart hvilke øvelser du skal bruke nå, hvilke senere, hvilke som virkelig fungerer og hvilke som ikke gjør det – les, boken forklarer alt.

Transformasjon er et problem i skjæringspunktet mellom DevOps og ledelse. Et sted i det samme skjæringspunktet mellom utvikling, drift og testing er temaene vi prøver å diskutere på DevOpsConf, den samme integrasjonen er nødvendig for å lage et kvalitetsprodukt - hovedtemaet Kvalitetskonf. Festivalledelse RIT++ presentert Whale Rider - Det betyr at alle er der for ideer til transformasjon. Bli med oss ​​27. og 28. mai, vi skal integrere og transformere.

Kilde: www.habr.com