Upload
harold-van-heeringen
View
251
Download
2
Embed Size (px)
DESCRIPTION
Inleiding/basics begroten van software projecten. Verschillen tussen waterval en agile projecten en de manier waarop deze begroot moeten worden.
Citation preview
Methodisch Begroten
van software projecten
Hogeschool Rotterdam5 november 2013
Harold van HeeringenSoftware Cost Engineer, Sogeti Nederland B.V.ISBSG presidentNESMA bestuur
werkgroep COSMIC werkgroep Benchmarking werkgroep FPA in contract(ing)
COSMIC IAC, NL afgevaardigde
@haroldveendam
haroldveendam
haroldvanheeringen
3
Introductie•Het belang van het goed begroten van projecten;
•Het verschil tussen expert begroting en methodische begroting;
•Traditioneel begroten (waterval);
•FPA overview en COSMIC overview; + eenvoudige oefening;
•Historische data en ervaringscijfers;
•Begroten van agile projecten in de praktijk;
•Benchmarking en performance measurement van afgeronde projecten;
4
Het belang van het goed begroten van projecten
5
Probleem: Software projecten
6
2 belangrijkste redenen Instabiele user requirements- Te weinig aandacht voor requirements analyse - Te vroeg starten met realisatie- Gebruikers weinig betrokken
Onrealistische begroting en planning- Onvolwassen begrotingstechnieken (optimistisch!!)- Druk om doorlooptijd korter te maken en kosten laag te houden- Ineffectieve projectmanagement technieken
7
Begroten van software
Zo denken veel klanten erover als ze om een begroting voor softwarerealisatie vragen.
Het is belangrijk een realistische, onderbouwde, objectieve en verdedigbare begroting aanbieden!
8
Waarom is een goede begroting belangrijk?De begroting is basis voor:
• de business case;• de planning;• de aanbieding (RVO; winst/verlies);• voortgangsrapportages;• het financieel resultaat van het project;• het vastleggen/vrijgeven van resources;• ‘alignment’ met de business/klant;• et cetera!
9
Begroten in de ITIT industrie: relatief jonge industrieLage volwassenheid op het gebied van begroten. Druk vanuit klant/business op kosten, leidt tot onrealistische verwachtingen.
Business: levert set requirements, vaak onvoldoende gedetailleerdBusiness: het is te duur bevordert optimismeBusiness: het moet sneller bevordert optimismeIT: weet niet precies ‘hoe groot het is’IT: kent eigen performance niet matige onderbouwing, weinig zicht op realiteitswaarde, gaat relatief eenvoudig mee met druk vanuit de klant.
Gevolg: veel mislukte projecten, overschrijdingen, gestopte projecten imago probleem IT, lage klanttevredenheid!
10
Wat is een goede begroting?Een goede begroting is een plan dat de stakeholders voldoende betrouwbaar vinden om te gebruiken als het nemen van beslissingen.
Een begroting geeft inzicht in de potentiële risico’s.
Een begroting is altijd een distributie, nooit een getal.Bijvoorbeeld: min. 500 uur, waarschijnlijk 800 uur, max. 1.300 uur.
Een begroting is nooit exact.
Een begroting komt bij voorkeur tot stand, gebruik makend van verschillende methoden. Eén van die methoden is bij voorkeur gebaseerd op historische data.
11
Overschatten/onderschatten
Onderschatten Overschatten
Lineaire extra kosten
Extra uren worden besteed
Te lage schattingen
Extr
a K
ost
en
0%
>100%
Te hoge schattingenRealistische schattingen
Non- Lineaire extra kosten
Planningsfouten
Vergroten team veel duurder maar nauwelijks sneller
Extra management attentie/overhead
Stress: Meer defects, lagere onderhoudbaarheid
12
Traditioneel begroten
13
Traditioneel begrotenStart: klant stelt functionele documentatie op. De scope van het project wordt bepaald door de beschreven functionaliteit binnen de aangegeven technische kaders.
Sogeti: begroot hoeveel uren het gaat kosten om het project uit te voeren:
• TO, coding, u-test, s-test, ond. a-test, oplevering, PL, QA• Wat is de doorlooptijd?• Wat is de teamsize en hoeveel FTE van welke expertise nodig?
Risico: te optimistische begroting leidt tot overrunsRisico: te pessimistische begroting leidt tot het niet winnen van het project
14
Cone of uncertainty
0
-50
50
100
150
200 Feasibilitystudy
Requirementsspecification
Software development
Pro
ject
clo
sure
Vari
ab
ility
(%
)
Slecht begroot of slecht beheerst project
De kegel wordt niet vanzelf nauwer. Men neemt beslissingen om hem nauwer te maken. Het later wijzigen van deze beslissingen leidt ertoe dat de kegel weer wijder wordt.
15
Het verschil tussen Expert- en methodische begroting
16
2 typen begrotingen1. Expertbegroting (technische calculatie)
Bottom-up , uren toekennen aan work items, kennis en ervaring
Voordelen: • Altijd uit te voeren (als er een expert beschikbaar is);• Experts lezen documentatie door en zien ‘de beren’.
Nadelen:• Niet alle activiteiten worden meegenomen
(testscripts??);• Vaak ontbreekt een onderbouwing van de cijfers
(‘gevoel’);• Een expert gaat niet het werk doen (wie wel?);• Is de expert eigenlijk wel een expert? (projecten zijn
uniek);• Geen impact van doorlooptijd, team size, et cetera?;• Geen check op realiteitswaarde (historie).
Resultaat: Meestal optimistisch (gemiddeld 30% onderschatting)
17
2 typen begrotingen2. Methodische begroting (cost engineer)
Top-down o.b.v. objectieve omvangbepaling, relevanteproductiviteitscijfers en geavanceerde begrotingstools
Voordelen:• Objectief, herhaalbaar, verifieerbaar, verdedigbaar!• Inzicht in risico’s• Scenario analyse: doorlooptijd, team size, %
confidence
Nadelen:• Vereist bepaalde volwassenheid van de organisatie:
• meten en analyseren afgeronde projecten• investeren in expertise en tooling
• Stelt minimale eisen aan de documentatie
18
Sogeti begrotingen CoE expertbegrotingFunctioneel ontwerper: F.O. urenTechnisch architect: coding +UT urenTester: testurenProjectleider: PL uren
Cost engineering begroting (SEC)Omvangmeting (FP / CFP)Methodische begroting - Uren, doorlooptijd, FTE, kosten - Scenario’s - Risico’s
Challenge
AanbiedingAanbieding
ABFABF
Plan vanaanpak
Plan vanaanpak
19
Volwassen begrotingenWaarom worden softwarerealisatie projecten vaak niet op een volwassen manier begroot?
• In de meeste organisaties: alleen expertbegrotingen;• Miljoenenprojecten worden begroot op basis van de meningen van individuele ‘experts’;
• Onderzoek: experts zijn gemiddeld 30% te optimistisch.
Gevolg: het merendeel van de projecten start op basis van onrealistische begrotingen en verwachtingen overschrijdingen in budget, doorlooptijd en … soms zelfs slechte kwaliteit.
En dat terwijl er voldoende cost engineering methoden, technieken en tools voorhanden zijn om projecten onderbouwd en verdedigbaar te begroten!
20
Methodische Begrotingen
1. Meet de functionele omvang van de ‘functional user requirements’.• ISO methodes NESMA, IFPUG of COSMIC FPA• Resultaat: omvang van de te realiseren functional
user requirements is 999 functiepunten• Objectief / verifieerbaar / herhaalbaar / verdedigbaar
2. Bepaal de te verwachten Productiviteit (Uren/FP) voor het project• Historische data (afgeronde projecten)• Benchmark data (ISBSG)
3. Verwerk de omvang en de productiviteit met een Begrotingstool• Scenario’s – doorlooptijd, teamgrootte, risico’s
21
Meten van Functionele omvang
Functional UR Technical UR Quality UR
User Requirements
FPA en COSMIC meten alleen de Functional User Requirements
Voordelen:
- Kan vroegtijdig worden toegepast (Requirements analyse)
- Omvang is onafhankelijk van techniek en implementatie
22
Functiepunt Analyse (FPA)
23
Wat is FPAUniforme methode om de aan de gebruikergeboden en door de gebruiker gevraagdehoeveelheid functionaliteit van eeninformatiesysteem uit te drukken in eeneenheid (functiepunt)
Kenmerken:• Objectief (ISO standaard)• Begrijpelijk voor niet automatiseerders• Reproduceerbaar, verifieerbaar, herhaalbaar, verdedigbaar• Onafhankelijk van de technische oplossing
24
FPA en begroten• Analogie: verven van een muur
• Meten oppervlakte: 20 m2 (= omvang)• Gebruik penseel (1 m2 p.u) • Gebruik kwast (2 m2 p.u)• Gebruik roller (5 m2 p.u) aantal uren afhankelijk van omvang en productiviteit
• Realiseren van een informatiesysteem• Omvang op basis van functiepunten• Productiviteit uit ervaringscijfers/benchmarks• aantal uren afhankelijk van omvang en productiviteit
25
Functiepunt Analyse
ILGV
KGV
Gebruikers Transacties Gegevensverzamelingen
IF
OF
UF
26
Interne Logische Gegevens Verzameling ILGV
Een logische groep permanente gegevensvanuit het gezichtspunt van de gebruiker die aanelk van de volgende criteria voldoet:– Wordt gebruikt door het te tellen informatiesysteem
– Wordt onderhouden door het te tellen informatiesysteem
Voorbeelden:KlantOrder
27
Koppelings Gegevens Verzameling KGV
Een logische groep permanente gegevensvanuit het gezichtspunt van de gebruiker die aanelk van de volgende criteria voldoet:– Wordt gebruikt door het te tellen informatiesysteem
– Wordt niet onderhouden door het te tellen informatiesysteem
– Wordt wel door een ander informatiesysteem onderhouden
– Is direct benaderbaar door het te tellen systeem
Voorbeelden:>Kredietbestand BKR>Kentekentabel RDW
28
Invoerfunctie IF
Een unieke door de gebruiker onderkende functie waarbij gegevens (data- en/of besturingsinformatie) van buiten hetinformatiesysteem naar binnen wordengehaald.
De functie moet door de gebruikerals een elementaire functie worden gezien.
Voorbeelden:>Toevoegen klant>Wijzigen order>Verwijderen verzekering
29
Uitvoerfunctie UF
Een unieke door de gebruiker onderkendeuitvoer die de systeemgrens passeert,waarvan de omvang variabel is of waarvoorverdere gegevensverwerking nodig is.
De functie moet door de gebruikerals een elementaire functie worden gezien.
Voorbeelden:>Het printen van een overzicht met daarop de omzet en winst per maand.
30
Opvraagfunctie OF
Een unieke door de gebruiker onderkende invoer/ uitvoer combinatie waarbij de uitvoer, waarvan de omvang volledig bepaald is, zonder verdere gegevens-verwerking, naar aanleiding van de invoer door hetinformatiesysteem wordt verstrekt.
De functie moet door de gebruiker als een elementaireFunctie worden gezien.
Voorbeeld:>Opvragen medewerkergegevens op medewerkernummer
31
VoorbeeldGevraagde functionaliteit
> Een overzicht met de geboortedata van de medewerkers, gesorteerd op afdeling, maand, dag
Benodigde gegevens:> medewerker : naam, geboortedatum> afdeling : afdelingsnaam
Soort functie:> Uitvoerfunctie
2 gerefereerde LGV :3 gerefereerde DET :
> ComplexiteitEenvoudig 4fp
0 - 1
2 -3
> 3
> 19
M(7)
G(5)
M(7)
6 - 19
E(4)
G(5)
M(7)
1 - 5
E(4)
E(4)
G(5)
32
In de praktijkIndicatieve FPA
Op basis van een conceptueel datamodel:35 FP per systeemeigen object15 FP per systeemvreemd object
Op basis van genormaliseerd datamodel:25 FP per interne logische gegevensverzameling10 FP per koppelingsgegevensverzameling
Globale FPAGegevensverzamelingen: eenvoudig
ILGV = 7 FP, KGV = 5 FPTransacties: gemiddeld
IF = 4 FP, UF = 5 FP, OF = 4 FP
> 50%
10 - 15 %tijd
bandbreedte
15 - 25 %
FunctioneelDetailOntwerp
Definitiestudie
Basisontwerp
Detailontwerp
Realisatie
> 50%
10 - 15 %tijd
bandbreedte
15 - 25 %
FunctioneelDetailOntwerp
Definitiestudie
Basisontwerp
Detailontwerp
Realisatie
33
VraagJe moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements:
- Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen- Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen- Je kunt uitlaatafspraken toevoegen en wijzigen
Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP)- Functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP)
34
Antwoord: LGV’sJe moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements:
- Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen- Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen- Je kunt uitlaatafspraken toevoegen en wijzigen
Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP)- functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP)
3 ILGV’s * 7FP = 21 FPGeen KGV’s
35
Antwoord: InvoerfunctiesJe moet een hondenregistratie programma maken voor de uitlaatservice van je buurvrouw. De requirements:
- Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen- Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen- Je kunt uitlaat afspraken toevoegen en wijzigen
Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP)- functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP)
8 IF’s * 4 FP = 32 FP
36
Antwoord: OpvragingsfunctiesJe moet een hondenregistratie programma maken voor de
uitlaatservice van je buurvrouw. De requirements:
- Je kunt honden toevoegen, wijzigen, verwijderen en raadplegen- Je kunt klanten toevoegen, wijzigen, verwijderen en raadplegen- Je kunt uitlaat afspraken toevoegen en wijzigen
Maak een globale FPA - LGV’s eenvoudig (ILGV: 7 FP, KGV: 5 FP)- functies: gemiddeld (IF en OF: 4 FP, UF: 5 FP)
3 OF’s * 4 FP = 12 FP
Uitvoerfuncties??
Raadplegen ??Raadplegen ??
37
Hondenregistratie
Type Aantal FP
ILGV 3 21
KGV 0 0
IF 8 32
OF 3 12
UF 0 0
Totaal 65 FP
38
ProductiviteitDe functionele omvang is bekend. Om een ruwe begroting te maken vermenigvuldigen we de omvang met een ‘Project Delivery Rate (PDR)’. Dit is het waarschijnlijke aantal uur/FP dat in het project gerealiseerd kan worden.
PDR:- Bij voorkeur eigen ervaringscijfers (afgeronde projecten)- Databases met marktdata (ISBSG repositories)
39
Historische Data - ISBSGInternational Software Benchmarking Standards Group (ISBSG)- Not for profit organisatie, verzamelt projectdata uit de markt
- Nieuwbouw en Releases- Beheer
- Stelt de data ter beschikking aan de markt (anoniem) in .xls- Analyse van en rapporten over de data
- Deze data is zeer geschikt voor:- Begroten projecten waar geen eigen ervaringscijfers van zijn- Reality check van offertes- Benchmarken van afgeronde projecten- Beantwoorden RFP’s- Etc.
40
Ruwe BegrotingHondenregistratie systeem: 65 FP
Min: 8 uur/FP * 65 FP = 520 uur Likely: 11 uur/FP * 65 FP = 715 uurMax: 15 uur/FP * 65 FP = 975 uur
Stel: er is een team van 3 fte beschikbaar om dit uit te voeren. De klant wil het hebben binnen 1 maand. Lukt dit?
41
De impact van doorlooptijd (Putnam)
Omvang/productiviteit = Inspanning1/3 * doorlooptijd4/3
Insp
anni
ng
Doorlooptijd
Plan A: 6 maanden, 4.500 uur
Plan B: 7 maanden, 2.400 uur
42
Project bij verschillende doorlooptijden
Doorlooptijd
ADoorlooptijd: 6 maandenInspanning: 4.500 uurMax. teamomvang: 5,8 fteMTTD: 1,764 dagen
BDoorlooptijd: 7 maandenInspanning: 2.400 uurMax. teamomvang: 2,7 fteMTTD: 2,816 dagen
Insp
anni
ng (
uren
)
43
BegrotingstoolsBegrotingstools- QSM SLIM - Galorath SEER-SEM
- Op basis van input parameters, wordt een begroting vastgesteld- Omvang (bv. Functiepunten)- productiviteit (uit ervaringscijfers / marktdata)- karakteristieken als ervaring team, complexiteit, e.d.- Doorlooptijd- Team omvang- ‘Confidence levels’ (begroting is een distributie!)
- Output: Scenario’s (b.v. doorlooptijd)- uren en kosten per activiteit en rol- risico’s
44
HondenregistratieStaffing & Probability Analysis
Avg Staff (people)<Control Panel - Peak = 3,0>
1okt'13
nov dec
0,0
0,5
1,0
1,5
2,0
2,5
3,0
3,5A
vg Staff (people)876543
Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
RISK GAUGE<Control Panel - Peak = 3,0>
<No constraints>
DurationEffort
Peak StaffQuality
% 0 10 20 30 40 50 60 70 80 90 100
SOLUTION PANEL - <Control Panel - Peak = 3,0>
DurationEffortCost
Peak StaffMTTD
Start Date
C&T1,773973,93,0
2,6701-11-2013
Life Cycle1,773973,93,0
2,6701-11-2013
MonthsMHREUR (K)peopleDay s
PI=17,4 MBI=7,7 Eff FP=65
CONTROL PANEL<Control Panel - Peak = 3,0>
PI 14,0 20,9
17,4
Peak Staff 2,4 3,6
3,0
Eff FP 52 78
65
Max. 3 fte, 65 FP, 1 maand lukt niet
45
Hondenregistratie – 3 fteStaffing & Probability Analysis
Avg Staff (people)<Control Panel - Peak = 3,0>
1okt'13
nov dec
0,0
0,5
1,0
1,5
2,0
2,5
3,0
3,5A
vg Staff (people)876543
Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
RISK GAUGE<Control Panel - Peak = 3,0>
<No constraints>
DurationEffort
Peak StaffQuality
% 0 10 20 30 40 50 60 70 80 90 100
SOLUTION PANEL - <Control Panel - Peak = 3,0>
DurationEffortCost
Peak StaffMTTD
Start Date
C&T1,773973,93,0
2,6701-11-2013
Life Cycle1,773973,93,0
2,6701-11-2013
MonthsMHREUR (K)peopleDay s
PI=17,4 MBI=7,7 Eff FP=65
CONTROL PANEL<Control Panel - Peak = 3,0>
PI 14,0 20,9
17,4
Peak Staff 2,4 3,6
3,0
Eff FP 52 78
65
Max. 3 fte, 65 FP, 1 maand lukt niet
46
Hondenregistratie – 1 mnd Staffing & Probability Analysis
Avg Staff (people)<Single Goal - C&T Duration 1,0>
1okt'13
nov dec
0
10
20
30
40
Avg Staff (people)
876543
Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
RISK GAUGE<Single Goal - C&T Duration 1,0>
<No constraints>
DurationEffort
Peak StaffQuality
% 0 10 20 30 40 50 60 70 80 90 100
SOLUTION PANEL - <Single Goal - C&T Duration 1,0>
DurationEffortCost
Peak StaffMTTD
Start Date
C&T1,0
6.037603,734,90,505
1-11-2013
Life Cycle1,0
6.037603,734,90,505
1-11-2013
MonthsMHREUR (K)peopleDay s
PI=17,4 MBI=13,0 Eff FP=65
CONTROL PANEL<Single Goal - C&T Duration 1,0>
PI 14,0 20,9
17,4
Peak Staff 27,9 41,9
34,9
Eff FP 52 78
65
Max. 35 fte, 65 FP, 1 maand lukt ‘wel’
47
COSMIC FPA
• Methode voor de bepaling van de functionele omvang van software• Bestaat sinds eind jaren ’90• ISO standaard, objectief, herhaalbaar, verifieerbaar• Open standaard, gratis documentatie• Beter geschikt voor moderne ontwikkelmethodieken dan FPA• Beter geschikt om moderne architecturen te begroten dan FPA• Ook geschikt voor traditionele ontwikkelmethodieken en architecturen• Realtime / embedded software• Mobile apps, cloud• Modernere methode dan FPA, maar nog weinig ingeburgerd in NL• Vooral groot in Canada, Turkije, Polen, India, Frankrijk
48
COSMIC FPA
Gebruikers Transacties Gegevens
W
X R
E
49
Data movementsE Entry verplaatst gegevens naar binnen
X eXit verplaatst gegevens naar buiten
R Read verplaatst gegevens vanuit opslag
W Write verplaatst gegevens naar opslag
Generiek Software Model
Notitiewijze sluit aan bijUML - Activity Diagram
E
X W
R
Functioneel proces
Alle Data Movements:1 CFP
50
COSMIC voorbeeld
Persistent OOIWERKNEMERFUNCTIE
Data MovementEntry {Werknemergegevens}Read FUNCTIEWrite WERKNEMERExit {Werknemergegevens}Exit {Meldingen}
AttributenNr, naam, adres, datum in dienst, functiecodefunctiecode, omschrijving, salaris schaal
Data groupnaam, adres, functiecodefunctiecodenaam, adres, datum in dienst, functiecodeWerknemernr.boodschap (fout / bevestiging)
Functioneel proces:
Aanmaken nieuwe medewerkerTrigger: oproepkracht meldt zich
5 COSMIC FP
51
Begroten van agile projecten
Is de documentatie uit agile projecten geschikt om te meten m.b.v. (traditionele) omvangbepalingsmethoden?
52
Is agile documentatie meetbaar?Vaak: User stories.
Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>.
Als een boekkoper wil ik de klantbeoordelingen van een boek lezen, zodat ik beter kan beslissen of ik het boek wil kopen.
De omvang van dit soort requirements is met traditionele omvangbepalingsmethoden als Functiepuntanalyse en COSMIC prima te meten.
Ook high level requirements als, “Er moet een faciliteit komen voor klanten om reviews te plaatsen, te wijzigen, te verwijderen en te lezen” zijn prima te meten.
53
Agile projectenVaak gehoord: “Waarom begroten? We gaan starten, werken in sprints en leveren de meeste waarde aan de klant….”
Maar: er is altijd een klant of een opdrachtgever met een zak geld en die wil weten wat hij wel en niet gaat krijgen voor dit geld.
100 features?
200 features?
300 features?
54
De ijzeren driehoek
Kwaliteit
Geld/middelen Tijd
Functionaliteit
Omdat het in agile projecten mogelijk is om de gewenste functionaliteit tussentijds te wijzigen, moet één van de zijden variabel zijn, anders gaat het ten kosten van de kwaliteit.
55
Waterval vs. agileWaterval projecten: Scope is ‘fixed’. Halen van doorlooptijd en uren gaat vaak mis. Risico bij leverancier (fixed price).Agile projecten: Doorlooptijd en uren staan vast, scope is variabel (maar wel geprioriteerd). Risico bij klant (wat krijgt hij?).
56
Begroten van agile projecten
De hamvraag: hoeveel functionaliteit moet er gemaakt worden en hoeveel functionaliteit kunnen we maken?
Als de doorlooptijd vast staat (vaak wens van klant) en de teamomvang staat vast, dan zijn twee zijden van de ijzeren driehoek ingevuld. Het aantal te besteden uren staat vast.
Hoeveel functionaliteit kunnen we met de gegeven teamomvang, in de gegeven doorlooptijd in deze omgeving opleveren?
In hoeverre match dit op de verwachtingen (impliciete of expliciete backlog) van de klant?
57
Ras Hondpunten
Poedel 5
Schnautzer 6
Duitse herder 10
Chihuahua 2
Labrador 11
Sint Bernhard 12
Bulldog 7
Story pointsRelatieve omvangsmaat, meet de omvang van user stories t.o.v. elkaar.
VB: Hondpunten (o.b.v. hoogte).
Team X: Duitse herder = 10Team Y: Schnautzer = 10Team Z: Chihuahua = 1
Hondpunten/Story points is geen standaardNiet bruikbaar voor opbouwen historische dataNiet bruikbaar voor begroten projectNiet bruikbaar voor benchmarking
Wel bruikbaar voor begroten sprintWel bruikbaar voor velocity/burn down
58
Planning pokerPlanning poker meeting met alle teamledenKaarten: 0,1,2,3,5,8,13,20,40 en 100 (voorbeeld)Moment: Sprint 0 + als er nieuwe user stories bijkomen
1.Een moderator leest de beschrijving van de user story.2.Teamleden stellen vragen aan product owner.3.Ieder teamlid kiest een kaart en houdt deze privé.4.Alle teamleden draaien tegelijk de kaart om.5.Vaak: significante verschillen in gekozen kaart.6.De teamleden met de hoogste en laagste kaart leggen uit.7.De groep discussieert over de oplossingen.8.De user story wordt opnieuw begroot op dezelfde manier.9.De kaarten moeten nu bij elkaar in de buurt liggen, zo niet: nog een ronde.10.Herhalen tot er consensus is.
59
Voordelen planning poker“Planning is everything, plans are nothing.”
1.Discussie vanuit verschillende invalshoeken leidt tot meer inzicht bij iedereen.
2.Te grote features worden onderkend en opgesplitst in kleinere features.
3.Team commitment op afgegeven schatting.
60
Ideal days vs actual daysFeature X: inschatting 3 dagen werk voor ontwikkelaar.
Vraag: hoe lang duurt dit in de praktijk?
• Andere taken (b.v. support huidige release)• Meetings• Reistijd tussen kantoren• Stand-ups, koffie, wc, pauze, vragen collega’s• Telefoon, e-mail• Training, • Ziekte, vakantie?
Niemand is 8 uur per dag volledig productief. In de praktijk zal de ontwikkeling van feature X eerder 4 of 5 dagen duren!
61
Onze visie
62
Typische size metriekenEen story point is een arbitraire (maar intuïtieve) eenheid voor de omvang van een feature {1,2,4,8,16…}, {1,2,3,5,8…}.
Een functiepunt (FP) is een eenheid voor de omvang van een feature vanuit een functioneel perspectief.
Lines of code (LOC) is een eenheid voor de omvang van een feature vanuit een fysiek perspectief.
63
Productiviteit vs. velocityAgile velocity ≈ productiviteit ?
Velocity is tactisch – “Hoeveel kunnen we realiseren in een sprint?”Productiviteit is strategisch – “Hoeveel kunnen we realiseren in een project?”
Velocity – “story points per sprint” Productiviteit – “functiepunten per uur, dag of maand”
Beide metrieken zijn belangrijk, maar voor verschillende redenen/doelen.
64
Velocity/Burn down charts
65
Wat willen we?Aanbieding t.b.v. een bid of PvA voor het projectZo goed mogelijk begroten van het projectMethode: cost engineering begroting o.b.v. productiviteit
Begroten van sprint XPlanning pokerGebaseerd op velocity X-1 (X-2, X-3, etc.)
Gedurende volledige project: Project controlBewaken van de geleverde features o.b.v. de actuals en de match op de ‘minimum releasable scope’ van de klant.Gebaseerd op bestede uren en opgeleverde features (FP en SP)
Na afloop van projectPerformance measurement + benchmark + vastleggen data
66
Begroten van een projectInput:
• Functionele documentatie (mag high-level)• Begrotingsparameters
• doorlooptijd• team omvang• technische omgeving• onshore/offshore• activiteiten in scope/uit scope
Output:• Functionele omvangmeting van de backlog, uitgedrukt in
FP• Cost engineering begroting: aantal FP dat binnen
doorlooptijd en uren gerealiseerd kan worden• Inschatting van de risico’s• Aanbeveling t.a.v. doorlooptijd/uren/FTE
67
Case – SNS Bank RPUAanbieding het project RPU
Input:• High level functional requirements;• Team: 7 FTE;• Max. offshore;• Java;• Klant wil op 15 december een werkende en zinvolle applicatie;
• Geen prioritering.
SEC: size = 425 FP (indicatieve FPA: 225 > 425 > 635 FP).
68
425 FP, 3 maandenStaffing & Probability Analysis
Avg Staff (people)<Single Goal - Life Duration 3,5 incl FO>
1 2 3jul'13
aug sep okt nov dec
0
5
10
15
20
Avg S
taff (people)
654321
D ActR Act
Milestones 1 - 1 # 6 2 - 2 # 6 3 - 3 # 6 4 - 4 # 6 5 - 5 # 6 6 - 6 # 6
Milestones 1 - 1 # 6 2 - 2 # 6 3 - 3 # 6 4 - 4 # 6 5 - 5 # 6 6 - 6 # 6
RISK GAUGE<Single Goal - Life Duration 3,5 incl FO>
<No constraints>
DurationEffort
Peak StaffQuality
% 0 10 20 30 40 50 60 70 80 90 100
SOLUTION PANEL - <Single Goal - Life Duration 3,5 incl FO>
DurationEffortCost
Peak StaffMTTD
Start Date
R Act3,4
7.925673,717,00,468
2-9-2013
Life Cycle3,5
10.779916,223,10,468
2-9-2013
MonthsMHREUR (K)peopleDay s
PI=18,6 MBI=7,4 Eff FP=425
CONTROL PANEL<Single Goal - Life Duration 3,5 incl FO>
PI 14,9 22,3
18,6
Peak Staff 13,6 20,4
17,0
Eff FP 340 510
425
Functionaliteit vastDoorlooptijd vastEffort variabel
69
7 FTE, 3 maandenStaffing & Probability Analysis
Avg Staff (people)<Control Panel - Peak = 7,0, incl fo>
1 2 3jul'13
aug sep okt nov dec
0
1
2
3
4
5
6
Avg S
taff (people)
654321
D ActR Act
Milestones 1 - 1 # 6 2 - 2 # 6 3 - 3 # 6 4 - 4 # 6 5 - 5 # 6 6 - 6 # 6
Milestones 1 - 1 # 6 2 - 2 # 6 3 - 3 # 6 4 - 4 # 6 5 - 5 # 6 6 - 6 # 6
RISK GAUGE - <Control Panel - Peak = 7,0, incl fo>
<No constraints>
DurationEffort
Peak StaffQuality
% 0 10 20 30 40 50 60 70 80 90 100
SOLUTION PANEL - <Control Panel - Peak = 7,0, incl fo>
DurationEffortCost
Peak StaffMTTD
Start Date
R Act3,5
2.477210,65,2
0,9772-9-2013
Life Cycle3,5
3.369286,47,0
0,9772-9-2013
MonthsMHREUR (K)peopleDay s
PI=18,8 MBI=6,0 Eff FP=343
CONTROL PANEL<Control Panel - Peak = 7,0, incl fo>
PI 15,0 22,6
18,8
Peak Staff 4,1 6,2
5,2
Eff FP 274 411
343
Is 343 FP genoeg voor de ‘minimum releasable scope’?
Functionaliteit variabelDoorlooptijd vastEffort vast
70
Project benchmarkOok in agile projecten wordt functionaliteit gerealiseerd in een x aantal uren met een doorlooptijd van een y aantal maanden. Benchmark is zeker mogelijk!
Speed of Delivery vs Effective FP
0 100 200 300 400 500 600 700 800 900 1.000
Effective FP
-200
0
200
400
600
800
Speed of Delivery
Project XProject X
Microsoft Totaal Special Project QSM Business Avg. Line Sty le 1 Sigma Line Sty le
PI vs Omvang (FP)
0 100 200 300 400 500 600 700 800 900 1.000
Omvang (FP)
0
5
10
15
20
25
30
PI
Microsoft New Developmen... Special Project QSM Business Avg. Line Sty le 1 Sigma Line Sty le
71
Sogeti en cost engineeringAfdeling Shared SEC (Sizing, Estimating & Control)Gebundelde kennis, ervaring, skills, methoden, technieken, data, literatuur en tools op het gebied van software cost engineering.
Sizing: FP, CFP, UCP, CP, IBRA, slocs, et ceteraData: Sogeti databases, ISBSG industry data Tools: QSM SLIM, Galorath SEER-SEM, Sogeti wizards
Best in class als het gaat om begroten van IT projecten en beheerAl jarenlang betrokken bij de RVO’s binnen Sogeti. Nu ondersteunend aan de hele Sogeti organisatie.
Bedankt voor jullie aandacht!
Harold van Heeringen Senior Consultant Software Metrics /Software Cost Engineer
Sogeti Sizing, Estimating & Control (SEC)
President ISBSG (International Software Benchmarking Standards Group (www.isbsg.org))Board member NESMA (Netherlands Software Metrics Association (www.nesma.nl))IAC member COSMIC (www.cosmicon.com)