6.5 En sprinthistorie

Alle teammedlemmene lager en markør som skal brukes til å vise hvilken oppgave de jobber med. Hvis det er en tusjtavle, bruker de gjerne en magnet som er litt større enn en tjuekroning, slik at de kan feste et portrettbilde eller skrive navnet sitt på den. Er tavla ikke magnetisk, finner de på noe annet.

Når teamet har bestemt seg for hvilke oppgaver de skal jobbe med, skriver de en kort beskrivelse av hver oppgave på atskilte lapper, for eksempel «Designe navigasjonsmeny», «Kode innloggingssiden», «Sette opp brukerdatabase» og «Legge inn eksempelartikkel». Oppgavene på hver lapp bør være så små at ett teammedlem alene (eller to som samarbeider) kan løse dem på kort tid uten hjelp fra noen andre. Hvis oppgaven på en lapp virker for omfattende eller tidkrevende, prøver teamet å dele den opp i flere oppgaver (og lapper). Hvis et teammedlem først oppdager dette når hun begynner å jobbe med en oppgave, deler hun den opp der og da. Når teamet er ferdig med å skrive lappene, fester de dem i kolonnen «Skal gjøres». Tavla bør være plassert slik at alle teammedlemmene kan se den mens de jobber. På den måten blir den et samlingspunkt for teamet.

Når et teammedlem skal ta en oppgave, flytter det lappen fra «Skal gjøres» til «Gjøres» og fester markøren sin på lappen. Når medlemmet er ferdig med oppgaven, flytter det lappen til «Ferdig» og tar en ny lapp fra «Skal gjøres»-kolonnen. Slik gjentar teammedlemmene prosessen til alle lappene er flyttet til «Ferdig»-kolonnen.

Det er gøy å bruke en oppgavetavle. Alle i teamet har oversikt over fremdriften i prosjektet, og det er lett å se hvordan oppgavene gradvis blir ferdige. I tillegg er det lett å se hva hver enkelt holder på med. Og siden hvert teammedlem bare har én markør, unngår man at folk holder av de morsomste oppgavene til seg selv.

DIGITAL OPPGAVETAVLE

I de senere årene har det blitt stadig vanligere at teammedlemmer ikke sitter fysisk sammen i et felles arbeidsrom. Noen har kanskje hjemmekontor, og enkelte team har til og med medlemmer som befinner seg i andre land. Da er det ikke hensiktsmessig å ha en fysisk oppgavetavle. Men det finnes digitale oppgavetavler som gjør den samme jobben som fysiske oppgavetavler. Også team der alle medlemmene sitter sammen, kan av ulike grunner foretrekke å ha en digital oppgavetavle.

EKSTRASTOFF

Det enkle er ofte det beste

Ofte har prosjekter flere enn én kolonne mellom «Skal gjøres»- og «Ferdig»-kolonnene. Disse kolonnene representerer gjerne flere understeg av «Gjøres», for eksempel «Kodes», «Kvalitetssikres», «Testes», «Venter på hjelp» og så videre. Hvis oppgavetavla blir så avansert at teammedlemmene glemmer å flytte lappen sin eller er usikre på hvor en lapp hører til, synker tavlas verdi. Derfor anbefaler vi at man ikke legger til flere kolonner i midten enn «Gjøres»kolonnen, med mindre det faktisk skaper problemer for teamet at tavla bare har én kolonne i midten.

En digital oppgavetavle kan brukes på samme måte som en fysisk tavle, men den byr som regel på noen ekstra muligheter. Vi kan for eksempel ofte skrive lengre kommentarer på lappene, som blir synlige hvis vi klikker på dem, og noen ganger kan vi legge ved filer. Hvis vi hadde en «Kode innloggingssiden»-lapp, kunne vi for eksempel ha lagt ved skissen til koden.

Hvis vi skriver kommentarer på lappene, kan vi for eksempel si fra om at vi står fast og trenger hjelp, eller om at vi er usikre på om vi skal velge ett eller flere alternativer. For å løse slike problemer må vi ofte ha en samtale. Det er nyttig å kunne si fra om behovet for en samtale og legge frem «saksmateriale» til samtalen på forhånd.

En oppgavetavle har kolonner for oppgaver som skal gjøres, oppgaver som pågår, og oppgaver som er ferdige. Tavla kan være fysisk eller digital. Oppgavene skrives på en lapp eller i en boks som kan flyttes mellom kolonnene. På den måten får teamet oversikt over hva som skal gjøres, hva de andre jobber med, og hvilke oppgaver som er ferdige.

Digitale oppgavetavler: • Trello • Asana • Microsoft Planner

EKSTRASTOFF

Datasikkerhet og personvern for prosjektstyringsverktøy

