Embed Size (px)
Citation preview
Agile kontrakter
2. marts 2016 Jesper Thaning, partner BestBrains P/S
Agenda
• Har vi brug for kontrakter (Dl agile projekter)? • Commitment • Kontraktparadigmer • Behovsopgørelse • Rammer for Dllid og samarbejde • Eksempler på formuleringer • Eksempel på agil prismodel
Det agile Manifest
Processer og værktøjerIndivider og samspil over
Fastholdelse af en planHåndtering af forandringer over
Kilde: www.agilemanifesto.org
Omfattende dokumentationVelfungerende software over
KontraktforhandlingSamarbejde med kunden over
”While there is value in the items on the right, we value the items on the le4 more”.
A5
Har vi så overhovedet brug for en kontrakt?
Agil værdiskabelse
Agil Vandfald
Sker det helt af sig selv?
Hvad kan vi gøre for at skabe rammerne for succes?
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 Dd • ”Time & Material”
(K03) (K01 – K02)
1. Procesmæssige krav 2. Behovsopgørelse 3. Prismodel 4. Evaluering af leverandører
Agile kontrakter Non-‐agile kontrakter
Risikoen er kundens og leverandørens Risikoen er kundens
• Hvilket resultat vil vi opnå? • business case • forretningsmål Mål
• Hvilken funk/onalitet tror vi vil skabe resultatet? • temaer • features/epics • user stories
Behov • Hvordan skal systemet opføre sig og se ud? • acceptkriterier • design skærmbilleder • non-‐funkDonelle krav
Krav
Behov i en agil kontrakt B2
Ikke for mange funk/onelle detaljer!
Kravspec
Agil kontrakt
9
Succesfulde so_ware-‐projekter 1. Kunde og leverandør samarbejder 2. Projektet slu`er Ddligt med den re`e funkDonalitet 3. Kunden kan levere krav løbende 4. Kunden får produkDonsklar so_ware leveret løbende 5. Risici og gevinster deles af kunde og leverandør
Hvordan sæ`er vi rammer for Dllid og samarbejde?
Kunde Leverandør
4 Krav ü -‐ ü -‐ ü -‐ ü -‐
5 Krav ü -‐ ü -‐ ü -‐ ü -‐ ü -‐
Krav nr. 1 Dl kunden • Kunden skal specificere krav løbende
“Kunden leverer krav løbende. Ikke detaljeret kravspec up-‐front.”
Krav nr. 2 Dl kunden • Kunden skal prioritere funkDonalitet løbende
“Prioritering hver 14. dag forud for sprint-‐planning”
Krav nr. 3 Dl kunden • Skal teste og godkende leveret so_ware løbende
“Godkende leverance hver 14. dag ved sprint review”
Krav nr. 4 Dl kunden • Skal prioritere fejlre`elser over udvikling af funkDonalitet
Commitment!
Fire krav Dl kunden
ü Skal specificere krav løbende ü Skal prioritere funkDonalitet løbende ü Skal teste og godkende leveret so_ware løbende ü Skal prioritere fejlre`elser over udvikling af funkDonalitet
• Kunden har en klart formuleret produktvision • Kunden sæ`er so_ware i dri_ undervejs
Et godt udgangspunkt:
Krav nr. 1 Dl leverandøren • Leverandøren skal esDmere funkDonsområder på baggrund af en overordnet produktvision og behov
“Hver delleverance skal esKmeres forud for påbegyndelse”
Krav nr. 2 Dl leverandøren • Skal nedbryde funkDonalitet og opgaver i uger og dage
“Leverandøren skal udarbejde detaljeret plan for iteraKon”
Krav nr. 3 Dl leverandøren • Skal levere Dl test hyppigt
“Leverandøren skal forsøge at levere færdig funkKonalitet hver 14. dag”
Krav nr. 4 Dl leverandøren • Skal gennemføre automaDske regressionstest
“Leverandøren skal opbygge regressiontest, der kan køre automaKsk”
Krav nr. 5 Dl leverandøren • Skal følge kundens prioriteringer
Commitment!
Rammer for godt samarbejde
ü 1. Skal esDmere på grundlag af en overordnet produktvision og behov
ü 2. Skal nedbryde funkDonalitet og opgaver i uger og dage
ü 3. Skal levere hyppigt ü 4. Skal gennemføre automaDske
regressionstest ü 5. Skal følge kundens prioriteringer
ü 1. Skal specificere krav løbende ü 2. Skal prioritere funkDonalitet løbende ü 3. Skal teste og godkende leveret
so_ware løbende ü 4. Skal prioritere fejlre`elser over
udvikling af funkDonalitet
Kunde Leverandør
Eksempler på formuleringer
• Kontrakt A: Detaljeret kontrakt – Procesmæssige krav
• Kontrakt B: Letvægts-‐kontrakt – Agil prismodel – Samarbejde
Krav X.X SamarbejdsorganisaDon
• Ingen af Parterne kan udskiFe medarbejdere uden den anden Parts samtykke, medmindre udski_ningen skyldes medarbejderens personlige forhold, herunder ophør af ansæ`elsesforhold eller lignende omstændigheder. – Den nye medarbejder skal mindst have samme kvalifikaDoner.
• Parterne skal af hensyn Dl konDnuiteten og kvaliteten i arbejdet i videst muligt omfang undgå udskiFning af medarbejdere. – Udski_ning må ikke påføre den anden Part yderligere omkostninger, og den
nye medarbejder skal have mindst Dlsvarende kvalifikaDoner. En Part skal orienteres skri_ligt om udski_ningen medarbejdere.
• En Part skal eFer anmodning udskiFe en medarbejder, såfremt anmodningen er rimeligt begrundet.
PROCESMÆSSIGT KRAV – organisaDon
Leverandøren kan udskiFe Kundens
medarbejder!
Krav X.X Prisafslag omkring samarbejdsorganisaDon
• Kunden kan kræve, at der skal ske et forholdsmæssigt afslag i de vederlag, som Leverandøren er berekget Dl i henhold Dl kontrakten, såfremt der er mangler, herunder organisatoriske mangler i kontraktens løbe/d. – Organisatoriske mangler er f.eks. ikke /lstrækkelige
medarbejderressourcer hos Leverandøren, at Leverandøren ikke deltager i organisaDonen som forudsat i bilag 7 (SamarbejdsorganisaDon), eller at Leverandøren ikke konkret sDller med de rigDge kompetencer.
– Det forholdsmæssige afslag kan kræves fra Ddspunktet for den fremsa`e reklamaDon.
BODSBESTEMMELSE
Krav X.X Organisering og placering
• Leverandørens projektgruppe skal være fysisk /l stede hos Kunden i hele projektets leve/d – 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 lokaDon al den Dd, 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 sDller skriveborde, stole og nemorbindelse Dl 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 Dl test kan være ret intensiv
PROCESMÆSSIGT KRAV – organisaDon
Krav X.X User stories afslu`es løbende -‐ som potenDelle 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 idriFsæOe dem, hvis man ønsker det.
• De angivne User Stories for hver enkel epic er Kundens forslag Dl hvordan epic'en kan underopdeles. Listen af user stories afgrænser omfanget af epic'en og er udgangspunkt for Leverandørens es/mat i forbindelse med /lbudsgivning. – Det forudsæ`es 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æOes også at der vil blive ændret og /lføjet acceptkriterier i user stories under aQlaringsfasen.
• Krav Dl rytme af agile leverancer: der må højst være 14 dage mellem hver Agile leverance
PROCESMÆSSIGT KRAV – proces
Krav: Åbenhed i udviklingsprocessen
• Der skal være fuld gennemsig/ghed 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 Dl review hos Kunden.
• Leverandøren må ikke igangsæOe 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 /d
forbrugt på hhv. aolaring, udvikling, test og projektledelse m.v. – Den endelige specificering a_ales i aolaringsetapen
Kontrakt A
PROCESMÆSSIGT KRAV – Åbenhed
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 aTolde retrospec/ves, hvor både Kunde og Leverandør deltager. – Kunden afsæ`er i udgangspunktet 1,5 /mer Dl hvert retrospekDv. Leverandøren og Kunden skal i samarbejde sikre, at de forbedringsDltag og forhindringer som retrospecDves idenDficerer implementeres henholdsvis forsøges rernet.
– Leverandøren skal sikre at udviklingsprocessen forbedres. – Facilitator sDlles Dl rådighed af Kunden.
PROCESMÆSSIGT KRAV – læring og forbedring
Krav X.X AutomaDseret systemtest
• Til at automaDsere testen af brugergrænsefladen anvendes for nuværende Selenium og test udføres af Leverandøren. – Testcases skal afdække de centrale fejlscenarier, som ikke fanges af
uni`est, og samDdig begrænse vedligeholdelsesbyrden ved ændringer i brugergrænsefladen.
– Testen vil primært omhandle hovedvejen i relaDon Dl de enkelte registreringsforløb.
– Udover fokus på forretningsindholdet vil forløb som akDverer yderligere felDndtastning også blive testet.
– Automa/serede test konfigura/onsstyres og baselines på samme måde som alle andre Testprodukter, dokumentaDon og kode mv.
PROCESMÆSSIGT KRAV – automaDseret test
h`ps://acpn-‐2016.confek.events/
28th April 8:30 – 17:00 @ BestBrains (networking dinner 27th)
Join us in knowledge sharing of Procurement with Agile Contracts in the Nordic -‐ A Game Changing Experience
SHARING EXPERIENCES WITH AGILE CONTRACTS IN THE NORDIC
Risiko
Resultat-‐forplig/gelse: • ”Fastpriskontrakt”
Indsats-‐forplig/gelse: • ”Time & Material”
Risiko er kundens og leverandørens
Risiko er kundens (men ikke leverandørens)
Agil prismodel Deling af gevinst og risiko
Et projekteksempel med agil prismodel • ApplikaDonen skal gøre os i stand Dl at opnå X og Y
– Es/mat: Det vil tage 1000 Dmer at udvikle – Opdeling: 2 delleverancer – Betaling: 500 kr/Dme og 2*250.000 kr når det sæ`es i dri_
BETALING
TID
X
Y
500.000 kr
1.000.000 kr
3 mdr 6 mdr
2. Lav Kmepris 3. Færdiggørelsespris
1. Opdeling i delleverancer
IdenDficerede behov
33
Hvis vi slu`er Dl Dden • Pris for kunden 1.000.000 • Samlet Dmepris for leverandøren 1.000
betaling
arbejde
34
Hvis vi slu`er 25% før Dd • Pris for kunden 875.000 • Samlet Dmepris for leverandøren 1.166
betaling
arbejde
35
Hvis vi slu`er 25% over Dd • Pris for kunden 1.125.000 • Samlet Dmepris for leverandøren 900
betaling
arbejde
Brug Dmepris for visse faser
• Afklaringer• Tidlige prototyper• Eksperimenter• Indledende estimering
Vedligeholdelse
Dd
betaling
Leverancer
TimeprisTimepris Agile prismodel
Opstart
Fordele ved prismodellen
• Fælles incitament Dl at slu`e før Dd og under budget – Billigere for kunden – HurDgere aoast på investeringen for kunden – Højere fortjeneste for leverandøren
Justering af kontrakten
• Højere Dmepris – Når funkDonalitet er vigDgst
• Højere færdiggørelsespris – Når Ddsfristen er vigDgst
betaling pr time betaling ved færdiggørelse Timepris Fast pris
Formuleringer – prismodel
• Formålet med prismodellen er at skabe et fælles økonomisk incitament for både [leverandør] og [kunde] /l at løse opgaven indenfor /dsplan og budget, og dermed Dlskynde Dl konstrukDvt samarbejde mellem parterne under projektet. • Perioden op Dl starten af første releaseperiode afregnes e_er en Dmebaseret prismodel Dl [x] kr/Dme
ex. moms.
• Releaseperioderne afregnes eFer en agil færdiggørelsespris. • Den lavere Dmepris er [y] kr/Dme ex. moms, og færdiggørelsesprisen forhandles endeligt inden hver
releaseperiode på grundlag af den forudgående analyse af prioritering, es/mater 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æ`es i driF, er deOe en implicit godkendelse.
PROCESMÆSSIGT KRAV – prismodel Kontrakt B
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 Dl test og feedback, begge dele i tæt samarbejde og dialog, i itera/oner af 1 /l 2 ugers varighed.
• Udviklingen opdeles i et antal releaseperioder (milepæle) af 4-‐8 ugers varighed. • Hver releaseperiode starter på grundlag af en overordnet specifikaDon og et esDmat som indgår i
prismodellen. Releaseperioden afslu`es med at [kunden] godkender leverancen og så vidt muligt sæ`er 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.
Kontrakt B PROCESMÆSSIGT KRAV – specifikaDon
AlternaDv prismodel – Maksimalpris • PrisesDmat på hele leverance (antal Dmer) • Over antal esDmerede Dmer -‐> Dmepris falder
• Hvor drasDsk falder den? Kan den blive 0 kr.?
