Agilt bara scrum?

2013-02-20 Artikelbanken Test Läst 12002 gånger

De flesta av oss är redan bekanta med Scrum, och har en kännedom om agila metoder generellt, samt hur de kontrasterar mot de mer traditionella metoderna, såsom Vattenfallsmetoden. Vad som är bäst för ett specifikt sammanhang, agila metoder eller inte, beror på många olika faktorer. Om du tror att en agil metod är den mest lämpliga för ditt sammanhang, så finns det olika varianter att välja mellan.

 

Vilken ska du då välja och varför? Att allt för hastigt byta från Vattenfall till agilt, utan att tänka efter - före, vore kanske inte det mest praktiska. Det är självklart rätt ogenomtänkt att börja använda Scrum utan att ens känna till alternativen, och ha funderat på om någon av dem kan vara ett bättre val.

 

I den här artikeln kommer jag därför gå igenom några andra agila metoder, samt försöka reda ut vad som skiljer dem från varandra. Det är dock ingen djuplodande beskrivning utan snarast en introduktion för att visa bara några få av alternativen som finns. Exakt vilken metod som passar ditt sammanhang bäst går inte att säga utan att känna till just de behov som ni har, vad ni gör och vilka ni är. Men en sak är säker - agilt är inte bara renodlad Scrum!

 

Vad har de agila metoderna gemensamt?

Gemensamt för olika metoder, rent allmänt, är att de försöker strukturera och kontrollera systemutvecklingsprocessen, vilket även gäller för de agila metoderna, på sitt eget sätt. Även om de olika agila metoderna kan skilja sig lite åt, så är de alla byggda på samma grundfundament, som finns nedtecknat i det Agila manifestet. Gemensamt för dem är att de:

  • är lätt anpassningsbara till förändring
  • har en fungerande produkt som sitt mål
  • förespråkar kontinuerlig kommunikation och interaktion

 

Rent praktiskt innebär detta följande:

  • Genom att vara anpassningsbar till förändring har man en öppen inställning till framväxande och/eller föränderliga krav. Man utgår helt enkelt från att krav kommer att förändras och tillkomma över tid, och att det är helt naturligt att det är så. När förändringarna kommer så bejakar man dem och anpassar sig efter dem.
  • Med en fungerande produkt, eller kvalitativ kod, som mål poängterar man att det inte är på den noggranna dokumentationen som man bedömer slutresultatet. Det är produkten och koden i sig själv som är av den högsta betydelsen.
  • Medarbetare i teamet och medarbetare utanför teamet måste prata med varandra på regelbunden basis. Utvecklare och testare m.fl. skall möta och tala med representanter från verksamhetssidan. Men det är också så att medarbetarna inom teamet mår bra av kontinuerlig kommunikation med varandra!

 

 

Om vi tittar lite närmre på andra vanliga agila metoder förutom Scrum, hittar vi exempelvis Dynamic Systems Development Method (DSDM), eXtreme Programming (XP) och Kanban. DSDM och XP var vanligare för några år sedan än vad de är idag, men de finns kvar i vissa sammanhang och hänvisas till ofta, varför det är värt att ta med dem i den här genomgången. Kanban har under de senaste åren blivit klart mycket vanligare, varför även den är värd sin plats i den här artikeln.

 

Vi ska i de kommande styckena "lyfta på locket" för att ge en förståelse för hur dessa metoder fungerar.

 

DSDM

DSDM är ett arbetssätt som består av tre sekventiella faser med totalt sju steg. Arbetssättet inleds med ett "pre-project" för att identifiera kandidatprojekt, fastställa budget och för att säkerställa att man är överens om vad som ska göras. Detta följs av en fas som inkluderar en förstudie, en studie som fokuserar på affärsnytta ("business needs" i terminologin i DSDM), prototyping, design/utveckling och en implementationsfas, där i synnerhet prototypingen och utvecklingen innehåller understeg som itereras. Metoden avslutas med ett "post-project" för att säkerställa att systemet fungerar effektivt i produktion.

 

