Hva er forskjellen mellom iterativ og inkrementell utvikling?
I kursene mine legger jeg ofte merke til at studentene blander sammen iterativ og inkrementell utvikling (IID). Målet med denne artikkelen er å gi en forståelse av forholdet mellom inkrementell og iterativ utvikling.
Jeg begynner med en sammenligning av en fossefalls- og en agil tilnærming, ved å bruke eksempelet med å levere en betalingsapp. Et tilhørende kort webinar om disse tilnærmingene er også inkludert. I den andre delen av denne artikkelen plasserer jeg fossefallsmodellen og agil utvikling i en matrise som viser skjæringspunktet mellom inkrementell og iterativ utvikling, og forklarer alle de fire kvadrantene i matrisen.
Agil kontra fossefallsmodellen: Utviklingen av en betalingsapp
Fossefallstilnærmingen
Hvis denne eksempelappen utvikles i henhold til en tradisjonell fossefallsmodell, kan følgende trinn observeres 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: Dette diagrammet viser en typisk livssyklus for fossefallsmodellen, med levering av en app som eksempel.
Prosjektinitiering
Det hele begynner med en prosjekteier fra markedsavdelingen, som klarte å frigjøre de nødvendige midlene til denne appen. Han antok at appen ville forbedre kundelojaliteten og tilstrømningen av nye kunder. Han så for seg tre funksjonsgrupper på høyt nivå.
Når prosjektet er godkjent, blir en prosjektleder utnevnt, og et prosjektteam settes sammen. Etter mange diskusjoner og workshop-er for innhenting av krav ble man enige om å levere en betalingsapp med 250 funksjoner. Alle disse funksjonene ble dokumentert i et omfattende og svært detaljert dokument med programvarekrav, som ble signert av prosjekteieren og kunderepresentanten (samt andre viktige interessenter).
Prosjektets designfase
I neste trinn oversetter prosjektteamet kravene til et design for appen. Arkitekten kontrollerer designet mot designprinsippene. Han sjekker også om alle nødvendige dataattributter er tilgjengelige i backend-systemet.
Vi er nå to måneder inne i prosjektet, og kunden har ennå ikke sett noe som fungerer, bare noen fremdriftsrapporter. Og disse fremdriftsrapportene innebærer sannsynligvis en form for «vannmelon»-rapportering, slik at kunden ikke har noen anelse om prosjektet er i rute eller ikke.
Prosjektets utviklingsfase
Det tar seks måneder å utvikle appen, og når den er ferdig, blir kunderepresentanten bedt om å finne noen som kan hjelpe til med en brukergodkjenningstest. Under testen blir det tydelig at flere funksjoner ikke fungerer.
Prosjektteamet forstår ikke hvorfor. Det er akkurat slik det ble beskrevet i kravdokumentet. Dette fører til mange diskusjoner, omarbeiding og forsinkelser, og kundene er ikke fornøyde med resultatene. Hvis vi dessuten ser på det endelige resultatet, vil vi kanskje legge merke til at mange av kravene som ble utviklet, ikke brukes eller sjelden brukes av kunden.
Det kunne til og med vært verre. Anta at utviklingen av appen tok 1,5 år, og at en annen bank leverer en betalingsapp når du er halvveis ferdig. Hva ville du gjort på det tidspunktet? Ville du fortsatt hatt et levedyktig forretningsgrunnlag for å fortsette og ferdigstille din egen app?
Når vi ser på figur 1, blir det tydelig at omfanget og de underliggende kvalitetskriteriene er fastsatt ved én enkelt levering i en fossefallstilnærming. Alle trinn utføres én gang for hele prosjektet, og styringen fokuserer på kostnad og tid. Verdileveransen til kunden finner først sted etter at hele appen er satt i produksjon.
Den agile tilnærmingen
Hvis vi utvikler appen ved hjelp av en agil prosjektstyringstilnærming, ser vi følgende mønster:
- Utviklingsteamet sier at de kan levere de to første funksjonene som produkteieren har prioritert, i den første iterasjonen.
- Prosjektteamet leverer et inkrement av produktet hver tredje uke (sprint, iterasjon eller tidsboks).
- Etter de første leveransene eller inkrementene ser vi en kunde som har tillit til at prosjektet vil levere. Kunden har allerede en fungerende app og forstår at ikke alle funksjonene er på plass ennå, men at funksjonene som er tilgjengelige, fungerer.
Når kunden ser på den nyeste versjonen og funksjonene som er levert, nevner kunden en helt ny funksjon. En funksjon som ingen hadde tenkt på ved prosjektets begynnelse, men som kunne gjøre kundens hverdag mer produktiv.
Etter hvert inkrement fører tilbakemeldinger fra kunden til nye funksjonelle muligheter (som ikke sto på den opprinnelige listen) eller justeringer av mulige funksjoner. Produktet blir stadig mer modent. For hvert inkrement mottar kunden en ny versjon og blir mer fornøyd.
Figur 2: Diagrammet viser den smidige utviklingssyklusen ved å bruke det samme eksempelet med levering av en app.
Hvis vi ser på figur 2, ser vi en jevn leveringsflyt innenfor en fast tidsperiode og ved bruk av permanente smidige team (dette er faste kostnader). Omfanget og de underliggende kvalitetskriteriene er fleksible (dynamiske), med hyppige små leveranser (dette er inkrementene).
Alle trinn som skal levere en funksjon eller brukerhistorie, utføres gjentatte ganger (noe som gjør prosessen iterativ) til den nødvendige kvaliteten er nådd. Ledelsens kontroll er rettet mot levering av kundeverdi. Verdi leveres til kunden etter hver distribusjon av et inkrement.
Fossefallsmetoden kontra smidig: Leveringsresultater
Hvis vi ser nærmere på de to produktene fra henholdsvis fossefallsmetoden og den smidige programvareutviklingstilnærmingen, ser vi et produkt med 250 funksjoner og en ikke særlig fornøyd kunde, samt et produkt med bare 150 funksjoner og en svært fornøyd kunde (se figur 3).
Figur 3: Dette diagrammet sammenligner forskjellene i tid, antall funksjoner og kundetilfredshet for fossefalls- og smidige tilnærminger.
Og hvis vi ser enda nærmere på produktet som ble levert gjennom den smidige tilnærmingen, ser vi bare et utvalg på 100 funksjoner fra den opprinnelige listen og 50 funksjoner som er nye eller justerte. Dette samsvarer med noen viktige prinsipper i Det smidige manifestet, blant annet:
- Enkelhet, som er kunsten å maksimere mengden arbeid som ikke utføres: bare 150 funksjoner i stedet for 250
- Ta imot endrede krav, selv sent i utviklingen: tilpass deg tilbakemeldinger fra kunden etter hver iterasjon og hvert inkrement
Smidige utviklingsprosesser utnytter endringer til kundens konkurransefortrinn (50 nye eller justerte funksjoner ble levert). Som et resultat er kunden svært fornøyd. Teamets høyeste prioritet er å tilfredsstille kunden gjennom tidlig og kontinuerlig levering av verdifulle programvaresystemer.
Kort nettseminar: Fossefallsmetoden kontra smidig levering
Her er et kort nettseminar med mer informasjon om forskjellene mellom fossefallsbasert og smidig levering.
Forskjeller mellom iterativ og inkrementell utvikling
Nå som jeg har gått gjennom forskjellene mellom en fossefallsbasert og en smidig tilnærming ved å bruke eksempelet med å lage en betalingsapp, skal jeg plassere fossefallsmetoden og smidig utvikling i en matrise som sammenligner iterativ og inkrementell utvikling.
Som et siste trinn skal jeg utdype minimumsproduktet (MVP) og det minste salgbare produktet (MMP), og vise hvor disse passer inn i de ulike tilnærmingene og et historiekart. Jeg har også inkludert et tilhørende kort nettseminar.
Matrise for iterativ og inkrementell utvikling
Som nevnt la jeg merke til at studenter ofte blander sammen iterativ og inkrementell. I figur 4 finner du fire kvadranter som er et resultat av en horisontal linje som viser inkrementell eller ikke, og en kryssende vertikal linje som viser iterativ eller ikke. Se denne YouTube-videoen for en svært enkel versjon av denne figuren.
Figur 4: Denne matrisen viser ulike utviklingstilnærminger og hvorvidt teammedlemmer som følger disse tilnærmingene, må iterere og/eller arbeide i inkrementer.
Nedre venstre kvadrant
I det nedre venstre hjørnet ser vi tilnærmingen der det verken finnes iterasjoner eller inkrementer. Dette er fossefallstilnærmingen. Alle aktiviteter (design, analyse, bygging, testing og distribusjon) utføres én gang for hele prosjektet.
I dette tilfellet ser vi én enkelt levering av sluttproduktet basert på et fast omfang. Kundeverdi kan først oppnås etter at sluttproduktet er levert. Et av hovedmålene med denne tilnærmingen er å styre kostnadene.
Nedre høyre kvadrant
I den nedre høyre kvadranten ser vi en inkrementell tilnærming uten iterasjoner. Dette er en trinnvis eller inkrementell levering av mindre deler av produktet. Alle aktiviteter for et gitt trinn (design, analyse, utvikling, testing og utrulling) utføres én gang.
Innenfor et gitt trinn er omfanget fast, men hele produktet er basert på et mer dynamisk eller fleksibelt omfang. Kundeverdi kan oppnås etter hver levering av produktet. Et av hovedmålene med denne tilnærmingen er rask levering.
Øvre venstre kvadrant
I den øvre venstre kvadranten ser vi en spiralformet eller iterativ tilnærming uten inkrementer. Dette er én enkelt levering der sluttproduktet skapes gjennom flere iterasjoner. Et godt eksempel på denne tilnærmingen er designtenkning. I diagrammet ser du en sekvens av aktivitetene innramming, analyse, idégenerering, realisering og refleksjon.
Denne sekvensen gjennomføres gjentatte ganger eller iterativt, og i hver iterasjon kommer du nærmere det endelige, korrekte eller nødvendige produktet. I mange tilfeller er dette sluttproduktet en prototype eller modell. I denne spiralformede tilnærmingen har vi et dynamisk eller fleksibelt omfang. Kundeverdi kan først oppnås etter leveringen av sluttproduktet. Et av hovedmålene med denne tilnærmingen er at løsningen skal være korrekt.
Øvre høyre kvadrant
I den øvre høyre kvadranten ser vi den smidige tilnærmingen, som bruker inkrementer og en iterativ metode. Scrum er et godt eksempel på denne tilnærmingen.
På slutten av hvert inkrement, som ofte kalles en sprint eller tidsboks, leveres et inkrement av produktet. Dette inkrementet er resultatet av mange iterasjoner for å utvikle små, men korrekte deler av produktet, ofte kalt brukerhistorier eller elementer i produktkøen. Det endelige iterative prosjektet leveres del for del.
I denne smidige tilnærmingen har vi et dynamisk eller fleksibelt omfang. Kundeverdi kan oppnås etter hver levering av produktet. Et av hovedmålene med denne tilnærmingen er kundeverdi gjennom hyppige leveranser og tilbakemeldinger fra brukerne.
MVP eller MMP?
I figur 4 finner du også akronymene MVP og MMP. MVP står for minimum levedyktige produkt og er en versjon av et nytt produkt eller en ny tjeneste som gjør det mulig for et team å samle inn mest mulig læring om kundene og få validering med minst mulig innsats. MVP-en for Dropbox-tjenesten var en enkel film. Dette betyr at P-en i MVP kan være et helt annet produkt enn det som til slutt blir sluttproduktet.
Et eksempel som illustrerer MVP og MMP
Jeg bruker ofte følgende eksempel på et nytt finansielt produkt. En entusiastisk salgssjef har en god idé om et nytt finansielt produkt. Han tror at de kan selge minst 100 000 av disse produktene.
Sammen med noen finansieringseksperter utformer de produktet i løpet av et par måneder. Et utviklingsteam blir satt på oppgaven, og det tar dem 4 måneder å utvikle produktet. Parallelt utvikles kommersielle brosjyrer, og produktet lanseres med et stort arrangement.
Det er dessverre bare noen få som kjøper produktet. Hvis vi følger MVP-tilnærmingen, kan vi anta at 10 % av nettbrukerne deres er interessert i dette produktet. Deretter ville vi utviklet en MVP for å teste denne hypotesen.
I dette tilfellet kan MVP-en være en enkel knapp på hjemmesiden. Hvis du klikker på den, får du opp et skjermbilde med en melding om dette nye produktet og muligheten til å legge inn e-postadressen din hvis du er interessert. Hvis mindre enn 1 % av de besøkende trykket på knappen, ville produktet ikke blitt utviklet, og selskapet ville spart mange knappe ressurser.
Hvis vi ser nærmere på figur 4, ser vi at MVP-er potensielt kan brukes i alle kvadrantene. Når du bruker en fossefallsmodell, kan du opprette en MVP i den første programvaredesignfasen for å undersøke om prosjektet har en forretningsmessig begrunnelse.
Det samme kan gjøres i den første fasen av det første inkrementet når du følger en trinnvis leveranse. I noen tilfeller kan resultatet av designtenkningstilnærmingen være en MVP. MVP-en kan også være nyttig i begynnelsen av en smidig tilnærming.
Mange ser på det første produktet som leveres på slutten av den trinnvise leveransen, som MVP-en. Det kan være tilfelle, men i de fleste tilfeller er dette ikke en MVP, men en MMP. MMP, eller minimum salgbare produkt, er det minste produktet som kan skape verdi for kunden.
Hvordan ser smidig levering ut?
Nå som det er tydelig at inkrementelle modeller og iterative modeller ikke er det samme, og vi forstår bruken av MVP og MMP, kan vi se nærmere på hvordan inkrementell og iterativ levering foregår.
Du har sannsynligvis sett Jeff Pattons berømte eksempel med Mona Lisa, der maleriet skapes del for del (trinnvis levering). En annen måte å gjøre dette på er å begynne med det første inkrementet, der det bare lages en grov skisse, og der flere detaljer legges til skissen i hver nye iterasjon, inntil du til slutt har det ferdige maleriet (inkrementell og iterativ eller smidig levering).
I den første situasjonen må du allerede ha en detaljert idé om sluttproduktet, mens du i den andre situasjonen bare trenger en skisse på høyt nivå, ettersom endringer er mye enklere å gjøre. Hvis vi ser på figur 5, ser vi et historiekart for et nytt produkt kalt ABC.
Figur 5: Et eksempel på et storykart for et spesifikt eksempelprodukt.
Produkteieren så for seg sju funksjoner for dette produktet. De fire første funksjonene er absolutte krav. Funksjon 5 og 6 er bør-krav, og den siste funksjonen er et kan-krav. Mange vil kalle dette MoSCoW-prioritering (absolutte krav, bør-krav, kan-krav og krav som ikke skal inkluderes).
Hver funksjon kan i seg selv deles opp i mindre deler. I figuren ser du funksjoner eller brukerhistorier med absolutte krav, bør-krav og kan-krav. En funksjon kan være et absolutt krav, men det betyr ikke at alle de underliggende brukerhistoriene også er absolutte krav. Eller en funksjon kan være et bør-krav, men hvis du implementerer denne funksjonen, er noen brukerhistorier absolutte krav, mens andre er bør- eller kan-krav.
For å implementere dette ABC-produktet ser du fem inkrementer eller utgivelser. Den første er det minste markedsførbare produktet. Dette MMP-et består av de to første brukerhistoriene som er absolutte krav, i funksjon 1, samt de første brukerhistoriene som er absolutte krav, i funksjon 2 og 3.
Utgivelse 2 inneholder de to neste brukerhistoriene som er absolutte krav, i funksjon 1, 2 og 3 (iterativ utvikling). Produktutviklingen fortsetter ved å implementere de neste utgivelsene. Med hver utgivelse øker kundeverdien.
Etter utgivelse 5 slutter produkteieren å implementere brukerhistorier. Tilbakemeldinger fra kunden viste ham at ABC-produktet er «egnet til formålet», og han tar Agile-manifestets prinsipp om enkelhet i betraktning og avslutter den videre utviklingen.
Kort webinar: Iterativ og inkrementell utvikling
Her er et grundig webinar om iterativ og inkrementell programvareutvikling.
Avsluttende tanker
Har programvareutviklingsteamet ditt en klar forståelse av iterativ og inkrementell utvikling? Hvordan anvender dere dette i de smidige metodene eller fossefallsmetodene deres?
Fortell oss det i kommentarfeltet, eller bli med i DPM-medlemskapet og diskuter med andre medlemmer i vårt eksklusive forum!
