INF112 Innføring i systemutvikling

Prosjekt og arbeidsmetodikk

- Bilde: føtter på et barn som såvidt har lært seg å gå

- byggebransjen har eksistert i tusenvis av år, vi er kvitt barnesykdommene

- alle har et forhold til byggebransjen

- de fleste klarer å spikre sammen småting

- de fleste klarer å gjøre litt større ting, feks lage en terasse, ved å lese

litt

- noen klarer å gjenkjenne godt arbeid selv om de ikke er i bransjen selv

- IT-bransjen har kun eksistert i noen få år, vi kan regne fra ca 60-tallet

- Dette har flere konsekvenser, først og fremst: umoden bransje, ikke alle har

funnet ut hva som virkelig fungerer. I tillegg går utviklingen veldig fort, du

kan ikke være lenge vekke før det du kunne er utdatert. Utvikling av hva?

Prosjektmetodikk, arbeidsprosesser, teknologi

- en konsekvens er at det som er relevant nå, som dere lærer i dette kurset,

gjerne ikke er like relevant om 3 år eller 5 år. Prøver å fiske ut de

generelle temaene, men vær forberedt på at verden endrer seg

- prosjekt- og arbeidsmetodikk handler om hvordan folk skal samarbeide, og det finner stadig

mer forskning på dette --> hva som er beste praksis endrer seg over tid

- Litt historie

- Smidig/agile -- hva er det?

- Smidige prosjekter

- Gå gjennom verktøy (arbeidsteknikker)

Oppgave

arbeidsmetodikk, prosjekt, prosjektmetodikk

- Oppgave: Hva legger dere i disse begrepene?

- bruk 4 minutter i grupper, en av dere skriver en oppsummering i chat-en

- en eller flere oppgaver som skal utføres

- Ofte utvikle et produkt

- som oftest lenger varighet

- helst flere folk

- noe skal leveres (produkt?)

- et prosjekt har en livsyklus: planlegging/utredning, implementasjon,

forvaltning) som gjentar seg gjennom hele levetiden til prosjektet

- tegne på tavlen: enkel livssyklus (utrede, planlegge, impl., forvalte)

- livssyklus for et softwareprosjekt er akkurat som prosjekter i andre domener,

faktisk er software-utviklingen bare en del av et prosjekt (vi prøver å løse

et overordnet problem)

- hensikt: organisere arbeid.

- hva skal gjøres, hvem skal gjøre hva, prioriteringer (også opp mot økonomi)

- organisere mennesker: teammedlemmer, kunder, interessenter

- organisere interaksjon mellom ulike "flater", mennesker, maskiner, behov,

krav, økonomi

- håndtere endringer både strukturelt i organisasjon, i team, i hva som skal

lages, hvordan det skal lages

- håndtere risiko

- historie på et par minutter for å sette kontekst

Dijkstra

The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

- bilde: dijkstra-strektegning

- på 60-tallet var programmering/utvikling en vitenskap

- fra 60-tallet til midten av 80-tallet var det mange enorme softwareprosjekter,

og mange gikk ordentlig på trynet, enorme tap (kalt the software crisis)

- Edsger Dijkstra: "The major cause of the software crisis is that the machines

have become several orders of magnitude more powerful! To put it quite

bluntly: as long as there were no machines, programming was no problem at all;

when we had a few weak computers, programming became a mild problem, and now

we have gigantic computers, programming has become an equally gigantic

problem."

- Software får fort tilnærmet uendelig mange mulige eksekveringsstier, gjør at risiko

for feil er veldig høy, ikke mulig å teste alt (verifisere oppførsel).

- som et resultat av dette vokste det frem ulike typer prosjektmetodologier for

å få bukt med disse problemene

- en annet problem: kunden har alltid rett

- en av årsakene: kunden (og forsåvidt folk i bransjen) visste ikke på hvilken måte

software-prosjekter var ulike fra prosjekter i andre bransjer

