Helgen viste meg noen av de beste mulighetene man har til å utnytte open space. Her er et utvalg av sesjoner og hva som gjorde dem bra:

• På min første sesjon “Certified Scrum Dev exercises” ba jeg om ideer og innspill til hvordan å gjennomføre et kurs for folk som vil bli bedre utviklere. Det var bare seks personer som møtte opp og vi hadde en ganske kort diskusjon, før jeg spurte de som var til stede om de hadde lyst til å prøve en praktisk workshop jeg hadde lest om. Så brukte vi 30 minutter der vi programmerte “Elephant Carpaccio”. Jeg hadde lest litt om øvelsen før workshopen og jeg har selv deltatt på øvelsen for et halvt år siden. Ut over det hadde jeg ikke gjort noen forberedelser.
• Jeg deltok på Olaf Lewitz sin open space om “Scoping techniques“. Olaf tegnet opp et sett med teknikker på en flipover: Feature Injection, BDD, User Story Mapping, Effect Maps. Noen i publikum spurte “kan du fortelle litt mer om feature injection,” og så tegnet Olaf opp en skisse som demonstrerte arbeidsflyten. Noen foreslo andre teknikker, for eksempel så forklarte jeg modellen Evo. Olaf skisserte det jeg beskrev på en flipover. Olaf hadde forberedt seg med noen tanker på forhånd om hvilke teknikker han ville ha med seg og hvordan han kunne fremstille disse.
• Karianne gjennomførte en liten open space sesjon med tittelen “Refactoring dojo“. Hun hadde tatt med et kodeeksempel hun hadde brukt før og en PC, og de som møtte opp gjorde forbedringer i koden. Karianne koblet sin PC opp på en projektor og det gikk på omgang hvem som satt ved tastaturet og hvem som observerte og kommenterte det som ble gjort.
• Jeg hørte fra noen som hadde deltatt på Joh og Simon sin open space “Breaking big rocks“. Her hadde facilitatorene forberedt et nøye planlagt opplegg: De beskrev et eksempel på et “stort problem” (“big rock”). Så delte de opp gruppen i grupper på 3 og ba hver gruppe komme opp med noen store problemer på post-its. De hang opp problemene på en flipover. Så ba de gruppene om å velge et problem hver og diskutere hva som gjorde det stort. Når gruppene hadde diskutert, samlet de sammen beskrivelsene og demonstrerte hvordan de problemene folk hadde samlet inn egentlig var veldig like. Jeg fikk inntrykk av at Joh og Simon hadde brukt litt tid på å planlegge sesjonen og bestemme seg for hvilke spørsmål de skulle stille til gruppen.
• Jeg deltok på en annen sesjon med Olaf Lewitz – “Lean procrastination“. I introduksjonen fortalte Olaf at han hadde holdt en keynote med denne tittelen for et par uker siden. Vi hadde en projektor tilgjengelig, så deltagerne spurte om han kunne gå gjennom presentasjonen for oss. Resten av sesjonen ble en uformell presentasjon med slider.
• Jeg foreslo en kvelds-open space med tittelen “how to fix devs“. Jeg introduserte med “vi klager alltid over prosjektledere, kunden, produkteiere, arkitekter osv. Nå vil jeg klage litt over (oss) utviklere”. Vi hadde en liten diskusjon og jeg presenterte noen tanker om hvordan vi burde justere på rammene for utviklere, for eksempel at “i stedet for at utviklere gir estimater for oppgaver, hva om produkteier gir budsjetter for oppgaver”. Jeg hadde tenkt mye på temaet før open space og fikk masse bra feedback på hvilke av disse tankene som virket fornuftig som jeg kan ta med meg videre.
• I en tidsperiode der jeg ikke fant en sesjon som jeg inspirerte meg, gikk jeg rundt og hørte på litt forskjellig. Jeg ble sittende på slutten av en sesjon som het “Definition of Agile Coaching“. I løpet av sesjonen hadde gruppen produsert denne definisjonen: “Agile coaching is a 100% client-focused engagement which enables continuous improvement, because the client owns aligned goals and purpose across organisational levels and the people doing the work define the steps towards those.”
• Jeg holdt en siste open space på søndag, denne om “non-violent communication“. Jeg introduserte med “jeg har lest en bok som ga meg masse tanker jeg synes var spennende, jeg vil gjerne diskutere dette med dere”. Diskusjonen var ustrukturert og springende, men det var mange som deltok og alle følte at de både bidro og fikk utbytte av alle de forskjellige diskusjonene. Jeg noterte meg noen ord på et par flipovers, men notatene var ikke mulige for noen som ikke hadde deltatt å forstå. Diskusjonen skapte mye tanker om hva vil det egentlig si å tvinge noen i en diskusjon. Vi fikk en positiv atmosfære i gruppen som ga en fin avslutning på helgen.

Om jeg skal trekke noen konklusjoner: Man kan komme til en open space med forskjellig grad av forkunnskap og forskjellige forventninger. Du kan stille med med en ferdig presentasjon, en plan med spørsmål, en liste over relevante spørsmål og ideer, eller bare med et tema (som da jeg foreslo “non-violent communication”). Resultatet kan bli at man gjennomfører en øvelse sammen, produserer et resultat, kommer opp med en liste med ideer som folk kan sjekke ut etterpå eller at man bare har en hyggelig samtale.

Vellykkede open spaces kommer i mange størrelser og fasonger. Et av prinsippene bak open space er “whatever happens is the only thing that could have happened”. Eksemplene mine fra Agile Coach Camp demonstrerer dette prinsippet: Man kan komme til en open space med forskjellig grad av forkunnskap og forskjellige forventninger. Når gruppen får en sjanse til å forme innholdet, blir opplevelsen verdifull for alle.

På kick-off i år vil Steria feire “The Power of Sharing” ved å vie den faglige delen til Open Space. Her har alle som deltar anledning til å skape dialog om ting som interesserer dem. På en open space kan du ta opp ting du er flink til som du ønsker å dele, ting du ikke er flink til som du ønsker å lære, måter du ønsker andre endrer seg på eller hva enn som interesserer deg.

Praktisk fungerer det slik at deltagerne foreslår sine temaer ved oppstarten av open space. Du vil få ti sekunder på scenen å fortelle hva du vil diskutere og så får du plassere temaet i programmet som vi henger opp på en stor tavle. Når “din” sesjon starter er du ansvarlig for å ønske velkommen og etter det kan du lytte eller snakke så mye eller lite du ønsker. Du trenger ikke å forberede noe før en open space (men du kan om du vil). Alle diskusjonsgruppene vil ha flipover og noen få vil ha projektor.

