1. Methodisch Begroten
van software projecten
Hanzehogeschool Groningen
10 januari 2014

2. Harold van Heeringen
Software Cost Engineer, Sogeti Nederland B.V.
ISBSG president
NESMA bestuur
werkgroep COSMIC
werkgroep Benchmarking
werkgroep FPA in contract(ing)
COSMIC IAC, NL afgevaardigde
harold.van.heeringen@sogeti.nl
@haroldveendam
haroldveendam
haroldvanheeringen

3. 2. Sogeti Nederland
ICT dienstverlener met ruim 35
jaar ervaring en 3.000
medewerkers
Vestigingen in:
> Vianen (hoofdkantoor)
> Groningen
> Amsterdam Zuidoost
> Amersfoort
> Maastricht
Young Professional dag| Presentatie | Amersfoort/Diemen |02-05-2013
3

4. 3. Sogeti & Capgemini
Young Professional dag| Presentatie | Amersfoort/Diemen |02-05-2013
4

5. 4. Sogeti Group
+20,000 werknemers over 100 locaties in 15 landen
USA 2,000
Chicago, Cincinatti, Houston, New
York, Seattle, Washington…
Europe
18,600
Frankrijk
Paris, Toulouse, Lyon, Marseille…
Benelux
Brussels, Antwerpen, Vianen
Spanje
Madrid, Barcelona, Valencia…
Scandinavië
Stockholm, Oslo, Copenhagen…
UK & Ierland
London, Dublin, Galway
Duitsland
Hamburg, Munich, Frankfurt…
Zwitserland
Geneva, Basel, Zürich
Finland
Helsinki
10,000
4,000
1,100
India 1,000
Mumbai, Bangalore
1,100
300
230
110
35
Young Professional dag| Presentatie | Amersfoort/Diemen |02-05-2013
5

6. 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;
6

7. Het belang van het goed begroten van projecten
7

8. Probleem: Software projecten
8

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

10. 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!
10

11. 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!
11

12. Begroten in de IT
IT industrie: relatief jonge industrie
Lage volwassenheid op het gebied van begroten.
Druk vanuit klant/business op kosten, leidt tot onrealistische
verwachtingen.
Business: levert set requirements, vaak onvoldoende gedetailleerd
Business: het is te duur  bevordert optimisme
Business: het moet sneller  bevordert optimisme
IT: 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!
12

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

14. Overschatten/onderschatten
Non- Lineaire extra kosten
>100%
Planningsfouten
Vergroten team veel duurder maar nauwelijks sneller
Extra Kosten
Extra management attentie/overhead
Stress: Meer defects, lagere onderhoudbaarheid
Lineaire extra kosten
Extra uren worden besteed
Onderschatten
Overschatten
0%
Te lage schattingen
Realistische schattingen
Te hoge schattingen
14

15. Traditioneel begroten
15

16. Traditioneel begroten
Start: 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 overruns
Risico: te pessimistische begroting leidt tot het niet winnen van het
project
16

17. Variability (%)
200
Feasibility
study
Requirements
specification
Software development
150
100
50
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.
Slecht begroot of slecht
beheerst project
Project closure
Cone of uncertainty
0
-50
17

18. Het verschil tussen Expert- en methodische begroting
18

19. 2 typen begrotingen
1. 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)
19

20. 2 typen begrotingen
2. Methodische begroting (cost engineer)
Top-down o.b.v. objectieve omvangbepaling, relevante
productiviteitscijfers 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
20

21. Sogeti begrotingen
CoE expertbegroting
Functioneel ontwerper: F.O. uren
Technisch architect: coding +UT uren
Tester: testuren
Projectleider: PL uren
Challenge
Cost engineering begroting (SEC)
Omvangmeting (FP / CFP)
Methodische begroting
- Uren, doorlooptijd, FTE, kosten
- Scenario’s
- Risico’s
Aanbieding
Aanbieding
ABF
ABF
Plan van
Plan van
aanpak
aanpak
21

22. Volwassen begrotingen
Waarom 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!
22

23. 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 x 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
23