Software Crisis

Løsninger?

Formelle metoder
Formell prosjektorganisering – waterfall?
Model-drevet utvikling
Xp, Agile, Scrum, Kanban

“Mythical Man-Month”

Adding manpower to a late software project makes it later.

– Fred Brooks (1975)

Releasefrekvens

Verden endrer seg

- mål for prosjekt endrer seg

- metoder endrer seg

- folk endrer seg (både i og utenfor prosjektet)

- landskapet rundt prosjektet endrer seg (feks hvilke andre systemer ditt system

skal integrere mot)

- Invaliderer ferdig-produkt-tankegangen

- Fortsatt noen som opererer med sjeldne release.

- I tillegg: Mange har ikke tenkt på folkene i prosjektet som folk, men som

deler som kan byttes ut (som har samme funksjon)

- Ca 90-tallet vokste det frem både rammeverk og et annet tankesett rundt det å

utvikle. Først var det blitt noe ingeniører holdt på med (software

engineering). Så endret tankesettet seg fra en ingeniør-gesjeft til håndverk.

To bøker som også hadde stor innflytelse: The pragmatic programmer (1999) og

Software Craftsmanship (2001) som introduserer programvareutvikling som

håndverk i stedet for en ingeniørdisiplin. Etter disse kom Smidig-manifestet

(2001)

Agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

- Bakgrunn: mange krevde "ryggdekning" i form av dokumentasjon

- software kunne bli levert med enorme avhandlinger av dokumentasjon

- Dokumentasjon lyver ofte, særlig hvis det er mye av det.

- eks: kravspek. Enorme mengder arbeid lagt ned i å lage detaljert kravspek, og

så endrer verden seg.

- eks: test script: manuelle beskrivelser av hvordan teste systemet

- eks: endringsønsker: i veldig rigide strukturer blir det å be om endringer i

forhold til planen en stor oppgave

- skal ikke bruke mer tid på å skrive dokumentasjon enn å lage kode

- Vær kritisk: hva er viktig dokumentasjon? Hvorfor er en spesifikk løsning

valgt. Ikke hva skjer her: det burde være beskrevet i kode.

- Hvis løsningen krever dokumentasjon for å være brukbar, symptom på annet

problem. Ekspert-verktøy kan være unntak.

- Trenger noe teknisk dokumentasjon for utviklere: Hvordan bygge og jobbe med

prosjektet. Hvor finner man hemmeligheter? Informasjon man ikke finner andre

steder eller feks i kode

Customer collaboration over contract negotiation

Responding to change over following a plan

Team

Prosjektmetodikker

Smidige prosjektmetodikker

- følger smidig-manifestet, men ble etablert før agile manifesto ble publisert

- felles for smidige prosjektmetodikker:

- ikke planlegge altfor langt frem i tid

- teamene er selvorganiserende og i stor grad autonome

- lag de viktigste tingene først (reduserer risiko i forhold til finansiering,

gir brukbart system fortere. I tillegg gir bruktbart system raskere feedback

fra kunden om hva som virker og ikke virker, og avslører om det er

misforståelser mellom teamet og kunden tidlig)

- prøve å ikke gjøre for mye på en gang

- holde på med oppgaver som er godt beskrevet. Disse skal også være prioritert i

samarbeid med kunden (konkrete arbeidsoppgaver er lette å jobbe med)

- alle i teamet må skjønne hva som foregår (alle i samme båt)

- nok kunnskap i teamet til å kunne fullføre ide til realitet

- empiriske: lære av det som allerede er gjort

- samarbeid viktig --> kunnskapsoverføring, bedre løsninger, færre feil

- integrere endringene dine med andres så ofte som mulig, ikke seile sin egen

sjø (ikke bare unngå mergekonflikt, men sørge for at din kode fungerer med

resten av kodebasen. Alle andre må vite at deres kode virker med dine

endringer like mye som at din kode må virke med andres endringer)