Her er eksempler på ideer som andre har tenkt å bidra med på Sterias open space:

• ABC of ICT
• Slik kommer du igang med brukertesting
• Hvordan få til tverrfaglige løsningsteam i smidige prosjekter
• Hvordan få brukertesting inn i alle Sterias systemutviklingsprosjekter
• Hva bør en SharePoint-konsulent være?
• Hvordan bli en bedre leder og hvordan få en bedre leder
• Kommuniksasjonsstil: Er du grønn, gul eller rød
• Bli med og leke med CoffeeScript
• Skal vi bidra til et open source prosjekt?
• Sterias bidrag til FNs tusenårsmål
• The rise and fall of Intranets
• Trender og utvikling i IT-bransjen
• Kan en kontrakt være smidig?

Som deltager på open space er du ansvarlig for ditt eget utbytte. Så det er lurt at mange tenker litt på forhånd om hva de vil diskutere! Så gjør deg selv og dine medmennesker en tjeneste: Bruk ett minutt på å tenke på hva du kunne tenke deg å dele, å lære, å endre sammen med de du jobber med. Skriv gjerne en (uforpliktende) kommentar med et mulig tema.

Et godt foredrag starter med at du snakker om noe du kan. Og du kan mer enn du tror. Det er som regel sånn at de tingene du kan selv, føles som selvfølgeligheter. Men de erfaringene du har og de opplevelsene du har, de er unike for deg. Kanskje det er mange som har interessert seg for de sammen tingene som du har, men det er lite sannsynlig at de har samme perspektiv på tingene. Du bringer noe unikt til bordet. Velg et tema du har erfaring med, og du har tatt første skrittet til et fascinerende foredrag.

Når du skal bestemme deg for nøyaktig hva du vil snakke om, hjelper det å tenke på hvordan du vil påvirke ditt publikum. Publikumet ditt kan noe når de kommer til foredraget ditt. Ta utgangspunkt i at de vil noe med det de kan. Hvilket problem eller behov har de når de kommer inn i salen? Et vellykket foredrag kanaliserer denne viljen til handling: Hva vil du at de skal gjøre når de har hørt foredraget ditt? Skriv ned den (for deg) perfekte tilhørers kunnskap, vilje og handling etter at han eller hun har hørt foredraget. Dersom du kan beskrive en transformasjon som engasjerer deg, har du tatt skritt nummer to til et fascinerende foredrag.

For å oppnå noe, kreves arbeid. Når du holder et foredrag er det viktigste arbeidet du gjør å trene på å snakke. Bruk under 30 minutter på å strukturere tankene dine før du prøver å holde foredraget første gangen. Hold det for deg selv, men snakk høyt. Tren mange ganger. Tren foran andre om du kan. Tren minst tre ganger på foredraget før du lager en eneste slide. Tren mange ganger på foredraget ditt, og du vil komme i mål med et fascinerende foredrag.

Dersom du får med deg hodet (kunnskapen), hjertet (viljen) og kroppen (treningen), så er du garantert å holde et bra foredrag.

Øvelsene kan tjene som inspirasjon til dine egne retrospektiver og workshops.

Jeg brukte tre workshop-øvelser under hele workshopen:

• “Tenke og svare”: Et retrospektiv kan være en sjelden anledning til å bare sitte og tenke uavbrutt. I “tenke og svare” øvelser får deltagerne to minutter i stillhet til å tenke på svaret til et personlig spørsmål. Etter to minutter får alle fortelle svaret sitt, mens resten av gruppen og moderatoren lytter.
• “Tre svar på tre spørsmål i grupper på tre”: Deltagerne blir delt i grupper på tre som alle skal finne tre svar på hver av tre spørsmål. Etter ti minutter avgir gruppene ett svar hver. Dersom spørsmålene krever handling, kan deltagerne i plenum stemme fram hvilke svar de ønsker å handle på grunnlag av
• “Snakker og lytte”: Det er overraskende sjelden vi blir lyttet uavbrutt i ett minutt, eller lytter oppmerksomt til en annen i et minutt. I “snakke og lytte” øvelsen får deltagerne et personlig viktig spørsmål og blir delt i grupper på to og to. I hver gruppe skal én person snakke og den andre lytte i ett minutt. Etter ett minutt bytter parene roller.

På Smidig 2010 kjørte jeg workshopen som et retrospektiv av den første dagen på konferansen. Øvelsens form var delvis inspirert av “Agile Retrospektives” av Diana Larsen og Esther Derby. “Agile Retrospekives” anbefaler en fem-stegs prosess som ledet hovedstrukturen for workshopen:

1. Set the stage: “Tenke og svare” øvelse med på spørsmålet “Hva har vært høydepunkter så langt”
2. Gather data: “3×3 spørsmål” øvelsen der to av spørsmålene var for å samle data. (“hva har overrasket meg” og “hva har jeg lært”)
3. Generate insights: “Lytte og snakke” øvelsen med spørsmålet “hva vil gjøre meg lykkeligere”. Av praktiske grunner gjorde jeg den etter det siste spørsmålet fra “3×3 spørsmål”.
4. Decide what to do: Det tredje spørsmålet fra “3×3 spørsmål” var “hva vil du lære mer om”. Etter at ti grupper hadde kommet opp med ett svar hver, stemte vi i plenum på de mest interessante temaene.
5. Close the retrospektive: Å tenke og svare på spørsmålet “hva håper du å oppleve” var øvelsen som avsluttet retrospektivet.

For å få en mest mulig konstruktiv dialog, forsøkte jeg å strukturere spørsmålene etter inspirasjon fra “Appreciative Inquiry”. Ola Ellnestams blogpost om Appreciative Inquiry Retrospectives var en viktig kilde til inspirasjon.

Hvilke spørsmål kan du tenkte deg å stille til “tenke og svare”, “3×3 spørsmål” og “snakke og lytte” øvelser? Hvilke spørsmål kan hjelpe gruppen å generer innsikter, samles om et mål og gå ut av retrospektivet fulle av ideer og håp for fremtiden?

Jeg har vært så heldig å være på et prosjekt med en produkteier som har sørget for at vår innsats har blitt brukt til å effektivt skape verdi for brukerne av systemet. Jeg vil trekke fram mine observasjoner om hvordan produkteieren på dette prosjektet brukte produktkøen, hvordan han skapte dialog med brukerne og hvordan han kommuniserte effektivt med utviklerne.

Produktkøen