24. Meten van Functionele omvang
FPA en COSMIC meten alleen de Functional User
Requirements
Functional UR
Technical UR
Quality UR
User Requirements
Voordelen:
- Kan vroegtijdig worden toegepast (Requirements analyse)
- Omvang is onafhankelijk van techniek en implementatie
24

25. Functiepunt Analyse (FPA)
25

26. Wat is FPA
Uniforme methode om de aan de gebruiker
geboden en door de gebruiker gevraagde
hoeveelheid functionaliteit van een
informatiesysteem uit te drukken in een
eenheid (functiepunt)
Kenmerken:
• Objectief (ISO standaard)
• Begrijpelijk voor niet automatiseerders
• Reproduceerbaar, verifieerbaar, herhaalbaar, verdedigbaar
• Onafhankelijk van de technische oplossing
26

27. 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
• Java: 8 uur/FP
• Cobol: 22 uur/FP
aantal uren afhankelijk van omvang en productiviteit
27

28. Functiepunt Analyse
Gebruikers
Transacties
IF
UF
Gegevensverzamelingen
ILGV
KGV
OF
28

29. Voorbeeld
Gevraagde functionaliteit
> Een overzicht met de geboortedata van de
medewerkers, gesorteerd op afdeling, maand, dag
Benodigde gegevens:
> medewerker :
> afdeling
:
naam, geboortedatum
afdelingsnaam
1-5
6 - 19
0-1
E(4)
E(4)
G(5)
2 -3
E(4)
G(5)
M(7)
>3
G(5)
M(7)
M(7)
Soort functie:
> Uitvoerfunctie
2 gerefereerde LGV :
3 gerefereerde DET :
> Complexiteit
Eenvoudig
4fp
> 19
29

30. In de praktijk
Indicatieve FPA
Op basis van een conceptueel datamodel:
35 FP per systeemeigen object
15 FP per systeemvreemd object
Op basis van genormaliseerd datamodel:
25 FP per interne logische gegevensverzameling
10 FP per koppelingsgegevensverzameling
Globale FPA
Gegevensverzamelingen: eenvoudig
ILGV = 7 FP, KGV = 5 FP
Transacties: gemiddeld
IF = 4 FP, UF = 5 FP, OF = 4 FP
b
a
n
d
b
r
e
e
d
t
e
> 50%
15 - 25 %
10 - 15 %
Definitie
studie
Basis
ontwerp
Functioneel
Detail
Ontwerp
tijd
Detail
ontwerp
Realisatie
30

31. Vraag
Je 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)
31

32. Antwoord: LGV’s
Je 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 FP
Geen KGV’s
32

33. Antwoord: Invoerfuncties
Je 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
33

34. Antwoord: Opvragingsfuncties
Je 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
Raadplegen ??
Raadplegen ??
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??
34

35. Hondenregistratie
Type
Aantal
FP
ILGV
3
21
KGV
0
0
IF
8
32
OF
3
12
UF
0
0
Totaal
65 FP
35

36. Productiviteit
De 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)
36

37. Historische Data - ISBSG
International 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.
37

38. Ruwe Begroting
Hondenregistratie systeem: 65 FP
Min: 8 uur/FP * 65 FP = 520 uur
Likely: 11 uur/FP * 65 FP = 715 uur
Max: 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?
38

39. De impact van doorlooptijd (Putnam)
Inspanning
Omvang/productiviteit
= Inspanning1/3 * doorlooptijd4/3
Plan A: 6 maanden, 4.500 uur
Plan B: 7 maanden, 2.400 uur
Doorlooptijd
39

40. Inspanning (uren)
Project bij verschillende doorlooptijden
A
Doorlooptijd: 6 maanden
Inspanning: 4.500 uur
Max. teamomvang: 5,8 fte
MTTD: 1,764 dagen
B
Doorlooptijd: 7 maanden
Inspanning: 2.400 uur
Max. teamomvang: 2,7 fte
MTTD: 2,816 dagen
Doorlooptijd
40

41. Begrotingstools
Begrotingstools
- 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
41

