træt af it-skandaler e2012

“Hvorfor kravspecifikationen skal dø” Og

“Agile kontrakter”

Dagsorden

•  Intro •  Hvorfor kravspecifikationen skal dø •  Pause •  Agile kontrakter •  Q&A

Agile kontrakter

Casper Wilstrup & Jesper Thaning, BestBrains

4. oktober 2012 betaling

arbejde

6

BestBrains

Er det lige i overkanten med alle de logoer som ikke har noget med agile kontrakter at gøre?

Dagsorden

•  Succesfulde software-projekter •  Prismodel •  Samarbejdsform •  Krav til kunden og leverandøren

8

Succesfulde software-projekter

•  Kunde og leverandør samarbejder •  Projektet slutter tidligt med den rette funktionalitet •  Kunden kan levere krav løbende •  Kunden får produktionsklar software leveret løbende •  Risici og gevinster deles af kunde og leverandør

Tillid

Sæt pris på agile projekter

•  Ikke fast pris –  Forudsætter en detaljeret kravspecifikation for hele projektet

•  Ikke timepris –  For så bærer kunden hele den økonomiske risiko

•  Hvordan så?

Et projekteksempel

•  Applikationen skal gøre os i stand til at opnå X og Y –  Estimat: Det vil tage 3 personer i 6 måneder at udvikle –  Metode: Krav og programmering i ugentlige iterationer –  Betaling: 600 kr/time og 2 * 250.000 kr når det sættes i drift

betaling

arbejde

X

Y

6 mdr 3 mdr

11

Hvis vi slutter til tiden

•  Pris for kunden 1.000.000 •  Samlet timepris for leverandøren 1.000

betaling

arbejde

12

Hvis vi slutter 25% før tid

•  Pris for kunden 870.000 •  Samlet timepris for leverandøren 1.170

betaling

arbejde

13

Hvis vi slutter 25% over tid

•  Pris for kunden 1.130.000 •  Samlet timepris for leverandøren 900

betaling

arbejde

Brug timepris for visse faser

•  Tidlige prototyper

•  Eksperiementer •  Indledende

estimering

X

Y •  Vedligeholdelse

Timepris Timepris Agil prismodel

Fordele ved prismodellen

•  Fælles incitament til at slutte før tid og under budget –  Billigere for kunden –  Hurtigere afkast på investeringen for kunden –  Højere fortjeneste for leverandøren

Justering af kontrakten

•  Højere timepris –  Når funktionalitet er vigtigst

•  Højere færdiggørelsespris –  Når tidsfristen er vigtigst

betaling pr time

betaling ved færdiggørelse Timepris Fast pris

Andre prismodeller

•  Risk-Reward model •  Bonus pr. sprint •  K03

Hvordan sætter vi rammer for tillid?

Kunde Leverandør Fire krav Fem krav

Krav nr. 1 til kunden

•  Kunden skal specificere krav løbende

•  Ikke detaljeret kravspec up-front

Krav nr. 2 til kunden

•  Kunden skal prioritere funktionalitet løbende

Krav nr. 3 til kunden

•  Skal teste og godkende leveret software løbende

Krav nr. 4 til kunden

•  Skal prioritere fejlrettelser over udvikling af funktionalitet

Fire krav til kunden

1) Skal specificere krav løbende 2) Skal prioritere funktionalitet løbende 3) Skal teste og godkende leveret software løbende 4) Skal prioritere fejlrettelser over udvikling af funktionalitet

•  Kunden har en klart formuleret produktvision •  Kunden sætter software i drift undervejs

Godt udgangspunkt

Krav nr. 1 til leverandøren

•  Leverandøren skal estimere funktionsområder på baggrund af en overordnet produktvision

Krav nr. 2 til leverandøren

•  Skal nedbryde funktionalitet og opgaver i uger og dage

Krav nr. 3 til leverandøren

•  Skal levere til test hyppigt (continuous delivery)

Krav nr. 4 til leverandøren

•  Skal gennemføre automatiske regressionstest

Krav nr. 5 til leverandøren

•  Skal følge kundens prioriteringer

Fem krav til leverandøren

1) Skal estimere på grundlag af en overordnet produktvision 2) Skal nedbryde funktionalitet og opgaver i uger og dage 3) Skal levere hyppigt 4) Skal gennemføre automatiske regressionstest 5) Skal følge kundens prioriteringer

Formuleringer – samarbejde

•  Parterne udvikler systemet efter en agil udviklingsmodel, hvor [kunden] specificerer kravene, tester og giver feedback undervejs, og [leverandøren] løbende leverer systemet til test og feedback, begge dele i tæt samarbejde og dialog, i iterationer af 1 til 2 ugers varighed.

•  Udviklingen opdeles i et antal releaseperioder (milepæle) af 4-8 ugers varighed. Hver releaseperiode starter på grundlag af en overordnet specifikation og et estimat som indgår i prismodellen. Releaseperioden afsluttes med at [kunden] godkender leverancen og så vidt muligt sætter den leverede software i drift.

•  Inden hver releaseperiode starter, og i høj grad inden første releaseperiode starter, er parterne (udviklere, brugere, styregruppe) i tæt dialog om den konkrete udformning af den del af systemet, der indgår i releaseperioden, fx gennem workshops og løbende feedback.