- jevnlig tilbakemelding fra kunder og brukere. Dette oppnås ved hyppige

leveranser

- viktig å sette av tid til å vurdere retningen på prosjektet (og teamet), lære

underveis og gjøre endringer utfra de erfaringene teamet har gjort seg

- dette innebærer ulike ting, som å justere kursen sammen med kunden, men også

hvordan teamet fungerer i seg selv

- hvilke verktøy har vi?

Extreme Programmring (XP), Scrum og Kanban

XP handler om team-aktiviteter

XP: Mål og arbeidsoppgaver

- Aktivitet (særlig begynnelsen av prosjektet): få ned historier som er mest

viktige. Ikke altfor nøye, men må ha oversikt på overordnede mål der og da.

- Denne aktiviteten gjentas/følges opp hver 2. til 3. måned --> releaseplan

- Aktivitet: bryte ned oppgaver til noenlunde fornuftig størrelse (ikke for

store, ikke for små), gjøres ved begynnelsen på en iterasjon. Dette er en

teknisk planlegging. Hver oppgave skal være omtrent 1-2 dagers arbeid.

- justere fart (velocity) etterhvert som prosjektet fortsetter

(endringshåndtering). Vi vet at estimater er vanskelig, bør helst unngås.

Estimater i XP handler om relativ arbeidsmengde, ikke antall timer. Etterhvert

som teamet får erfaring kan teamet si noe mer fornuftig om hastighet

- planlegge release (hver 2. til 4. måned). Husk at dette ikke betyr at software

leveres bare hver 2. til 4. måned, software leveres ved slutten av hver

iterasjon

Scrum, en top-down-approach?

Sprint

Scrum begrenser arbeid i en iterasjon

Kanban begrenser parallelt arbeid

Kanban handler om kontinuerlig flyt

Prosjekt-tavle

- bilde: lapper på veggen/prosjekttavle

- hvorfor? holde kontroll på hva teamet jobber med til enhver tid

- kolonnebasert

- inneholder oppgaver

- minimum: TODO, Doing, Done

- ofte også: backlog/inbox e.l. til ting som ikke ennå er prioritert

- ofte også: egen kolonne til ekstern test, review etc.

- tavle kan være fysisk, men mange digitale muligheter også: github project

board, trello, jira osv.

- Hvordan jobbe med en prosjekttavle:

- Plukk oppgaver fra kolonnen med prioriterte oppgaver (typisk todo). Denne

kolonnen fylles som oftest i planleggingssesjon (feks 2. hver uke). Kolonnen

er gjerne også prioritert slik at de viktigste oppgavene ligger øverst

- Flytt oppgaven du begynner på fra TODO til Doing, slik at andre vet at

oppgaven er påbegynt. Gi oppgaven til deg selv slik at andre vet hvem som

jobber med den.

- Når oppgaven er ferdig og godkjent flyttes oppgaven til Done. Hva som regnes

som ferdig (Definition of Done) blir teamet enige om (hvilke tester skal

gjøres, kvalitet på kode osv)

- All informasjon som trengs for å løse en oppgave skal legges inn på oppgaven,

slik at den som begynner på oppgaven kjapt kan sette seg inn i og utføre

oppgaven. Dette skal fylles inn på planleggingssesjon (evt på en teknisk

gjennomgang)

- hvis oppgaver er avhengig av hverandre, tillater mange systemer å koble sammen

oppgaver slik at det blir tydelig at en oppgave ikke kan påbegynnes før en

annen er ferdig

- Hold orden på prosjekttavlen. Flytt oppgaver på riktig tid, særlig hvis man

jobber remote eller har kunder som følger med på tavlen er det viktig at den

viser hva som faktisk skjer

- Ha en egen kolonne der kunder/brukere kan legge inn oppgaver. Disse skal

gjennom planlegging og prioritering før de havner i Todo-kolonnen

- Finnes mange fine features i prosjekttavle-verktøy, hovedregel: Keep it

