Vad är ett agilt arbetssätt?

Agil är en term som beskriver metoder för programvaruutveckling som betonar inkrementell leverans, teamsamarbete, kontinuerlig planering och kontinuerlig inlärning. Termen Agile myntades 2001 i det agila manifestet. I manifestet angavs principer för att vägleda en bättre strategi för programvaruutveckling. I grunden deklarerar manifestet fyra värdeförklaringar som representerar grunden för den agila rörelsen. Som det är skrivet står det i manifestet:

Vi har kommit att uppskatta:

• Individer och interaktioner över processer och verktyg.
• Fungerande programvara framför omfattande dokumentation.
• Vikt på kundsamarbete framför avtalsförhandling.
• Svara på förändringar framför att följa en plan.

Manifestet antyder inte att objekten på höger sida av dessa uttalanden inte är viktiga eller behövs. I stället är objekt till vänster helt enkelt mer värderade.

Agila metoder och praxis

Det är viktigt att förstå att Agile inte är något. Du tillämpa inte agil metodik. Agile är snarare ett tänkesätt som driver en metod för programvaruutveckling. Eftersom det inte finns någon enskild metod som fungerar för alla situationer har termen Agile kommit att representera olika metoder och metoder som överensstämmer med värdeinstruktionerna i manifestet.

Agila metoder, som ofta kallas ramverk, är omfattande metoder för faser i DevOps-livscykeln: planering, utveckling, leverans och drift. De föreskriver en metod för att utföra arbete, med tydlig vägledning och principer.

Scrum är det vanligaste agila ramverket, och det som de flesta börjar med. Agila metoder är däremot tekniker som tillämpas under faser av livscykeln för programvaruutveckling.

• Planning Poker är en samarbetsuppskattningspraxis som är utformad för att uppmuntra teammedlemmar att dela sin förståelse för vad som gjort innebär. Många tycker att processen är rolig, och det har visat sig hjälpa till att främja teamarbete och bättre uppskattningar.
• Kontinuerlig integrering (CI) är en vanlig agil ingenjörspraxis som innebär att integrera kodändringar i huvudgrenen ofta. En automatiserad version verifierar ändringar. Därför minskar integrationsskulden och en ständigt leveransklar huvudgren.

Dessa metoder, liksom alla agila metoder, bär agil etikett, eftersom de är förenliga med principerna i det agila manifestet.

Vad agilt inte är

Eftersom Agile har blivit populärt har många stereotyper och feltolkningar kastat en negativ skugga över dess effektivitet. Det är lätt att säga "Ja, vi gör agilt", utan något ansvar. Tänk på några saker som Agile inte är.

• Agil utveckling är inte cowboykodning. Agile ska inte förväxlas med en "vi löser det efter hand" inställning till programvaruutveckling. En sådan idé kunde inte vara längre från sanningen. Agile kräver både en definition av gjort och explicit värde som levereras till kunder i varje sprint. Även om Agile värderar autonomi för individer och team, betonar det anpassad autonomi för att säkerställa att den ökade autonomin ger ökat värde.
• Agil är inte utan stringens och planering. Tvärtom betonar agila metoder och metoder vanligtvis disciplin i planeringen. Nyckeln är kontinuerlig planering i hela projektet, inte bara planering i förväg. Kontinuerlig planering säkerställer att teamet kan lära sig av det arbete som de utför. Med den här metoden maximerar de avkastningen på investeringar (ROI) för planering.

"Planer är värdelösa, men planering är allt." - Dwight D. Eisenhower