42. Hondenregistratie
Staffing & Probability Analysis
Avg Staff (people)
<Control Panel - Peak = 3,0>
3
4
5
6
78
3,5
3,0
2,5
2,0
1,5
1,0
Avg Staff (people)
Milestones
0 - CSR
1 - SRR
2 - HLDR
3 - LLDR
4 - CUT
5 - IC
6 - STC
7 - UAT
8 - FCR
9 - 99R
10 - 99.9R
0,5
0,0
1
okt
'13
nov
RISK GAUGE
Duration
Effort
Peak Staff
Quality
%
0
<Control Panel - Peak = 3,0>
10
20 30 40 50 60
<No constraints>
70
80
90 100
SOLUTION PANEL - <Control Panel - Peak = 3,0>
C&T
Life Cycle
Duration
1,7
1,7
Months
Effort
739
739
MHR
Cost
73,9
73,9
EUR (K)
Peak Staff
3,0
3,0
people
MTTD
2,670
2,670
Day s
Start Date 1-11-2013
1-11-2013
PI=17,4 MBI=7,7 Eff FP=65
Max. 3 fte, 65 FP,
1 maand lukt niet
dec
CONTROL PANEL
<Control Panel - Peak = 3,0>
17,4
14,0
3,0
20,9
PI
2,4
3,6
Peak Staff
65
52
78
Eff FP
42

43. Hondenregistratie – 3 fte
Staffing & Probability Analysis
Avg Staff (people)
<Control Panel - Peak = 3,0>
3
4
5
6
78
3,5
3,0
2,5
2,0
1,5
1,0
Avg Staff (people)
Milestones
0 - CSR
1 - SRR
2 - HLDR
3 - LLDR
4 - CUT
5 - IC
6 - STC
7 - UAT
8 - FCR
9 - 99R
10 - 99.9R
0,5
0,0
1
okt
'13
nov
RISK GAUGE
Duration
Effort
Peak Staff
Quality
%
0
<Control Panel - Peak = 3,0>
10
20 30 40 50 60
<No constraints>
70
80
90 100
SOLUTION PANEL - <Control Panel - Peak = 3,0>
C&T
Life Cycle
Duration
1,7
1,7
Months
Effort
739
739
MHR
Cost
73,9
73,9
EUR (K)
Peak Staff
3,0
3,0
people
MTTD
2,670
2,670
Day s
Start Date 1-11-2013
1-11-2013
PI=17,4 MBI=7,7 Eff FP=65
Max. 3 fte, 65 FP,
1 maand lukt niet
dec
CONTROL PANEL
<Control Panel - Peak = 3,0>
17,4
14,0
3,0
20,9
PI
2,4
3,6
Peak Staff
65
52
78
Eff FP
43

44. Hondenregistratie – 1 mnd
Staffing & Probability Analysis
Avg Staff (people)
<Single Goal - C&T Duration 1,0>
3
4
5
6
7 8
40
Milestones
0 - CSR
1 - SRR
2 - HLDR
3 - LLDR
4 - CUT
5 - IC
6 - STC
7 - UAT
8 - FCR
9 - 99R
10 - 99.9R
30
10
Avg Staff (people)
20
0
1
okt
'13
nov
RISK GAUGE
Duration
Effort
Peak Staff
Quality
%
0
<Single Goal - C&T Duration 1,0>
10
20 30 40 50 60 70
<No constraints>
80
90 100
SOLUTION PANEL - <Single Goal - C&T Duration 1,0>
C&T
Life Cycle
Duration
1,0
1,0
Months
Effort
6.037
6.037
MHR
Cost
603,7
603,7
EUR (K)
Peak Staff
34,9
34,9
people
MTTD
0,505
0,505
Day s
Start Date 1-11-2013
1-11-2013
PI=17,4 MBI=13,0 Eff FP=65
Max. 35 fte, 65 FP,
1 maand lukt ‘wel’
dec
CONTROL PANEL
<Single Goal - C&T Duration 1,0>
17,4
14,0
34,9
20,9
PI
27,9
41,9
Peak Staff
65
52
78
Eff FP
44

45. Begroten van agile projecten
Is de documentatie uit agile projecten geschikt om te meten
m.b.v. (traditionele) omvangbepalingsmethoden?
45

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

