Skip to main content

När du tänker på en högpresterande organisation, har du någonsin undrat vilka bästa metoder den följer som gör det möjligt för den att uppnå den positionen? Lutar den sig mot agila metoder eller DevOps-metoder?

För att uppnå sina mål förlitar sig dessa organisationer ofta på en kombination av agila verktyg för att hantera iterativ utveckling och adaptiv planering, tillsammans med DevOps-verktyg som effektiviserar automatisering, kontinuerlig integrering och driftsättning.

Målet med en utvecklings- och driftprocess är att hjälpa företaget att uppfylla sina krav, hjälpa teammedlemmarna att samarbeta och bryta ned stuprör för att undanröja hinder, och slutligen slutföra de projekt och funktioner de arbetar med, så att de kan öka antalet dagligen eller månadsvis aktiva användare – eller, när det gäller företagsapplikationer, öka funktionaliteten i sina applikationer.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

När team arbetar i stuprör leder det till brister i kommunikationen, vilket i sin tur leder till kaos. När team däremot arbetar tillsammans blir de mer effektiva. 

Inom ramen för den här artikeln kommer jag att gå igenom agila metoder och DevOps-metoder, exempel på när specifika metoder bör användas och hur testningen påverkas i vart och ett av dessa scenarier. 

Agila metoder för programvaruutveckling

Jämfört med vattenfallsprocessen för utveckling fokuserar agilt arbete på en av de centrala principerna, som innebär att kunderna ska bli nöjda tidigt i processen och genom kontinuerlig leverans. Kontinuerlig leverans är endast möjlig när vi involverar kvalitetsteamet tidigt i processen och samarbetar med dem ofta. 

Agil programvaruutvecklingsprocess.

För närvarande befinner sig vissa små och medelstora företag i ett läge där de varken helt följer agila metoder eller vattenfallsmetoden, utan en kombination av båda. Dessa så kallade agila teammedlemmar lägger så mycket energi på detaljerade processer som 30-minutersmöten och 60-minuters retrospektiva möten att de glömmer bort vilken avkastning på investeringen de bidrar med, vilket leder till en situation där många buggar upptäcks i produktion. 

Get regular tech leadership wisdom for delivering better software and systems.

Har branschen verkligen gått från en vattenfallsmetod? 

Har du någonsin varit en del av en organisation (som du trodde följde agila programvaruutvecklingsprocesser), för att sedan inse att kvalitetsteamet bara deltar i testningen efter att utvecklingen är slutförd? 

I det här exemplet kallade de det fortfarande agilt eftersom utvecklingsteamets medlemmar arbetade med flera grenar (eller funktioner) samtidigt på ett iterativt sätt. Men när deras funktioner skulle testas väntade de tills all utveckling var klar – vilket är kärnan i vattenfallsmetoden. Eftersom företag vill gå snabbare fram för att kunna utöka sin kundbas slutar teamen dock oftast med att samla på sig teknisk skuld. 

Det bästa sättet att lösa problemet är att ställa om organisationen så att den blir helt agil och arbetar hand i hand med kvalitetsteamet iterativt. Det innebär att arbeta med alla intressenter för att säkerställa att de förstår konsekvenserna av att inte göra förändringen och hur den kan påverka slutanvändarens upplevelse. 

Agila ramverk och deras varianter

Inom ramen för den här artikeln kommer jag att diskutera två av de mest populära agila ramverken:

  1. Scrum
  2. Kanban

Scrum är en agil metodik som används inom programvaruutveckling och bygger på iterativa och inkrementella processer. Den innebär att man följer en tidsbegränsad utveckling som kallas sprintar. Sprintarnas längd varierar mellan organisationer, från veckovisa till månatliga eller kvartalsvisa sprintar.

Först hålls ett sprintplaneringsmöte, följt av sprinten där implementering och testning genomförs, inklusive dagliga möten, och slutligen avslutas den med ett retrospektivt möte. 

Scrum-metodik.

Scrum används vanligtvis i produktutvecklingsteam där teammedlemmarna måste tidsbegränsa sitt arbete för att hålla kundernas tidsfrister. Det används främst för B2C-applikationer, eftersom din funktion inte längre är ny om du väntar för länge – någon annan kan redan ha implementerat den! 

I B2B-applikationer, som främst används av företagsorganisationer, används ofta en modifierad version av den agila metodiken som kallas SaFe – ett skalat agilt ramverk. 

De flesta projekt i företagsorganisationer tillhör en av följande kategorier:

  1. Teamnivå
  2. Programnivå
  3. Portföljnivå

