Veien til smidig For NAVs samling Johannes Brodwall BBS

Tema: •Vi kan ikke redusere risiko uten å redusere omfang. Vi kan ikke redusere omfang hvis vi ikke kan endre. Vi kan ikke trygt endre uten at vi har tillit til endringene •Magemål –Hvordan skape verdi underveis? •Kontroll –Feedback: Kundeinvolvering –Feedback: Ekte leveranser –Feedback: Automatert verifikasjon

Å nei, enda et buzzword •Buzzword er ikke viktig •Spørsmål: Hva gjør oss i stand til å levere –Med mer kontroll? –Mer effektivt? –Mer forretningsorientert? •Svar: Hyppighet –CHAOS Report, Standish Group •Prosjekt success/challenge/failed: 29 %/53 %/18 % •Success by budget: $750k: 55 %, $1500k: 33 %, $3M: 25 %, $6M: 15 %, $10 M: 8 %, > $10 M: 0% •Jo større prosjektrammer, desto dårligere resultat –Surviving Object Oriented Projects, Alistair Cockburn •Basert på prosjektstudier •6 måneder siden leveranse = problemer •9 måneder siden leveranse = krise –Lean software development, Mary and Tom Poppendieck •Det eneste meningsfulle å måle en org på er leveransefrekvens og kundefornøydhet.

Hvordan bli hyppigere? •Erfaringene fra BBS –Innførte smidige metoder som en del av fornyingsprosjekt, men primært på teknologisiden –Har innført smidige teknikker og arbeidsformer –Sliter med å få magemål •Vår største utfordring som mennesker og som utviklingsorganisasjoner: Å styre vår appetitt

Så, hva er ”smidig” (agile?) •En paraply av teknikker og ideer –XP, Scrum, DSDM, FDD –Pragmatic programmers, Adaptive – •Et løfte

Det smidige manifest (Uoffisiell norsk versjon) “Smidig handler om å levere software hyppig til en ekte kunde slik at vi kan få feedback. Dersom vi må velge, vil vi heller levere løsninger enn dokumentasjon, heller tilpasse oss erfaring enn å møte en plan, heller utvikle et god samarbeidsforhold med kunden enn å lage enn vanntett kontrakt, og heller fokusere på personene som skaper verdi sammen enn på prosesser og verktøy.”

Hvordan gjør mitt prosjekt det? •Bygging og testing feedback på timesbasis •Interne leveranse og planlegging på ukesbasis •Eksterne leveranser... alt for skjeldent •Det hele starter med kravene

Om krav •Den vanligste analysen: ”Ikke en grundig nok jobb med kravspec’en” –Dette er feil! •Krav er tre ting: 1.Behovforståelse (mål: oversikt, forståelse) 2.Planlegging av prosjektaktiviteter (mål: prioritering, omfangskontroll) 3.Spesifikasjon av hva programmet skal gjøre (mål: nøyaktig definisjon) •Forskjellige teknikker fokusere på forskjellige ting –Eksempel: Hva har fire hjul, et ratt, bremser og motor? –Svar: En gressklipper –(Hva var brukerbehovet?)

Prosessen •Planlegging: User stories –Vi bruker i dag Use cases –Use case eksempel: •1. Bruker logger inn –1a. Bruker taster feil passord –1a1: Systemet gir bruker sjansen til å taste passord på nytt –1a1a: Bruker taster feil passord tre ganger –1a1a1: Systemet låser brukers konto –1b. Bruker er ikke registrert •2. Bruker velger ”registrer ny kampanje” –Use cases er forferdelig til scope kontroll –Som en X, ønsker jeg Y, slik at Z •Som kampanjeansvarlig, ønsker jeg å registrere nye tilbudskampanjer, slik at vi har noe å presentere i markedsføringsmateriale •Som kassaoperatør, ønsker jeg å kunne scanne varer, slik at jeg kan be kunden om korrekt betaling •Som butikksjef ønsker jeg å kunne å vite hvilken kassaoperatør som har betjent et salg, slik at jeg kan følge opp feil og sikre mot misbruk –For tidlig detaljering medfører økt endringsrisiko (konsekvens og sannsynlighet) –Skrives snart som lapper (håper jeg!)

... forts •Iterasjoner: 2-3 uker –Oppgaver planlegges på første dag og spores med gule lapper på tavle •Kravspesifikasjon: Funksjonelle tester –Alle krav må kunne verifiseres. Det er her detaljene ligger –Spesifikasjon ved eksempler •Gitt at ett par sokker koster ti kroner, og vi har et tilbud som gir det tredje sokkeparet til halv pris. Når kassaoperatør scanner tre par sokker, så skal totalbeløpet være 25 kroner •... Når en kassaoperatør scanner to par sokker, skal totalbeløpet være kroner 20 •Gitt at en kunde har en korrekt avtale. Når leverer en fil der oppgitt sum beløp ikke stemmer med summen av alle transaksjonene (eksempelfil), så skal kunden motta en kvittering med feilkode ”sum beløp feiler”, og transaksjonen på filen skal ikke prosesseres –Vi skriver disse i FitNesse –En del har startet å bruker ”Behaviour Driven Design” for å spesifisere krav.