Produktkøen er produkteiers fremste verktøy for å styre prosjektet dit han ønsker. Det viktigste med produktkøen er derfor at den er representert i et verktøy produkteieren er komfortabel med å bruke. Vår produkteier brukte Excel, noe som fungerte godt for dette prosjektet. Hver brukerhistorie var en rad i et regneark. Når vi skulle endre prioritet, kunne vi dra og slippe en brukerhistorie til riktig sted. (Dette er et lurt knep å lære i Excel).

Etter hver iterasjon gikk jeg som Scrum master og produkteieren gjennom alt som var levert i iterasjonen. Vi markerte i produktkøen hva som var levert og hva som ikke var levert. I iterasjon 4, 5 og 6 skjedde noe merkelig. Iterasjon 4 hadde vi planlagt 7 brukerhistorie-poeng, men leverte 4. I iterasjon 5 hadde vi planlagt 7 og leverte 7. I iterasjon 6 hadde vi planlagt 7 og leverte 10. Det som skjedde var et en stor brukerhistorie var nesten ferdig på slutten av iterasjon 4. En ny stor brukerhistorie var nesten ferdig på slutten av iterasjon 5, og denne brukerhistorien fikk vi endelig levert i iterasjon 6. Produkteier insisterte på at en brukerhistorie var enten ikke ferdig (0%) eller helt ferdig (100%). Dette gjorde at det aldri var noen skjønnsvurdering om hva vi hadde levert.

I prosjektet vårt skulle vi erstatte et eksisterende system. Produkteieren var veldig bevisst på å prioritere et sammenhengende sett med brukerhistorier som gjorde at brukerne kunne benytte de leveransene vi ble ferdig med i løpet av prosjektet. Det var to viktige vurderinger som produkteier tok: For det første må brukerne kunne utføre en arbeidsoppgave i den nye systemet, og ikke måtte hoppe mellom det nye og det gamle. For det andre må leveransene inneholde funksjonalitet som er interessant for brukerne.

Personer og samspill

Men produktkøen er den minst viktige delen av produkteiers jobb. Det smidige manifestet sier det selv: “Vi verdsetter personer og samspill over prosesser og verktøy.” Det er to viktige grupper som produkteieren må forholde seg til: Brukerne og utviklerne.

Involvere brukere

Før prosjektet startet, hadde produkteieren involvert brukerne i prosjektet. Mange brukere var blitt spurt om hva de mente var viktig med det nye systemet og noen brukere var valgt ut til en fokusgruppe. De to mest involverte brukerne deltok hele veien i prosjektet. Produkteieren identifiserte to brukere som de andre brukerne respekterte faglig, som forsto dagens system godt, som hadde meninger om hvordan ting burde være, og som ikke var redd for å si disse meningene.

Så snart vi hadde et produkt som kunne vises fram, satt vi dette i drift i demoversjon som brukerne kunne teste ut. Det viste seg å være vanskelig å få brukerne til å prioritere å teste det nye systemet. Det hjalp litt når produkteieren ga dem en oppgave de skulle utføre med det nye systemet (hjemmelekse). Det hjalp veldig når brukerne kunne bruke det nye systemet mot produksjonsdata som en del av jobbe sin.

Ekspertbrukerne deltok på alle demoer. Ettersom en av de bodde i Rogaland og en i Hedmark, var det vanskelig for dem å reise til Oslo for hver eneste to-ukers iterasjon. De første iterasjonene var de alltid til stede, men etter dette kjørte vi kun demo annen hver iterasjon. Etter et halvt år i prosjektet forsøkte vi også å kjøre noen demoer med screen sharing (go-to-meeting, tror jeg) og telefonkonferanse. Det fungerte ok, men vi fikk mye nyttigere feedback når vi møttes ansikt til ansikt. Ekspertbrukerne hjalp oss å bli flinkere og validerte arbeidet vårt når et var bra.

Kommuniserer med programmere

For å ha framdrift, var prosjektet avhengig av at produkteier og utviklere møtes hver dag. Produkteier deltok på standup-møtene hver morgen. Etter standup-møtene hadde han satt av opp til en time der en utvikler kan vise fram ny funksjonalitet og få tilbakemeldinger, der produkteier kan gi tilbakemeldinger til en utvikler på funksjonalitet han testet i går og der produkteier kan forklare detaljene rundt nye brukerhistorier.

Når produkteieren forklarte brukerhistorier, var han flink til å være konkret. Dette er alfa og omega når en produkteier snakker med utviklere. Forskjellen på å vise fram en skjermbildeskisse og å forsøke å beskrive et abstrakt behov er gigantisk. Forskjellen på å fortelle et eksempel og å forklare en abstrakt arbeidsprosess er enorm. Ved å bruke eksempler til å forklare brukerhistorier var produkteiers forklaringer gode for utviklerne.

Til slutt var produkteieren vår rask til å bestemme seg. Dersom det var et uklart valg, fikk vi ofte en avgjørelse der og da. Når produkteier måtte sjekke med andre, tok det en eller to dager før han kunne gi oss en beslutning. Noen ganger fant han senere ut at han måtte ombestemme seg. Da utførte vi ganske enkelt den endelig løsningen i en senere iterasjon. Det er mye mer effektivt å utvikle noe som er en rimelig hypotese, få tilbakemelding og så utvikle det riktige, enn det er å vente på en beslutning.

For å lykkes som produkteier, må du kunne bruke produktkøen effektivt, du må involvere brukerne dine gjennom hele prosjektet og du må kommunisere med utviklerne hver dag. Da vil du ha et vellykket Scrum-prosjekt!

Bedre kommunikasjon

• Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
• Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
• Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner “venter”, “under arbeid” og “ferdig”. Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til “ferdig” hver dag.

Bedre kvalitet

• Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
• Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
• Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

• Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
• Bli helt ferdig med funksjonalitet: Teamet får kun “poeng” for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
• Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Dette er et eksempel på hvordan kommunikasjon erstatter planlegging. Slik kan det også være i prosjekter. Man må være enige om hva målet med prosjektet er, men dersom man kommuniserer underveis, kan de nøyaktige midlene bli til underveis.

Nesten daglig sitt-ned-møte

Mange bruker “daglige stå-opp møter” i Scrum. Teamet står rundt tavla og koordinerer utførte, pågående og kommende oppgaver. På mitt forrige prosjekt ble vi inspirert av en blogpost til å utvide stå-opp møtet med et “nesten daglig sitt-ned møte” når det var hensiktsmessig.

