Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012

Transkript

1 Kontrakter og test i smidige prosjekter Fagmøte Dataforeningen i Trondheim 12.Mars 2012

2 Agenda Smidige manifest Smidige prosjekter og testing Samarbeid og tillit teori Hva er en kontrakt Gjennomgang av PS2000 og SSA-S Egne erfaringer fra smidige prosjekter

3 Smidige manifest Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.

4 Scrum som eksempel på smidig metodikk Karakteristikker Produkt- og sprintbacklog 2-4 ukers sprinter Produkteier Demo etter hver sprint Tett samarbeid mellom kunde og leverandør Test i smidige prosjekter Test i og etter sprint Enhetstest- og systemtestnivå Automatisert testing Godkjenning av leveranser underveis ikke bare i akseptansetest Systemintegrasjonstester Akseptansetest

5 Samarbeid og tillit er nøkkelen For at et smidig prosjekt skal bli vellykket krever det et godt samarbeid mellom kunde og leverandør og høy grad av tillit

6 Utfordringer rundt samarbeid i team Samarbeid har en kostnad Det finnes alltid barrierer mot samarbeid Samarbeid må læres, noe som tar tid, men ofte er det budsjettert med for liten tid til læring av samarbeid Samarbeid krever tillit

7 Hvordan oppnå tillit? Tillit som basic trust og lim i samarbeid Tillit eksisterer som en relasjon mellom flere aktører og ikke som en egenskap ved individuelle aktører. Tillit er dynamisk og vil stadig forandres gjennom aktørenes interaksjon. Tillit må læres. Tillit er vanskelig å etablere og lett å ødelegge. Ref: UIO, PSY2400: Ledelse og kommunikasjon Vårsemester 2005

8 Kontrakter Definisjon av en kontrakt: Gjensidig bebyrdende avtale som inngås skriftlig mellom en eller flere oppdragsgivere og en eller flere leverandører anskaffelser.no Skrevne regler som skal regulere samarbeid og eventuelle problemer som kan oppstå

9 Smidige kontrakter Trenger man kontrakter i et smidig prosjekt hvor alt skal være basert på tillit? Kan vi ikke bare stole på det smidige manifest? Hvor mye av testingen tenger å være regulert i kontrakten for smidige prosjekter?

10 Smidige kontraktsformer PS-2000 Kontraktsstandard som forvaltes av DND Utviklet under forskningsprogrammet PS2000 i regi av Sintef og NTNU Kan kjøpes på DND sine sider SSA-S Kontraktsstandard under utvikling Ute på høring nå. Svarfrist 14.mai! Forvaltes av Difi Gratis Page 10 Version 0.3

11 PS-2000 Smidig Generelt Tar utgangspunkt i en iterativ modell Benytter Scrum som utgangspunkt Samme standardtekst som standard PS-2000 Består av 3 deler: Kontraktsdokument Definerer kontraktspartene og kontraktsinnhold og -struktur Generelle kontraktsbestemmelser Standardtekst som legger alle generelle føringer (komplett utfylt) Spesifikke forhold (Bilag) Bilag som regulerer den spesifikke leveranse (delvis utfylt)

12 PS Begreper PS-2000: Kontrollpunkt etter hver iterasjon (sprint) Målpris Innledende løsningsbeskrivelsesfase Smidig veileder Brenndiagram Brukerhistorie Daglig Scrum Produkteier Produktkø Sprintkø Sprintdemo etc Page 12 Version #

13 PS2000 Smidig veileder Hva sier kontraktens veileder om test? Felles teststrategi Testmiljø Kontrollpunkt Test i og etter sprint Automatisert tester Kundens deltagelse Ansvar Vurder SIT tidlig som mulig Avsluttende ST før kundens AT/GP

