Agilt, Iterativ & Inkrementell!

22 03 2013

Jag fick den här frågan från en kompis & student:

”Agile, Iterativ & Inkremell! Vi har pratat lite om det jag & några från klassen, och alla typ blandar ihop allt!
Vissa säger att tex Scrum är agilt, andra säger att det är ngt annat bla bla, jätte förvirrande :b det ända jag har
koll på är att RUP iaf är iterativt haha.”

Ska jag göra ett försök att förklara begreppen lite kort?  Jag gör ett försök..

Agile
Agile är ett sätt att tänka. Det är inte ett verktyg. Det är inte en metod. Det finns metoder som Scrum, Kanban, Lean Software Development som kan hjälpa dig att komma framåt. Du kan vara agil utan att använda någon metod alls. Du kan också vara agil med en gammaldags metod som RUP, eller vilken som helst annars. Det handlar om ditt sätt att se på projekt som en icke-förutsägbar händelse, och ditt sätt att se på verkligt samarbete (arbeta tillsammans), ständigt omfamna förändringar i omgivningen och hos dina kunder, kontinuerligt förbättra hur du och ditt team arbetar och samarbetar.

Det går att jobba enligt Scrum och inte alls vara agil, även om Scrum med sina regler om att inom en kort tid leverera fungerande programvara ofta hjälper till på vägen att bli agil.

Den här blog posten beskriver vad agile inte är  – med referenser till principerna i det Agila manifestet, som handlar om principer – inte verktyg & metoder.   http://www.tommycode.se/2012/12/what-is-agile.html?m=1

En gång delade jag några tankar om vad agilt är, på stapplande engelska..

http://blog.smartbear.com/software-quality/bid/224669/Ulrika-Park-Becoming-Agile

Iterativ

Iteration är ett annat ord för upprepning. Inom matematiken och i programmering handlar detta om att en funktion eller process åstadkommer något genom att upprepa tills ett önskat resultat uppnåtts.  (wikipedia nerkortat)

Ett annat ord är loop. Tänk dig ett flygplan som gör en loop. Sedan gör flygplanet samma loop igen. Det är den 2:a iterationen. Bilden nedan är ett gäng iterationer av samma flygplan.

Smoke-Loops-Flight-demonstration-Circle-Sky-300x187

Inom systemutveckling är det att utveckla samma funktion flera gånger tills den är tillräckligt bra.
Det kan också vara att genomföra samma projekt flera gånger tills det är tillräckligt bra att släppa till kund.

Säg att du skriver en uppsats om ett ämne. Du skriver en version rakt på tills den är klar. Sedan börjar du om och skriver samma uppsats en gång till. Du tar med dig saker från första versionen, kanske många meningar, men lägger till saker, tar bort saker, ändrar ord. Den andra versionen är andra iterationen. Skriver du den en tredje gång, har du gjort 3 iterationer.

Detta är något som glömts bort i många genomföranden av s.k agile.

Jag har varit med i ett par projekt där vi verkligen jobbade iterativt. Det vill säga – vi valde en funktion att bygga. Definierade vilka krav & testfall som skulle passera för att funktionen skulle kunna fungera någotsånär. Vi visade upp funktionen för beställaren/kravställaren. Sedan byggde vi samma funktion en gång till – byggde ut, snyggade till, förbättrade både bakom ytan (programkoden) och framför ytan (användargränsnittet). Ibland en tredje och fjärde gång.

Att jobba iterativt är att ALLTID bygga samma funktion minst 2 iterationer – 2 gånger.

Faktiskt så påstod även någon att även den förhatliga Vattenfallsmetoden var iterativ från början. Meningen var att man skulle driva sitt projekt enligt Krav – design – implementation – test – integration – leverans och sedan köra samma projekt en gång till och då göra det rätt och snyggt. Kanske borde kolla upp källorna på detta, men har för mig att jag sett bilder på en loop – där man går tillbaka till början direkt efter slutet.

Idén med RUP var också att vara iterativ. Dvs definiera krav (use cases), design, progammera, testa under en fas, sedan gör samma sak en gång till. Tyvärr dränktes den idén i för mycket annan information, regler & dokumentation så att jag har sett få RUP-projekt som faktiskt jobbat iterativt, även om jag har hört talas om dem som faktiskt gjort det.