På stå-opp møtet gikk vi gjennom hvilke oppgaver utviklerne hadde gjort ferdig, og hvilke oppgaver produkteier hadde sett gjennom. Etter stå-opp møtet satt produkteieren og utviklerne seg sammen og gikk inn i detaljene:

• Produkteier hadde med seg en liste med forbedringer fra tidligere funksjoner. De forbedringene som tok under 2 minutter å utføre gjorde utvikleren der og da. Oppgaver som ville ta litt lengre tid noterte utvikleren seg. Oppgaver som var for omfattende ble tatt inn i fremtidige planer.
• Utvikleren viste produkteieren de tingene som var “ferdige” i går. Produkteieren kom med direkte feedback der og da, og noterte seg hva han skulle seg gjennom på egen hånd.
• Produkteieren gikk gjennom detaljene for funksjonalitet som utvikleren skulle starte på og besvarte spørsmål

“Jeg vet det når jeg ser det”

“Measure twice, cut once” er det noen som sier. Men på utviklingsprosjekter er det slettes ikke sikkert at det å beskrive noe ekstra grundig forbedrer sjansene for å lykkes. De eneste gangene jeg har opplevd at en kunde ikke kommer med tilbakemelding første gang hun ser produktet er når jeg har en kunde som egentlig ikke bryr seg. Eller når jeg hadde brukt alt for lang tid på å dekke alle eventualiteter, inkludert de som ikke var kostnadeffektive.

I et vellykket prosjekt vil prøving, visning og tilpasning være normalen. Jo tidligere prosjektet får tilbakemeldingene, desto bedre og billigere blir prosjektet. Og jo mer nøyaktige planer vi legger i prosjektet, desto vanskeligere blir det å tilpasse seg tilbakemeldingene.

Felles mål, daglig kontakt, daglig tilbakemelding og daglig tilpasning vinner over grundige planer.

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

• Meld deg på som deltager eller foredragsholder
• Meld deg på LinkedIn-gruppa vår
• Meld deg på mailingslista for de som er interessert i Smidig 2010

Et eksempel: Å få deltagerne til å følge resonnementet ditt

Dette er et spørsmål jeg stilte til deltagerne på et scrum-kurs som jeg holdt flere ganger. Jeg lærte etter hvert hva som fikk forsamlingen til å svare:

1. “Skal teammedlemmene avgi status til Scrum master på morgenmøtet?” (svaret er “nei”, men sjansene for at noen føler seg dumme fordi de svarte feil er nesten 50%)
2. “Hvem skal teammedlemmene avgi status til under morgenmøtet?” (svaret er “hverandre”, men sjansene for at noen føler seg dumme fordi de svarer feil er godt over 50%)
3. “Hvorfor skal teammedlemmene ikke fortelle status bare til Scrum master på morgenmøtet?” (for åpent, folk vet ikke hvordan de skal angripe spørsmålet)
4. “Hvordan skal teammedlemmene fortelle status på morgenmøtet?” (fortsatt for åpent)
5. “Hva er feil dersom teammedlemmene gir status til Scrum masteren på morgenmøtet?” (nå starter det å nærme seg, men fortsatt for åpent)
6. “Hvilke negative effekter kan man oppleve dersom teammedlemmene kun gir status til Scrum masteren på morgenmøtet?” (her inviterer man deltagernes kreativitet inn i diskusjonen)

Et eksempel: Å få deltagerne til å tenke gjennom hva de har hørt

Her er noen spørsmål jeg har prøvd å stille til deltagerne etter at jeg har holdt et kurs.

• “Hvordan vil du bruke det du har lært?”: Hvordan-spørsmål blir fort så åpne at deltagerne ikke vet hvor de skal starte
• “Hvilke av teknikkene i Scrum vil være vanskelige å få til i deres organisasjon?”: Hvilke-spørsmål kan være åpne og medføre overfladisk gjennomgang.
• “Hvilken av teknikkene i Scrum vil være vanskeligst å få til i deres organisasjon?”: Hvilken-spørsmål inviterer til å gjøre en mental gjennomgang (som hjelper folk å huske) og begrenser hvor mye hver enkelt føler seg pliktig til å besvare. Egner seg godt for refleksjon på slutten av en workshop.
• “Hva vil du gjøre annerledes etter det du har lært?”: Et tung og forpliktende spørsmål. Effektivt, men må brukes med måte.

Hvilke spørsmålstillinger synes du stimulerer til god diskusjon?

Det siste halve året eller så har jeg gått å gledet og gruet meg over dette tilbudet. Og det har slått meg: Å skrive et tilbud er som å forelske seg.

Først blir man litt kjent med kunden og kundens problem. Noen fanger interessen, og man får lyst til å vite alt om problemet. Man spør og graver. Om man ikke får snakke med kunden (og det får man ofte ikke i denne fasen), så snakker man med kolleger og venner som naturligvis ikke har noe svar: “Tror du at det er sånn? Tror du at dette er forklaringen på hvorfor det som de ba om var litt pussig? Tror du at de vil være interessert i dette forslaget?”

Til slutt bestemmer man seg for å satse alt. Søvnløse netter går mens man forsøker å fremstille seg attraktiv for den andre parten. Man forsøker å finne hva den andre parten har lyst til. Og noen ganger må man våge å si noe de ikke vil, men egentlig trenger å høre. Så leverer man et tilbud. Man må tørre å legge alle følelsene sine i tilbudet, fullt vitende om at man kan bli avvist. Den som intet våger, intet vinner.

Så kommer forhandlingene. Den andre parten føler seg attråverdig. De har mange beilere. Man snakker om en mulig fremtid sammen, men den andre parten vil ikke forplikte seg. Man tenker i sitt stille sinn “men jeg liker deg, liker ikke du meg, da?” Men man våger naturligvis ikke å si det.

Og til slutt sier de “ja”. Man er klar til å knytte knuten.

Og nå starter deg egentlig jobben. Jeg gleder meg.

I Crossing the Chasm foreslår Geoffrey Moore en mal for å lage visjon som jeg selv har hatt mye hell med:

• For <en målgruppe>
• Som har <et behov eller en mulighet>
• Så er <produktnavnet> et <type produkt>
• Som <har en god grunn til å like>.
• I motsetning til <viktigste alternativ>
• Har vårt produkt <viktigste differensiator>

Formen er ment brukt til å beskrive produkter, som for eksempel “For skogbruksansvarlige på fylkesmannens kontor som skal forvalte skogsprosjekter så er skogsforvaltningsløsningen et regnskapsystem som gir kontroll og oversikt over regnskapet. I motsetning til den gamle versjonen av systemet gir vår løsning støtte for fullstendig elektronisk saksbehandling.”

