Hvis du ikke forstĂ„r, hvad DevOps er, sĂ„ her er en kort huskeseddel. DevOps er et sĂŠt praksisser, der minder ingeniĂžrernes frygt og reducerer antallet af nedbrud i softwareproduktionen. Som regel reducerer de ogsĂ„ tid til markedet â perioden fra idĂ© til levering af det endelige produkt til kunderne, hvilket gĂžr det muligt hurtigt at gennemfĂžre forretningseksperimenter..
Hvordan starter man DevOps transformation? Kort sagt: vĂŠlg den service, vi skal begynde processen med, identificer dem, der har en interesse i servicen, byg en Value Stream Map, skab et midlertidigt team, der skal arbejde med transformationen i starten, og giv dem en opgave. Gentag cyklussen det nĂždvendige antal gange.
En detaljeret plan for DevOps transformation med eksempler og instruktioner findes nedenfor â i transkriptionen Andrey Aleksandrov â ingeniĂžr hos Express42, som rĂ„dgiver om implementering af DevOps, hvilket fremskynder denne proces, da de allerede har kortlagt de udfordringer, der kan opstĂ„. Hvis du mener, at transformationen ikke er nĂždvendig, eller at din specifikation gĂžr, at DevOps-praksis ikke passer, â brug prĂŠsentationen som en guide til at finde og fjerne begrĂŠnsninger.
Hvis du er bekymret for DevOps transformation, sÄ har du en stor virksomhed, og det er nÞdvendigt gradvist at skalere denne proces til hele strukturen. SÄ lÊnge der er behov for at transformere teamet eller fjerne en begrÊnsning, kan algoritmen nedenfor gentages.
Valg af service
Planen er lagt, lad os begynde med det fĂžrste skridt â valg af service. Det fĂžrste kriterium â levetid: der findes gamle service â legacy, og nye. Man kan starte med begge.
At vĂŠlge en ny service er logisk.Den er ny, der er endnu ikke etablerede arbejdsprocesser i det team, der arbejder med den. Omkring den er der ikke en bjerg af teknisk gĂŠld, man behĂžver ikke hele tiden at reparere den. Vi kan gĂžre hvad vi vil med den.
I tilfĂŠlde af en gammel service er der problemer relateret til, at det altid er svĂŠrt at ĂŠndre.Der er allerede et sĂŠt alvorlige begrĂŠnsninger, men muligvis er der folk, der allerede er klar til at ĂŠndre alt â de er trĂŠtte og vil gĂžre noget anderledes, fordi det gĂžr ondt.
At arbejde med en gammel service skaber et stĂŠrkt eksempel i din virksomhed â man kan ĂŠndre noget. Hvis du ĂŠndrer en ny service, der gĂ„r i produktion 100 gange i timen, og alt er godt, kan folk i din virksomhed sige:
â Det er en ny tjeneste! Det var sĂ„ enkelt, forsĂžg at lave noget med vores gamle skrammel.
Legacy-tjenesten giver mening at transformere, nÄr du gÞr det med nogen, for eksempel hvis du har inviteret en ekstern konsulent. Lad os vÊre Êrlige, transformationen vil ryste alt, hvad der er muligt.. Du eksperimenterer og ved ikke, hvor du vil ende, hvilke teknologier og hvorfor du vil bruge, hvor og hvilke faldgruber der kan opstÄ i processerne. Derfor er det nemmere at Êndre det nye.
Hvis du gĂžr alt selv, og der ikke er seriĂžs ekspertise i virksomheden â sĂ„ vĂŠlg den nye tjeneste. Hvis du kender en ekstern konsulent og har midlerne â sĂ„ vĂŠlg den gamle.
Der er tjenester, der bare reprĂŠsenterer et interface for brugerne, for eksempel en simpel hjemmeside eller en mobilapplikation. Men der er ogsĂ„ alvorlige ting som fakturering. Hvis noget gĂ„r galt med faktureringen â bliver det svĂŠrt at finde ud af. Her har vi ogsĂ„ et valg.
Vi arbejder enten med en kritisk tjeneste, men vi lider allerede under den, den skaber begrĂŠnsninger, eller vi arbejder med interfacet. Dette er det andet valgkriterium. Ligeledes, hvis der er mulighed for at engagere en erfaren konsulent â arbejder vi med den tunge variant.
Men selv i dette tilfĂŠlde ville jeg ikke anbefale at gĂžre det, fordi mens der ikke er en forstĂ„else for, hvad man arbejder med og hvilken retning man skal transformere, er det ikke en god idĂ© at tage det kritiske og gennemgĂ„ det â derfor foretrĂŠkker vi i dette tilfĂŠlde at arbejde med interfacet, hvis det gĂ„r i stykker er det ikke kritisk.
Lad os kigge nÊrmere pÄ tjenesteteamet. Med dem, der beskÊftiger sig med denne tjeneste, bliver vi nÞdt til at arbejde og interagere konstant i meget tÊt kontakt.
Folk i teamet kan overordnet opdeles i to kategorier: konservative â lever i den gamle verden, eller ved simpelthen ikke noget om DevOps, og innovatorer, der trĂŠkker alle de moderne praksisser ind. De sidstnĂŠvnte forstĂ„r ikke altid emnet, men de er i det mindste Ă„bne for det.
PĂ„ den ene side er de konservative â erfarne personer: de har vĂŠret i virksomheden lĂŠnge, forstĂ„r fra A til Z, men ved ikke noget om praksisser. PĂ„ den anden side â innovatorer, der har hĂžrt noget, men sandsynligvis ikke har vĂŠret i virksomheden sĂŠrlig lĂŠnge. Hvem er bedst at arbejde sammen med?
Vi mÄ interagere med konservatorerne, da det er deres service. Vi skal kommunikere med dem for at finde ud af detaljerne om servicen, hvad vi kan gÞre pÄ én mÄde, og hvad der skal gÞres pÄ en anden mÄde. Vi er afhÊngige af deres rÄdgivning. Det vil helt sikkert vÊre nÞdvendigt at give dem opgaver, da de kender deres service bedst. Derfor er det vigtigt, hvilken gruppe vi ender med at have kontakt til.
Det er logisk at vÊlge innovatorer til teamet, fordi konservatorerne kan finde pÄ at sabotere.
I praksis viser det sig ofte, at konservative personer har betydelig erfaring, men ikke forstÄr, hvordan man skal komme videre. De er simpelthen bange for, at de bliver fyret efter transformationen og omstruktureringen af servicen, og nogle gange saboterer de arbejdet blot fordi de ikke forstÄr, hvad der sker.
Jeg havde en situation, hvor en fyr fra teamet reparerede alt muligt, fordi det angiveligt var mere kritisk end det, vi lavede lige nu. Vi sĂŠtter en opgave: at implementere denne del i dag â nej, der er brand pĂ„ den anden side af jorden, sĂ„ lad os tage derhen og fikse det. Det er svĂŠrt at arbejde med sĂ„danne mennesker.
Folk fra konservatorernes team glemmer ofte opgaver eller udsĂŠtter dem til det sidste. Og hvis, Gud forbyde, du har lavet en fejl og givet dem KPI for antallet af udfĂžrte opgaver, men nogle opgaver ikke er inkluderet i KPIâen, sĂ„ vil de overhovedet ikke gĂžre noget. Faktisk vil de have ret, fordi de sĂ„ mister deres bonus.
Det er lettere at arbejde med innovatorer â de er mere loyale.De har allerede hĂžrt noget, vil gerne bevĂŠge sig fremad, sĂ„ de vil hjĂŠlpe. Vi har brug for folk, der er villige til at tĂ„le lidt i starten: hvis servicen ĂŠndres, vil innovatorerne som pionerer tage alle stĂždene og faldgruberne. Innovatorerne sĂžger alt det nyeste og moderne, og de er villige til at lide lidt.
Senere kan konservatorerne overbevises om vores tro. NÄr du viser, at du har Êndret en del og at alt fungerer, vil de sandsynligvis ogsÄ vÊre interesserede og tage imod den nye DevOps-religion.
Lad os opsummere. Hvis vi selv laver hele transformationen i vores virksomhed, vĂŠlger vi: en ny service, helst med et simpelt interface for ikke at lide for meget under dens nedbrud, og et team af innovatorer.
Hvis det er muligt at hyre en ekstern konsulent, sÄ vÊlger vi at bruge den gamle service, vi allerede lider under, i stedet for at fÄ en ny. De personer, der har arbejdet med transformation i forskellige virksomheder over lÊngere tid, har set forskellige tilfÊlde og ved allerede, hvordan man gÞr det rigtigt, og hvilken retning man skal gÄ.
Hvem er involveret?
Vi skal finde alle, der har nogen form for tilknytning til servicen: udviklere, testere, administratorer, sikkerhedsspecialister, ledere og muligvis Product Owners. Selvom Product Owners ikke er teknikere, har de alligevel en forbindelse til servicen: de trĂŠffer beslutninger og sĂŠtter opgaver.
Alle, der trÊffer nogen beslutninger og pÄvirker, hvad der sker med servicen, skal findes, introduceres og taler med.
Hvad skal de bruge os til? For at vide, hvem vi skal forhandle med.. Under transformationen, nÄr den sÊdvanlige arbejdsmetode for servicen Êndres, vil der vÊre rystelser. Der vil vÊre nogle fejl i et stykke tid, mens vi tester nye tilgange. Menneskerne skal vÊre klar til og enige om dette.
Herefter skal vi bygge en Value Stream Map, og uden disse mennesker kan vi ikke gĂžre det, for kun de kender den fulde sammenhĂŠng. Ăn person kender aldrig alt, hvad der sker med servicen.
De vil anbefale folk til teamet. Senere vil vi diskutere, hvorfor vi har brug for et separat team. Vi mÄ tage folk fra eksisterende afdelinger. De, der har tilknytning til servicen, kan anbefale kolleger, der tÊnker i vores retning, som kan hjÊlpe os og har den nÞdvendige kompetence.
Derefter samler vi alle disse mennesker fra forskellige afdelinger i Ă©t rum og begynder at bygge Value Stream Map.
Vi bygger Value Stream Map.
Value Stream Map er et diagram eller kort, der viser vÊrdistrÞmmen til kunden.. Det er hele processen fra idéen til implementering, inklusive alle mellemtrin og hvordan vÊrdien i sidste ende nÄr vores kunder.
Value Stream Map er nÞdvendig for at visualisere alle udviklingsfaser, lokalisere problemer gennem mÄlinger i den nuvÊrende proces og begynde at lÞse disse problemer, og fastsÊtte det oprindelige mÄl. Det er her, vi begynder at gÞre noget reelt.
MĂ„linger
I litteraturen om Value Stream Map er der beskrevet mange forskellige mÄlinger, men for nu er tre nok.
Lead Time â forsinkelse/ventetid â tiden, hvor vi venter pĂ„ noget. For eksempel venter en tester pĂ„, at testmiljĂžet bliver ledigt, og i mellemtiden kan vedkommende ikke lave andet.
Value Added Time â tiden for vĂŠrdifuldt arbejde â den tid, vi bruger i et bestemt trin for at skabe vĂŠrdi for brugeren. For eksempel har testeren startet sin test og begyndt at kontrollere noget. Dette er tiden for vĂŠrdifuldt arbejde, hvor vi faktisk laver noget for produktet. Det er det, kunderne betaler for â for kvalitetssoftware.
%C/A â procentdelen af accepteret arbejde. Vi har Ă©t trin â udvikling, det andet trin â test. Hvor mange funktioner testerne har accepteret fra udviklerne, og da er der denne procent.
SĂ„dan ser vores kort ud.
Det kan se anderledes ud afhÊngig af organisationens struktur, antallet af afdelinger og hvad I laver. Men generelt vil kortet have to trin: idé og analyse. I dette trin forventes data, for eksempel Lead Time 2 uger og Value Added Time 2 dage.
Metrikker dĂŠkker alle trin.
Backlog â hvor mange opgaver der lĂ„ efter, at analytikerne havde fundet pĂ„ dem.
Udvikling â hvor mange uger udviklerne ventede pĂ„ afklaringer angĂ„ende opgaver, testmiljĂžer eller udstyr â ligegyldigt, men de venter pĂ„ noget. For eksempel implementerer de en funktion i 4 dage. Her kommer metrikken %C/A ind. Udviklerne tog kun 80% af opgaverne fra Backlog. De mener, at 20% af dem ikke har en tilstrĂŠkkelig klar kravspecifikation, og sendte dem tilbage til revidering.
Testning. I diagrammet er LT angivet til 4 dage. For eksempel ventede testerne pĂ„ frigivelsen af testmiljĂžet, VA 2 dage hvor de faktisk tester noget, og %C/A = 40 %. â kun 40 % af koden eller funktionerne, som udviklerne sendte, blev vurderet som acceptable af testerne. Alt andet kunne de ikke lide af en eller anden grund.
Jeg vil ikke gÄ i detaljer med, hvordan man foretager disse mÄlinger, men jeg vil anbefale litteratur, hvor man kan lÊre om dem i slutningen af artiklen.
Det eneste, jeg vil rĂ„de til â tro ikke pĂ„ folk, der vil lave en Value Stream Map med dig. De pĂ„stĂ„r at vide, hvor lang tid forskellige processer tager, men disse vurderinger er ikke altid korrekte, sĂ„ det er bedst at mĂ„le selv.
Vi havde en situation, hvor vi gik til Operations-afdelingen og spurgte, hvor lang tid det tager at levere en ny funktion til produktion. Vi fik at vide, at det tager 10 minutter, og vi tĂŠnkte, hvorfor vi overhovedet kom til denne virksomhed? Det viste sig, at 10 minutter er den tid, det tager for et script at tage koden og levere den til serveren. Men inden dette ligger udgivelsen tre dage pĂ„ serveren og samler stĂžv â der ligger en opgave i Backlogen, der skal implementeres. Det viser sig, at der er en ventefase fĂžr implementeringen, hvor projektet blot ligger stille. Hvis ikke vi var gĂ„et med en notesblok, havde vi ikke fĂ„et Ăžje pĂ„ opgaven i Jira og begyndt at fĂžlge den trin for trin, sĂ„ ville vi have troet, alt var fint og at der ikke var noget problem.
Derfor bliver du nÞdt til selv at foretage mÄlingerne, helst ikke kun én gang, for at skabe et sÄ realistisk billede som muligt. AfhÊngig af Value Stream Map vil du tage en beslutning om, hvorfra du skal starte og hvad der skal rettes fÞrst.
Midlertidigt team
Mange virksomheder, der har besluttet at implementere DevOps, opretter et team, men ikke et midlertidigt, et der har eksisteret i flere Är. Hvis du besÞger en DevOps-tjeneste, der beskriver forskellige mÞnstre for at opbygge organisatorisk struktur i DevOps, vil du forstÄ, at dette er et antipattern.
NĂ„r DevOps-teamet eksisterer konstant i flere Ă„r â er det en stor fejl, fordi DevOps handler om kommunikation mellem afdelinger, om hastighed og effektivitet.
Hvis teamet eksisterer mellem afdelingerne, kun for at lave noget separat, og har eksisteret lÊnge, skaber det en unÞdvendig barriere. Nu skal programmÞren, i stedet for straks at henvende sig til administrationen for at lÞse et spÞrgsmÄl, fÞrst gÄ til DevOps-afdelingen, som sÄ mÄ tage det videre.
Derfor, for at komme i gang, skal der oprettes et midlertidigt team.Den vil eksistere i cirka et halvt Är, maks et Är, afhÊngigt af opgaven, for kun at fÄ lÞst en begrÊnsning, vi har valgt. Derefter vil den dÞ. Hvis vi vÊlger det nÊste punkt, hvor vi har meget ondt, og indser, at vi ogsÄ har brug for et separat team til det, vil vi sÄ oprette det igen. Men sÄdanne teams bÞr ikke eksistere permanent - ellers forstyrrer de kommunikationen og pÄtager sig opgaver, der kun skal lÞses. Disse opgaver kan slet ikke vÊre relateret til DevOps og transformation. Hvorfor ikke overdrage denne opgave til eksisterende afdelinger?
Hvorfor er et midlertidigt team nĂždvendigt
Konflikt med nuvÊrende processerDevOps-transformation er ikke kun en Êndring af teknologierne og vÊrktÞjerne, vi bruger, men ogsÄ en Êndring af selve arbejdsprocessen, tankemÄden og vÊrdierne. Hvis teamet arbejder pÄ den mÄde, de allerede er vant til, vil de ikke kunne afprÞve andre tilgange.
Disse mennesker skal leve efter andre regler: ignorere alle KPI'er i virksomheden, fordi de prÞver at arbejde anderledes. Midlertidige teams vil ikke udfylde ansÞgninger om at fÄ en server, men vil i stedet henvende sig direkte til den afdeling, der administrerer dem, med krav om at fÄ det, de har brug for fÞrst, fordi det er en prioriteret opgave, og fordi de forsÞger at leve anderledes. Teamet er i fuld konflikt med alle nuvÊrende processer. For at eksisterende arbejdsmetoder ikke skal forstyrre dem nu, og de ikke skal forstyrre andre, isolerer vi disse mennesker ved at oprette et separat team.
UndgÄ bureaukrati i eksperimenterI midlertidige teams er der ikke bureaukrati, de udfylder ikke timerapporter, og de skal ikke rapportere til ledere. Det er en helt separat verden, hvor mennesker lever og tÊnker anderledes og laver helt andre ting. Der er ikke behov for at forstyrre dem unÞdigt.
Uafbrudt arbejde pÄ servicenI det fÞrste punkt valgte vi noget, vi vil eksperimentere med. Eksperimenter og sÞgninger efter bedre arbejdsmetoder er gode, men funktioner Þnsker vi ogsÄ at lave. Hvis hele teamet i stedet for funktioner beskÊftiger sig med transformation, vil vi begynde at miste indtÊgter, fejl vil hÊnge lÊnge - det er ikke noget, vi vil have. Oprettelsen af et midlertidigt team giver mulighed for at eksperimentere uden at stoppe arbejdet med produktet.
Ikke spilde tid pĂ„ arbejdsopgaver. Dette handler igen om produktet. Det tager lang tid for teamet at prĂžve andre vĂŠrktĂžjer og sĂ„ videre. For at folk kan lĂŠre vĂŠrktĂžjerne at kende, begynde at implementere dem og bruge dem ordentligt, vil det tage mindst et halvt Ă„r. Hvis de ogsĂ„ arbejder med produktet, vil de seks mĂ„neder strĂŠkke sig ud i det uendelige. Hvis folk arbejder med produktet, arbejder de igen med gamle processer â det har vi ikke brug for.
Derfor udvÊlger vi folk fra forskellige afdelinger til et separat team, som skal arbejde med transformationen af servicen. Som resultat fungerer servicen, fortsÊtter med at udvikle sig, og vi laver nogle eksperimenter pÄ den.
Det midlertidige team arbejder kun med DevOps-transformation â fjernelse af den begrĂŠnsning, vi har fundet, og ikke andet.
Teamet bestĂ„r af alsidige personer. Det betyder, at vi ikke kun har taget udviklere. Vi kom ikke ind i servicen og tog halvdelen af teamet â nej, vi tog folk fra forskellige afdelinger. Flere punkter tilbage fandt vi forskellige afdelinger og ansatte, som har relation til den transformerede service. Herfra samler vi et team, fordi det skal vĂŠre alsidigt â vi vil ĂŠndre bĂ„de testprocessen, udviklingsprocessen og servicevedligeholdelsen. Forskellige kompetencer er nĂždvendige.
Normalt tager vi betinget en udvikler, en tester og en ingeniĂžr â hver isĂŠr Ă©n, og sammen med dem finder vi en lĂžsning, der gĂžr det muligt at leve anderledes.
Det er Ăžnskeligt, at disse personer har autoritet i organisationen. Det kan vĂŠre nĂždvendigt at tage en konservator, selv om det ikke er Ăžnskeligt. Hvis vi har en stor virksomhed, er der langt fra alle, der vil tro pĂ„ vores idĂ©, og nogle kan finde pĂ„ at sĂŠtte kĂŠppe i hjulet, for eksempel ved ikke at stille en stand til rĂ„dighed. Her vil "autoriteten" vĂŠre nĂždvendig â en respekteret person med stor erfaring, der har opnĂ„et et godt forhold til kolleger. En medarbejders autoritet i teamet vil gĂžre opgaven og det midlertidige teams arbejde lettere. Folk vil tĂŠnke:
â Aha, denne seje fyr, som vi alle kender og elsker, er trĂ„dt ind â Ă„benbart er der noget ved DevOps, som er vĂŠrd at se nĂŠrmere pĂ„!
SÊtter et mÄl
Vi har samlet folk, valgt servicen, set begrĂŠnsningerne, bestemt, hvilke personer vi vil pĂ„virke. Nu er det nĂždvendigt at sĂŠtte et mĂ„l, og det skal vĂŠre direkte ifĂžlge SMART â alt som vi elsker.
Specifik â specifik.
MĂ„lbar â mĂ„lbar. Dette er et meget vigtigt punkt i SMART. Hvis du ikke kan mĂ„le noget, kan du ikke ĂŠndre det og forstĂ„, hvad og hvordan du har gjort det bedre eller dĂ„rligere.
OpnĂ„elig â opnĂ„elig. Tag hĂžjde for din specifik. Hvis du er en enterprise-virksomhed med en lang historie og et stort ansvar, der udgiver en produktversion om Ă„ret, vil du ikke vĂŠre i stand til at nĂ„ at udgive nye produktversioner hver time pĂ„ seks mĂ„neder. Det kommer ikke til at ske. Derfor skal du sĂŠtte et realistisk mĂ„l, der kan opnĂ„s inden for en rimelig tidsramme.
Relevant â relevant. Vi fjerner kun den begrĂŠnsning, som virkelig forfĂžlger vores nuvĂŠrende mĂ„l.
TidsbegrĂŠnset â tidsbegrĂŠnset. Hvis der ikke er nogen deadline, vil teamet beskĂŠftige sig med alt muligt: prĂžve 15 teknologier i stedet for 3, skrive omfattende rapporter, udfĂžre meningslĂžse undersĂžgelser, polere deres implementering til perfektion, nĂ„r mĂ„let allerede er nĂ„et.
MĂ„lene fastlĂŠgges netop ved hjĂŠlp af Value Stream Map â vi samler alle mennesker igen og tegner. Men denne gang baserer vi det pĂ„ den tidligere Value Stream Map, vi tegner, hvad vi Ăžnsker at opnĂ„.
Vi identificerer Ă©n begrĂŠnsning, som vi vil fjerne lige nu â det er det, teamet vil arbejde med. For eksempel har jeg taget ventetiden fra den fĂŠrdige udgivelse til dens deployment i produktionen â det er den mest almindelige begrĂŠnsning, folk henvender sig til konsulenter med.
Baseret pÄ dette sÊtter vi opgaven: vi Þnsker, at ventetiden mellem den fÊrdige version og lanceringen hÞjst skal vÊre en time.
Eksempler pÄ opgaver.
- Reducer testens Lead Time fra 4 dage til 1 time.
- Reducer Value Added Time for test fra 2 dage til 3 timer.
- Reducer deploymentens Lead Time fra 5 timer til 10 minutter.
- Ăg C/A fra 50% til 95%, hvilket betyder at Ăžge antallet af funktioner, som testere accepterer, med andre ord forbedre kvaliteten af udviklernes arbejde.
Eksemplerne pĂ„ opgaver er ikke opfundet â de er baseret pĂ„ mĂ„linger, vi foretog, da vi udviklede Value Stream Map.
SÊt en lignende opgave til vores team og en tidsbegrÊnsning. AfhÊngigt af hvor godt det gÄr i din virksomhed, sÊtter du forskellige tidsrammer. I gennemsnit tager det seks mÄneder at fjerne en begrÊnsning, hvis folk arbejder med dette for fÞrste gang og stadig ikke ved, hvilke teknologier og hvordan de konkret vil lÞse problemet.
Kort planlĂŠgning
SÄ, vores team er dannet; vi har et mÄl, og folk begynder at arbejde. Et vigtigt punkt er den korte planlÊgning af arbejdet: sprints pÄ en til to ugerog ikke mere, mÄlbare forbedringer hver uge og kursjustering.
For eksempel bruger vi ofte tilgangen moving-moving, hvor hele teamet samles i starten af hver uge, skitserer i en fil, hvad hver person skal lave. Efter en uge vurderer vi: hvad er gjort, og hvad er ikke gjort, hvis ikke, sÄ hvorfor, og tÊnker over, hvad vi skal gÞre nÊste gang.
Sprints muliggĂžr rettidige kursjusteringer.
Vi prĂžver noget i en uge eller to: teknologier, tilgange, arbejdsmetoder; derefter mĂ„ler vi igen og ser â er det blevet bedre eller vĂŠrre med denne tilgang? Hvis det er blevet vĂŠrre, sĂ„ gĂ„r vi ikke i den rigtige retning, og vi skal justere kursen: sĂŠtte et nyt mĂ„l, tage en anden teknologi eller gĂžre noget andet. Korte sprints pĂ„ 1-2 uger tillader os at navigere og hurtigt trĂŠkke os vĂŠk fra dĂ„rlige beslutninger.
Vi deler succes
Teamet opnĂ„r nogle resultater, uanset om de er smĂ„ eller store â det er ikke vigtigt, der er altid et eller andet resultat. Alle bĂžr vide om dette resultat: bĂ„de dem, der er involveret i DevOps, og naboskaber. I en ideel verden bĂžr det helst nĂ„ til alle i virksomheden.
Hvorfor? Hvis vi Þnsker at transformere ikke en del af virksomheden, eliminere ikke én begrÊnsning, men alt, sÄ virksomheden kan blive mere fleksibel, koden flyver hurtigt til kunden, og intet gÄr i stykker, er det nÞdvendigt, at alle er loyale over for idéen om DevOps. Du vil ikke kunne anvende tilgangen pÄ tjenester og teams, som er kategorisk imod.
For at skabe loyalitet skal vi fortĂŠlle alle, hvad vi har prĂžvet â vi har et resultat, prĂžv ogsĂ„! Dette vil Ăžge interessen og loyaliteten for det, vi laver, og folk vil begynde at prĂžve at gĂžre noget lige nu. Som praksis viser, nĂ„r vi fortĂŠller, hvad vi har prĂžvet og opnĂ„et, begynder andre teams at spĂžrge, hvordan og hvad vi har gjort. De ser implementeringer, kode, dokumentation, kommer med spĂžrgsmĂ„l og forsĂžger at ĂŠndre noget hos dem selv.
Det er vigtigt at fortÊlle om de resultater, I har opnÄet. SÄ vil I overbevise de mere konservative, der Þnskede at gÞre alt som fÞr, om at transformere dem til innovatÞrer.
I alt
Vi vĂŠlger tjenesten, som udgangspunkt â det sted, hvor vi starter ĂŠndringerne i virksomheden. Vi identificerer alle, der har nogen relation til tjenesten og sammen med dem bygger vi et Value Stream Map, mĂ„ler og ser, hvor der er begrĂŠnsninger og hvilke.
Vi opretter et nyt midlertidigt team, som skal lĂžse den stillede opgave. Baseret pĂ„ mĂ„lingerne og Value Stream Map tegner vi et nyt kort, hvor vi fremhĂŠver den begrĂŠnsning, vi skal lĂžse. Baseret pĂ„ denne begrĂŠnsning sĂŠtter vi en opgave, som teamet skal arbejde pĂ„. Opgaven skal vĂŠre SMART â specifik, mĂ„lbar, relevant for de aktuelle opgaver og tidsbegrĂŠnset.
Vi gentager processen, indtil vi har transformeret alle vores tjenester til den Ăžnskede form og elimineret alle begrĂŠnsninger.
Bonus. Nyttefulde materialer
For dem, der har besluttet at arbejde med DevOps pÄ egen hÄnd.
Projekt «FÞniks»
Den oprindelige titel er «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». Det er en roman om DevOps â historien om, hvordan en medarbejder blev leder af en afdeling, der konstant var i brand. Den nye leder fik opgaven:
â Du har nogle Ă„r til at rette op pĂ„ alting, sĂ„ vi endelig kan levere vores produkt hurtigt og effektivt til vores kunder.
«Projekt âFĂžniksâ. En roman om, hvordan DevOps forandrer livet til det bedre» â en bog for alle ledere, fordi det netop er disse personer, der trĂŠffer beslutninger om, hvad der sker i virksomheden. Hvis du er ingeniĂžr eller programmĂžr og Ăžnsker, at din virksomhed skal begynde at bevĂŠge sig og transformere â kĂžb bogen og giv den til ledelsen. Denne roman forklarer alt, og den lĂŠses hurtigt og let.
Guide til DevOps
En mere kompleks bog. Udgivet for nogle Ă„r siden pĂ„ engelsk med titlen «The DevOps Handbook How to create worldâclass agility, reliability, and security in Technology organizations», men nu er den ogsĂ„ tilgĂŠngelig pĂ„ russisk. Dette er en rigtig handbook â en praktisk guide: hvordan man foretager mĂ„linger, hvad et Value Stream Map er, og hvorfor det er nĂždvendigt, hvilken retning man bĂžr tage, og i hvilken rĂŠkkefĂžlge. Bogen er netop til dem, der Ăžnsker at gĂžre alt selv. Det vigtigste er, at den indeholder eksempler pĂ„ erfaringer fra andre virksomheder.
For example, it describes how one company created a Value Stream Map and realized that its constraint was not the product itself, but the fact that the cashier had to walk from the store to a neighboring office to use that product. Instead of solving the problem with the software, they simply bought tablets for their sellers, and now no one has to go anywhere; all actions are performed at the workplace. Conclusion: Value Stream Mapping can be applied not only to software but to all processes in the organization.
Accelerate
Full title: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations." This is the next level â hardcore. The book was released last year, currently only in English, and it focuses on research. The authors â Nicole Forsgren, Jez Humble, and Gene Kim â have applied various practices in different companies over many years and studied which practices affect outcomes and in what ways.
In the second chapter, dedicated to measurements, Value Stream Map, the metrics I mentioned, and many others are discussed, along with a detailed description of the measurement process. The authors conduct measurements using surveys and self-tracking of tasks. They explain in detail which metrics should be measured correctly, which should not, and human errors in measurements. If you're struggling with measurements, refer to the second chapter of the book "Accelerate." If your team has many practices, but it's unclear which practices to apply now, which later, which actually work, and which do not â read this book; it covers everything.
Transformation is a question at the intersection of DevOps and management. Somewhere in that same intersection of development, operations, and testing are the topics we try to discuss at , the same integration is needed for creating a quality product â the main topic of . Management at the festival prĂŠsenteret â means all ideas for transformation will be there. Join us on May 27 and 28; we will integrate and transform.
Kilde: habr.com
