DevOps bruges af mere end blot software projektgrupper. Men det store spørgsmål er, hvilket metode vinder? DevOps eller Agile?
I det ene hjørne har vi Agile. I det andet hjørne har vi DevOps.
De enkelte elementer af Agile og DevOps kan få dem til at lyde som meget forskellige ideer. For yderligere at forvirre, så virker det som om de trodser deres definition, selv med deres egen jargon og slogans. Som den ældste metode, så kan agile være mindre vag, men det er meget normalt, at folk bliver frustrerede over de utallige definitioner der er i DevOps.
Note: Mange tror, at agile betyder scrum og DevOps betyder kontinuerlig levering. Denne oversimplifikation skaber unødvendig forviring mellem agile og DevOps, så du vil måske blive overrasket over at få at vide, at de passer perfekt sammen!
Man kan ikke benægte den historiske forbindelse der er mellem DevOps og Agile. Da Patrick DuBois og Andrew Clay Schafer forsøgte at mødes til den Agile 2008 konference omkring “agile infrastructure”, blev forbindelsen til DevOps født. Selvom Patrick senere hen opfandt begrebet “DevOps”, så fortsætter den Agile Conference med at ære denne forbindelse med et DevOps spor. Men lad os kigge dybere end historien og overveje den praktiske forbindelse mellem agile og DevOps, når vi kigger under overfladen af scrum og kontinuerlig levering.
Der er mere til agile end scrum
I nogle projektgrupper er scrum forskellen mellem en konstant, frustrerende kamp og produktivt, belønnende samarbejde. I andre projektgrupper erstatter scrum politik og overarbejde med objektivitet og fokus. Når begrænsningerne af virksomheden eller selve arbejdet kræver noget anderledes, så vil en agile projektgruppe udnytte de underliggende principper af scrum, de inspicerer deres metoder, og tilpasser sig for at blive mere effektive. Dette er specielt vigtigt, når scrum udnyttes uden for konteksten af softwareudvikling.
Planlægning af uplanlagt arbejde
I DevOps samfundet anerkender dem med Scrum erfaring, at det er brugbart til at tracke planlagt arbejde. Nogle former for arbejde i operationer kan planlægges; release af en stor system ændring, ting der skal flyttes mellem datacentre, eller når der skal laves systemopgraderinger. Men meget af arbejdet af operationer er ikke planlagt: performance begrænsninger, systemafbrydelser og kompromitteret sikkerhed. Disse begivenheder kræver et svar med det samme. Der er ikke tid til at vente på at items kan blive prioriteret i en backlog eller til den næste sprint planlægning session. Af denne grund er flere projektgrupper begyndt at omfavne DevOps tankegangen ved at kigge ud over scrum til kanban. Dette hjælper dem med at tracke begge typer af arbejde, og hjælper dem med at forstå samspillet mellem dem. Eller, de tilpasser sig til en hybrid tilgang, ofte kaldet Scrumban eller Kanplan (kanban med en backlog).
På mange måder er årsagen til Scrums brede tilpasning, at den ikke beskriver nogle former for tekniske praksis. Scrums lette ledelses praksis gør ofte en stor forskel for en projektgruppe. Hvor der engang var konkurrerende prioriteter fra flere forskellige kilder, er der nu et enkelt sæt af prioriteter i en backlog. Og hvor der engang var for meget work-in-progress, er der nu en plan som er begrænset af hvad tiden har vist virkeligt er muligt. I kombination kan disse tage en projektgruppe til nye niveauer af produktivitet. Men, en projektgruppe kan måske være begrænset af manglen på tekniske metoder, som f.eks. kode reviews, automatiseret acceptering tests og kontinuerlig integration.
Andre agile processer, som Extreme Programming, har stærke holdninger omkring hvordan tekniske praksis støtter projektgruppens evne til at vedligeholde et bæredygtigt tempo og give gennemsigtighed og tydelighed til ledelse og interessenter. Nogle scrum projektgrupper bliver nødt til at placere tekniske opgaver i deres backlog. Mens det passer godt ind i scrum, så rammer det hurtigt et praktisk problem af en product owners bias mod features. Med mindre en product owner er meget teknisk, så har han eller hun muligvis ikke evnerne til at evaluere cost/benefit af tekniske praksis. Det bliver endnu sværere for en product owner, da tekniske opgaver kan være alt fra operationer til support, driftsikkerhed, performance og sikkerhed.
Product owners og service owners
Jeg har opdaget, at det hjælper, at have to forskellige roller for projekter der drives. En product owner er god til at forstå de features, som brugere har behov for, men de er ikke så gode til at opveje disse features mod ikke-funktionelle ting som performance, driftsikkerhed og sikkerhed. Derfor har nogle SaaS produkter også en service owner, som er ansvarlig for at prioritere disse ikke-funktionelle egenskaber. Fra tid til anden vil de to owners måske foretage noget “horse trading”, men for det meste, så kan de blive arbejdet på at uafhængige projektgrupper.
Det er måske ikke den eneste måde at forbedre feedback fra operationer, men det hjælper med at overkomme en alt for hyppig bias i product owners omkring features. Denne “two-owner” tilgang er ikke den eneste vej til DevOps. Det der er vigtigt at forstå er disse ikke-funktionelle karakteristikker, som “features” og at være i stand til at planlægge og prioritere dem præcis ligesom hvilken som helst anden funktionel user-story.
Ultimativt stammer ingen af disse kritikpunkter udelukkende fra Scrum selv. Som med alle agile metoder har scrum en indbygget “process forbedrende” mekanisme, kaldet retrospective. Dermed er det fornuftigt at tro på, at nogle scrum projektgrupper vil bruge DevOps som en kilde for inspiration og bruge Scrum retrospectives som en mulighed for at tilpasse sig mod DevOps. Men, for at realisere dette skal de fleste projektgrupper bruge hjælp fra eksterne ideer. Indtil DevOps er mainstream, bliver DevOps ikke et organisk resultat af Scrum. Uanset om projektgrupper bruger en agile eller DevOps træner er ikke vigtigt, så længe at personen kan medbringe erfaring til automatisering på tværs af udvikling, testing og levering af software.
Der er mere til DevOps end kontinuerlig levering
Når udført godt, så hjælper disciplinen af kontinuerlig levering med at begrænse work in progress, mens automationen af implementering hjælper med at elevere begrænsninger. På denne måde hjælper kontinuerlig levering software projektgrupper med at levere hyppigere og med højere kvalitet, i stedet for at skulle vælge mellem de to. Men i takt med at projektgrupper kun fokuserer på scrum kan de miste den bredere kontekst af agile og på samme måde kan projektgrupper der fokuserer på kontinuerlig levering misse den bredere kontekst af DevOps.
Ideen bag kontinuerlig levering adresserer ikke direkte problemerne i kommunikation mellem virksomheden og en software projektgruppe. Hvis virksomheden har en år-lang budget-drevet planlægningscyklus, så kan en projektgruppe der leverer alt ind til produktion måske stadig skulle vente måneder for virksomheden kan reagere. Alt for ofte kommer disse reaktioner som step-funktioner, som annullering af projektet, eller værre fordobling af projektgruppen (fordi et stort indskud af nye folk er disruptivt).
Den Agile Fluency Model indikerer at det første niveau af fluency som “Fokus på værdi”, hvor projektgrupper fokuserer på gennemsigtighed og justering. Uden denne fluency kan kontinuerlig levering nemt udvikle sig til at være en uendelig cyklus af tekniske forbedringer der ikke giver nogen vigtig værdi til virksomheden. En projektgruppe får måske en god levering hurtigt med høj kvalitet, men til et produkt der har lav værdi for slutbrugerne eller virksomheden. Selv når der er mange brugere, som siger gode ting, så vil vurderingen af lav værdi måske kun være muligt på et større forretnings portfolio niveau. Uden denne vigtige fluency er det svært at opveje tekniske praksis op i mod features. Dette er specielt vigtigt for en projektgruppe med en gammel kodebase, som måske ikke har automatiseret tests eller et design der er egnet til hyppig implementering. I et eftermæle kontekst vil en kontinuerlig levering transformation muligvis tage flere år. Så det er meget mere vigtigt, at kunne demonstrere denne forretningsfordel.
The three ways
DevOps er mere end bare at automatisere en implementeringspipeline. Som beskrevet af John Allspaw, så er DevOps: “Ops who think like devs. Devs who think like ops.” For at uddybe dette, så beskriver Gene Kim the three ways som principper af DevOps:
The first way: System Thinking
Fokuserer på performance af hele systemet, i modsætning til performance af en specifik del af arbejdet eller afdeling – dette kan være så stort som en division eller så småt som en enkelt person.
The second way: Amplify Feedback Loops
Skaber hele vingen af feedback loops. Målet med næsten hvilken som helst forberedelses initiativ er at forkorte og forbedre loops så nødvendige rettelser kontinuerligt skal laves.
The third way: Culture of Continual Experimentation and Learning
Det at lave en kultur opfordrer to ting: kontinuerlig eksperimentation, risikotagen og læring fra fejl; og at forstå at gentagelser og øvelser er opskriften til perfektion.
Kontinuerlig levering fokuserer på The First Way: Automatisering af flowet fra dev til ops. Automatisering spiller en åbenlys rolle med at hjælpe i at accelerere et implementeringssystem. Men der er mere til systemtænkning end bare automatisering.
The Second Way er karakteriseret ved øvelse, “Devs wears pagers too.” Selvom den bogstavelige brug af pagers måske ikke er nødvendig, så betyder det at trække udviklere ind i operationelle problemstillinger. Dette hjælper udviklere med at forstå konsekvensen af deres udviklingsvalg. F.eks. kan det inspirere udviklere til at placere log beskeder i bedre steder og at gøre disse beskeder mere betydningsfulde. Det handler ikke kun om opmærksomhed. Udviklere bringer også deres interne forståelse af systemet til indsatser for at finde problemer, så en løsning kan findes og implementeres hurtigere.
The Third Way handler om at lave inkrementelle eksperimenter i systemet som en helhed, ikke bare ændringer til applikationen der går gennem en pipeline. Med andre ord, så er det relativt nemt at se hvor lang tid automatisering tager og at bruge stærkere infrastruktur til at fortsætte med at forbedre det. Det er svære, at forstå hvordan disse hand-offs mellem roller eller organisationer introducerer forsinkelser. Det betyder, at projektgrupper inspicerer og tilpasser på tværs af hele leverings workflowet, og leder efter muligheder for at styrke samarbejde. Til det kræver kontinuerlig levering en vane af tilpasning og forbedring. Hvis projektgruppen ikke reflekterer på hvordan de kan blive mere effektive, og derefter tilpasser sin adfærd på alt muligt andet, så vil kontinuerlig levering ikke vokse og virke. Projektgruppen skal føle, at de har magten til at løse deres egne problemer.
I scrum er hver retrospective en mulighed for at forbedre praksis og redskaber. Men hvis projektgruppen ikke tager fordel af disse muligheder for at løse både short-term og long-term tekniske problemer, så vil de bare vente til at deres product owner placerer disse kontinuerlig leverings opgaver i deres backlog, hvilket aldrig vil ske.
DevOps er agile som bruges af mere end bare software projektgruppen
Scrum laver primært en plan for det agile princip, “Byder ændringskrav velkommen, selv sent i udviklingen. Agile processer udnytter ændringer for kundes konkurrencefordele.”
Kontinuerlig levering laver en plan for det agile princip, “Vores højest prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifuld software.”
Det betyder, at agile mere handler om at omfavne nye og ældre ændringer end ceremonier som standups og sprint planlægning. Der er 10 andre principper i det agile manifest. Men i stedet for at prøve på at vælge mellem disse principper, så bør de ses på som en helhed. Sammen repræsenterer disse principper en attitude mod ændringer, som både er hyppig ved agile og DevOps.
Mange har siddet fast i at forsøge på at køre svage systemer som også er de mest vigtige for virksomheden. Fordi de er de mest vigtige for virksomheden, så er det også der de vigtigste ændringer er nødvendige. Derfor er denne agile ide af at omfavne ændringer ikke omkring “ændring for ændringens skyld”. Det handler om at holde udviklingen ansvarlig for kvaliteten af deres ændringer, men den overordnede kapacitet til at levere forretningsværdi forbedres. Denne fokus på forretningsværdi er endnu et aspekt, som er delt at agile og DevOps.
Sidst men ikke mindst, så er hverken DevOps eller agile forretningsmål i sig selv. Begge er kulturelle bevægelser, som kan inspirere din organisation med bedre redskaber til at opnå dine mål. Agile og DevOps virker bedre i kombination end som modsætninger. Tricket for at undgå konfrontationer mellem disse to ideer er at forstå de dybere ideer og principper hvorpå de er formeret. Hurtige, men præcise definitioner fører til silotænkning. Nå da du ved, at der er mere til agile end scrum, og at der er mere til DevOps end kontinuerlig levering, så er du klar til at prøve den kraftfulde agile + DevOps kombination.