Projekt på teamnivå är funktionsbaserad utveckling där varje teammedlem ansvarar för sitt projekt och sina processer. Dessa team använder vanligtvis Scrum eller Kanban beroende på arbetets natur.

Om teamen ingår i forsknings- och utvecklingsorganisationer eller arbetar med testautomatisering är det mycket viktigt att de följer Kanban, som är mindre strikt, och att målet i högre grad är att slutföra den aktuella uppgiften än att hoppa vidare till nästa glänsande objekt! Om teamen är en del av produktutvecklingsorganisationen tenderar de att använda Scrum-processer. 

Projekt på programnivå omfattar flera team som arbetar mot ett specifikt mål, till exempel en AWS-migrering. Även om detta projekt kan betraktas som ett projekt på portföljnivå skulle jag hävda att det inte nödvändigtvis skulle påverka HR- eller redovisningsteamen.

I det här fallet kan AWS-migreringen pågå i flera månader på grund av oförutsedda problem, så fokus ligger på att slutföra AWS-migreringen framgångsrikt samtidigt som den delas upp i motiverade sprintar. 

Projekt på portföljnivå omfattar olika organisationer inom företaget; ett exempel är en JIRA-implementering. Varje organisation skulle behöva få JIRA-arbetsflöden implementerade på olika sätt utifrån sina behov. Personalteam behöver inte utföra tester; fokus ligger främst på att hantera specifika förfrågningar från anställda, och när de har hjälpt dem markeras uppgiften som “slutförd.”

Agila metoder bör införas av organisationer som är kända för att ständigt genomgå förändringar. Men dessa förändringar måste fortfarande genomgå en test- och felkorrigeringsomgång, och testningen är inte nödvändigtvis automatiserad, vilket leder till längre processtider.

Slutligen, när funktionerna är redo att distribueras lämnas de över till bygg- och driftteamet. Testningen sker alltså iterativt jämfört med vattenfallsmetoden, men flyttas inte särskilt långt åt vänster eftersom fokus inte ligger på kontinuerlig testning och leverans. Därför behövs DevOps-metoden! 

DevOps-metoden

DevOps-metoden fokuserar på aspekter bortom utveckling och testning och förespråkar en helt automatiserad CI/CD-pipeline tillsammans med övervakningsfunktioner. Medan Agile välkomnar förändringar fokuserar DevOps-metoden på kontinuerlig testning och leverans för att säkerställa att frekventa lanseringar till slutanvändarna lyckas. 

Målet för IT-driftteamet är att skala upp programvaruutvecklingsprocessen för att påskynda skrivandet och uppdateringen av koden som ansvarar för att skapa nya applikationer och tjänster samt uppdatera funktioner inom IT-teamet.

Även när det gäller teamstrukturen ingår kvalitets- och IT-driftteamen numera i samma organisation så att de kan arbeta hand i hand. Faktum är att en ny roll kallad TestOps har införts för att specifikt fokusera på att konfigurera CI/CD-pipelines där automatiserade tester körs mot pullförfrågningar, vilket ger omedelbar återkoppling till utvecklingsteamen.

Automatiserad testning är avgörande för att skala testinsatserna, och dess värde går förlorat om den inte ingår i kontinuerlig testning och kontinuerlig distributions- och lanseringscykel. Därför har TestOps-personalen alltid fullt upp med underhåll av infrastrukturen för automatiserade tester.

Detta säkerställer att medlemmarna i driftteamet kan fokusera på att leverera en infrastruktur i världsklass för programvaruutveckling utan att distraheras av testinfrastrukturen. 

DevOps-metoden.

Det finns numera många verktyg och DevOps-metoder som effektiviserar den övergripande processen. 

  • En Terraform-tillståndsfil hänvisar till en uppsättning infrastrukturer som definieras och hanteras som en enda enhet—så här definieras och hanteras olika test- och utvecklingsmiljöer. Terraform hjälper till att konfigurera servrar, men vi behöver en infrastruktur för att köra dessa servrar. 
  • AWS tillhandahåller infrastrukturen via EC2-instanser, som för närvarande är det mest kostnadseffektiva sättet att konfigurera och köra dessa servrar. Om vi tar det ett steg längre och teknikstacken innehåller många mikrotjänster kan du med docker compose definiera och köra flera Docker-baserade containermiljöer.
  • Ansible automatiserar processen att konfigurera maskiner för att köra valfria processer eller servrar. 
  • Kubernetes hjälper till att hantera ett kluster av dessa EC2-instanser som en podd och schemalägger containrar som ska köras på detta kluster baserat på de tillgängliga beräkningsresurserna. 

