Smidige metoder er som sjakk: Du kan lære grunnreglene på en kveld, men bruke hele livet på å mestre detaljene. I denne guiden får du konkrete tips om hvordan du forbedrer kommunikasjon, kvalitet og verdiskapning i smidige og ikke-smidige prosjekter.

1. Tema: Smidig systemutvikling
è www.steria.no/guide
è Slik lykkes du med smidig utvikling
Smidige metoder er som sjakk: Du kan lære grunnreglene på en kveld, men bruke hele
livet på å mestre detaljene. I denne guiden får du konkrete tips om hvordan du forbedrer
kommunikasjon, kvalitet og verdiskapning i smidige og ikke-smidige prosjekter.
è Denne guiden lærer deg mer om hvor- dag og som har myndighet til svare på - Daglig kommunikasjon mellom
dan du får bedre kommunikasjon, kvalitet avklaringer angående dagens oppgaver. kunde og leverandør har stor doku-
og forretningsfokus i utviklingsprosjekter. mentert effekt på hvor vellykket et
Vi har fokusert på at tipsene skal være 2. Programmér sammen prosjekt blir.
nyttige uansett om prosjektet kjøres med Utviklere på prosjekter innehar enorm
smidig metodikk eller ikke. kunnskap, både om de delene av systemet lagt i iterasjonen. Lappene henger i kolonner
man lager og om programmering generelt. “venter”, “under arbeid” og “ferdig”. Opp-
SLIK BEDRER DU KOMMUNIKASJONEN Når man programmerer i par og roterer gaven på hver lapp bør ha et så lite omfang
God kommunikasjon i prosjektet fører til hvem som jobber sammen hyppig, blir at teamet kan flytte flere lapper til “ferdig”
færre misforståelser, mer følelse av eier- denne kunnskapen spredt til alle. Dermed hver dag.
skap og bedre kontroll. reduserer man konsekvensen når noen er
SLIK ØKER DU KVALITETEN
syke eller på ferie og alle får lært mer på
Det finnes flere måter å måle kvalitet på,
1. Inkluder kunden på morgenmøtene jobben. Spe gjerne på med seanser der
og ikke alle metodene er like gode i prak-
Daglig kommunikasjon mellom kunde og hele teamet går gjennom deler av koden
tisk bruk. I Steria fokuserer vi på kvalitet
leverandør har en dokumentert enorm på storskjerm.
som gjør sluttresultatet så godt som mulig i
effekt på hvor vellykket et prosjekt blir.
henhold til kundens behov og ønsker.
Teamets fokus blir mye bedre dersom det 3. Bruk en Scrum-tavle
er noen på de daglige standup-møtene For å hjelpe alle å huske på hva som er målet
1. Verifiser krav med funksjonelle tester
som er interessert i å prøve ut det som har med iterasjonen, er det lurt om teamet
Når teamet skal jobbe med en oppgave i en
blitt laget i går, som er interessert i å holder standup-møtene rundt en tavle med
iterasjon, er det viktig at alle har konkret
komme med innspill på det som lages i lapper for alle aktiviteter teamet har plan-
forståelse av oppgaven. Kunden bør beskri-

