8.3 Prosjektplanlegging og smidig utvikling

Prosjektplanlegging og smidig utvikling

Når du skal lage et digitalt produkt – enten det er en nettside, en app eller et annet program – trenger du mer enn bare kodingsferdigheter. Du trenger en plan. Hvordan organiserer du arbeidet? Hva gjør du først? Hvordan håndterer du endringer underveis? Og hvordan sørger du for at det du lager faktisk er noe brukerne trenger?

Tradisjonelt ble IT-prosjekter planlagt i detalj på forhånd, med lange kravspesifikasjoner som beskrev alt som skulle lages. Problemet var at kravene ofte endret seg, og når produktet endelig var ferdig etter måneder eller år, var det ikke lenger det brukerne trengte. Denne tilnærmingen kalles fossefallsmetoden fordi arbeidet flyter nedover som en foss – fra krav til design til utvikling til testing – uten å gå tilbake.

Smidig utvikling (agile) er svaret på disse problemene. I stedet for å planlegge alt på forhånd, jobber du i korte sykluser der du leverer fungerende deler av produktet, samler tilbakemeldinger og tilpasser planen underveis. I dette kapittelet skal vi lære om de mest brukte smidige metodene: Scrum og Kanban.

Fossefallsmetoden vs. smidig utvikling

For å forstå hvorfor smidig utvikling er blitt dominerende, er det nyttig å sammenligne med den tradisjonelle fossefallsmetoden.

Fossefallsmetoden

Fossefallsmetoden organiserer prosjektet i sekvensielle faser:

1. Kravinnsamling – Alle krav defineres i detalj på forhånd
2. Design – Systemet designes basert på kravene
3. Implementering – Koden skrives
4. Testing – Produktet testes mot kravene
5. Lansering – Produktet leveres til kunden
6. Vedlikehold – Feil rettes og oppdateringer gjøres

Hver fase skal fullføres før neste begynner. Fordeler: tydelig struktur, lett å planlegge budsjett og tidsbruk. Ulemper: vanskelig å håndtere endringer, brukerne ser ikke produktet før sent i prosessen, feil oppdages sent.

Smidig utvikling

Smidig utvikling jobber i korte sykluser (iterasjoner):

1. Planlegg en liten del av produktet
2. Bygg denne delen
3. Test med ekte brukere
4. Lær fra tilbakemeldingene
5. Gjenta – planlegg neste del basert på det du har lært

Fordeler: tidlig og hyppig levering, enklere å tilpasse seg endringer, risiko oppdages tidlig. Ulemper: krever tett kommunikasjon, kan være vanskelig å estimere total tid og kostnad.

I dag bruker de fleste IT-selskaper en form for smidig utvikling. Fossefallsmetoden brukes fortsatt i prosjekter med svært tydelige og uforanderlige krav, som bygging av broer eller fly.

Scrum i praksis

Scrum er det mest utbredte rammeverket for smidig utvikling. Det organiserer arbeidet i korte sprinter (vanligvis 2 uker) der teamet leverer en fungerende del av produktet.

Roller i Scrum

Product Owner (PO): Ansvarlig for hva som skal lages. Eier produktkøen (backlog), prioriterer oppgaver basert på forretningsverdi, og representerer brukernes behov. PO-en bestemmer hvilke funksjoner som er viktigst.

Scrum Master (SM): Ansvarlig for at Scrum-prosessen fungerer. Fjerner hindringer for teamet, fasiliterer møter og beskytter teamet mot forstyrrelser. Scrum Master er ikke en sjef, men en servant-leader som hjelper teamet å jobbe effektivt.

Utviklingsteamet: Tverrfaglig team (vanligvis 3-9 personer) som gjør selve arbeidet – designere, utviklere, testere. Teamet er selvorganiserende og bestemmer selv hvordan oppgavene løses.

Scrum-seremonier (møter)

Sprint Planning: Møte i starten av hver sprint der teamet velger oppgaver fra produktkøen og planlegger arbeidet for sprinten. Resultatet er et sprint-mål og en sprint-backlog.

Daily Stand-up: Kort daglig møte (15 minutter) der hvert teammedlem svarer på: Hva gjorde jeg i går? Hva skal jeg gjøre i dag? Har jeg noen hindringer?

Sprint Review: Møte på slutten av sprinten der teamet demonstrerer det de har laget for Product Owner og andre interessenter. Tilbakemeldinger noteres for fremtidig arbeid.