Bör du använda agilt arbetssätt eller DevOps?

Även om agilt programvaruutvecklingsarbete kontra DevOps är en ständig debatt inom organisationer, är det bästa sättet att se på frågan att utgå från följande frågor:

  • Hur anpassningsbar är vår organisation när det gäller ny teknik? 
  • Kan vi konkurrera med våra konkurrenter när det gäller kvaliteten på våra produkter? 
  • Är det sannolikt att kunderna använder våra produkter eftersom de uppfyller deras förväntningar? 

Om svaren på ovanstående frågor innebär någon form av nekande är det dags att fokusera mer på en kombination av båda arbetssätten och anpassa den efter våra behov.

Den idealiska metoden för programvaruutveckling

Den viktigaste skillnaden mellan agila och DevOps-baserade programvaruutvecklingsprocesser är att den förstnämnda fokuserar mer på att hantera ständiga förändringar, medan den senare fokuserar på kontinuerlig testning, leverans och driftsättning. Samarbete mellan utvecklings- och driftteamen är avgörande så att utvecklingsteamet inte blockeras. 

Så enligt min mening bör en idealisk programvaruutvecklingsprocess omfatta följande:

  • Hantering av kund- och användarpersonas samt integrering av kundfeedback
  • Fokus på bästa praxis för att förhindra att teknisk skuld byggs upp
  • Kontinuerlig förbättring, kontinuerlig testning, kontinuerlig integration, kontinuerlig leverans, kontinuerlig driftsättning och övervakning

Så här skulle processen se ut:

Kunddriven AI/ML-baserad metodik.

Hantering av olika kundpersonas är inte begränsad till produktledningsteam. I slutändan, varför utvecklar vi dessa produkter? Vad är syftet med dessa produkter om de inte används av kunderna? 

Ta det klassiska exemplet med Nokia—när de fortsatte att bygga upp teknisk skuld genom att inte hålla jämna steg med marknadstrenderna, särskilt innovationerna från konkurrenten Apple. De fokuserade på att följa rigorösa sprintcykler, för att till slut bli bortglömda! 

Alla företag bör förstå varför deras funktioner utvecklas och vilken typ av kunder de riktar sig till. Detta säkerställer att vi utvecklar användarcentrerade funktioner. 

När en ny produkt lanseras, oavsett om det är en mobilapplikation eller en webbapplikation, bör du alltid se till att kunderna har möjlighet att lämna feedback. Alla företag följer inte en strikt process för att arbeta nära kundsupporten. 

CI/CD

Förespråka slutligen AI/ML-baserad kontinuerlig integration och kontinuerlig leverans. När ett projekt misslyckas betyder det inte nödvändigtvis att teammedlemmarna saknar kompetens; det beror i stället på otillräcklig testning och att problem inte upptäcktes tidigare under utvecklingen.

Men ibland går saker fel även när tillräcklig testning och automatisering finns på plats—så om det fanns ett rekommendationssystem som kunde identifiera när en version ska lanseras och när den inte ska lanseras, kanske sådana katastrofala fel kunde undvikas.

Frekventa iterationer hjälper utvecklingsteamet att förstå vad som fungerar och vad som inte gör det, samt att tänka på skalbarhet. Nackdelen är att det är tidskrävande! Om ett annat rekommendations-/prognossystem kunde samla in data om kunder och förutsäga om en viss funktion skulle bidra till att få genomslag eller misslyckas redan innan utvecklingen börjar, skulle det hjälpa till att effektivisera processen för att bygga en högkvalitativ produkt från dag 1! 

Det övergripande målet är att säkerställa att verksamhetseffekterna multipliceras snabbare när dessa bästa praxis införs som en del av utvecklingsprocessen. 

Avslutande tankar

I slutändan spelar både agilt arbetssätt och DevOps avgörande roller i modern programvaruutveckling, men det rätta valet beror på organisationens mål, teamstruktur, prisalternativ och projektets behov.

Agilt fokuserar på iterativ utveckling och flexibilitet, medan DevOps betonar kontinuerlig leverans, automatisering och samarbete mellan utveckling och drift. Många organisationer når framgång genom att kombinera båda metoderna för att maximera effektivitet och kvalitet. Oavsett vilken väg du väljer är det viktigt att anpassa dina verktyg och processer för att driva innovation och leverera värde snabbare.

För fler insikter om hur du optimerar dina utvecklingsarbetsflöden och håller dig steget före branschtrenderna kan du prenumerera på The CTO Clubs nyhetsbrev.