Scrum är enklare och studerar man metoden noga kan man se att tanken är att iterera, loopa, över funktioner. Det har tyvärr också ofta dränkts i idén att man bara ska leverera snabbt snabbt. Att leverera snabbt är inte huvudfokus i principerna i det agila manifestet. Ingenstans sägs att man ska leverera snabbt. Men man ska prioritera fungerande programvara framför pappersprodukter (oändliga dokument som inte går att använda).

En ”sprint” i Scrum är INTE en iteration. En sprint är rätt och slätt en time-box på t.ex 2 veckor (aldrig mer än 4). Efter 2 veckor ska teamet visa upp resultatet för sina intressenter. Och bara fungerande programvara. Dokumentation, tankar, idéer och planer är oväsentligt. Huruvida man faktiskt tar samma funktion och itererar över den i nästa sprint, sägs inget om i Scrum, även om metoden kan tvinga fram det beteendet. Man hinner inte på 2 veckor göra så mycket ”lull lull”. Man måste ofta gå tillbaka till samma funktion nästa eller senare sprintar för att göra den värdig att sälja/använda.

Man kan säga att en sprint i Scrum kan vara en projekt-iteration. Dvs man genomför samma projekt i många iterationer, tills det är tillräckligt bra. Första iterationen så har man gjort projektet (krav, test, utveckling, integration, leveransfärdigt) fast det kanske inte är tillräckligt bra – än, så man gör en iteration till över samma projekt så blir resultatet bättre.

Jag har inte sett många Scrum-projekt som sett på sprintar på det sättet. Även om tanken var att en sprint – skulle vara en iteration av ett projekt.

Sprint och iteration är alltså (oftast) två helt olika saker.

Du kan bygga en funktion under en sprint, och sen strunta i att bygga/förbättra den igen. Då har du inte itererat över den funktionen. Du har bara jobbat i en time-box, en sprint.

Inkrementell

”An increment is an increase of some amount, either fixed or variable. For example one’s salary may have a fixed annual increment of x%” (redigerat från wikipedia).   Om din lön ökar med en fast % varje år, så ökar den i inkrement.

Inkrement är alltså en utökning.

Jag tänker på en bakelse. Säg att du har en liten rund bit sockerkaka och fyller den med bär. Sedan tittar du på den och tycker den förtjänar lite grädde runtom. Du lägger till grädde. Det är ett inkrement. Bakelsen var redan klar att äta och njuta av med sockerkakan och bär, men med inkrementet grädde så har du utökat bakelsen till en lite större upplevelse. Sedan tittar du på bakelsen igen och bestämmer dig för att lägga på riven choklad runtom. Ytterligare en utökning, ett inkrement. Den var redan färdig som den var, men chokladen gav det lilla extra.  Som ett sista inkrement lägger du på hyvlad mandel.

Du hade en färdig bakelse från början med sockerkaka & bär. Bara sockerkakan hade  inte varit tillräckligt, det hade bara varit en sockerkaka. Efter den första inkrementet, utökade du den stegvis, inkrementellt, till en större finare bakelse.

Samma gäller funktioner i systemutveckling. Du bygger en funktion som är färdig som den är. Den går att använda. Sedan utökar du den med (små) inkrement, ett extra värde, ett extra inmatningsfält, extra information.

Exempel
Ett exempel på inkrementell funktionsutveckling var när vi skulle presentera kursinformation i ett utbildningssystem för studenter.

Det första inkrementet bestod bara i att visa upp kurskoden och namnet på kursen. Fullt fungerande.
Det andra inkrementet bestod i att visa upp ytterligare information, såsom kort beskrivning, hur många poäng kursen var, vilken institution som gav kursen.
Tredje inkrementet var att visa upp kurstiteln på engelska och vilka prov som ingick.
Etc.

Vid första inkrementet kunde vi inte släppa funktionen till studenter, den var för fattig på information. Däremot kunde vi visa upp den för vår beställare/kravställare/produktägare, så att han kunde se att det fungerar.
Efter 3:e inkrementet var funktionen redo att släppas till studenter – slutanvändaren.