14 SSA-S Høringsutkast Generelt Smidig modell inspirert av Scrum Kapittel 2 i avtaleteksten er spesielt tilpasset Øvrige kapitler tilnærmet lik de andre SSA Består av standard vedlegg: Bilag 1 Kundens behovsbeskrivelse Bilag 2 Leverandørens løsningsbeskrivelse Bilag 3 Kundens tekniske plattform og IT-miljø Bilag 4 Prosjekt- og fremdriftsplan Bilag 5 Testing, godkjenning og idriftssetting Bilag 6 Administrative bestemmelser Bilag 7 Samlet pris og prisbestemmelser Bilag 8 Endringer i avtaleteksten Bilag 9 Endringer av leveransen etter avtaleinngåelse Page 14 Version #

15 SSA-S Begreper Generelt Produktkø Sprinter Sprintkø Daglig møte Ferdigdefinisjon Sprintgjennomgangsmøte Sprintevaluering etc Test Avsatt feilrettingstid Test i løpet av sprinten og etter AT av delleveranser AT av samlet leveranse Helhetstest = Akseptansetest (AT) Page 15 Version #

16 SSA-S Hva sier kontrakten om test? Teststrategi felles mellom kunde og leverandør Avsatt feilrettingstid Fra og med sprint nr 2 Ferdigdefinisjon i Bilag 5 Kunde skal teste resultatet fra forrige sprint Akseptansetest på delleveranse-nivå Akseptansetest av samlet leveranse - Helhetstest Samlet leveranse kan bestå av en eller flere delleveranser Helhetstest minimum gjennomføres som en regresjonstest Deler som er godkjent i AT tidligere kan ikke underkjennes i senere delleveranser Det vil da bli håndtert som en endring

17 Erfaringer fra smidige prosjekter Tilliten mellom kunde og leverandør - avgjørende faktor Ryddig bruk av kontrakt har bidratt til at det har vært mulig for kunde å samarbeide flere leverandører i samme prosjekt Kvalitet i smidige prosjekter kommer ikke av seg selv Bruk kontrollpunktet! Gjør porten som koden skal gjennom før produksjonssetting så liten som mulig Ikke vent med kvalitetssikring av kodekvalitet til akseptansetesten God kvalitet og effektive tester oppnås bare med et godt rammeverk for: Kodestandard og kodegjennomganger Felles teststrategi og implementering av den God tilgang til funksjonelle ressurser underveis Tidlig integrasjonstesting Avsluttende system- og akseptansetest som fokuserer på eksterne integrasjoner og verdikjeder Kontraktsfestet bruk av kontrollpunkt eller andre quality gates

18 Foreløpig takk for meg! Page 18 Version #

19 Fossefall vs Smidig Fossefall: Kravspesifikasjon i kontrakt med leverandørens besvarelse Akseptansekriterier i kontrakt eller minimum i teststrategien Test mot kravspesifikasjon og/eller oppdaterte krav Har leverandøren levert i forhold til hva kravene sier? Stor og omfattende systemtest og akseptansetest på slutten Ønsker helst ikke endringer Smidig: Behovsbeskrivelse i kontrakt Løsningsbeskrivelsesfase sammen med leverandøren Brukerhistorier og/eller akseptansetester for hver sprint som grunnlag for test og godkjenning Delvise godkjenninger underveis Fokus på kode som virker og gjør det kunden ønsker Ønsker endringer

20 Hva betyr dette for kontrakten og test-bilaget? Veldig likt, men Startkriterier og krav til avslutning for testnivåene kan beskrives bare for overgangen til: Avsluttende ST Kundens AT Definisjon av ferdig (definition of done) Ansvar for testing må beskrives i henhold til at man jobber smidig Kundens deltagelse i utarbeidelse av testbeskrivelser under Leverandørens tester Leverandøren er fortsatt ansvarlig men Kunden må forplikte seg til å delta Felles testverkøty Automatiserte tester kan gjenbrukes i forvaltning Testprosedyrer kan gjenbrukes Felles feil-logg Page 20 Version #

21 Takk for meg! Marianne Falkenås Sjefskonsulent Sogeti Mobil Page 21 Version #