Upload
bestbrainsdk
View
67
Download
0
Embed Size (px)
Citation preview
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
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
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 ü -‐ ü -‐ ü -‐ ü -‐ ü -‐
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
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