Smidig systemutviklingsavtale fra Difi - status

SMIDIG SYSTEMUTVIKLINGSAVTALESSA-S

av rådgiver Anne-Lise Monsen

Thursday, May 26, 2011

INNHOLD

• Hvorfor lager vi denne avtalen?

• Kort om hva smidig systemutvikling er - i motsetning til fossefallsmodellen

• Hvordan er avtalen bygget opp

“Ny smidig systemutviklingsavtale fra Difi - statusoppdatering”

• Hvordan har vi implementert smidig metodikk i avtalen?

• Når bør den brukes?

• Når er avtalen ferdig?


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


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


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!


HVA ER SMIDIG SYSTEMUTVIKLING?

Ikke et introkurs - men noen helt sentrale punkter må nevnes


HVA ER FOSSEFALLSMETODEN?Lag kravspesifikasjon

Skriv kontrakt

Forbered og organiser

Utvikling

Akseptansetesting

Leveringsdag

Detaljspesifisering

Installasjon

Godkjenning




Kundens beskriver hva han vil ha

Leverandørens prosjektleder forstår det slik

Systemet ble designet slik

Utviklerne programmerte

det slik



Det kunden egentlig trengte


KOMMUNIKASJON



Kunden finner ut hvilke behov han har - og beskriver disse på et overordnet nivå

Kundens behov nedfelles i en funksjonsliste (product backlog)



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)



• Utvikling foregår i “iterasjoner” - eller “sprinter”

• Lengen for en iterasjon er f. eks satt til 28 dager



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


HELHETEN

Funksjonsliste (Product Backlog)

Oppgaveliste(Sprint Backlog)

Iterasjon (Sprint) Delleveranse



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


CHANGE!


OM AVTALEN

• Avtaletekst - i “SSA-stil”

• 10 bilag - ny struktur

• Veiledning - dynamisk dokument


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.”


AVTALENS BILAG


PROSJEKTORGANISERING

Styrings-gruppe Detaljerings-

gruppe

Utviklingsteam


Styrings-gruppen

- Behandle statusrapporter knyttet til avvik eller andre problemer

- Utskifting av underleverandør

- Utskifting av nøkkelpersonell


Detaljerings-gruppen

- Jobb med funksjonslisten!

- Prioriter funksjonene i funksjonslisten

- Bryt funksjonene ned i mindre bolker slik at utviklingsteamet kan lage en håndterbar oppgaveliste


Utviklingsteam- Plukk ut funksjoner fra toppen av funksjonslisten, g jør dem om til oppgaver i en oppgaveliste

- Velg ut så mange funksjoner som du tror du kan få utviklet i én iterasjon

- Sett i gang med utvikling, test, dokumentering og utarbeidelse av testplan

- Rapporter fremdrift jevnlig.

(det er masse annet du må g jøre også....)


Utviklingsmiljø Systemtestmiljø

Produksjons-miljø

Produksjons-testmiljø


SPRINT ZERO

Gjøres av detaljeringsgruppenFørste fase i prosjektet

Sprint zero = Forberedende arbeid med funksjonslisten

Beskrivelse av funksjonen

Grovestimat for utvikling av funksjonen

Unik prioritet

Hvis relevant:Spesielle krav til kundens medvirkning

Virkning på tidligere utviklede funksjoner

Virkning på krav til teknisk plattform

Behov for endring i testplan og testkriterier

Betydning for fremtidig vedlikehold av standardmoduler, tilpasninger og spesialutviklede moduler.

Skal inneholde:


DETALJERING, SPESIFISERING OG PRIORITERING AV FUNKSJONSLISTEN

Men - noen restriksjoner:

Hvis funksjonen er påbegynt spesifisert

eller utvikletAnskaffelsesregelverket

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


OPPGAVELISTENUtviklingsteamets 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


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.


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


ITERASJONSDEMO

Etter endt iterasjon avholdes iterasjonsdemo

Leverandøren demonstrerer ferdig utviklet funksjonalitet

Dersom praktisk mulig: demonstrasjon i produksjonstestmiljø


DOKUMENTASJON

Dokumentasjon


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


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.


GODKJENNINGSPERIODE..?

Tatt ut av avtalen, lagt til bilag

Valgfritt om man ønsker å

gjennomføre godkjenningsperiode


BETALING

Ikke helt ferdig med denne delen av kontrakten

Fastpris Målpris Timepris

Ulike prisbilag-modeller?


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.


MINE TANKER OM AVTALEN

• SSA-smidig vs. PS2000

• Metoden

• Utfordrende med administrasjon

• Utfordrende ved konflikt


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


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?


ARBEIDSGRUPPEN

Atle Gram - Computas

Jorunn Værp - Bouvet

Jarle Roar Sæbø - HP

Inger-Anne Folkestad - Atea

Andreas Wahl - Bull & Co

Sigbjørn Krunenes - Devoteam

Kari Anne Støkken - Lånekassen

Mette Gulbrandsen - Bouvet

Ragnar Lindefjeld - Wiersholm

Audun Rundberg - Bufetat

Simen Fure Jørgensen - Iterate

Anne-Lise Monsen - Difi


Hilsen A

nne-Li

se


Technology

Smidig systemutviklingsavtale fra Difi - status