Jeg har også brukt den til workshops og andre aktiviteter. Når jeg avholdt en Scrum-workshop startet gruppen med å utarbeide følgende visjon: “For nye og litt erfarne Scrum Mastere som ønsker å bli bedre Scrum Mastere så er Iterasjon-0-workshoppen en gruppeaktivitet som gir konkrete tiltak til aktiviteter. I motsetning til å lese en bok gir denne aktiviteten mulighet til å utveksle erfaring med andre som har samme rolle.”

Slik går jeg fram for å hjelpe en gruppe med å komme fram til en visjon:

1. Først bruker jeg fem minutter på å forklare formatet og hvorfor vi gjør oppgaven
2. Jeg deler gruppen opp i arbeidsgrupper på 3-4 personer. En arbeidsgruppe mister noe når det blir mer enn 4 personer
3. Hver gruppe får ti minutter på å fylle ut formatet over. Dersom det er mye gode diskusjoner i gruppene lar jeg dem gå fem minutter over tida.
4. Jeg går gjennom malen og ber alle gruppene lese opp for forsamlingen hva de svarte på hvert punkt. For hvert punkt spør jeg åpent “hvilket svar var best?” Det nominerte beste svaret skriver jeg på tavle eller flipover. Dette tar cirka ti minutter.
5. Vi avslutter workshopen med en liten oppsummering av hva folk fikk ut av øvelsen.

Totalt får man en brukbar, felles visjon for en gruppe på under en halv time. Som en bonus blir gruppa som helhet litt bedre kjent med hverandre.

• Bug rapport: “Administrative kostnader” skal fjernes: Når vi beregner totalkostnaden til et veiprosjekt, inkluderer vi kostnaden av nyanlegg, ombygging, bruer og administrative kostnader. Når vi demonstrerte applikasjonen til brukerne våre, husket de plutselig at administrative kostnader er sjelden i bruk og burde egentlig fjernes fra applikasjonen. Endringen var enkel og det er usannsynlig at en bedre analyse på forhånd hadde kommet fram til samme konklusjon. Dette er den type feilrapport vi liker å få.
• Bug rapport: Ikke-effektuerte utbetalinger skal telle mot totalt tilgjengelige midler: Når vi sjekket om det var tilstrekkelige midler for å utføre en utbetaling, glemte vi å ta med de utbetalingene som var registrert, men ikke utført enda. Tilstandsovergangen av utbetalinger fra registrert til godkjent til utført var litt mer kompleks enn vi hadde forventet, og enhetstestene sjekket ikke tilstrekkelig med varianter. Vi burde ha funnet denne feilen med enhetstestene våre, men dersom vi aldri får feil av denne typen, kan det være en indikasjon på at vi er for nøye med testingen vår. Så feilen er helt grei. Spesielt ettersom konsekvensene for brukeren ikke var spesielt store
• Bug rapport: Perioder som starter i desember rapporterer IllegalArgumentException: Når vi beregnet neste måned, glemte vi å ta hensyn til at du kan ikke bare legge til én på månedsnummer. Neste måned etter desember er ikke måned 13! Dette var en slurvete feil og jeg tror den ble introdusert en gang når vi ikke parprogrammerte (fordi koden var så triviell, liksom!). Brukerne våre forstår at slike type feil kan skje, men vi må se nøyere på prosessen vår for å unngå slike feil i fremtiden.
• Bug rapport: Layout ser rotete ut i Internet Explorer: For å unngå noen tekniske problemer når vi skrev enhetstester for HTML’en vi produserte, fjernet vi midlertidig doctype-definisjonen fra webside-malene våre. Så glemte vi å putte definisjonen inn igjen (jada, et nytt eksempel der vi ikke parprogrammerte). Sidene så fortsatt fine ut i Chrome og Firefox, som utviklerne brukte for manuell verifisering. Men i Internet Explorer så websidene direkte kaotiske ut. Den tekniske konsekvensen av feilen var triviell, men feilen kunne lett ha vært unngått, dersom vi vi hadde testet med samme nettleser som brukerne våre. Noen av brukerne våre fikk dette håpløse førsteinntrykket av applikasjonen mens de hjalp oss å teste. Det var skikkelig flaut. Dette vil vi ikke at skjer igjen!

Det er litt vanskelig å definere hvilke bugs som gjør meg mest flau. Noen viktige faktorer er hvor vanskelig ville det vært for oss å unngå feilen og hvor stor konsekvens feilen har. Men andre faktorer påvirker også hvordan vi oppfatter en bug. Av feilene på lista over, så er den jeg er mest flau over kun en kosmetisk feil. Men siden dette var noen brukeres førsteinntrykk av applikasjonen, var det mye mer problematisk enn de særtilfellene vi ikke helt støttet.

Hva synes du gjør en feil mer eller mindre akseptabel?

• Påpek noe positivt: Etter kurset fikk vi en mail fra en av deltagerne som sa “takk for kurset, det var veldig bra”. Det gjorde meg bevisst på hvor sjeldent vi gir og mottar skryt uten at det er et “men…” hengende rundt hjørnet og hvor motiverende det er når man faktisk får det.
• Vær konkret: Dersom du sier “foredraget var litt uklart”, gjør du mottakeren av kritikken en bjørnetjeneste. Uten at du påpeker noe konkret er det vanskelig for mottakeren å gjøre noe med det. Dersom du i stedet kan si: “Eksemplene gikk litt fort”, så er det lettere å gjøre noe med det.
• Foreslå en forbedring: I stedet for å peke på hva som var dårlig, kan du finne rom for å gjøre det bedre?
• Motiver forbedringen: I stedet for å bare gi et forslag til forbedring, kan du forklare hvordan endringen vil forbedre foredraget. Det tydeliggjør at du ønsker å hjelpe, samtidig som du anerkjenner at det er den som mottar forbedringen som tar den endelig avgjørelsen.

Som et eksempel på prinsippet, sa jeg under kurset til min med-instruktør: “Du Ram, ‘å bli en bedre presentatør’ høres litt klønete ut. Dersom du i stedet sier ‘å bli flinkere til å presentere’, så tror jeg setningen vil flyte bedre.”

Er du bevisst på å gi gode tilbakemeldinger? Hvilken tilbakemelding kan du gi meg når det gjelder denne artikkelen?

“If A System Is Working, Leave It Alone. Don’t Change Anything!”
- John Gall, Systemantics (1975)

Planen