Når vi bruker digitale oppgavetavler og andre prosjektverktøy, lagres dataene så å si alltid på et datasenter utenfor Norge. De som har tilgang til datasenteret, har som regel mulighet til å se hva vi skriver, og regjeringen i landet der datasenteret ligger, kan kreve å få overlevert dataene uten en spesiell grunn. Selv i demokratiske land er det juridiske vernet av andre enn landets egne borgere ganske svakt. Som skoleelev har du ikke det samme juridiske ansvaret for å behandle personopplysninger trygt som du ville hatt om du jobbet for en bedrift. Du jobber heller ikke med informasjon som er forretningssensitiv. Hvis du etablerer en bedrift, for eksempel et enkeltpersonsforetak, for å tjene penger på koden din, må du derimot ta hensyn til personvernregler når det gjelder brukerne dine. I tillegg må du sørge for at oppdragsgiveren din er innforstått med konsekvensene av at du lagrer data som angår forretningen deres, i utlandet. Hvis du lager en hjemmeside for en kafé, har det neppe like mye å si som om du jobber for en advokat eller en lege, men kundene skal i alle tilfeller ha kontroll over opplysningene sine. Da må du være på den sikre siden.

I dette delkapittelet skal vi se nærmere på de ulike stegene i en sprint gjennom et tenkt prosjekt med tre teammedlemmer: Alice (produkteier), Bob og Christine (vanlige teammedlemmer). Alice, Bob og Christine har tatt IT2 sammen og har bestemt seg for å tjene penger på å lage nettsider mens de tar et friår etter videregående. De har laget en bedrift de kaller Kodemagi.

Kodemagi har spredd budskapet om planene sine blant folk de kjenner. Etter noen dager tar daglig leder ved konsertscenen Dunken kontakt. Han ønsker å bestille en hjemmeside. Dermed har Kodemagi fått sitt første oppdrag.

OPPDRAGSGIVEREN

Oppdragsgiveren er daglig leder ved Dunken, som er en populær konsertscene i nærområdet. Han heter Abdi og er 35 år gammel. Abdi har ikke hatt en egen hjemmeside for Dunken før. I stedet har han hatt kontakt med publikum via en sosial medieplattform. Tidligere fikk alle som hadde likt Dunkens side, opp innlegg om arrangementer i feeden sin uten at Abdi trengte å betale for det. Nå har imidlertid selskapet bak plattformen besluttet å ta betalt for å vise disse postene, så Abdi vil prøve å ha kontakt med publikum uten et mellomledd. Han har lyst til å se om en egen hjemmeside kan ha en positiv effekt.

OPPDRAGET

Kodemagi har fått i oppdrag å lage hjemmesiden til konsertscenen Dunken. Dunken, som har plass til 200 publikummere, har litt av hvert på programmet:

• • • • På kveldene kan det være en DJ eller et band på scenen. Av og til er en standupkomiker innom. Noen ganger har det lokale koret øvinger. Det er mulig å leie lokalet til private arrangementer.

Oppdragsgiveren har ikke lyst til å bruke for mye penger på hjemmesiden – bare noen få tusen i utgangspunktet. Derfor blir oppdragsgiveren og Kodemagi enige om at Kodemagi skal eie opphavsretten til koden, slik at de kan selge produktet videre til andre konsertscener eller bedrifter senere.

Teamet har gjort det klart for Abdi at de er interessert i å ta på seg andre oppdrag når de er ferdige med dette oppdraget. Dersom han vil vedlikeholde hjemmesiden, må han altså gjøre det selv. Abdi forstår HTML og JSON, så han har sannsynligvis nok kunnskap til å legge ut innhold på hjemmesiden når den er ferdig.

De blir enige om en sprintlengde på én uke, slik at interessentene kan gi tilbakemelding raskt.

BRUKERE

Abdi og Kodemagi er enige om at hjemmesiden har tre hovedbrukergrupper:

• • • publikum – de som besøker en konsert promotører – de som booker inn artister til konserter private arrangører – de som vil leie lokalet til et privat arrangement

INTERESSENTER

Abdi mener at han selv kjenner promotører og private arrangører godt nok til å vite hva de ønsker seg.

Abdi foreslår at en av interessentene kan være 22 år gamle Jenny. Jenny er dørvakt og vekter på mange av arrangementene på kveldstid. Hun studerer på dagtid og er en ivrig konsertgjenger. Hun representerer dermed en av de viktigste brukergruppene: publikum.

DET FØRSTE MØTET MED INTERESSENTENE

Alice møter Abdi og Jenny på dagtid torsdag før de skal begynne arbeidet. Begge har mange ideer. Her er notatene Alice tar på møtet:

• • Forsiden skal vise hvilke arrangementer som kommer de neste ukene. Det skal være lett for promotører å finne ut hvordan de kontakter Abdi for å selge inn en artist. • Brukerne bør kunne filtrere de kommende arrangementene etter type, slik at de kan se bare den typen arrangementer eller de musikksjangrene de er interessert i. • Når noen klikker på et arrangement, skal de få opp informasjon om de som spiller, og konserten, som når dørene åpnes. Kanskje siden kan inneholde lenker til strømmetjenester der man kan høre på musikken til artisten eller gruppen? • • Det bør være mulig å kjøpe billetter via siden. Folk som vil leie lokalet til private arrangementer, skal kunne sende inn et skjema for å booke tider.