47. Agile projecten
Vaak 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?
47

48. De ijzeren driehoek
Functionaliteit
Kwaliteit
Geld/middelen
Tijd
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.
48

49. Waterval vs. agile
Waterval 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?).
49

50. 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?
50

51. Story points
Relatieve omvangsmaat, meet de omvang van user stories t.o.v.
elkaar.
VB: Hondpunten (o.b.v. hoogte).
Ras
Hondpunten
Poedel
5
Schnautzer
6
Duitse herder
Chihuahua
10
2
Labrador
11
Sint Bernhard
12
Bulldog
7
Team X: Duitse herder = 10
Team Y: Schnautzer = 10
Team Z: Chihuahua = 1
Hondpunten/Story points is geen standaard
Niet bruikbaar voor opbouwen historische data
Niet bruikbaar voor begroten project
Niet bruikbaar voor benchmarking
Wel bruikbaar voor begroten sprint
Wel bruikbaar voor velocity/burn down
51

52. Planning poker
Planning poker meeting met alle teamleden
Kaarten: 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.
52

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

54. Ideal days vs actual days
Feature 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!
54

55. Onze visie
55

56. Typische size metrieken
Een 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.
56

57. Productiviteit vs. velocity
Agile 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.
57

58. Velocity/Burn down charts
58

59. Wat willen we?
Aanbieding t.b.v. een bid of PvA voor het project
Zo goed mogelijk begroten van het project
Methode: cost engineering begroting o.b.v. productiviteit
Begroten van sprint X
Planning poker
Gebaseerd op velocity X-1 (X-2, X-3, etc.)
Gedurende volledige project: Project control
Bewaken 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 project
Performance measurement + benchmark + vastleggen data
59

60. Begroten van een agile project
Input:
• 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
60

61. Sogeti en cost engineering
Afdeling 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 cetera
Data: 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 beheer
Al jarenlang betrokken bij de RVO’s binnen Sogeti.
Nu ondersteunend aan de hele Sogeti organisatie.
61

62. Young
Professional
@Sogeti

63. Titel | Onderwerp | Plaats | Datum |
63

64. 5. Enkele klanten van Sogeti
64

65. 6. In de prijzen
•Beste Werkgever
Incompany Award: Beste werkgever van 2013 (5e keer!)
•Beste Werkgever
Imago onderzoek Intomart/GfK (Telegraaf Media Groep & Elsevier): Beste
werkgever van 2011
•Beste Imago, MT500
Bedrijven met het beste imago, van nr 123 naar 47
•Beste ICT- dienstverlener
Computable Awards: Beste ICT-dienstverlener van 2011 ( 2e keer!)
•IBM Beacon Awards
Internationaal Winnaar in de categorieën “Cloud Computing Innovation Cloud Builder” en “Outstanding Collaboration with IBM Global Technology
Services”
•Nummer 1 in Testen
volgens internationaal onderzoeksbureau Ovum.
•Microsoft Partner of the Year 2011
65

66. 7. Duurzaam ondernemen
Duurzaam betekent voor Sogeti:
Verspilling voorkomen en verantwoord omgaan met mens
en milieu.
2011: Sogeti CO2-neutraal
66

67. 8. Sogeti Nederland
Piet Wybe Wagter, CEO
Expertise divisies
Commerciële divisies
Testing & Quality Control
Finance
IS, Security & High Tech
Application New Technology
Public
Transport & Utilities
Application Lifecycle
Management
Manufacturing & Services
Consulting Services
Banking & Payments
67

68. 10. Jouw carrière & het ontwikkeltraject
68

69. 11. Ohio (USA)
High Performance Teaming (HPT), klantgericht werken, coaching,
persoonlijke vaardigheden
3 weken, 2 weekenden
69

70. Bedankt voor
jullie aandacht!
SEC@sogeti.nl

71. Harold van Heeringen
Senior Consultant Software Metrics /Software Cost Engineer
Sogeti Sizing, Estimating & Control (SEC)
@haroldveendam
Harold.van.heeringen@sogeti.nl
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)