Når dere har lagd en kravspesifikasjon er det fortsatt en del å gjøre før dere kan starte på selve prosjektet. Kravspesifikasjonen sier noe om hvordan det endelige produktet skal fungere, men den sier ikke noe om hvordan dere skal lage det. For å finne ut av det må dere lage en produktbacklog. Dette er en liste over alle de konkrete oppgavene dere må gjøre for å realisere produktet.
Som et eksempel skal vi se for oss at vi skal lage en web-app der brukerne kan lage ulike topp 5-lister ned f.eks. sine favorittsanger, favorittfilmer, tv-serier, band eller lignende. Vi kan da se for oss følgende kravspesifikasjon:
Det første man gjør når man skal gå fra kravspesifikasjon til produktbacklog er å identifisere hovedtemaene. I softwareutvikling kalles dette ofte Epics. En Epic er et stort mål som inneholder mange små oppgaver. Da ser man på både funksjonelle og ikke-funksjonelle krav i kravspesifikasjonen og slår sammen de som hører til under samme tema. I eksempelet vårt over kan vi trekke ut FK1 (brukerregistrering) og IFK3 (sikkerhet) til en Epic vil kaller Autentisering. FK2 (opprettelse), FK4 (redigering) og FK7 (kategorier) blir til Epic: Listehåndtering.
Når vi har identifisert alle epics skal vi bryte ned disse til enkeltoppgaver. Vi tar utgangspunkt i hva en bruker skal kunne gjøre i appen og lager brukerhistorier. En brukerhistorie ser sånn ut:
"Som en [type bruker] vil jeg [handling], slik at jeg [gevinst]"
For eksempel:
Når vi har lagd brukerhistoriene må vi finne ut hvilke spesifikke oppgaver som må gjøres for å oppfylle hver enkelt brukerhistorie. Hver av brukerhistoriene trenger mest sannsynlig både elementer fra frontend, backend og database. Vi må derfor bryte ned historiene.
Brukerhistorien "Som en bruker vil jeg logge inn, slik at jeg kan se mine lagrede lister" krever at vi har registrert brukere og lagret lister i en database, at vi har en innloggingsside og et skjema for å legge inn lister. Dette kan vi bryte ned slik:
Når vi har brutt ned alle Epics og har en lang liste med korte oppgaver, kan vi samle alle disse i en backlog. Hver oppgave i backlogen skal være sånn at en person kan gjennomføre oppgaven alene i løpet av en eller to dager.
Nå kan vi legge inn oppgavene i backlogen i Github-repoen vår, som Issues. Da blir det enkelt for hele teamet å se hva som må gjøres, og man kan se status på oppgavene om de er gjort, og av hvem.
Det er vanlig å tenke at man skal starte med å lage en versjon av det endelige produktet som fungerer som en fullstendig app, men som har med kun de absolutt nødvendige funksjonene. Målet er å lage en smal, men fungerende versjon av skuttproduktet som kan tas i bruk med en gang. Etter dette fortsetter man å videreutvikle produktet til man fullfører alle funksjonene man har planlagt i kravspesifikasjonen.
Målet med en MVP er at man kan bruke denne til å faktisk finne ut om folk vil bruke den ferdige appen - man sjekker om ideen var god, uten at man har brukt mye tid på å perfeksjonere en fullstendig app.
I eksempelet med topp 5-appen kan vi lage en MVP ved å starte med kun FK1, FK2 og FK4 og lage en fullstendig app som dekker disse tre kravene. Legg merke til at MVP skal være brukbart, så man må fortsatt ha en ferdig designet app med både frontend og backend som fungerer. Vi har da en app med nok funksjoner til at den kan testes, men som kan bygges ut senere.
Når vi lager programvare eller nettsider, er det ikke nok å bare skrive koden. Vi må også kunne d...
© 2024 • Contents under CC-BY-NC • Maintained by Karl Arne Dalsaune