... forts •Utvikling –Test first (yes, really!) –Understøttes av moderne utviklingsverktøy •Continuous integration –Hver gang vi gjør en endring, kjøres alle tester –Dersom noe går feil, sendes feil, feil vises på lamper etc. –Hindrer feil fra å snike seg inn. –Funksjonelle tester som aldri har fungert vil ikke rapportert som feil •Manuelle testmiljøer –En kommando for å installere eller oppgradere –Eksperimentelt: Autoinstallasjon ”Continuous deployment”

... forts •Release på slutten av hver iterasjon –Vi ønsker demonstrasjon, men får det ikke enda (noen prosjekter har det okay ofte) •Kopiproduksjon –Inputdata fra produksjon, kvitteringer fra produksjon –Kjører gjennom systemet og avstemmer –Kjører kontinuerlig •Produksjon –To problemer: •Forretningssiden må ”tørre” •Forskjeller fra preproduksjon til produksjon medfører cirka 2- 4 ukers arbeid

Hva får det til å fungere? •Feedback gir kontroll med kvaliteten hele tiden •Tidlig og robust oppdagelse av feil gir endringsdyktighet

Hvordan kan vi bli bedre •Enklere å komme fra kopiproduksjon til produksjon –Bedre arbeidsprosesser med drift •”One team” –Unngå overleveringer –Forårsaker misforståelser, feil og kostnader •Bedre involvering av forretningssiden –Redusere omfang tidlig –Levere ”nok for denne gangen” •Magemål

Å få magemål •Hara hachi bu – Spis til du er 80 % mett •Er du noen gang redd for at prosjektet aldri skal bli ferdig? •Hyppig feedback gir bedre forståelse for hva vi kan oppnå –Ting tar tid –Og vi misforstår hva forretningssiden vil –Men kanskje vi har noe brukbart alt? –Pragmatisk produksjonssetting: Hva hindrer oss å gå i produksjon nå? •Unngå lange kravspesifikasjoner –Just-in-case krav (”tøm hjernen”) –Just-in-case implementasjon (”kanskje de egentlig også kommer til å trenger”) –Detaljer blir feil og endrer seg – dyrt å vedlikeholde, eller vi antar at vi vet ting vi ikke vet –Kvalitetssikring av detaljer i dokumenter er dødelig vanskelig (”bubbles don’t break”) –Krav: 45% brukes aldri, 19 % skjelden, 16 % noen ganger, 13 % ofte, 7 % alltid •Fokus –Ikke: Hva kommer vi til å trenge? –Ikke: Hva er en meningsfull delleveranse? –Ikke: Hva er den minste meningsfulle delleveransen vi kan komme med? –Men: Hva er det minste vi kan sette i produksjon uten å ødelegge ting? •Edruelig ikke-funksjonelle krav –Man trenger ikke 5 9-ere for en intern kundeoppfølgingsapplikasjon –En to-veis redundant løsning er ikke dobbelt så kompleks, den er 10 ganger så kompleks –Ikke: Ingen risiko –Men: Riktig risiko

Galskap •Å gjøre det samme igjen og igjen og forvente et annet resultat

Konklusjon •I stedet for å bli flinkere til å dokumentere må vi bli flinkere til å unngå behovet for å dokumentere •I stedet for å bli flinkere til å koordinere, må vi bli flinkere til å unngå behovet for koordinere •I stedet for å bli flinkere til å kvalitetssikre, må vi bli flinkere til å unngå å innføre feil •I stedet for å bli flinkere til å gjøre ting riktig første gangen, må vi bli flinkere til å tilpasse oss erfaring

EKSTRAMATERIALE

Case Study: Oslo Smidig Community •Oslo XP meetup: –Resultat: Minst ett møte i måneden i 2,5 år personer på community møter, 100+ på guru-foredrag –”Korrekt” verktøystøtte –Aldri mer enn 2-3 uker i forveien –Låne lokaler av en pub •Smidig 2007 –Resultat: 250 deltagere, 80 foredrag, 22 sponsorer, 14 entusiaster –Tre ”prosjektledere” –Min modell: 4 styreparametre + fargekoder + slipp kontrollen –Utvikler programvaren as-we-go (med noen feil under veis, jada)