2. Områder
1.
Kontraktparadigmer
2.
Mål
–
behov
–
krav
3.
Agil
prismodel
5.
Rammer
for
samarbejde
4.
Eksempler
på
formuleringer
3. 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. 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. 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. 6
Både
agil
og
krav?
• Kan
vi
både
være
agile
og
s1lle
krav
1l
leverandøren?
7. 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å?
8. 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. 9
Hvis
vi
sluaer
Pl
Pden
• Pris
for
kunden
1.000.000
• Samlet
Pmepris
for
leverandøren
900
betaling
arbejde
10. 10
Hvis
vi
sluaer
25%
før
Pd
• Pris
for
kunden
870.000
• Samlet
Pmepris
for
leverandøren
1.070
betaling
arbejde
11. 11
Hvis
vi
sluaer
25%
over
Pd
• Pris
for
kunden
1.130.000
• Samlet
Pmepris
for
leverandøren
800
betaling
arbejde
13. 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
14. 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
16. 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.
17. 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.
18. 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.
19. 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.
20. 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.
21. 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
.
22. 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
23. 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.
24. 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.
25. Hvordan
sæaer
vi
rammer
for
samarbejde?
Kunde
Leverandør
4
Krav
ü -‐
ü -‐
ü -‐
ü -‐
5
Krav
ü -‐
ü -‐
ü -‐
ü -‐
ü -‐
26. Krav
nr.
1
Pl
kunden
• Kunden
skal
specificere
krav
løbende
• Ikke detaljeret kravspec up-front
27. Krav
nr.
2
Pl
kunden
• Kunden
skal
prioritere
funkPonalitet
løbende
28. Krav
nr.
3
Pl
kunden
• Skal
teste
og
godkende
leveret
so_ware
løbende
29. Krav
nr.
4
Pl
kunden
• Skal
prioritere
fejlreaelser
over
udvikling
af
funkPonalitet
30. 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
31. Krav
nr.
1
Pl
leverandøren
• Leverandøren
skal
esPmere
funkPonsområder
på
baggrund
af
en
overordnet
produktvision
32. Krav
nr.
2
Pl
leverandøren
• Skal
nedbryde
funkPonalitet
og
opgaver
i
uger
og
dage
33. Krav
nr.
3
Pl
leverandøren
• Skal
levere
Pl
test
hyppigt
(conPnuous
delivery)
34. Krav
nr.
4
Pl
leverandøren
• Skal
gennemføre
automaPske
regressionstest
35. Krav
nr.
5
Pl
leverandøren
• Skal
følge
kundens
prioriteringer
36. 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
