36
Agile kontrakter Jesper Thaning, Partner BestBrains AS

Agile kontrakter april 2015

Embed Size (px)

Citation preview

Agile  kontrakter    

Jesper  Thaning,  Partner  BestBrains  AS  

Områder  

1.  Kontraktparadigmer  

2.  Mål  –  behov  –  krav  

3.  Agil  prismodel  

5.  Rammer  for  samarbejde  

4.  Eksempler  på  formuleringer  

Kontraktparadigmer  

Resultat-­‐forplig/gelse:  •  Fokus  på  produkt  og  pris  •  Regulerer  resultatet  •  Vederlag  for  leverancer  •  ”Fastpriskontrakt”  

Indsats-­‐forplig/gelse:  •  Fokus  på  proces,  rammer  

og  mennesker  •  Regulerer  indsats/adfærd  •  Vederlag  for  medgået  Pd  •  ”Time  &  Material”  

(K03)  (K01  –  K02)  

1.  Behovsopgørelse  2.  Kundens  modenhed  3.  Prismodel  4.  Evaluering  af  leverandør  

Agile  kontrakter  

4.  Mål  –  behov  –  krav  

Anbefal  ugens  Plbud  hvis  X  E-­‐mail  besked  om  X  …  Ny  præsentaPon  af    SMS  om  X  når  Y  …  Find  nærmeste  Z  på  mobil  Indtastning  af  Y-­‐oplysning  …  

Forslag  Pl  merkøb  …  Ny  produktoversigt  ….  Stedtjenester  …  AutomaPsk  registrering  …  

Mere  salg  ...  Højere  konvertering  …  HurPgere  sagsbehandling  …  

Mål  

Behov  

Krav  

5  

Succesfulde  so_ware-­‐projekter  1.  Kunde  og  leverandør  samarbejder  2.  Projektet  sluaer  Pdligt  med  den  reae  funkPonalitet  3.  Kunden  kan  levere  krav  løbende  4.  Kunden  får  produkPonsklar  so_ware  leveret  løbende  5.  Risici  og  gevinster  deles  af  kunde  og  leverandør    

Tillid

6  

Både  agil  og  krav?  

•  Kan  vi  både  være  agile  og  s1lle  krav  1l  leverandøren?  

Agil  prismodel  –  BestBrains  forslag  

Resultat-­‐forplig/gelse:  •  Fokus  på  produkt  og  pris  •  Regulerer  resultatet  •  Vederlag  for  leverancer  •  ”Fastpriskontrakt”  

Indsats-­‐forplig/gelse:  •  Fokus  på  proces,  rammer  

og  mennesker  •  Regulerer  indsats/adfærd  •  Vederlag  for  medgået  Pd  •  ”Time  &  Material”  

Ikke  fast  pris!  •  Forudsæaer  en  detaljeret  

kravspecifikaPon  for  hele  projektet  

Ikke  Pmepris!  •  For  så  bærer  kunden  hele  den  

økonomiske  risiko  Hvordan  så?  

Et  projekteksempel  med  agil  prismodel  •  ApplikaPonen  skal  gøre  os  i  stand  Pl  at  opnå  X  og  Y  

–  EsPmat:  Det  vil  tage  3  personer  i  6  måneder  at  udvikle  –  Opdeling:  2  delleverancer  –  Betaling:  500  kr/Pme  og  2*250.000  kr  når  det  sæaes  i  dri_  

BETALING  

TID  

X

Y

500.000  kr  

1.000.000  kr  

3  mdr   6  mdr  

2.  Lav  1mepris  3.  Færdiggørelsespris  

1.  Opdeling  i  delleverancer  

IdenPficerede  behov  

9  

Hvis  vi  sluaer  Pl  Pden  •  Pris  for  kunden                        1.000.000  •  Samlet  Pmepris  for  leverandøren            900  

betaling

arbejde

10  

Hvis  vi  sluaer  25%  før  Pd  •  Pris  for  kunden            870.000  •  Samlet  Pmepris  for  leverandøren          1.070  

betaling

arbejde

11  

Hvis  vi  sluaer  25%  over  Pd  •  Pris  for  kunden                    1.130.000  •  Samlet  Pmepris  for  leverandøren              800  

betaling

arbejde

Brug  Pmepris  for  visse  faser  

•  Afklaringer•  Tidlige prototyper•  Eksperimenter•  Indledende estimering

Vedligeholdelse

Pd  

betaling  

Leverancer

TimeprisTimepris Agile prismodel