• • Det bør være mulig å se hva de tilbyr av snacks i baren. På forsiden vil de ha en boks der de viser bilder og videoer som publikummerne har tatt på de siste arrangementene og lagt ut på sosiale medier. • De vil ha en e-postliste som publikummerne kan melde seg på, slik at de kan få varsel om kommende arrangementer. • Forsiden bør ha lenker til sider på sosiale medier der man kan følge konsertscenen.

Etter møtet omformulerer Alice disse ønskene til brukerhistorier. Hun snakker med resten av teamet om hva det er realistisk at de får til, og de blir enige om hva de skal prioritere.

ALICE BLIR ENIG MED INTERESSENTENE OM SPRINTMÅLET

På fredag har Alice et kort videomøte med interessentene. Hun forteller at teamet har blitt enige om å oppfylle følgende brukerhistorier i den første sprinten:

1. Som daglig leder vil jeg kunne legge inn et nytt arrangement, slik at det dukker opp på forsiden og publikum kan se det. 2. Som publikummer vil jeg kunne se hvilke arrangementer som kommer, slik at jeg kan bestemme meg for hva jeg vil gå på. 3. Som promotør vil jeg kunne se hvordan jeg tar kontakt med konsertscenen, slik at artistene mine kan spille der. 4. Som privat arrangør vil jeg kunne ta kontakt med konsertscenen, slik at jeg kan booke lokalet til et privat arrangement.

Sprintmålet er altså å ha en hjemmeside som møter de grunnleggende behovene til alle brukerne av konsertscenen. Alice og interessentene blir enige om å ha første sprintgjennomgang torsdag ettermiddag uken etterpå.

ARBEIDSUKEN

Teammedlemmene jobber hjemmefra. De er enige om å ha daglige standupmøter klokken 11.

Den første dagen møtes Kodemagi klokken 9 og gjør brukerhistoriene som Alice har valgt ut, om til arbeidsoppgaver som de skal ha på tavla:

• • • Lage et dataformat for arrangementer Lage utkast til design for hjemmesiden Lage en arrangementslistekomponent som henter inn rådataene om arrangementer og viser dem på hjemmesiden • • • Lage en navigasjonslinje Lage siden promotører skal besøke Lage siden private arrangører skal besøke

Slik ser oppgavetavla ut når medlemmene har lagt inn oppgavene.

Slik ser oppgavetavla ut etter at medlemmene har tatt på seg oppgaver. De har tre dager på seg før de skal møte interessentene til første sprintgjennomgang. Altså må hver person i gjennomsnitt bli ferdig med to oppgaver hver dag. Det er litt mye, men de tre siste oppgavene er heldigvis mindre enn de tre første.

Alice tar ansvar for oppgaven «Lage et dataformat for arrangementer». Bob tar oppgaven «Lage utkast til design for hjemmesiden». Christine tar oppgaven «Lage en arrangementslistekomponent …». De jobber en åtte timer hver dag.

DAGLIGE STANDUPMØTER

Hver dag klokken 11 har medlemmene et videomøte for å snakke om det de holder på med.

På tirsdag sier medlemmene dette:

•Alice • I går bestemte jeg meg for at arrangementene skal lagres som en stor JSON-fil som Abdi redigerer manuelt. Jeg har lagt inn noen eksempelarrangementer i kodebasen. • I dag skal jeg ta en prat med Abdi og finne ut om han forstår hvordan han kan redigere filen. • Det som kan hindre meg, er at Abdi ikke har tid til å svare. I så fall begynner jeg på en annen oppgave i mellomtiden.

Slik ser oppgavetavla ut etter standupmøtet. • Bob • I går laget jeg noen enkle skisser av hjemmesiden på papir. Jeg tok turen til kjøpesenteret og gikk bort til folk på en kafé for å utføre en geriljatest, det vil si jeg ga dem ulike oppgaver som publikummer og privat arrangør. Jeg droppet å teste promotørrollen, for kafégjestene har ikke mulighet til å sette seg inn i hva den går ut på. Det var litt kleint først, men jeg ble vant til det ganske raskt. • Jeg fikk noen tilbakemeldinger på papirtegningene som jeg skal rette på i dag. • Det er ingen hindre i sikte.

•Christine • I går laget jeg et utgangspunkt for arrangementslistekomponenten. • I dag må jeg nok endre på designet basert på tilbakemeldingene du fikk, Bob, og basert på dataformatet du har bestemt, Alice. • Ingen hindre.

Oppgavetavla er uendret fra i går.

På onsdag sier medlemmene dette:

•Alice • Abdi hadde ikke tid til å snakke i går. Derfor tok jeg på meg å lage siden som private arrangører skal besøke. • Jeg har avtalt et møte med Abdi i dag. Derfor regner jeg med å bli ferdig med begge oppgavene. • Ingen hindre.

•Bob • Jeg ble ferdig med skissene i går og kodet designet for hjemmesiden. • I dag skal jeg lage navigasjonslinjen. • Ingen hindre.

•Christine • I går endret jeg arrangementslistekomponenten. Jeg satset på at dataformatet var greit, Alice. Du kan endre den hvis Abdi vil endre på dataformatet. • I dag skal jeg legge inn arrangementslisten på forsiden av hjemmesiden. Etter det skal jeg lage siden som promotører havner på. • Ingen hindre.