Sprint Retrospektiv: Møte der teamet reflekterer over prosessen: Hva fungerte bra? Hva kan forbedres? Hva skal vi gjøre annerledes neste sprint?

Sprint-syklus

Sprint Planning --> Daglig arbeid (med Daily Stand-ups) --> Sprint Review --> Retrospektiv
     ^                                                                          |
     +--------------------------------------------------------------------------+
                            (Ny sprint starter)

Kanban – visuell arbeidsstyring

Kanban er en enklere metode enn Scrum som fokuserer på å visualisere arbeidsflyten. En Kanban-tavle er et verktøy der oppgaver representeres som kort som flyttes gjennom kolonner:

+----------------+----------------+----------------+----------------+
|  A gjore       |  Under         |  Testing       |  Ferdig        |
|  (To Do)       |  arbeid        |  (Review)      |  (Done)        |
|                |  (In Progress) |                |                |
+----------------+----------------+----------------+----------------+
| [Lage logo]    | [Design        | [Login-        | [Database-     |
|                |  forside]      |  side]         |  oppsett]      |
| [Feilmelding   |                |                |                |
|  ved login]    | [Bruker-       |                | [Wireframes]   |
|                |  profil]       |                |                |
| [Soke-         |                |                |                |
|  funksjon]     |                |                |                |
+----------------+----------------+----------------+----------------+

WIP-grense (Work In Progress)

Et sentralt prinsipp i Kanban er å begrense antall oppgaver som er under arbeid samtidig. Hvis du har en WIP-grense på 2 for «Under arbeid»-kolonnen, kan ikke teamet starte en tredje oppgave for en av de to pågående er ferdig. Dette forhindrer multitasking (som reduserer effektiviteten) og tvinger teamet til å fullføre oppgaver for de starter nye.

Verktøy for Kanban

- Trello – Gratis og enkelt, perfekt for skoleprosjekter
- GitHub Projects – Integrert med GitHub, fint for kodeprosjekter
- Jira – Brukes mye i profesjonelle IT-selskaper
- Fysisk tavle – Post-it-lapper på en whiteboard fungerer utmerket

For skoleprosjekter anbefales enten Trello eller GitHub Projects, som begge er gratis og enkle å komme i gang med.

MVP – start med det viktigste

Et vanlig problem i IT-prosjekter er å prøve å lage alt på én gang. Du har en stor idé, du vil ha alle funksjonene, og du ender opp med et halvferdig produkt der ingenting fungerer ordentlig. MVP (Minimum Viable Product) er løsningen på dette.

Et MVP er den enkleste versjonen av produktet ditt som gir verdi til brukerne. Det er ikke en halvferdig versjon – det er en komplett versjon med bare de mest essensielle funksjonene.

Eksempel: MVP for en nettavis

Full visjon: Nettavis med artikler, kommentarer, brukerprofiler, nyhetsbrev, podcast, videoinnhold, personalisert forside, push-varsler, delefunksjoner og annonsesystem.

MVP: Nettavis med artikler organisert etter kategori, og en enkel forside som viser de nyeste artiklene.

Med MVP-en kan du:
- Teste om folk er interessert i innholdet ditt
- Lære hva brukerne savner (kanskje de vil ha søkefunksjon, ikke kommentarer)
- Lansere raskt og forbedre basert på tilbakemeldinger

MVP i et skoleprosjekt

Når du har et skoleprosjekt med begrenset tid, er MVP-tenking spesielt nyttig:

1. List opp alle funksjonene du ønsker i produktet
2. Prioriter: Hva er absolutt nødvendig for at produktet skal fungere?
3. Definer MVP: De 3-5 viktigste funksjonene
4. Bygg MVP først – sørg for at disse fungerer skikkelig
5. Legg til flere funksjoner hvis det er tid igjen

Det er alltid bedre å ha et lite produkt som fungerer perfekt, enn et stort produkt fullt av feil.

Oppsummering

I dette kapittelet har du lært:

- Smidig utvikling (Agile): fleksibel utvikling med hyppige leveranser.
- Fossefall vs. smidig: sekvensiell mot iterativ metode.
- Scrum: roller, seremonier og sprinter.
- Kanban: visuell arbeidsstyring med WIP-grenser.
- MVP: minste brukbare produkt.

Noekkelbegreper