Opstart

Fordele  ved  prismodellen  

•  Fælles  incitament  Pl  at  sluae  før  Pd  og  under  budget  –  Billigere  for  kunden  –  HurPgere  aoast  på  investeringen  for  kunden  –  Højere  fortjeneste  for  leverandøren  

Justering  af  kontrakten  

•  Højere  Pmepris  –  Når  funkPonalitet  er  vigPgst  

•  Højere  færdiggørelsespris  –  Når  Pdsfristen  er  vigPgst  

betaling pr time betaling ved færdiggørelse Timepris  Fast  pris  

Eksempler  på  formuleringer  

•  Kontrakt  1:  Letvægts-­‐kontrakt  •  Kontrakt  2:  Detaljeret  kontrakt    

Formuleringer  –  prismodel  •  Formålet  med  prismodellen  er  at  skabe  et  fælles  økonomisk  incitament  for  både  

[leverandør]  og  [kunde]  Pl  at  løse  opgaven  indenfor  Pdsplan  og  budget,  og  dermed  Plskynde  Pl  konstrukPvt  samarbejde  mellem  parterne  under  projektet.  

•  Perioden  op  Pl  starten  af  første  releaseperiode  afregnes  e_er  en  Pmebaseret  prismodel  Pl  [x]  kr/Pme  ex.  moms.  

•  Releaseperioderne  afregnes  e_er  en  agil  færdiggørelsespris.  Den  lavere  Pmepris  er  [y]  kr/Pme  ex.  moms,  og  færdiggørelsesprisen  forhandles  endeligt  inden  hver  releaseperiode  på  grundlag  af  den  forudgående  analyse  af  prioritering,  esPmater  og  risici.  Den  a_alte  færdiggørelsespris  betales  ved  releaseperiodens  afslutning,  når  den  leverede  so_ware  godkendes  af  [kunden].  

•  Når  den  leverede  so_ware  sæaes  i  dri_,  er  deae  en  implicit  godkendelse.  

Formuleringer  –  samarbejde  •  Parterne  udvikler  systemet  e_er  en  agil  udviklingsmodel,  hvor  [kunden]  

specificerer  kravene,  tester  og  giver  feedback  undervejs,  og  [leverandøren]  løbende  leverer  systemet  Pl  test  og  feedback,  begge  dele  i  tæt  samarbejde  og  dialog,  i  iteraPoner  af  1  Pl  2  ugers  varighed.    

•  Udviklingen  opdeles  i  et  antal  releaseperioder  (milepæle)  af  4-­‐8  ugers  varighed.  Hver  releaseperiode  starter  på  grundlag  af  en  overordnet  specifikaPon  og  et  esPmat  som  indgår  i  prismodellen.  Releaseperioden  afsluaes  med  at  [kunden]  godkender  leverancen  og  så  vidt  muligt  sæaer  den  leverede  so_ware  i  dri_.    

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

Krav  X.X  SamarbejdsorganisaPon  

•  Ingen  af  Parterne  kan  udski_e  medarbejdere  uden  den  anden  Parts  samtykke,  medmindre  udski_ningen  skyldes  medarbejderens  personlige  forhold,  herunder  ophør  af  ansæaelsesforhold  eller  lignende  omstændigheder.  Den  nye  medarbejder  skal  mindst  have  samme  kvalifikaPoner.    

•  Parterne  skal  af  hensyn  Pl  konPnuiteten  og  kvaliteten  i  arbejdet  i  videst  muligt  omfang  undgå  udski_ning  af  medarbejdere.  Udski_ning  må  ikke  påføre  den  anden  Part  yderligere  omkostninger,  og  den  nye  medarbejder  skal  have  mindst  Plsvarende  kvalifikaPoner.  En  Part  skal  orienteres  skri_ligt  om  udski_ningen  medarbejdere.  

•  En  Part  skal  e_er  anmodning  udski_e  en  medarbejder,  såfremt  anmodningen  er  rimeligt  begrundet.  

Krav  X.X  Prisafslag  omkring  samarbejdsorganisaPon  

•  Kunden  kan  kræve,  at  der  skal  ske  et  forholdsmæssigt  afslag  i  de  vederlag,  som  Leverandøren  er  beretget  Pl  i  henhold  Pl  kontrakten,  såfremt  der  er  mangler,  herunder  organisatoriske  mangler  i  kontraktens  løbePd.  Organisatoriske  mangler  er  f.eks.  ikke  Plstrækkelige  medarbejderressourcer  hos  Leverandøren,  at  Leverandøren  ikke  deltager  i  organisaPonen  som  forudsat  i  bilag  7  (SamarbejdsorganisaPon),  eller  at  Leverandøren  ikke  konkret  sPller  med  de  rigPge  kompetencer.  Det  forholdsmæssige  afslag  kan  kræves  fra  Pdspunktet  for  den  fremsaae  reklamaPon.  

