Et agilt prosjekt består av mange utviklings-sprinter. I starten av hver sprint velges det ut brukerhistorier (user stories) eller funksjoner som skal utvikles. Lengden på en sprint er normalt på 3 til 4 uker. Under sprintene er det vanlig med daglige korte «stand-up» møter for å avklare uklarheter og fordele oppgaver. Mot slutten av sprinten blir arbeidet som er gjort presentert gjennom den demo, dette møte heter «sprint review». Etter at koden er lastet opp til serveren gjennomføres det er «retrospektivt møte»

Hva er agile? Hva er smidig metodikk?

Sist oppdatert 27.10.2020 av Jens Christian Bang

«Agil» eller «smidig» programvareutvikling refererer til en prosjektmetodikk med raske og repeterende utviklingsfaser kalt sprinter. Funksjonskravene til programvaren, kalt brukerhistorier, utvikler seg gjennom samarbeid i selvstyrte tverrfaglige team.

Innhold på denne siden:

Agile / smidig metodikk

Agile team

Historikk: «Det agile manifestet»

Podcaster om agil metodikk

Produkt eller prosjekt?

Start et agilt prosjekt

Fossefall

Agile / smidig metodikk

Waterfall - fossefall

Fossefall er den tradisjonelle metodikken for prosjektgjennomføring. Prosjektet planlegges og spesifiseres prosjektet i detalj før utviklingen starter. Deretter gjøres utviklingsjobben i et stort stykke arbeid.

Agile team

Til smidig metodikk hører et "agilt team". I programvareutvikling kjennetegnes agile team med at de har få deltakere, de har korte leveransesykluser og at oppdragsgiver er aktivt deltakende i leveransen.

Deltakerne i et agilt team

Produkteier som ofte er oppdragsgiver
Scrum master som veileder resten av teamet
Utvikler som koder systemet
Tester som sikrer kvaliteten
UX designer og designer som produserer grensesnittet
Tech lead setter retningslinjene for arkitekturen for applikasjonen
Devop som deployerer applikasjonen «ut i skyen» tester

Medlemmene i et smidig team hjelper hverandre med å løse oppgaver. Hvis testeren har mye å gjøre kan f.eks. utvikleren hjelpe til med testing eller om scrum master har mye å gjøre kan UX designeren hjelpe til. Medlemmene i et smidig team tar solidarisk ansvar og er fokusert på felles suksess.

Historikk: «Manifestet for smidig programvareutvikling», eng. «Agile manifesto»

I 11. til 13. februar 2001 møttes 17 menn i Wasatch-fjellene i Utah. På denne fjellturen ble det agile manifestet skapt. De 17 fagfolkene innen programvareutvikling, ønsket å finne et alternativ til tunge prosesser for programvareutvikling og dokumentering. Manifestet og prinsippene er klippet fra https://agilemanifesto.org.

«Manifestet for smidig programvareutvikling»

Gjennom å tilvirke programvare selv har vi funnet en bedre utviklingsmetodikk. Metodikken har følgende verdier:

Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan

Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.

De 17 menn som skapte den agile metodikken

Illustrerer Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland og Dave Thomas fra fjellturen i Utah.

Prinsippene bak "Det smidige manifestet"

Vi følger disse prinsippene:

Vår høyeste prioritet er å tilfredsstille kunde gjennom tidlige og kontinuerlige leveranse av programvare som har verdi.
Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden.
Lever fungerende programvare hyppig med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
Forretningssiden og utviklerne må arbeide sammendaglig gjennom hele prosjektet.
Bygg prosjektet rundt motiverte personer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort.
Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt.
Fungerende programvare er det primære målet på fremdrift.
Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden.
Kontinuerlig fokus på fremragende teknisk kvalitet og godt design fremmer smidighet.
Enkelhet – kunsten å maksimere mengden arbeid som ikke blir gjort – er essensielt.
De beste arkitekturer, krav og design vokser frem fra selvstyrte team.
Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt og så justerer det adferden sin deretter.

Podcaster om agil metodikk

Produkt eller prosjekt?

Resultatet av en programvareutvikling kaller vi et produkt. Produktet kan være en programvare som skal brukes av sluttkunder eller internt i en bedrift. Programvaren kan være en webapplikasjon eller en mobilapp. I motsetning til et fysisk produkt er programvare noe som konstant videreutvikles.

Endringen av programvare fører til:

Mer funksjonalitet
Flere integrasjoner
Bedre brukergrensesnitt
Større kapasitet

Start et agilt prosjekt

Agile team leies i et gitt antall timer per rolle i en periode. Vi setter sammen et team som passer for det produktet som skal utvikles. I våre smidige team er vi opptatt av å hele tiden levere funksjonalitet. Dette gjør vi i tett samarbeid med produkteier eller oppdragsgiver.

Hva er prisen på et agilt team?

Prisen på et agilt team er avhengig av hvor stort det er og hvilke roller som deltar. Kontakt oss for en prat om omfanget på ditt agile prosjekt.

Fossefall

Fossefall. Alternativet til agile team er fossefallsmetoden (waterfall). Med fossefall planlegges og spesifiseres prosjektet i detalj før utviklingen starter. Selve utviklingsjobben er et stykke arbeid. Utfordringen med denne metoden er at det tar lang tid før produktet er ferdig og at det som er bestemt i spesifikasjonsfasen er ganske fast bestemt for selve utviklingsprosjektet.

Det høres kanskje rart ut, men produkteieren ønsker sannsynligvis ikke det samme produktet på slutten av prosjektet som hun ønsket ved begynnelsen av prosjektet. Dette kommer av læring underveis i prosjektet og at markedet forandrer seg. Det som virket som en god ide for et år siden, er helt sikkert ikke så gjennomtenkt som en ide utformet i dag. Samtidig er markedet og forutsetningene for produktet i konstant endring.

Det er fordeler med fossefall, ellers ville ikke fossefall vært foretrukne metode i mange tiår.

Forutsigbar pris. I fossefall er alt spesifisert ned til minste detalj (vi tror vi har tenkt på alt på dette tidspunktet) og ut fra det kan leverandøren gi en fastpris på oppdraget. Dette passer utmerket for virksomheter som har faste budsjetter å forholde seg til. Men også her dukker det opp noen problemer, i løpet av prosjektet vil det alltid dukke opp endringer. Dette er endrede behov, endrede ambisjoner eller endrede utenforliggende rammebetingelser. I post-evalueringen av et fossefallsprosjekt blir det alltid konkludert med at «Vi skulle brukt mer tid på planleggingen!».

Frigjøring av produkteiers tid. I fossefallsprosjekter er produkteier eller oppdragsgiver dypt involvert i spesifikasjonsperioden. Produkteier må ta stilling til alle mulige problemstillinger innen organisasjonen, markedet og teknologien. Men når utviklingen starter får produkteier fri. Da kan produkteier gjøre sine daglige sysler og kun motta statusrapporter fra utviklingsteamet. Denne beskrivelsen stigmatiserer kanskje hvordan et fossefallsprosjekt fungerer, men veldig ofte er det faktisk slik det foregår. Resultatet blir dårligere, som nevnt tidligere endrer de ytre forutsetningene seg mens utviklingsteamet jobber ufortrødent videre etter rammene i spesifikasjonen som blir mer og mer avleggs etterhvert som tiden går.