Hvordan forklare Agile til noen? Med en metafor

Agile programvareutvikling er litt som å dra på en backpackingtur jorden rundt. La meg forklare.

Tilpasset programvareutvikling er en ganske komplisert prosess, helt forskjellig fra enhver annen opplevelse i våre hverdagsliv.

Under mine interaksjoner med potensielle kunder, snakker jeg ofte med folk som har fantastiske ideer for sin første oppstart, men ingen tidligere erfaring med programvareutvikling. Hvis du er en av dem - er denne artikkelen for deg.

Så hvordan forklarer jeg Agile programvareutvikling på en relativt enkel måte?

Med en analogi.

I denne artikkelen vil du lære noen ting om Agile programvareutvikling:

• hva som er likhetene mellom Agile programvareutvikling og en veldig lang backpackingtur,
• hvorfor estimater er en form for en utdannet ekspertgjetning snarere enn et fast omfang & kostnadsoverslag,
• hvorfor det er umulig å forutse og planlegge alt på forhånd (og hvorfor du faktisk ikke ville ønsket å gjøre det)
• hva som er den alternative tilnærmingen (Waterfall)
• hvorfor du ikke kan sette en fast kostnad på et Agile prosjekt

Hva har en reise rundt i verden og Agile programvareutvikling til felles?

I dette tilfellet tenker jeg på den typen reise der du drar med ryggsekk for å besøke noen land halvveis rundt jorden og ønsker å se så mye som mulig, eller kanskje til og med en backpacking-reise rundt kloden.

La oss liste opp noen av de viktigste likhetene mellom reisen og skapelsen av ditt første produkt:

• Begge er ganske forskjellige fra våre vanlige kjøp eller aktiviteter
• De er ganske dyre engangssituasjoner, og du ønsker å få mest mulig ut av dem og gjøre det riktig første gang
• Begge er langvarige prosesser snarere enn enkeltkjøp
• Begge innebærer å gjøre noe unikt som sannsynligvis ingen har gjort før
• Det er umulig å vite eller planlegge alt på forhånd i begge scenarier
• Du må være forberedt på å akseptere endringer og justere planene dine underveis

En forbehold i metaforen min: du kan planlegge og dra alene på reisen din, men du kan ikke lage programvaren din selv. Du må enten rekruttere ditt eget design- og utviklingsteam eller få ekstern hjelp fra et programvareutviklingsbyrå. 

Du kan også være interessert i å lese:

Når skal du ansette et byrå for programvareutviklingen din?

Så for eksemplets skyld, la oss anta at du ikke kan (eller rett og slett ikke vil) planlegge turen selv, og du trenger ekstern hjelp. Derfor bestemmer du deg for å samarbeide med et reisebyrå som spesialiserer seg på fullt tilpassede backpacking-opplevelser. De vil hjelpe deg ikke bare med å lage reiseplanen, men også ta seg av alle formaliteter, bestillinger og utgifter mens du er ute og reiser slik at du virkelig kan fokusere på å få mest mulig ut av turen din.

Planlegging av reisen med byrået

La oss dykke dypere - hvordan ville det faktisk se ut?

Vi kan forestille oss å ha noen møter med byrået for å etablere dine forventninger, budsjett, hovedprioriteringer, forventede standarder for overnatting, land og landemerker du ønsker å besøke, og fordeler som er viktige for deg, slik at byrået kan forstå dine behov og basert på det foreslå den beste opplevelsen for deg.

På samme måte, når du snakker med en programvareutviklingspartner, vil du delta i en håndfull møter (kanskje en Product Design Workshop) hvor byrået vil diskutere dine ideer, forventninger, behov og mål og hjelpe deg med å justere planene til budsjettet ditt.

Byrået vil presentere deg for en plan eller en oversikt over hva som skal skje, gi deg forskjellige muligheter og foreslå retninger. På det tidspunktet er det et utkast med estimert tid og kostnad med høy-nivå informasjon.

I et programvareutviklingsmiljø ville dette være lik en innledende estimering. Byrået estimerer de beskrevne applikasjonens elementer og funksjoner basert på informasjonen (forretnings- og teknologimuligheter og begrensninger) som er gitt av klienten på det tidspunktet, så godt de kan forstå.

Forberedelse vs beredskap til å tilpasse seg endrede omstendigheter

La oss si at din opprinnelige reiseplan antok å besøke Japan etter å ha fullført Thailand-turen din. Men du finner deg selv fanget i Bangkok ettersom alle flyvninger til Tokyo har blitt kansellert de neste dagene. Du må justere planene dine. 