Krav  X.X  Organisering  og  placering  

•  Leverandørens  projektgruppe  skal  være  fysisk  Pl  stede  hos  Kunden  i  hele  projektets  levePd.  Det  daglige  arbejde  foregår  hos  Kunden,  og  Leverandørens  projektledelse,  testmanager,  chefudvikler/arkitekt  og  andre  beslutningstagere  i  projektgruppen  skal  være  placeret  på  Kundens  lokaPon  al  den  Pd,  de  arbejder  på  projektet.  Der  kan  a_ales  undtagelser  i  forbindelse  med  særlige,  forbigående  omstændigheder.  Projektleder,  testmanager,  chefudvikler/arkitekt  samt  centrale  seniorudviklere  skal  være  allokeret  100%  med  mindre  andet  a_ales  særskilt.  

•  Kunden  sPller  skriveborde,  stole  og  neuorbindelse  Pl  rådighed.  •  Herudover  må  der  ikke  være  personsammenfald  imellem  ressourcekrævende  

roller.  Eksempelvis  må  projektleder  og  testmanager  ikke  være  samme  person.  •  Der  skal  tages  højde  for  at  bemandingen  Pl  test  kan  være  ret  intensiv.    

Krav  X.X  User  stories  afsluaes  løbende  -­‐  som  potenPelle  delleverancer  

•  Kunden  ønsker  et  agilt  forløb  hvor  user  stories  løbende  færdiggøres  på  en  måde,  så  man  løbende  vil  kunne  idri_sæae  dem,  hvis  man  ønsker  det.  Leverandørens  Plbudte  proces  skal  følge  den  proces  der  er  beskrevet  i  deae  afsnit,  afsniaet  'Udviklingsprocessen'  nedenfor,  samt  Plstandsdiagrammet  for  User  Stories,  som  er  beskrevet  i  kapitlet  Leverancemodel.  Hvert  Plstands-­‐ski_  skal  være  godkendt  af  Kundens  Product  Owner,  og  godkendelsen  består  af  en  godkendelse  af  at  aaribuaerne  for  den  Plstand  der  ski_es  Pl,  er  leveret  i  Plstrækkelig  omfang  og  kvalitet.  

•  De  angivne  User  Stories  for  hver  enkel  epic  er  Kundens  forslag  Pl  hvordan  epic'en  kan  underopdeles.  Listen  af  user  stories  afgrænser  omfanget  af  epic'en  og  er  udgangspunkt  for  Leverandørens  esPmat  i  forbindelse  med  Plbudsgivning.  Det  forudsæaes  at  hver  enkelt  user  story  kan  blive  nedbrudt  i  yderligere  user  stories  i  forbindelse  med  user  storiens  aolaringsfase  beskrevet  nedenfor,  med  det  formål  at  gøre  implementering  og  opfølgning  nemmere.  Det  forudsæaes  også  at  der  vil  blive  ændret  og  Plføjet  acceptkriterier  i  user  stories  under  aolaringsfasen.  

•  Krav  Pl  rytme  af  agile  leverancer:  der  må  højst  være  14  dage  mellem  hver  Agile  leverance  .  

Krav  X.X  Åbenhed  i  udviklingsprocessen  

•  Der  skal  være  fuld  gennemsigPghed  i  udviklingsprocessen.  Det  betyder  blandt  andet:  

•  Kunden  skal  have  indsigt  i  leverandørens  arbejdsdokumenter,  herunder  dokumenter  om  arkitekturvalg  og  test.  Leverandøren  kan  dog  ikke  forvente  at  Kunden  har  set  dokumenter  m.v.  førend  det  officielt  har  været  sendt  Pl  review  hos  Kunden.  

•  Leverandøren  må  ikke  igangsæae  en  opgave  uden  Kundens  godkendelse.  Her  tænkes  blandt  andet  på  teknik,  arkitektur,  testbarhed  og  GUI.  

•  Kunden  skal  kunne  deltage  i  leverandørens  daglige  møder.    •  Leverandøren  skal  på  ugebasis  levere  en  opgørelse  over  Pd  forbrugt  på  hhv.  

