Foredrag holdt på SSA-konferansen 2011. Difi nærmer seg ferdigstilling av en ny standardavtale som kan benyttes ved utvikling av IT-prosjekt basert på smidige eller agile metoder.

1. SMIDIG SYSTEMUTVIKLINGSAVTALE
SSA-S
av rådgiver Anne-Lise Monsen
Thursday, May 26, 2011

2. INNHOLD
“Ny smidig systemutviklingsavtale fra Difi - statusoppdatering”
• Hvorfor lager vi denne avtalen? • Hvordan har vi
implementert smidig
• Kort om hva smidig metodikk i avtalen?
systemutvikling er -
i motsetning til • Når bør den brukes?
fossefallsmodellen
• Når er avtalen ferdig?
• Hvordan er avtalen bygget opp
Thursday, May 26, 2011

3. KORT OM HISTORIEN
Arbeidet ble påbegynt første gang i 2006
Utkast ligger på nettsidene våre - men den
kan ikke anvendes uten å gjøre en god del
endringer.
Arbeidet ble gjenopptatt i 2010
Frivillig arbeidsgruppe etablert
Thursday, May 26, 2011

4. DAGENS STATUS
Arbeidsgruppen har brukt mye tid på
prosessen bak avtalen
Prosessen er nå nedfelt i et kontraktsdokument
i SSA-struktur
Første utkast har nettopp vært på høring hos
arbeidsgruppen
Andre utkast skal på høring om 2-3 uker
Avtalen er (planlagt) ferdig etter sommerferien
Thursday, May 26, 2011

5. Hvem er du, og hvorfor skal du lage
en smidig systemutviklingsavtale?
Jeg er Difi - og jeg synes det er bra
med litt konkurranse!
La oss spille hverandre gode!
Thursday, May 26, 2011

6. HVA ER SMIDIG SYSTEMUTVIKLING?
Ikke et introkurs -
men noen helt sentrale punkter må nevnes
Thursday, May 26, 2011

7. HVA ER
Lag kravspesifikasjon FOSSEFALLSMETODEN?
Skriv kontrakt
Forbered og organiser
Detaljspesifisering
Utvikling
Installasjon
Akseptansetesting
Godkjenning
Leveringsdag
Thursday, May 26, 2011

8. Thursday, May 26, 2011

9. HVA ER SMIDIG SYSTEMUTVIKLING?
Utviklerne
Kundens beskriver hva Leverandørens prosjektleder Systemet ble
programmerte
han vil ha forstår det slik designet slik
det slik
Thursday, May 26, 2011

10. HVA ER SMIDIG SYSTEMUTVIKLING?
Det kunden
egentlig trengte
Thursday, May 26, 2011

11. KOMMUNIKASJON
Thursday, May 26, 2011

12. HVA ER SMIDIG SYSTEMUTVIKLING?
Kunden finner ut hvilke behov han
har - og beskriver disse på et
overordnet nivå
Kundens behov nedfelles i en
funksjonsliste (product backlog)
Thursday, May 26, 2011

13. HVA ER SMIDIG SYSTEMUTVIKLING?
Utviklerne plukker ut så mange funksjoner som de
tror de kan få utviklet i løpet av en iterasjon/sprint,
og bryter funksjoene ned i en oppgaveliste
(sprint backlog)
Thursday, May 26, 2011

14. HVA ER SMIDIG SYSTEMUTVIKLING?
• Utvikling foregår i “iterasjoner”
- eller “sprinter”
• Lengen for en iterasjon er f. eks
satt til 28 dager
Thursday, May 26, 2011

15. HVA ER SMIDIG SYSTEMUTVIKLING?
Når iterasjonen så er ferdig - har utviklerne
forhåpentligvis fått utviklet alle de oppgavene
som de påtok seg før iterasjonen satt i gang.
“Pakken”,
illustrerer en delleveranse
Thursday, May 26, 2011

16. HELHETEN
Funksjonsliste Oppgaveliste Iterasjon
Delleveranse
(Product Backlog) (Sprint Backlog) (Sprint)
Thursday, May 26, 2011

17. Thursday, May 26, 2011

18. FORDELENE?
• Leverandøren får bedre forståelse for kundes behov, ved at
kunden samarbeider tett med leverandøren.
• Kunden kan be om endringer underveis mens prosjektet
utvikles.
• Leveransen vil være i tråd med hvordan kunden så for seg at
leveransen skulle være
• Kunden tester hyppig, og derfor vil feil avdekkes i en tidlig
fase. Det gjør det lettere (og billigere!) å rette feilene.
• Kontinuerlig produksjonssetting gjør at systemet kan tas i
bruk før det er ferdig i sin helhet
Thursday, May 26, 2011

19. CHANGE!
Thursday, May 26, 2011

20. OM AVTALEN
• Avtaletekst - i “SSA-stil”
• 10 bilag - ny struktur
• Veiledning - dynamisk dokument
Thursday, May 26, 2011

21. AVTALENS OMFANG
1.1 Avtalens omfang
“Avtalen gjelder utvikling av IT-system spesielt
utviklet eller tilpasset for Kunden, samt levering
av øvrige tjenester og ytelser som står i
forbindelse med dette (“leveransen”). Avtalen
regulerer også eventuell leveranse av utstyr.”
Thursday, May 26, 2011

22. AVTALENS BILAG
Thursday, May 26, 2011

23. PROSJEKTORGANISERING
Styrings-
gruppe Detaljerings-
gruppe
Utviklingsteam
Thursday, May 26, 2011

24. Styrings-
- Behandle statusrapporter
gruppen knyttet til av vik eller
andre problemer
- Utskifting av
underleverandør
- Utskifting av
nøkkelpersonell
Thursday, May 26, 2011

25. Detaljerings-
- Jobb med funksjonslisten!
gruppen
- Prioriter funksjonene i
funksjonslisten
- Bryt funksjonene ned i
mindre bolker slik at
ut viklingsteamet kan lage
en håndterbar oppgaveliste
Thursday, May 26, 2011

26. - Plukk ut funksjoner fra toppen
Utviklingsteam av funksjonslisten, g jør dem om
til oppgaver i en oppgaveliste
- Velg ut så mange funksjoner
som du tror du kan få ut viklet i
én iterasjon
- Sett i gang med ut vikling, test,
dokumentering og utarbeidelse av
testplan
- Rapporter fremdrift jevnlig.
(det er masse annet du må g jøre også....)
Thursday, May 26, 2011

27. Utviklingsmiljø Systemtestmiljø
Produksjons- Produksjons-
testmiljø miljø
Thursday, May 26, 2011

28. SPRINT ZERO
Første fase i prosjektet Gjøres av detaljeringsgruppen
Sprint zero = Forberedende arbeid med funksjonslisten
Skal inneholde: Hvis relevant:
Beskrivelse av Spesielle krav til kundens medvirkning
funksjonen
Virkning på tidligere utviklede funksjoner
Grovestimat for
utvikling av
funksjonen Virkning på krav til teknisk plattform
Unik prioritet Behov for endring i testplan og testkriterier
Betydning for fremtidig vedlikehold av
standardmoduler, tilpasninger og spesialutviklede
moduler.
Thursday, May 26, 2011

29. DETALJERING, SPESIFISERING OG
PRIORITERING AV FUNKSJONSLISTEN
Detaljeringsgruppen skal fortsette arbeidet med
å detaljere, spesifisere og prioritere funksjonslisten.
Kunden kan omprioritere, fjerne og legge til nye
elementer i funksjonslisten gjennom hele kontraktsløpet
Men - noen restriksjoner:
Hvis funksjonen er
påbegynt spesifisert Anskaffelsesregelverket
eller utviklet
Thursday, May 26, 2011

30. OPPGAVELISTEN
Utviklingsteamets ansvar (men kunden må bidra)
Plukker elementer fra toppen av funksjonslisten
Bryter elementene ned til en håndterbar oppgaveliste
Elementene skal detaljspesifiseres og detaljestimeres
Spesifikasjon og estimat skal minimum omfatte følgende:
(1) Beskrivelse av oppgaven,
(2) Beskrivelse av omfang og tidsforbruk for arbeid med
å utvikle oppgaven
Og hvis relevant:
(3) Krav til kundens medvirkning
(4) Virkning på tidligere utviklede oppgaver
(5) Behov for endring i testplan og testkriterier
Thursday, May 26, 2011

31. ITERASJONSPLANLEGGINGSMØTE
Før hver iterasjon skal det holdes et
iterasjonsplanleggingsmøte
Detaljeringsgruppen beskriver funksjonene
med høyest prioritet for utviklingsteamet
Utviklingsteamet kan spørre om alt de lurer
på (kommunikasjon!)
Etter møtet flytter utviklerne så mange
funksjoner som de tror de kan få utviklet i
løpet av én iterasjon, til oppgavelisten.
Det er utviklerne selv som bestemmer hvor
mye som skal inntas i iterasjonen.
Thursday, May 26, 2011

32. UTVIKLING
Iterasjonsutvikling:
Utviklingsteamet utvikler, tilpasser, integrerer,
tester og dokumenterer.
Parallelt utarbeides testplan
Rapportere fremdrift i prosjektet til kunden
ukentlig (faktisk og forventet timebruk opp mot
estimert timebruk)
Standard iterasjonslengde: 28 dager
Thursday, May 26, 2011

33. ITERASJONSDEMO
Etter endt iterasjon avholdes
iterasjonsdemo
Leverandøren demonstrerer ferdig utviklet
funksjonalitet
Dersom praktisk mulig:
demonstrasjon i produksjonstestmiljø
Thursday, May 26, 2011

34. DOKUMENTASJON
enta sjon
Do kum
Thursday, May 26, 2011

35. HVA SKJER MED LEVERTE PAKKER?
Leverandøren leverer “pakker” etter hver iterasjon
Hver pakke skal (så langt det er mulig) integreres med
tidligere leverte “pakker”.
Pakkene produksjonssettes etter fremdriftsplan (sjelden
hensiktsmessig å produksjonssette alle pakker fortløpende)
Kunden setter i gang testingen. Det testes:
Per iterasjon
Per produksjonssetting
Heheltstesting
Thursday, May 26, 2011

36. NOEN MILEPÆLER
Installasjonsdag:
Inntrer når man produksjonssetter del- eller helleveranser
Idriftsettingsdag:
Inntrer når systemet er levert i sin helhet - og kundens
helhetstest er vellykket gjennomført og godkjent.
Thursday, May 26, 2011

37. GODKJENNINGSPERIODE..?
Valgfritt om man
Tatt ut av avtalen, ønsker å
lagt til bilag gjennomføre
godkjenningsperiode
Thursday, May 26, 2011

38. BETALING
Ikke helt ferdig med denne delen av kontrakten
Fastpris Målpris Timepris
Ulike prisbilag-modeller?
Thursday, May 26, 2011

39. HVEM BØR BRUKE AVTALEN,
OG NÅR BØR DEN BRUKES?
Innovative kunder som forstår hvilken grad av
samarbeid og ressurser som en nødvendig
Ingen fasit på når man bør kjøre fossefall og
når man bør kjøre smidig. Vurderes konkret.
Thursday, May 26, 2011

40. MINE TANKER OM AVTALEN
• SSA-smidig vs. PS2000
• Metoden
• Utfordrende med
administrasjon
• Utfordrende ved konflikt
Thursday, May 26, 2011

41. HVA NÅ?
Avtalen kommer rett etter sommeren
Bilagssett publiseres samtidig
Oppforer alle med interesse for temaet til å bidra i
høringsrunden
Avtalen vil bli revidert etter at vi har høstet
erfaringer
Ønsker du å holde det oppdatert?
Meld deg på SSA-nyhetsbrevet.
Frokostseminar om avtalen til høsten
Thursday, May 26, 2011

42. INNHOLD
Hva er status?
Hvorfor lager Difi denne
avtalen?
Kort om hva smidig
systemutvikling er - i
motsetning til fossefallsmodellen
Hvordan er avtalen bygget opp?
Hvordan har vi implementert
smidig metodikk i avtalen?
Når bør den brukes?
Når er den ferdig?
Thursday, May 26, 2011

43. ARBEIDSGRUPPEN
Atle Gram - Computas Kari Anne Støkken - Lånekassen
Jorunn Værp - Bouvet Mette Gulbrandsen - Bouvet
Jarle Roar Sæbø - HP Ragnar Lindefjeld - Wiersholm
Inger-Anne Folkestad - Atea Audun Rundberg - Bufetat
Andreas Wahl - Bull & Co Simen Fure Jørgensen - Iterate
Sigbjørn Krunenes - Devoteam Anne-Lise Monsen - Difi
Thursday, May 26, 2011

44. is e
- L
n e
A n
e n
i ls
H
Thursday, May 26, 2011