Vad är skillnaden mellan iterativ och inkrementell utveckling?
I mina utbildningar lägger jag ofta märke till att deltagarna blandar ihop iterativ och inkrementell utveckling (IID). Syftet med den här artikeln är att ge en förståelse för relationen mellan inkrementell och iterativ utveckling.
Jag börjar med en jämförelse mellan en vattenfalls- och en agil ansats, med exemplet att leverera en betalningsapp. Ett tillhörande miniseminarie om dessa ansatser ingår också. I artikelns andra del placerar jag vattenfall och agilt i en matris som visar skärningspunkten mellan inkrementell och iterativ utveckling och förklarar alla fyra kvadranter i matrisen.
Agilt kontra vattenfall: utvecklingen av en betalningsapp
Vattenfallsansatsen
Om exempelappen utvecklas enligt en traditionell vattenfallsmodell kan följande steg observeras i figur 1.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Figur 1: Diagrammet visar en typisk vattenfallslivscykel med exemplet att leverera en app.
Projektinitiering
Allt börjar med en projektsponsor från marknadsavdelningen, som lyckades frigöra de pengar som behövdes för appen. Hans antagande var att appen skulle förbättra kundlojaliteten och inflödet av nya kunder. Han visualiserade tre övergripande funktionsgrupper.
När projektet har godkänts utses en projektledare och ett projektteam bildas. Efter många diskussioner och workshoppar för insamling av krav kom man överens om att leverera en betalningsapp med 250 funktioner. Alla dessa funktioner dokumenteras i ett omfattande och mycket detaljerat dokument med programvarukrav och undertecknas av projektsponsorn och kundrepresentanten (samt andra viktiga intressenter).
Projektets designfas
I nästa steg översätter projektteamet kraven till en design för appen. Arkitekten kontrollerar designen mot designprinciperna. Han kontrollerar också om alla nödvändiga dataattribut finns tillgängliga i serverdelsystemet.
Vi är nu två månader in i projektet och kunden har ännu inte sett något som fungerar, bara några statusrapporter. Och dessa statusrapporter innehåller sannolikt någon form av ”vattenmelonrapportering”, vilket gör att kunden inte har någon aning om huruvida projektet ligger enligt plan eller inte.
Projektets utvecklingsfas
Det tar sex månader att utveckla appen och när det är klart ombeds kundrepresentanten att tillhandahålla några personer som kan hjälpa till med ett användaracceptanstest. Under testet blir det tydligt att flera funktioner inte fungerar.
Projektteamet förstår inte varför. Det är exakt det som beskrevs i kravdokumentet. Detta leder till många diskussioner, omarbetningar och förseningar, och kunderna är inte nöjda med resultaten. Om vi dessutom tittar på slutresultatet kan vi lägga märke till att många av de utvecklade kraven inte används, eller används sällan, av kunden.
Det skulle till och med kunna vara värre. Anta att utvecklingen av appen tog 1,5 år och att en annan bank levererar en betalningsapp när du har kommit halvvägs. Vad skulle du göra då? Skulle du fortfarande ha ett hållbart affärsunderlag för att fortsätta och slutföra din egen app?
Om vi tittar på figur 1 blir det tydligt att omfattningen och de underliggande kvalitetskriterierna i en vattenfallsansats är fasta och levereras vid ett enda tillfälle. Alla steg genomförs en gång för hela projektet och ledningens kontroll fokuserar på kostnad och tid. Värdeleveransen till kunden sker först efter driftsättningen av hela appen.
Den agila ansatsen
Om vi utvecklar appen med en agil projektledningsansats ser vi följande mönster:
- Utvecklingsteamet uppger att de kan leverera de två första funktionerna som produktägaren har prioriterat under den första iterationen.
- Projektteamet levererar ett inkrement av produkten var tredje vecka (sprint, iteration eller tidsbox).
- Efter de första leveranserna eller inkrementen ser vi en kund som känner sig trygg med att projektet kommer att leverera. Kunden har redan en fungerande app och förstår att alla funktioner ännu inte finns där, men de funktioner som finns fungerar.
När kunden tittar på den senaste versionen och de funktioner som har levererats nämner kunden en helt ny funktion. En funktion som ingen hade tänkt på i början av projektet, men som skulle kunna göra kundens vardag mer produktiv.
Efter varje inkrement leder kundens återkoppling till nya funktionella möjligheter (som inte fanns med på den ursprungliga listan) eller justeringar av möjliga funktioner. Produkten blir allt mer mogen. Vid varje inkrement får kunden en ny version och blir nöjdare.
Figur 2: Diagrammet visar den agila utvecklingscykeln med samma exempel på leveransen av en app.
Om vi tittar på figur 2 ser vi ett jämnt leveransflöde inom en fast tidsperiod och med permanenta agila team (detta är fasta kostnader). Omfattningen och de underliggande kvalitetskriterierna är flexibla (dynamiska), med frekventa små leveranser (dessa är inkrementen).
Alla steg som är avsedda att leverera en funktion eller användarberättelse genomförs upprepade gånger (vilket gör processen iterativ) tills den nödvändiga kvaliteten har uppnåtts. Ledningens kontroll fokuserar på leverans av kundvärde. Värdeleveransen till kunden sker efter varje driftsättning av ett inkrement.
Vattenfallsmodellen kontra agilt arbete: leveransresultat
Om vi granskar de två produkterna från både vattenfallsmodellen och den agila programvaruutvecklingsmetoden närmare ser vi en produkt med 250 funktioner och en inte särskilt nöjd kund samt en produkt med endast 150 funktioner och en mycket nöjd kund (se figur 3).
Figur 3: Diagrammet jämför skillnaderna i tid, antal funktioner och kundtillfredsställelse mellan vattenfallsmodellen och agila metoder.
Om vi dessutom granskar produkten som levererats med den agila metoden mer i detalj ser vi endast en delmängd på 100 funktioner från den ursprungliga listan samt 50 funktioner som är nya eller justerade. Detta överensstämmer med några viktiga principer i Agile-manifestet, däribland:
- Enkelhet, vilket är konsten att maximera mängden arbete som inte behöver utföras: endast 150 funktioner i stället för 250
- Välkomna förändrade krav, även sent i utvecklingen: anpassning till kundfeedback efter varje iteration och inkrement
Agila utvecklingsprocesser utnyttjar förändring till kundens konkurrensfördel (50 nya eller justerade funktioner levererades). Som ett resultat är kunden mycket nöjd. Teamets högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefulla programvarusystem.
Kort webbinarium: leverans enligt vattenfallsmodellen kontra agilt arbete
Här är ett kort webbinarium med mer information om skillnaderna mellan leverans enligt vattenfallsmodellen och agilt arbete.
Skillnader mellan iterativ och inkrementell utveckling
Nu när jag har gått igenom skillnaderna mellan vattenfallsmodellen och ett agilt arbetssätt med hjälp av exemplet att skapa en betalningsapp ska jag placera vattenfallsmodellen och agilt arbete i en matris som jämför iterativ och inkrementell utveckling.
Som ett sista steg ska jag utveckla resonemanget om en minsta livskraftig produkt (MVP) och den minsta marknadsförbara produkten (MMP) samt visa var dessa passar in i de olika arbetssätten och en berättelsekarta. Jag har också inkluderat ett motsvarande kort webbinarium.
Matris för iterativ och inkrementell utveckling
Som nämnts lade jag märke till att studenter ofta blandar ihop iterativ och inkrementell. I figur 4 hittar du fyra kvadranter, som skapas av en horisontell linje som visar inkrementell utveckling eller inte och en korsande vertikal linje som visar iterativ utveckling eller inte. Se den här YouTube-videon för en mycket enkel version av figuren.
Figur 4: Den här matrisen visar olika utvecklingsmetoder och huruvida teammedlemmar som följer dessa metoder behöver iterera och/eller arbeta i inkrement.
Nedre vänstra kvadranten
I det nedre vänstra hörnet ser vi arbetssättet där det varken finns iterationer eller inkrement. Detta är vattenfallsmodellen. Alla aktiviteter (design, analys, utveckling, testning och driftsättning) genomförs en gång för hela projektet.
I detta fall ser vi en enda leverans av slutprodukten baserad på en fast omfattning. Kundvärde kan endast uppnås efter leveransen av slutprodukten. Ett av de viktigaste målen med detta arbetssätt är att hantera kostnaderna.
Nedre högra kvadranten
I den nedre högra kvadranten ser vi ett inkrementellt tillvägagångssätt utan iterationer. Detta är en stegvis eller inkrementell leverans av mindre delar av produkten. Alla aktiviteter för ett givet steg (design, analys, utveckling, testning och driftsättning) utförs en gång.
Inom ett givet steg är omfattningen fast, men den totala produkten baseras på en mer dynamisk eller flexibel omfattning. Kundvärde kan uppnås efter varje leverans av produkten. Ett av de viktigaste målen med detta tillvägagångssätt är snabb leverans.
Övre vänstra kvadranten
I den övre vänstra kvadranten ser vi ett spiralformigt eller iterativt tillvägagångssätt utan inkrement. Detta är en enda leverans där slutprodukten skapas genom flera iterationer. Ett bra exempel på detta tillvägagångssätt är designtänkande. I figuren ser du en sekvens av aktiviteterna inramning, analys, idégenerering, förverkligande och reflektion.
Denna sekvens genomförs upprepade gånger eller iterativt, där du i varje iteration kommer närmare den slutliga, korrekta eller efterfrågade produkten. I många fall är denna slutprodukt en prototyp eller modell. I detta spiralformade tillvägagångssätt har vi en dynamisk eller flexibel omfattning. Kundvärde kan endast uppnås efter leveransen av slutprodukten. Ett av de viktigaste målen med detta tillvägagångssätt är lösningens korrekthet.
Övre högra kvadranten
I den övre högra kvadranten ser vi det agila tillvägagångssättet som använder inkrement och en iterativ metod. Scrum är ett bra exempel på detta tillvägagångssätt.
I slutet av varje inkrement, som ofta kallas en sprint eller tidsbox, levereras ett inkrement av produkten. Detta inkrement är resultatet av många iterationer för att utveckla små men korrekta delar, som ofta kallas användarberättelser eller uppgifter i produktbackloggen, av produkten. Det slutliga iterativa projektet levereras bit för bit.
I detta agila tillvägagångssätt har vi en dynamisk eller flexibel omfattning. Kundvärde kan uppnås efter varje leverans av produkten. Ett av de viktigaste målen med detta tillvägagångssätt är kundvärde genom frekventa leveranser och återkoppling från användarna.
MVP eller MMP?
I figur 4 hittar du även akronymerna MVP och MMP. MVP står för minsta livskraftiga produkt och är en version av en ny produkt eller tjänst som gör det möjligt för ett team att samla in största möjliga mängd lärdomar om kunderna och få validering med minsta möjliga ansträngning. MVP:n för Dropbox-tjänsten var en enkel film. Det innebär att P:et i MVP kan vara en helt annan produkt än den som till slut blir slutprodukten.
Ett exempel som illustrerar MVP och MMP
Jag använder ofta följande exempel på en ny finansiell produkt. En entusiastisk försäljningschef har en bra idé om en ny finansiell produkt. Han tror att de kan sälja minst 100 000 exemplar av denna produkt.
Tillsammans med några finansexperter utformar de produkten på ett par månader. Ett utvecklingsteam tilldelas uppgiften, och det tar dem 4 månader att utveckla produkten. Parallellt tas kommersiella broschyrer fram och produkten lanseras vid ett stort evenemang.
Tyvärr är det bara några få personer som köper produkten. Om vi följer MVP-metoden kan vi anta att 10 % av deras webbanvändare är intresserade av produkten. Därefter skulle vi utveckla en MVP för att testa denna hypotes.
I detta fall kan MVP:n vara en enkel knapp på startsidan. Om du klickar på den får du upp en skärm med ett meddelande om den nya produkten och möjlighet att ange din e-postadress om du är intresserad. Anta att mindre än 1 % av besökarna tryckte på knappen — produkten skulle inte utvecklas, och företaget sparade många knappa resurser.
Om vi tittar närmare på figur 4 ser vi den potentiella användningen av MVP:er i alla kvadranter. När du använder ett vattenfallsbaserat tillvägagångssätt kan du skapa en MVP i den första programvarudesignfasen för att kontrollera om det finns en affärsmässig motivering för projektet.
Detsamma kan göras i den första fasen av det första inkrementet när du följer en stegvis leverans. I vissa fall kan resultatet av ditt designtänkande vara en MVP. MVP:n kan även vara fördelaktig i början av ett agilt tillvägagångssätt.
Många ser den första produkten som levereras i slutet av den stegvisa leveransen som MVP:n. Det kan vara fallet, men i de flesta fall är detta inte en MVP utan en MMP. MMP, eller minsta marknadsförbara produkt, är den minsta produkt som kan skapa värde för din kund.
Hur ser agil leverans ut?
Nu när det står klart att inkrementella modeller och iterativa modeller inte är samma sak, och vi förstår användningen av MVP och MMP, kan vi undersöka mer i detalj hur inkrementell och iterativ leverans ser ut.
Du har förmodligen sett Jeff Pattons berömda exempel med Mona Lisa, där målningen skapas bit för bit (stegvis leverans). Ett annat sätt att gå tillväga är att börja med det första inkrementet, där endast en grov skiss skapas, och med varje ny iteration lägga till fler detaljer i skissen tills du slutligen har den färdiga målningen (inkrementell och iterativ eller agil leverans).
I den första situationen måste du redan ha en detaljerad idé om slutprodukten, medan du i den andra situationen endast behöver en översikt på hög nivå, eftersom förändringar är mycket enklare att genomföra. Om vi tittar på figur 5 ser vi en berättelsekarta för en ny produkt som heter ABC.
Figur 5: Ett exempel på en berättelsekarta för en specifik exempelprodukt.
Produktägaren föreställde sig sju funktioner för den här produkten. De fyra första funktionerna är måste-krav. Funktion 5 och 6 är bör-krav och den sista funktionen är ett kan-krav. Många skulle kalla detta MoSCoW-prioritering (måste-krav, bör-krav, kan-krav och ska-inte-krav).
Varje funktion kan i sig delas upp i mindre delar. I figuren ser du funktioner eller användarberättelser med måste-, bör- och kan-krav. En funktion kan vara ett måste-krav, men det betyder inte att alla underliggande användarberättelser också är måste-krav. Eller så kan en funktion vara ett bör-krav, men när du implementerar den funktionen är vissa användarberättelser måste-krav och andra bör- eller kan-krav.
För att implementera den här ABC-produkten ser du fem inkrement eller lanseringar. Den första är den minsta lanseringsbara produkten. Den här MMP:n består av de två första användarberättelserna som är måste-krav för funktion 1 samt de första användarberättelserna som är måste-krav för funktion 2 och 3.
Lansering 2 innehåller de nästa två användarberättelserna som är måste-krav för funktion 1, 2 och 3 (iterativ utveckling). Produktutvecklingen fortsätter genom att de följande lanseringarna implementeras. Kundvärdet ökar med varje lansering.
Efter lansering 5 slutar produktägaren att implementera användarberättelser. Kundens feedback visade att ABC-produkten är ‘lämplig för ändamålet’, och han tar hänsyn till Agile-manifestets princip om enkelhet och stoppar den fortsatta utvecklingen.
Kort webbinarium: Iterativ och inkrementell utveckling
Här är ett ingående webbinarium om iterativ och inkrementell programvaruutveckling.
Avslutande tankar
Har ditt programvaruutvecklingsteam en tydlig bild av iterativ och inkrementell utveckling? Hur tillämpar ni den i era agila metoder eller vattenfallsmetoder?
Berätta för oss i kommentarerna, eller gå med i vårt DPM-medlemskap och diskutera med andra medlemmar i vårt exklusiva forum!