Det gamle systemet hadde blitt uholdbart. Leverandøren ga ikke lenger support på maskinvare eller programvare, det var umulig å oppdrive kompetanse for å videreutvikle og det var ikke lenger vedlikeholdbart siden det var så kompleks.

Vi skulle derfor erstatte systemet med et nytt et. Bygget fra bunnen med moderne teknologi. Det burde bli enkelt, siden dagens system kan fungere som kravspesifikasjon. Vi hadde estimert arbeidet til 83 511 timeverk.

Vi ville naturligvis ikke investere store mengder arbeid i det gamle, døende systemet. Og dessuten var det umulig å integrere med. Så vi måtte bygge det nye systemet med all funksjonalitet, og så, en spennende helg om noen år, sette det i produksjon.

Slik høres introduksjonen til mange erstatningsprosjekter ut. I disse prosjektene har man et eksisterende system som typisk er kritisk for virksomheten. Av gode eller dårlige grunner har man valgt å gjennomføre et prosjekt som skal erstatte hele den gamle systemet med et nytt system som oppfyller samme målsetning.

Denne planen burde med en gang ringe noen varselbjeller. Hva er egentlig poenget med dette prosjektet? Prosjektet ønsker å videreføre dagens tjeneste med et nytt og moderne system. Og det er billigere måter å gjøre det på.

Uortodoks observasjon #1:

Et erstatningsprosjekt er en dyr måte å forlenge livet til vår nåværende forretningsmodell.

Det virker umulig å komme seg forbi hindrene i form av support, kompetanse og vedlikeholdbarhet. Men dersom vi doblet lønna til alle som ville programmere COBOL, så ville vi nok få nok kompetanse. Det er mulig å videreføre systemet. Det er bare veldig dyrt. Men det er også fantastisk dyrt å erstatte et system fra bunnen. Man kan bruke mange dyre teknikker for å holde systemet i gang før der lønner seg å erstatte.

På de fleste systemer er imidlertid support, kompetanse og vedlikeholdbarhet ikke de eneste, og kanskje ikke de egentlige motivene. Det finnes andre motiver, både dårlige (noen vil ha et stort prosjekt på CV eller jobbe med ny teknologi) og gode (vi ser muligheten til å levere verdi).

Først når erstatningsprosjektet tilfører forretningsverdi er det verdt å gjennomføre. Erstatningsprosjekter for å redusere kostnader eller forlenge levetiden på en utdatert forretningsmodell er en dårlig ide.

Virkeligheten

“A Complex System Designed From Scratch Never Works And Cannot Be Made To Work. You Have To Start Over, Beginning With A Working Simple System”
- John Gall, Systemantics

Den forrige arkitekten hadde holdt på med systemet i tre år. Og organisasjonen hadde ingenting å vise til. Det var ikke blitt ferdig, og han hadde insistert på at det var umulig å levere deler av systemet.

Styret er lei av denne unnskyldningen, og om administrerende direktør ikke finner en arkitekt som kan bevise at investeringene har verdi, er det han som må gå.

Et forsinket prosjekt mister politisk goodwill. Det er bare en måte for et prosjekt som har mistet troverdighet å redde seg på: Man må levere noe. Og da må man spise noen kameler.

Uortodoks observasjon #2:

Det nye og det gamle systemet kommer til å leve sammen.

Heldigvis er dette gode nyheter. Med en gang vi vet at det nye og det gamle systemet må leve sammen, åpner det døren for en rekke muligheter til å tenke bedre.

Gradvis erstatning

Først, her er fire patterns for å gradvis erstatte et system:

• Delt database: Dersom det gamle systemer benytter en relasjonsdatabase kan det nye systemet bruke denne direkte. Det gjør det mulig å levere deler av det nye systemet nesten umiddelbart, men det legger føringer for designer av det nye systemet som man kanskje kunne unngått.
• Import/eksport: Før eller siden må vi forholde oss til de dataene som finnes i det gamle systemet. Ta kostnaden tidlig og eksporter data til det nye systemet. Men vær forsiktig: Det er vanskelig å ha to mastere for data. Start med å la det gamle systemet være master.
• Datatjenestelag: Dersom du ønsker å erstatte det gamle systemets datalager, kan du innkapsle dette i en tjeneste. Legg imidlertid merke til at datatjenester har høyt endringsbehov og tjenester som deles i et stort prosjekt er kostbare å endre.
• Parallell produksjon: Dersom det nye systemet utvikler funksjonalitet som finnes i det gamle, se om det er mulig at begge versjonene kan være i produksjon samtidig. Da reduseres konsekvensen dersom den nye versjonen inneholder feil, siden å rulle tilbake en produksjonsetting er enklere. Dette gjør at det kan være mulig å produksjonsette med mindre testing. Det nye systemet kan også starte med et subset av brukerne. Dermed kan man utsette noe av ytelsesoptimaliseringen til man har bedre erfaring fra faktisk bruk.

Men det krever mer enn teknikker for å sette sammen systemene for å lykkes. Man må makte å finne oppgaver som man kan jobbe på og realisere verdi for organisasjonen i løpet av erstatningsprosjektet. Her er fire patterns for å finne områder å erstatte:

• Risiko: Enkelte endringer er så viktige at uten dem, vil prosjektet regnes som mislykkes. For prosjekter relatert til pensjonsreformen vil det være katastrofalt om man ikke kan implementere det nye regelverket. Andre systemer har lenge hatt kjente svakheter som man har forpliktet seg til å utbedre. Fiks dette først!
• Kostnad: Organisasjoner som benytter systemer har ofte noe arbeidsoppgaver som er ekstra arbeidskrevende. Kanskje det er å punsje data, eller å overføre data fra et system til et annet. Eller kanskje det er kundene som ringer og spør om hvordan saken deres ligger an. Ved å velge et slikt område kan prosjektet levere gevinst tidlig.
• Isolerte brukere: Mange systemer har brukergrupper som bare benytter en liten del av systemet. Det kan være lurt å starte med en slik brukergruppe, ettersom man kan erstatte hele den delen av systemet de benytter på noen få leveranser.
• Nye brukere: Mange organisasjoner ønsker å lage selvbetjeningsløsninger for publikum. Disse er også gode og vanlige steder å starte et fornyingsprogram.

Arkitektur

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”- Conway’s Law

En arkitekt på et stort prosjekt som lar prosjektlederen bestemme hvilke arbeidspakker hvert team skal jobbe med har begrenset mulighet til å påvirke prosjektets suksess.

Som arkitekt er det ofte fristende å jobbe med en målarkitektur. Men for et stort prosjekt blir målarkitekturens største føringer organisasjonen som skal utvikle systemet. Å oppfylle prosjektets behov for at folk kan jobbe uten å konstant ramle i beina på hverandre må prioriteres over andre arkitekturmål.