aolaring,  udvikling,  test  og  projektledelse  m.v.  Den  endelige  specificering  a_ales  i  aolaringsetapen    

Krav  X.X  Forbedring  af  udviklingsprocessen  

•  Leverandøren  skal  løbende  arbejde  på  at  forbedre  udviklingsprocessen.  Det  betyder  at  leverandøren  mindst  hver  14.  dag  skal  ayolde  retrospecPves  hvor  både  Kunde  og  Leverandør  deltager.  Kunden  afsæaer  i  udgangspunktet  1,5  Pmer  Pl  hvert  retrospekPv.  Leverandøren  og  Kunden  skal  i  samarbejde  sikre,  at  de  forbedringsPltag  og  forhindringer  som  retrospecPves  idenPficerer  implementeres  henholdsvis  forsøges  zernet.  Leverandøren  skal  sikre  at  udviklingsprocessen  forbedres.  Facilitator  sPlles  Pl  rådighed  af  Kunden.  

Krav  X.X  AutomaPseret  systemtest  

•  Til  at  automaPsere  testen  af  brugergrænsefladen  anvendes  for  nuværende  Selenium  og  udføres  af  Leverandør.    Testcases  skal  afdække  de  centrale  fejlscenarier,  som  ikke  fanges  af  uniaest,  og  samPdig  begrænse  vedligeholdelsesbyrden  ved  ændringer  i  brugergrænsefladen.  Testen  vil  primært  omhandle  hovedvejen  i  relaPon  Pl  de  enkelte  registreringsforløb.  Udover  fokus  på  forretningsindholdet  vil  forløb  som  akPverer  yderligere  felPndtastning  også  blive  testet.  AutomaPserede  test  konfiguraPonsstyres  og  baselines  på  samme  måde  som  alle  andre  Testprodukter,  dokumentaPon  og  kode  mv.  

Hvordan  sæaer  vi  rammer  for  samarbejde?  

Kunde   Leverandør  

4  Krav  ü -­‐  ü -­‐  ü -­‐  ü -­‐  

5  Krav  ü -­‐  ü -­‐  ü -­‐  ü -­‐  ü -­‐  

Krav  nr.  1  Pl  kunden  •  Kunden  skal  specificere  krav  løbende  

•  Ikke detaljeret kravspec up-front

Krav  nr.  2  Pl  kunden  •  Kunden  skal  prioritere  funkPonalitet  løbende  

Krav  nr.  3  Pl  kunden  •  Skal  teste  og  godkende  leveret  so_ware  løbende  

Krav  nr.  4  Pl  kunden  •  Skal  prioritere  fejlreaelser  over  udvikling  af  funkPonalitet  

Fire  krav  Pl  kunden  

ü Skal  specificere  krav  løbende  ü Skal  prioritere  funkPonalitet  løbende  ü Skal  teste  og  godkende  leveret  so_ware  løbende  ü Skal  prioritere  fejlreaelser  over  udvikling  af  funkPonalitet  

•  Kunden  har  en  klart  formuleret  produktvision  •  Kunden  sæaer  so_ware  i  dri_  undervejs  

Godt  udgangspunkt  

Krav  nr.  1  Pl  leverandøren  •  Leverandøren  skal  esPmere  funkPonsområder  på  baggrund  af  en  overordnet  produktvision  

Krav  nr.  2  Pl  leverandøren  •  Skal  nedbryde  funkPonalitet  og  opgaver  i  uger  og  dage  

Krav  nr.  3  Pl  leverandøren  •  Skal  levere  Pl  test  hyppigt  (conPnuous  delivery)  

Krav  nr.  4  Pl  leverandøren  •  Skal  gennemføre  automaPske  regressionstest  

Krav  nr.  5  Pl  leverandøren  •  Skal  følge  kundens  prioriteringer  

Et  godt  samarbejde?  

ü  Skal  esPmere  på  grundlag  af  en  overordnet  produktvision  

ü  Skal  nedbryde  funkPonalitet  og  opgaver  i  uger  og  dage  

ü  Skal  levere  hyppigt  ü  Skal  gennemføre  automaPske  

regressionstest  ü  Skal  følge  kundens  prioriteringer  

ü  Skal  specificere  krav  løbende  ü  Skal  prioritere  funkPonalitet  løbende  ü  Skal  teste  og  godkende  leveret  

so_ware  løbende  ü  Skal  prioritere  fejlreaelser  over  

udvikling  af  funkPonalitet