2. ve eksempler for å gjøre oppgavene mest
mulig konkrete. Om mulig, bør kunden
uttrykke eksemplene i et verktøy for auto-
matisert funksjonell testing, for eksempel
FitNesse eller Cucumber. Teamet kan da
kjøre testene og automatisk sjekke at de
oppfyller kundens forventning.
2. Skriv testen før du skriver koden
For å kunne utvikle funksjonalitet inkre-
mentelt, 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 funk-
sjonelle testene kan gi et sikkerhetsnett,
men det tar typisk lang tid å kjøre dem og
de gir ofte ikke en eksakt indikasjon av hva Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon.
som er feil når noe ikke virker. Derfor bør Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretnings-
teamet skrive raske tester som verifiser at verdi. Dét er måten du lykkes på med smidige prosjekter.
klassene i systemet fungerer, helst før man
skriver koden som skal testes. Da unngår
man å tilpasse testen til koden, men tilpas-
ser isteden koden til testen som på sin side 2. Bli helt ferdig med funksjonalitet Slik lykkes du med smidig utvikling
baserer seg på kundens forventninger. Teamet får kun “poeng” for helt dønn ferdig 1. Ta med kunden på morgenmøte
utført arbeid. Etter en iterasjon bør alt som
2. Programmér sammen
3. Integrer endringer bedre tilhører en oppgave være så ferdig at det
Endringer bør integreres kontinuerlig og er greit dersom man aldri mer bruker tid på 3. Heng opp oppgaver på en tavle
automatisk. Automatiske tester er kun ver- koden. Koden, tester og dokumentasjon må 4. Verifiser krav med funksjonelle tester
difulle dersom de kjøres! Sett derfor opp en være i en akseptabel tilstand. Det betyr ikke 5. Skriv tester før du skriver kode
Continuous Integration server som sjekker at koden er frosset. Dersom man for eksem-
ut og tester alle endringer hver gang en pel utfører en oppgave for å verifisere 6. Integrer endrering hele tiden
utvikler har sjekket inn en endring til kilde- responstid, må teamet oppdatere eksiste- 7. Bruk en prioritert produktkø
kodekontroll. Om mulig bør dette systemet rende kode slik at den støtter tidsmålinger 8. Helt dønn ferdig
også automatisk installere den siste versjo- og at man korrigerer eventuelle ytelsespro-
9. Hold demonstrasjon for brukerne underveis
nen av programvaren til et egnet testmiljø, blemer man oppdager. Dette arbeidet tilhører
slik at kunden alltid kan se hva som er siste det å implementere responstidskravet – den
versjon av systemet. originale funksjonen er ferdig. Les mer på: agilemanifesto.org/iso/no/
BEDRE FORRETNINGSFOKUS 3. Demonstrer systemet underveis
Det hjelper ikke om man lager det beste Dersom du lager et system som skal inter-
tenkelige tekniske systemet dersom det essere dine fremtidige brukere, bør teamet
ikke er det systemet som har verdi for bru- ha noe spennende å vise dem med jevne
kerne. Det viktigste elementet i et prosjekt mellomrom. Bruk gjerne Scrums demo-møte
er å sørge for at man prioriterer riktig hva til å involvere brukerne. Sørg for at input
som skal lages. fra brukerne blir tatt hensyn til, og at de får
beskjed om innspill som har blitt implemen-
tert, slik at de fortsetter å interessere seg.
Kontakt
- Automatiske tester er svært lite
verdifulle dersom de ikke kjøres.
FELLES FORSTÅELSE
Et prosjekt som vet hva det som skal
1. Bruk prioritert produktkø lages, der man konstant deler forståelsen
Mange team lurer på hvilke oppgaver som av problemet og løsningen og der systemet
skal puttes på produktkøen. Dersom noe som lages er teknisk fremragende gir
gir forretningsverdi og tar betydelig tid å bærekraftig verdi for kunden. Disse tipsene Johannes brodwall
utføre, bør kunden inkludere oppgaven på er gode å starte med for å nå gullet i enden Chief Scientist
produktkøen. Ikke-funksjonelle krav må av regnbuen. Tlf. 980 57 660 / E-post: jb@steria.no
som regel testes. Det tar tid å sette opp
Steria AS
testene og rette opp eventuelle mangler. Biskop Gunnerus’ gate 14A
Ikke-funksjonelle krav skal på produktkøen. Postboks 2, N-0051 OSLO
Brukerdokumentasjon må skrives og kvali-
è Gå inn på www.steria.no/guide og
tetsikres. Det tar tid å skrive god bruker- få tilgang til et helt bibliotek med gratis
dokumentasjon. Brukerdokumentasjon skal 3-minutters guider.
på produktkøen.
© 2011 Steria AS. Versjon: 2011-03-21