Imidlertid trenger ikke utløseren for endring å være ekstern. Kanskje du faktisk liker Bangkok så mye at du bare vil bli der lenger. Eller omvendt - kanskje du ville foretrekke å stryke noen punkter fra Thailand-listen din for å tilbringe mer tid i Tokyo? Eller kanskje, etter å ha snakket med noen lokale, innså du at det er en må-se-lokasjon i nærheten som du aldri har hørt om før, og du vil legge det til listen din?

I noen av eksemplene - dette var ikke din opprinnelige plan, men situasjonen har endret seg, og du må handle på det. Alt du trenger å gjøre er å gi byrået beskjed slik at de kan justere planene basert på tilbakemeldingen din, og raskt ta seg av alt for deg.

Det samme kan skje gjennom utviklingen av prosjektet ditt. Noen funksjoners prioriteringer kan endre seg; du kan legge til nye funksjoner eller gjøre de som opprinnelig var planlagt mer komplekse. Situasjonen på markedet kan endres og tvinge deg til å justere produktet ditt til noen nye forskrifter eller brukernes preferanser, eller du har rett og slett oversett noe.

Estimeringen du etablerte i begynnelsen er en generell veikart. Det gir en generell forståelse av omfanget, tidsrammen & kostnadene involvert, men forblir fleksibel.

Skulle noe endre seg, kan du handle og justere tidslinjen, og kostnadene og reagere deretter. Du er ikke presset til å utføre en streng plan laget når omstendighetene er forskjellige. For å si det enkelt, det lar deg ta de beste beslutningene underveis uten å binde deg til en urealistisk rigid plan fra starten av.

Med det i tankene, kan vi ikke glemme at den naturlige konsekvensen er at slike endringer også påvirker tid & kostnad. Du kan ikke forvente å bli noen dager lenger på det samme hotellet uten å forlenge reiseperioden og øke budsjettet ditt. Du må enten utvide budsjettet og tidslinjen din eller gi opp noen andre punkter på listen din for å kompensere for det. Det er akkurat den samme historien med programvareutvikling. 

Du kan også ønske å lese:

Unngå disse 4 Agile-fellene: Tips for nybegynnere

Hva er alternativet? Noen ord om Vannfall-tilnærmingen

La oss forestille oss at du ikke er komfortabel med usikkerheten i planen og kostnadene. Du ønsker en veldig fast plan for en fast kostnad. Hva gjør du da?

I stedet for å starte med en generell oversikt og være fleksibel gjennom hele reisen, må du planlegge alt på forhånd ned til den minste detalj og holde deg til det uansett hva som skjer.

Dette betyr å planlegge måneder i forveien, alle detaljer om overnatting, buss-/togbilletter, hvilke landemerker du vil se, til hvilken time, og hvor lenge. Selv hva du vil ha til frokost, lunsj og middag. Hver eneste dag og aktivitet er planlagt og fastsatt til timen, måneder før selve reisen, skrevet inn i kontrakten, uten mulighet for endring. Bare prøv å forestille deg det.

Dette (nesten) er Vannfall- og fastpris-tilnærmingen i programvareutvikling. Det er svært lite rom for justeringer, spesielt i sanntid. Du må planlegge alt i begynnelsen og deretter følge det til punkt og prikke, uansett det skiftende miljøet eller situasjonen rundt deg og produktet ditt.

Ikke bare det. I de fleste tilfeller ender Vannfall-tilnærmingen opp med å være dyrere enn Agile, og det er to hovedgrunner til dette.

Den første er risikomitigering. Å jobbe i Vannfall og fastpris betyr at byrået må kompensere for risikoene vi dekket ovenfor (interne og eksterne) for å unngå et økonomisk tap på et slikt prosjekt. Det oversettes enkelt til en hevet pris uansett om endringene faktisk skjer eller ikke eller i hvilken grad. Byrået må vurdere alle de verste mulige scenariene og sette en prislapp på det.

Den andre er ekstra arbeidsmengde og formaliteter. Ikke bare er prosjekt-dokumentasjonen før prosjektet starter uforholdsmessig mer kompleks og omfattende, men det er også kontrakten og all prosjekt-dokumentasjon og prosedyrer gjennom hele prosjektet. Hver endringsforespørsel i den opprinnelige planen krever sin egen prosess: estimering, beskrivelse og formalisering med et juridisk dokument (f.eks. Vedlegg til kontrakten, endringsforespørsel, osv.). Alle de ekstra aktivitetene utført av byrået kan virke "gratis" - de kan ikke være nevnt i tilbudet eller kontrakten, de kan bare bli høflig aldri nevnt. Men gitt at de alle tar tid, vær trygg på at de vil bli tatt med av byrået i den endelige kostnaden.