simple, stupid (KISS). Prosjekttavlen skal være et hjelpemiddel, ikke bli

målet med prosjektet

- Oppsummert:

- Hensikt: Holder oversikt på hvem som gjør hva, hvilke oppgavers om er ferdige,

og hvilke oppgaver som skal løses

- Kommunikasjon mellom teammedlemmer: hvem gjør hva (pågående)

- Kommunikasjon mellom team og kunde: hvilke oppgaver er løst (ferdig)

- Prioritering: hva er rekkefølge på de neste oppgavene som skal løses

(todo/prioritert)

- hva har vi valgt å ikke fokusere på (backlog) i denne fasen

- avklar hvem som har ansvar for å flytte kort fra en kolonne til en annen

- avklar hvem som kan legge inn kort i backlog, og hvem som kan flytte oppgaver

inn i prioritert

- ulike prosjektmetodikker setter ulike begrensninger på project board: dvs de

setter begrensninger på hvordan teamene jobber (eks: kanban begrenser antall

saker som er åpne samtidig, scrum begrenser antall totalsaker i en iterasjon)

### Retrospektiv

- Bilde: engasjerte, aktive teammedlemmer

- Handler om å gå gjennom de erfaringene teamet gjør seg i et prosjekt og

lære av dem, og endre oppførsel for å få teamet til å fungere bedre

- viktig prinsipp: alle har gjort det som der og da så ut som den beste

løsningen, og alle har gjort så godt de kan

- prinsippet er viktig fordi retrospektiv ikke handler om å legge skyld for

eventuelle problemer

- fokus skal være på forbedringer og løsninger på problemer (løsningsorientert i

stedet for problemorientert)

- et møte der hele teamet er med, varer typisk 1 - 1 1/2 time, men kan også være

kontinuerlig fokus

- et teammedlem (eller noen utenfra) fasiliteter møtet (styrer øvelsene,

tidsbruk, sørger for god og konstruktiv tone osv)

- går gjennom en eller flere "øvelser" for å vurdere hvordan perioden har vært

- ender som oftest med forslag til forbedringer, endringer i hva man skal

fokusere på osv

- teamet blir sammen enige om hva som skal endres på for å få bedre samarbeid

- noen vanlige ting å fokusere på i retrospektiv:

- hva har vært bra i sist periode?

- hva ønsker teamet å slutte med?

- hva ønsker teamet å begynne med?

- hva hindrer teamet?

- praktisk gjennomføring:

- bruker ofte post-its og mye tavleplass

- alle skriver ned det de kommer på på lapper og henger dem opp

- alle lapper gjennomgås, lignende/like lapper grupperes

- alle i teamet stemmer på hva som er mest viktig og blir sammen enige om noen

få punkter som skal endres/gjennomføres frem til neste retrospektiv

- husk: hold god stemning, vil helst ende opp med god-feeling etter retro

- OPPGAVE: liten retro om forrige forelesning

Programvareutvikling er kontinuerlig

Mål: alle i teamet forstår domenet

- programvareutvikling er vanskelig

- domene er vanskelig å forstå, krever mye innsikt

- vi lever i krysningen mellom mennesker og maskiner og må gjøre konkret mening

og presise regler ut av uklare og uferdige ideer

- ulike personer har ulik oppfatning av verden og hvilke problemer som skal

løses, hvordan de skal løses osv.

- Eksempel: innsiktsworkshop på tre dager i forb. med nytt team og nytt prosjekt

- møte brukerne, sørge for at vi vet hvem vi skal prate med og at de vet hvem vi

- komme frem til hva dagens arbeidsprosess faktisk er

- sjekke at brukerne forstår prosessen på samme måte

- sjekke at vi forstår prosessen

- bli enige om grove linjer for hvor vi tror vi skal

- stake ut umiddelbar kurs (hvor begynner vi)

- sjekke at alle har samme mål (hva er forretningsmålet)