De inledande faserna syftar till att utreda vilka intressenterna är, vilka behov de har och vilka högnivåkrav som finns. En teknik bland andra som används är MoSCoW - prioritering enligt kategorierna Must Have, Should Have, Could Have och Won’t Have (Would Have eller Won't Now förekommer också).

 

Projektet kan i teorin gå igenom de olika faserna, för att sedan avslutas, illustrerat genom de blå pilarna i modellen. I den händelse att allting inte löper helt felfritt kan projektet gå från vissa steg till andra, för att repetera dem – detta illustrerat av de grå pilarna.

 

Prototyping, vilket man förespråkar mycket inom DSDM, bidrar till att alla intressenter får en tydlig bild av samtliga aspekter av systemet, hur systemet fungerar, och att designen blir bra.

 

XP

eXtreme Programming (XP) är ett iterativt arbetssätt som saknar en separat kravfas, och som fokuserar på, och delar in arbetet i följande steg (kallad planering- och återkopplingsloop):

 

1. Releaseplanering som sträcker sig över månader

2. Iterationsplanering som sträcker sig över två veckor

3. Acceptanstestning som sträcker sig över dagar

4. Stå-upp-möten som sträcker sig över enskild dag

5. Parförhandlingar som sträcker sig över timmar

6. Enhetstestning (unit testing) som sträcker sig över minuter

7. Parprogrammering som sträcker sig över sekunder

8. Kod med regelbundna kodgranskningar

 

En viktig del är återkoppling mellan stegen så att arbetssättet och produkten blir bättre och bättre. Återkopplingen sker i stort sett hela tiden och den sker direkt.

 

XP kombineras oftast med utvecklingsmetodiken Testdriven Utveckling (Test-Driven Development eller TDD). TDD innebär att utvecklaren först skapar ett, ofta automatiserat, enhetstest, och sedan skapar kod som klarar testfallet. På så vis programmerar man endast det som verkligen behövs, och man vet redan i ett tidigt stadie att koden, genom att klara testet, uppfyller specificerade krav.

 

XP är visserligen en agil metod, men den har ett väldigt tydligt programmerarfokus. Detta gör den knepig som metod om teamet även inkluderar andra roller, vilket teamen ofta gör i verkligheten. Många av de tekniker som togs fram med XP, såsom parprogrammering och stå-upp-möten, har idag blivit vanliga delar i de flesta agila metoder men även i många andra sammanhang.

 

Kanban

I sammanhanget bör man även nämna Kanban, en metod som är tagen ur Toyotas Lean-koncept, som omdanats till en utvecklingsprocess. Lean menar att man enbart skall arbeta med det viktigaste, och eliminera allt onödigt. Detta kan innebära att stryka möten som inte är nödvändiga eller dokumentation som inte har en uppenbar nytta.

 

I Kanban följer man ett kontinuerligt flöde (i motsats till ett med sprintar), där man alltid arbetar med det viktigaste men aldrig med för mycket samtidigt. Man har därför ett fastställt maximalt antal aktiviteter man kan arbeta med i ett steg. Om maxgränsen är nådd innebär det att man inte kan flytta ytterligare arbete till den aktiviteten. I Kanban är då förväntan att alla som kan hjälper till att lösa flaskhalsen så att arbetsuppgifterna kan fortsätta att flöda igenom processen igen.

 

 

Nu kanske du tänker - men Kanban är väl inte en agil metod om den kommer från Lean? Om enda skillnaden mellan "traditionella agila metoder" [sic!] och Kanban är att den senare inte förespråkar ett arbetssätt uppdelat i kortare iterationer eller sprintar, tycker jag det börjar likna en falsk dikotomi.

 

Man talar också ibland om Scrum-ban, och menar då ett slags agilt arbetssätt där man använder sig av dagliga stå-upp-möten och annat matnyttigt från Scrum, såsom de typiska teamrollerna – men struntar i iterationerna. Istället använder man Kanban-tavlan.

 

Vilken metod eller variant ska man välja?

Vad man snabbt märker, när man grottar ned sig i ämnet, är att det finns väldigt många olika metoder - och de få som jag valt att ta upp krusar bara ytan. De är ganska komplicerade att sätta sig in i, och att de dessutom är förhållandevis lika varandra, gör inte saken lättare.

 

Så vad är då fördelarna respektive nackdelarna mellan dessa metoder, inklusive Scrum? I Scrum är kraven väldigt lättrörliga, vilket ju är något som kan vara både bra och dåligt. I vissa sammanhang kanske det emellertid är värt att klubba en del högnivåkrav redan i ett väldigt tidigt skede.

 

Är din organisation intresserad av agila arbetssätt men är rädd för att kravarbetet blir alltför lidande kanske det är värt att läsa på om DSDM. Om kraven är framväxande och/eller ständigt under förändring kanske Scrum är rätt. Har du någon gång känt att sprintarna är för långa, för korta, eller varför inte båda? Kanske är då Kanban med ett agilt mindset, eller Scrum-ban, något att undersöka!

 

Är det så viktigt vad metoden har för namn då? Nej, antagligen inte. Med största sannolikhet kommer du inte följa den till punkt och pricka ändå. Ta en titt på det Agila manifestets principer så kanske det går att plocka ihop något som fungerar för din organisation. Var bara tydlig mot dina medarbetare så att alla följer samma arbetssätt.

 

Nästa steg

Fler artiklar i Faktabanken:

Agil test - Vilka utmaningar får du?

Är agilt så bra som vi alla säger?

Utan automatiserade tester, ingen agil utveckling!

Hur Scrum har utvecklat testrollen

 

Konsultbolag1:s kurser inom kravhantering och test:

Agil test - lär dig hur du skapar bra tester vid agil utveckling.

Kravdesign - lär dig om en mängd olika tillvägagångssätt för att strukturera, skriva och jobba med krav i olika sammanhang.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln