Smidig systemutviklingsavtale fra Difi - status

Preview:

DESCRIPTION

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.

Citation preview

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?

Thursday, May 26, 2011

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

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

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

HVA ER SMIDIG SYSTEMUTVIKLING?

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

Thursday, May 26, 2011

HVA ER FOSSEFALLSMETODEN?Lag kravspesifikasjon

Skriv kontrakt

Forbered og organiser

Utvikling

Akseptansetesting

Leveringsdag

Detaljspesifisering

Installasjon

Godkjenning

Thursday, May 26, 2011

Thursday, May 26, 2011

HVA ER SMIDIG SYSTEMUTVIKLING?

Kundens beskriver hva han vil ha

Leverandørens prosjektleder forstår det slik

Systemet ble designet slik

Utviklerne programmerte

det slik

Thursday, May 26, 2011

HVA ER SMIDIG SYSTEMUTVIKLING?

Det kunden egentlig trengte

Thursday, May 26, 2011

KOMMUNIKASJON

Thursday, May 26, 2011

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

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

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

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

HELHETEN

Funksjonsliste (Product Backlog)

Oppgaveliste(Sprint Backlog)

Iterasjon (Sprint) Delleveranse

Thursday, May 26, 2011

Thursday, May 26, 2011

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

CHANGE!

Thursday, May 26, 2011

OM AVTALEN

• Avtaletekst - i “SSA-stil”

• 10 bilag - ny struktur

• Veiledning - dynamisk dokument

Thursday, May 26, 2011

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

AVTALENS BILAG

Thursday, May 26, 2011

PROSJEKTORGANISERING

Styrings-gruppe Detaljerings-

gruppe

Utviklingsteam

Thursday, May 26, 2011

Styrings-gruppen

- Behandle statusrapporter knyttet til avvik eller andre problemer

- Utskifting av underleverandør

- Utskifting av nøkkelpersonell

Thursday, May 26, 2011

Detaljerings-gruppen

- Jobb med funksjonslisten!

- Prioriter funksjonene i funksjonslisten

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

Thursday, May 26, 2011

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å....)

Thursday, May 26, 2011

Utviklingsmiljø Systemtestmiljø

Produksjons-miljø

Produksjons-testmiljø

Thursday, May 26, 2011

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:

Thursday, May 26, 2011

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

Thursday, May 26, 2011

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

Thursday, May 26, 2011

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

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

ITERASJONSDEMO

Etter endt iterasjon avholdes iterasjonsdemo

Leverandøren demonstrerer ferdig utviklet funksjonalitet

Dersom praktisk mulig: demonstrasjon i produksjonstestmiljø

Thursday, May 26, 2011

DOKUMENTASJON

Dokumentasjon

Thursday, May 26, 2011

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

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

GODKJENNINGSPERIODE..?

Tatt ut av avtalen, lagt til bilag

Valgfritt om man ønsker å

gjennomføre godkjenningsperiode

Thursday, May 26, 2011

BETALING

Ikke helt ferdig med denne delen av kontrakten

Fastpris Målpris Timepris

Ulike prisbilag-modeller?

Thursday, May 26, 2011

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

MINE TANKER OM AVTALEN

• SSA-smidig vs. PS2000

• Metoden

• Utfordrende med administrasjon

• Utfordrende ved konflikt

Thursday, May 26, 2011

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

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

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

Thursday, May 26, 2011

Hilsen A

nne-Li

se

Thursday, May 26, 2011

Recommended