8.3 Prosjektplanlegging og smidig utvikling

Prosjektplanlegging og smidig utvikling

Når du skal lage eit digitalt produkt – anten det er ei nettside, ein app eller eit anna program – treng du meir enn berre kodingsferdigheiter. Du treng ein plan. Korleis organiserer du arbeidet? Kva gjer du først? Korleis handterer du endringar undervegs? Og korleis syter du for at det du lagar faktisk er noko brukarane treng?

Tradisjonelt blei IT-prosjekt planlagde i detalj på førehand, med lange kravspesifikasjonar som skildra alt som skulle lagast. Problemet var at krava ofte endra seg, og når produktet endeleg var ferdig etter månader eller år, var det ikkje lenger det brukarane trong. Denne tilnærminga blir kalla fossefallsmetoden fordi arbeidet flyt nedover som ein foss – frå krav til design til utvikling til testing – utan å gå tilbake.

Smidig utvikling (agile) er svaret på desse problema. I staden for å planleggje alt på førehand, jobbar du i korte syklusar der du leverer fungerande delar av produktet, samlar tilbakemeldingar og tilpassar planen undervegs. I dette kapittelet skal vi lære om dei mest brukte smidige metodane: Scrum og Kanban.

Fossefallsmetoden vs. smidig utvikling

For å forstå kvifor smidig utvikling er blitt dominerande, er det nyttig å samanlikne med den tradisjonelle fossefallsmetoden.

Fossefallsmetoden

Fossefallsmetoden organiserer prosjektet i sekvensielle fasar:

1. Kravinnsamling – Alle krav blir definerte i detalj på førehand
2. Design – Systemet blir designa basert på krava
3. Implementering – Koden blir skriven
4. Testing – Produktet blir testa mot krava
5. Lansering – Produktet blir levert til kunden
6. Vedlikehald – Feil blir retta og oppdateringar blir gjorde

Kvar fase skal fullførast før neste byrjar. Fordelar: tydeleg struktur, lett å planleggje budsjett og tidsbruk. Ulemper: vanskeleg å handtere endringar, brukarane ser ikkje produktet før seint i prosessen, feil blir oppdaga seint.

Smidig utvikling

Smidig utvikling jobbar i korte syklusar (iterasjonar):

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

Fordelar: tidleg og hyppig levering, enklare å tilpasse seg endringar, risiko blir oppdaga tidleg. Ulemper: krev tett kommunikasjon, kan vere vanskeleg å estimere total tid og kostnad.

I dag bruker dei fleste IT-selskap ei form for smidig utvikling. Fossefallsmetoden blir framleis brukt i prosjekt med svært tydelege og uforanderlege krav, som bygging av bruer eller fly.

Scrum i praksis

Scrum er det mest utbreidde rammeverket for smidig utvikling. Det organiserer arbeidet i korte sprintar (vanlegvis 2 veker) der teamet leverer ein fungerande del av produktet.

Roller i Scrum

Product Owner (PO): Ansvarleg for kva som skal lagast. Eig produktkøen (backlog), prioriterer oppgåver basert på forretningsverdi, og representerer behova til brukarane. PO-en bestemmer kva funksjonar som er viktigast.

Scrum Master (SM): Ansvarleg for at Scrum-prosessen fungerer. Fjernar hindringar for teamet, fasiliterer møte og vernar teamet mot forstyrringar. Scrum Master er ikkje ein sjef, men ein servant-leader som hjelper teamet å jobbe effektivt.

Utviklingsteamet: Tverrfagleg team (vanlegvis 3-9 personar) som gjer sjølve arbeidet – designarar, utviklarar, testarar. Teamet er sjølvorganiserande og bestemmer sjølv korleis oppgåvene blir løyste.

Scrum-seremoniar (møte)

Sprint Planning: Møte i starten av kvar sprint der teamet vel oppgåver frå produktkøen og planlegg arbeidet for sprinten. Resultatet er eit sprint-mål og ein sprint-backlog.

Daily Stand-up: Kort dagleg møte (15 minutt) der kvart teammedlem svarar på: Kva gjorde eg i går? Kva skal eg gjere i dag? Har eg nokre hindringar?

Sprint Review: Møte på slutten av sprinten der teamet demonstrerer det dei har laga for Product Owner og andre interessentar. Tilbakemeldingar blir noterte for framtidig arbeid.

Sprint Retrospektiv: Møte der teamet reflekterer over prosessen: Kva fungerte bra? Kva kan forbetrast? Kva skal vi gjere annleis neste sprint?

Sprint-syklus

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

Kanban – visuell arbeidsstyring

Kanban er ein enklare metode enn Scrum som fokuserer på å visualisere arbeidsflyten. Ei Kanban-tavle er eit verktøy der oppgåver blir representerte som kort som blir flytta gjennom kolonnar:

+----------------+----------------+----------------+----------------+
|  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)

Eit sentralt prinsipp i Kanban er å avgrense talet på oppgåver som er under arbeid samtidig. Om du har ei WIP-grense på 2 for «Under arbeid»-kolonnen, kan ikkje teamet starte ei tredje oppgåve før ei av dei to pågåande er ferdig. Dette hindrar multitasking (som reduserer effektiviteten) og tvingar teamet til å fullføre oppgåver før dei startar nye.

Verktøy for Kanban

- Trello – Gratis og enkelt, perfekt for skuleprosjekt
- GitHub Projects – Integrert med GitHub, fint for kodeprosjekt
- Jira – Blir brukt mykje i profesjonelle IT-selskap
- Fysisk tavle – Post-it-lappar på ein whiteboard fungerer utmerkt

For skuleprosjekt blir anten Trello eller GitHub Projects anbefalt, som begge er gratis og enkle å komme i gang med.

MVP – start med det viktigaste

Eit vanleg problem i IT-prosjekt er å prøve å lage alt på éin gong. Du har ein stor idé, du vil ha alle funksjonane, og du endar opp med eit halvferdig produkt der ingenting fungerer ordentleg. MVP (Minimum Viable Product) er løysinga på dette.

Eit MVP er den enklaste versjonen av produktet ditt som gir verdi til brukarane. Det er ikkje ein halvferdig versjon – det er ein komplett versjon med berre dei mest essensielle funksjonane.

Døme: MVP for ei nettavis

Full visjon: Nettavis med artiklar, kommentarar, brukarprofilar, nyheitsbrev, podkast, videoinnhald, personalisert forside, push-varsel, delefunksjonar og annonsesystem.

MVP: Nettavis med artiklar organiserte etter kategori, og ei enkel forside som viser dei nyaste artiklane.

Med MVP-en kan du:
- Teste om folk er interesserte i innhaldet ditt
- Lære kva brukarane saknar (kanskje dei vil ha søkjefunksjon, ikkje kommentarar)
- Lansere raskt og forbetre basert på tilbakemeldingar

MVP i eit skuleprosjekt

Når du har eit skuleprosjekt med avgrensa tid, er MVP-tenking spesielt nyttig:

1. List opp alle funksjonane du ønskjer i produktet
2. Prioriter: Kva er absolutt nødvendig for at produktet skal fungere?
3. Definer MVP: Dei 3-5 viktigaste funksjonane
4. Bygg MVP først – syt for at desse fungerer skikkeleg
5. Legg til fleire funksjonar om det er tid igjen

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

Oppsummering

I dette kapittelet har du lært:

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

Nøkkelomgrep