• Agil är inte en ursäkt för bristen på en färdplan. Denna missuppfattning har förmodligen gjort mest skada på den agila rörelsen överlag. Organisationer och team som följer en flexibel metod vet absolut vart de är på väg och de resultat som de vill uppnå. Att känna igen ändringar som en del av processen skiljer sig från att pivotera i en ny riktning varje vecka, sprint eller månad.
• Agil är inte utveckling utan specifikationer. Det är nödvändigt i alla projekt att hålla ditt team i linje med varför och hur arbetet går till. En agil metod för specifikationer innebär att se till att specifikationerna är anpassade i storlek och att de på ett lämpligt sätt återspeglar hur teamet planerar och levererar arbete.
• Agil kan inte ta emot oplanerat arbete och andra avbrott. Det är viktigt att slutföra sprintar enligt schemat. Men bara för att ett problem uppstår som leder utvecklingen på fel spår innebär inte att en sprint måste misslyckas. Team kan planera för avbrott genom att ange resurser i förväg för problem och oväntade problem. Sedan kan de åtgärda dessa problem men hålla sig på rätt spår med utvecklingen.
• Agil är inte olämpligt för stora organisationer. Ett vanligt klagomål är att samarbete, en viktig del av agila metoder, är svårt i stora team. Ett annat klagomål är att skalbara angreppssätt på Agile inför struktur och metoder som äventyrar flexibiliteten. Trots dessa missuppfattningar är det möjligt att skala agila principer framgångsrikt. Information om hur du övervinner dessa svårigheter finns i Skala agil till stora team.
• Agil är inte ineffektiv. För att anpassa sig till kundernas föränderliga behov investerar utvecklarna tid varje iteration för att demonstrera en fungerande produkt och samla in feedback. Det är sant att dessa ansträngningar minskar den tid som de lägger på utveckling. Men att införliva kundförfrågningar tidigt sparar betydande tid senare. När funktionerna ligger i linje med kundens vision undviker utvecklarna större översyner.
• Agil passar inte dåligt för dagens program, som ofta fokuserar på dataströmning. Sådana projekt omfattar vanligtvis mer datamodellering och ETL-arbetsbelastningar (extract-transform-load) än användargränssnitt. Detta faktum gör det svårt att visa användbar programvara enligt ett konsekvent, tätt schema. Men genom att justera mål kan utvecklare fortfarande använda en flexibel metod. I stället för att arbeta för att utföra uppgifter varje iteration kan utvecklare fokusera på att köra dataexperiment. I stället för att presentera en fungerande produkt med några veckors mellanrum kan de sträva efter att bättre förstå data.

Varför agil?

Så varför skulle någon överväga ett agilt tillvägagångssätt? Det är tydligt att reglerna för engagemang kring att bygga programvara har förändrats i grunden under de senaste 10-15 åren. Många av aktiviteterna ser likadana ut, men de landskap och miljöer där vi tillämpar dem skiljer sig märkbart.

• Jämför hur det är att köpa programvara idag med början av 2000-talet. Hur ofta kör folk till butiken för att köpa affärsprogramvara?
• Fundera på hur feedback samlas in från kunder om produkter. Hur förstod ett team vad folk tyckte om sin programvara före sociala medier?
• Tänk på hur ofta ett team vill uppdatera och förbättra den programvara som de levererar. Årliga uppdateringar är inte längre genomförbara mot modern konkurrens.

Forresters Diego Lo Guidice säger att det är bäst i hans blogg, Transforming Application Delivery (oktober, 2020).

" Allt har förändrats dramatiskt. Hållbarhet, förutom grönt och rent, innebär att det vi bygger idag måste enkelt och snabbt förändras i morgon. Strategiska planer är kortsiktiga och planering och förändring är kontinuerliga." – Diego Lo Guidice, Forrester

Reglerna har ändrats och organisationer runt om i världen anpassar sig nu till programvaruutveckling i enlighet med detta. Agila metoder och metoder lovar inte att lösa alla problem. Men de lovar att etablera en kultur och miljö där lösningar uppstår genom samarbete, kontinuerlig planering och lärande och en önskan att leverera programvara av hög kvalitet oftare.

Nästa steg

Om du bestämmer dig för att ta den agila vägen till programvaruutveckling kan du introducera några intressanta möjligheter att förbättra din DevOps-process. En viktig uppsättning överväganden fokuserar på hur agil utveckling jämförs och kontrasterar med en organisations nuvarande metod.