Når fungerer Waterfall?

I programvareprosjekter - i noen tilfeller, prosjekter, er dette en tilnærming som fortsatt eksisterer.

Spesielt for store selskaper og store bedrifter, som har mye større budsjetter enn oppstartseiere, og offentlig sektor, er dette en tilnærming som noen ganger fungerer. Disse typene institusjoner har også vanligvis interne kapabiliteter (sine egne spesialiserte team) som har ferdighetene, ressursene og tiden til å forberede omfattende teknisk dokumentasjon før prosjektet starter.

Den beste Waterfall programvareprosjektdokumentasjonen jeg noen gang har sett var omtrent 300 sider lang, og det var kun for front-end delen av applikasjonen. Den var så detaljert at den til og med inkluderte mockups av alle skjermene i applikasjonen med grundige og presise beskrivelser av den minste detalj (inkludert størrelsen og fargene på knappene).

Det er ganske annerledes enn Agile-tilnærmingen, hvor nøkkelen er hastighet, effektivitet og smidighet. Men for organisasjoner med tid, ressurser og budsjetter for denne tilnærmingen - kan dette faktisk fungere.

Men for å være rettferdig, ser vi flere og flere av selv de største selskapene som velger Agile i programvareutvikling for alle fordelene det gir. Jeg har personlig hatt gleden av å samarbeide med et av de store 4-selskapene om et stort Agile programvareutviklingsprosjekt. Det er ingen overraskelse - Agile er den foretrukne metoden for å utvikle moderne programvare av en grunn.

Så hvorfor ikke sette en fast pris på et Agile-prosjekt?

Jeg har personlig vært borti situasjoner der en kunde hørte om alle fordelene med Agile, men for å redusere usikkerhetene, forventet å få det pakket inn med en fast pris fra byrået.

Så flott som det høres ut, er det like motstridende som det faktisk er.

Kan du forestille deg at et backpacking reisebyrå går med på å dekke alle kostnadene dine mens du får beholde den absolutte friheten til å endre, modifisere og utvide reisen din potensielt på ubestemt tid? Det er bokstavelig talt en sjekk uten beløpsgrense.

Hvis omfanget kan endres - kan du ikke ha en definert pris. Hvis du vil definere omfanget og prisen - tar du bort fleksibiliteten og øker de totale kostnadene.

Med andre ord, å prøve å erstatte ulempene ved Agile-tilnærmingen med fordelene fra den motsatte Waterfall-tilnærmingen ville vært som å prøve å ha lysbryteren både på og av samtidig. Hvis vi kan holde kvantefysikk utenfor diskusjonen, håper jeg du kan være enig i at det rett og slett ikke er mulig.

Hvordan få mest mulig ut av Agile?

Akkurat som med referansen til backpacking-opplevelsen - start med å kjenne budsjettet ditt, den estimerte tiden & kostnadene involvert. Vær klar til å justere, og bruk denne fleksibiliteten til din fordel. Endre, justere, legge til, fjerne, erstatte. Reager underveis avhengig av de nåværende behovene og situasjonen.

Du vil kanskje også lese:

13 Fordeler med å implementere Agile

Finn et byrå du kan stole på. Et byrå som fra starten av vil ha et sterkt fokus på å forstå dine behov og mål, du vil føle at de opererer på samme frekvens som deg.

Jeg vil også anbefale deg å sørge for at byrået du velger har sterke Agile Project Management ferdigheter. Du trenger noen innen prosjektteamet som kan hjelpe deg med å spore og administrere budsjettet, og overvåke fremdriften. Eller med andre ord - å ha en person dedikert til å minimere risikoene og ulempene ved å jobbe med Agile, samtidig som man beholder alle fordelene.

Fordi, alt i alt, har Agile oppstått fra den opprinnelige Waterfall-tilnærmingen på grunn av de store problemene den sto overfor. Og dette er grunnen til at det store flertallet av programvareprosjekter i dag gjennomføres med Agile-metoder. Agile er rett og slett den billigste og mest effektive måten å lage digitale produkter på.

Sjekk også ut

• Agile: Maksimer forretningsverdien med et begrenset budsjett —  I en byråmodell for programvareutvikling er et begrenset budsjett ikke en dødsdom for prosjektet. Det er mer en realitetskontroll som avgjør om et prosjekt er økonomisk overkommelig for kunden.
• Hvordan velge den agile rammeverket for prosjektet ditt? —   Vår senior Agile prosjektleder, Paulina Piechaczek, forklarer hvordan man vurderer metoden som er best tilpasset det du har på bordet.