Jo flere kokker, desto mer søl. Det er din jobb å sørge for at ikke alle må være på samme kjøkken. Eller enda verre: Løpe mellom alle kjøkkenene.

Uortodoks observasjon #3:

I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg.

Min erfaring er at det finnes noe fundamentale grenser for hvor mange personer som kan samarbeide:

• 4-6 personer kan jobbe med en person som dekker arkitektur, analytiker og teamleder-rollene. Dersom gruppen blir større enn dette, må man typisk ha tre personer for å dekke disse rollene.
• 10-12 personer kan jobbe på den samme koden og med den samme produktkøen uten å komme i beina på hverandre. I alle fall så lenge de kommuniserer daglig
• 30-35 personer kan jobbe med en kodebase som er kontinuerlig integrert. Dersom det er flere, vil tiden man bruker på å rette integrasjonsfeil bli en betydelig kostnad.

Og når prosjektet blir for stort for kontinuerlig integrasjon, må gjenbrukt kode versjonshåndteres. Dette betyr at det vil være dyrt å gjøre endringer. Kode som ikke kan endres blir ofte dårlig kode. Så gjenbruk ut over 30-35 personer er overraskende dyrt.

Til slutt bør team ha som målsetning å produksjonsette hver tredje måned. Dette er veldig vanskelig å gjøre dersom en leveranse inneholder mange deler som ikke er kontinuerlig integrert. Deler som ikke er kontinuerlig integrert bør fortrinnsvis produksjonssettes helt separat fra hverandre.

Konklusjon

Et prosjekt som skal erstatte dagens system uten å endre forretningsprosessene har feil fokus. Modernisering er bra, men ha fokus på verdien til andre enn de som vedlikeholder systemet.

Vi har en rekke antagelser om hvordan erstatningsprosjekter vil fungere. Etter min erfaring er mange av disse antagelsene feil. Du kan godt ha annen erfaring, men her er min:

• Et erstatningsprosjekt er en dyr måte å forlenge livet til en eksisterende forretningsmodell
• Det nye og det gamle systemet vil leve sammen
• I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg

Vi får til erstatningsprosjekter ved å levere gradvis.

“Galls Law: A Complex System That Works Is Invariably Found To Have Evolved From A Simple System That Worked.”
- John Gall, Systemantics, 1975

Hvem?

Det viktigste når du skriver en blogpost er å være bevist på hvem dine lesere er. For denne artikkelen gjorde jeg meg følgende tanker:

• Hva er leserens forhold til tema? Jeg regner med at du som leser blogger litt eller tenker på å starte å blogge.
• Hva tenker leseren om tema? Jeg regner med at du synes det er vanskelig å komme i gang med bloggingen.
• Hva får de ut av å lese blogposten? Etter å ha lest posten vil jeg at du skal føle deg mer i stand til å skrive dine egne blogposter.

Hva?

Når du vet hvem du henvender deg til, er det viktigste å jobbe med innholdet og strukturen.

• Struktur: For hvert avsnitt vil du miste 5% av leserne (for å trekke et tall ut av lufta). Skriv det viktigste først
• Språk: Bruk aktivt språk som henvender seg direkte til leseren. Et eksempel på aktivt språk er: “Bruk aktivt språk som henvender seg direkte til leseren”
• Eksempler: Det er vanskelig å formidle abstrakte ideer. Eksempler er enklere.

Hvordan?

Når jeg starter med en blogpost, starter jeg nesten alltid med å kladde på papir. Jeg skriver strukturen ned, river i stykker papiret og skriver den ned på nytt. For meg fungerer det veldig godt å skrive på papir for å bearbeide tankene. Når jeg tar fram datamaskinen, blir jeg distrahert av verktøyene.

Mine mest populære artikler er de som der jeg har fått mye innspill av andre før jeg har publisert artiklene. Send utkast til artikkelen til folk du stoler på og be om konstruktiv tilbakemelding. Konstruktiv tilbakemelding er konkret og spesifikk: For eksempel: “Dersom blogposten hadde brukt punktlister også i siste avsnitt hadde den virket mer helhetlig uttenkt”. Personlig liker jeg best å dele utkastene mine med andre via Google Docs, framfor å maile vedlegg frem og tilbake.

Spre ordet via de kanalene du kommuniserer med: Pass på at bloggen har en RSS-feed. Bruk twitter, yammer, facebook, linkedin etc for å spre ordet. Ikke glem den gamle traveren email, heller (men for guds skyld, ikke spam folk!)

Hvorfor?

Som mennesker ligger trangen til å kommunisere i vårt DNA. Når jeg er entusiastisk om noe, føles det riktig å dele det. Å nå andre bekrefter vår egen eksistens.

Blogito, ergo sum!

Fokus på “hvorfor”, ikke “hvordan”

Hva forsøker denne testen å uttrykke:

Når en bruker registrerer en betaling med beløp “-1234567890″, så skal brukeren se en feilmelding

Hva med denne:

Når en bruker registrerer en betaling med et negativt beløp så skal brukeren få en passende feilmelding

Magiske tall, tekster og verdier i tester skjuler hva vi forsøker å spesifisere. Noen flere eksempler: “når en bruker utelater et eller flere påkrevde felter, så skal brukeren få en feilmelding knyttet til de manglende feltene”, “gitt at brukeren leverer en lottorekke med for få tall”.

Å koble slike tester mot systemet krever mer arbeid, spesielt de første gangene, men testene blir mye klarere etterpå. Og hovedformålet med en akseptansetest er at den er en spesifikasjon som kan diskuteres mellom prosjektet og omverdenen. Og da er det viktig å være klar. Noen ganger vil det virke svært vanskelig å automatisere forståelige spesifikasjoner. Da bør du huske at en god beskrivelse er mer verdifull enn en dårlig test.

Given-when-then

Noe av det første du lærer med tester er “bruk formen ‘gitt X, når Y, så Z’”. Men det er ikke alltid så klart hva X, Y og Z skal være. Tester består av tre typer steg:

• Arrange (oppsett, “given”): Beskriver tilstanden til systemet før testen starter. Typiske eksempler er “gitt at det eksisterer en bruker med utestående betalinger“, “gitt at tjenesten levert fra vår partner har registrert et varenummer” eller kanskje “gitt at det er en fredag” (du får vente til freddan). Avhengig av systemet og tilstanden vi beskriver, kan testen benytte disse stegene på forskjellige måter: Vi kan sette opp brukeren og betalingene i systemet, vi kan se på steget som en forutsetning som vi sjekker om er oppfylt, for eksempel ved å gjøre et søk mot tjenesten fra vår partner, vi kan forutsette, eller endog håpe at det er oppfylt og vi kan la steget kun være dokumentasjon, slik at når testen feiler, så vet vi noen ting vi kan verifisere manuelt, eller det kan være en ren løgn. Kanskje systemet er satt opp på en spesiell måte slik at det ikke er avhengig av ukedagen. Men vi har lyst til å dokumentere hvordan det hadde sett ut om det hadde vært “på ordentlig.”
• Act (utfør, “when”): Beskriver stimuli inn fra omverden. “Når brukeren registrerer en ny betaling,” “når klientsystemet sender en betalingsforespørsel med manglende kundeinformasjon”. Disse kan implementeres på flere måter i de fleste systemer: Et test av et web-grensesnitt kan simulere en klient med for eksempel webdriver, den kan gjøre et http-kall og direkte, eller testen kan bruke klassene som implementerer tjenesten direkte. For funksjonelle tester foretrekker jeg nesten alltid det siste. Det gjør at testene vil kjøre hundre ganger raskere, og vil som regel innebære mindre jobb. Husk: Det er ikke nødvendig å teste brukergrensesnittet på nytt for hver valideringsregel eller spesialtilfelle i applikasjonen din.
• Assert (sjekk, “then”): Beskriver hvordan systemet skal reagere på stimuli og hva tilstanden til systemet skal være etterpå. For eksempel “så skal brukeren få en feilmelding om at alle betalinger må være utført før en ny betaling kan registreres”, “så skal den nye betalingen ikke lagres i systemet.”

Veien fra testscript til spesifikasjoner

Når prosjekter først tar i bruk FitNesse er det veldig vanlig å se tester som ser cirka slik ut:

• Putt inn en kjempeliste med rader med en bråte kolonner inn i tabell A.
• Putt inn en ny kjempelist med rader etc i tabell B
• Send inn et kjempemessig XML dokument
• Sjekk at svaret matcher et nytt XML dokument

Dette er ikke en spesifikasjon – det er et testscript. Og det er ikke slike tester som gir verdi til et prosjekt. Men det er et sted å starte, for det krever ikke så veldig mye kreativitet. Og vi kan gjenbruke lærdommen fra slike tester. Men før det blir en hel skog av tester som dytter XML-dokumenter hit og dit, kan det være lurt å løfte testene opp på et mer logisk nivå:

• Gitt at det ikke eksisterer noen betalingsforespørsler
• Og en bruker er registrert
• Når brukeren sender inn en betalingsforespørsel med ett gitt problem
• Så skal brukeren få feilmeldingen en gitt feilmelding

I FitNesse-terminologi kan en slik test implementeres som en ColumnFixture. Det vil si: Hvert par av “problem” og “feilmelding” er en rad i en tabell. Slik kan vi uttrykke mange regler ved systemet klart og konsist.

Dersom du har startet å gå veien med testscript, er det ikke vanskelig å snu: For hver rad i den nye spesifikasjonen din skal du utføre alt det testscriptet ditt gjorde.

Jeg vil bruke jobben med akseptansetester til ikke bare å gjøre automatiske kjøringer av systemet mitt, men til å spesifisere og diskutere de egentlige kravene brukerne mine bryr seg om. Og dersom jeg må velge mellom tester som lar seg automatisere og spesifikasjoner som beskriver kravet, vil jeg alltid velge det siste.

For noen uker siden hadde jeg en interessant erfaring på prosjektet mitt. Jeg og produkteieren fra kunden satt oss ned og så hva vi hadde produsert de siste to ukene – fire “brukerhistorier” som beskrev hva applikasjonen skal gjøre. Hver hadde en estimert relativ kostnad. Meg: “Ett poeng, tre poeng, to poeng, ett poeng, det blir syv poeng totalt.” Kunden: “Ok. Og denne iterasjonen kostet 140.000 kroner. Det blir 20.000 per poeng, ikke sant.” Jeg: “Høres riktig ut. Så denne oppgaven (peker på en brukerhistorie) kostet seksti tusen. Oi, det var dyrt.” Kunden: “Oi. Ja, det var dyrt.” Stillhet. Litt ukomfortabel latter.

Dersom du blir helt ferdig med ting under veis i prosjektet og du holder greie på hva du gjør, blir plutselig prisen på arbeidet veldig tydelig. Både for kunde og leverandør kan dette være et skummelt øyeblikk, for utviklingsprosjekter er alltid dyrere i praksis enn det føles ut som de burde være i teorien.

En ærlig leverandør vil ikke love å levere billigere enn man har vist å levere så langt. En ærlig kunde vil vite at det blir dyrt uansett leverandør og at informasjonen om kostnaden har en verdi i seg selv.

Men både den som skal svare til sin kunde og den som skal svare til sin styringsgruppe kan få hjertet litt i halsen første gang man faktisk får erfaringstall på hva prosjektet koster. Man føler seg litt naken. Men det er befriende også. For da kan man ha en dialog som er basert på fakta i og ikke bare følelser.

Lykke til med ditt testbare prosjekt!

Uten mer om og men, poster jeg en video her av hvordan jeg liker å jobbe med tester for å drive fram “kravene” til en applikasjon og refactoring for å forme designet til applikasjonen. Se spesielt rundt 11:30 minutter inn i videoen hvor jeg refactorer inn et regelmotordesign i en fungerende løsning.

Oppgaven kalles “Fizz buzz kataen”. Den går ut på å generere en sekvens av nummer der hvert tall som er delelig på 3 erstattes med “fizz” og alle tall som er delelig på 5 erstattes med “buzz”. Så starten blir “1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, buzz, 11, etc.” Seks minutter inn i kataen endres kravet (og musikken!): Nå skal man kunne programmere inn hvilke erstatningsregler som gjelder. Som eksempel bruker jeg at “tall delelig med 2 skal erstattes med ‘coconut’ og tall delelig med 7 skal erstattes med ‘banana’”.

Takk til Emily Bache for inspirasjon til oppgaven.

Fizz buzz code kata av Johannes Brodwall på Vimeo.

Jeg bruker IntelliJ IDEA Community Edition på Windows Vista (!) til å løse oppgaven. Videoen er filmet med BB FlashBack Express (som er gratis), konvertert til AVI med Windows Media 1 codec og lastet opp til Vimeo.

Denne blogposten var originalt publisert på engelsk på min personlige blog.