Skillnaden mellan iteration och inkrement??

Inte helt lätt att avgöra. När man stegvis utökar (increment) – en färdig funktion, så gör man det genom att iterera – alltså återkomma till samma funktion (bakelse) flera gånger.

Inkrement = utökning
Iteration = upprepning

Solklart?

Skulle vara jätteintressant  om den som rättar era tentor vill kommentera den här artikeln, kanske har hen ett ännu bättre svar på skillnaden mellan iteration & inkrement?

Kram

Ulrika

Annonser

Åtgärder

Information

5 responses

23 03 2013
Matti

Här är lite info om Royces tvåstegsversion av vattenfallsmodellen, se andra stycket

http://en.m.wikipedia.org/wiki/Modified_waterfall_models#section_1

28 03 2013
Ulrika Park

Tack! Wikepedia löser källproblemet – igen 🙂

5 01 2014
Bjorn

Hej Ulrika! Du borde jobba med kompetensutveckling. Ditt sätt att förklara grejar absolut inte vem som helst! Toppen!

5 01 2014
Ulrika Park

Tack! Det värmer och uppmuntrar, särskilt eftersom jag ägnat mycket tid genom åren åt att jobba med just kompetensutveckling 🙂

9 06 2014
johanna

Det här kan kanske vara till hjälp;
vattenfallsmetoden använder Poylas problemlösnings algoritm men vattenfall applicerar den på hela systemets utveckling i ett svep. Vilket innebär fler risker än att dela upp hela systemet och applicera analys, design och test på varje fas. Det senare gör man i den inkrementella metoden. Då har man utvärderat skissen och affärsplanen för ett system och prioriterat funktioner. De funktioner med högst affärsvärde vilket vanligtvis är ca 20 % av alla funktioner i ett system!! 🙂 Utvecklas först. Kraven / funktioner är alltså kända från början. Ett inkrement är en delleverans, vid slutet av varje inkrement förs det nya inkrementet ihop med det förra inkrementen och systemet testas. Inkrementellt ger två fördelar, först drar den nytta av en känd algoritm för problemlösning för att minimera risker, och för det andra kortar den ledtiden för produktion av systemet vilket gör att systemet fortare kan dra in inkomster till företaget.
Inkrementellt OCH/ELLER Iterativt. Dessa är två principer som kan kombineras. Inom ett inkrement kan man iterera faserna analys, design, test hur många gånger man vill. varje iteration innebär en förbättring av inkrementet. Obs! Här kommer det som gör allt komplicerat… När man delar upp ett system i specifika delar som i inkrementellt och producerar inkrement av systemt, betyder det att man vid varje nytt inkrement itererar över tidigare inkrement och att det sker en förbättring. Förenklat:
Inkrement = dela upp i delar och addera dessa.
Iterera = loopa utveckling oavsett om det sker i inkrement eller i annan form. för att förbättra något.

Scrum är både en iterativ och inkrementell process när den utförs rätt. Varje iteration ska nämligen resultera i en fullt fungerande inkrement som ska kunna installeras. När användarna skickat in feedback har det utförts en test.. men.. i början av scrums historia har scrum levererat endast i slutet när produkten varit helt färdig. Skillnaden är alltså beroende på testning och leverering av produkten; sker det i småbitar? Eller sker leveransen först i slutet då produkten är färdig? Kravhanteringen är olika i processerna; det inkrementella har kraven klara tydliga i början av hela projektet men kan ta emot feedback från test. Scrum itererar analys av krav vid varje iteration i nära samarbete med kund eller med en representant för kund. Scrum prioriterar krav och hittar krav vid varje test pga det iterativa.

// Om scrum inte utförs rätt ja då är den endast iterativ och då räknas sprintarna tillsammans med test och analys av krav som iterationer.

Kontakta gärna mig om det fortfarande finns frågor eller om ni tycker att det finns en annan förklaring som jag bör känna till.

johannabertilsson@live.se

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s




%d bloggare gillar detta: