Begroten van agile projecten, technical meeting Sogeti 2013-09

929 views

Published on

Begroten van Agile projecten, waarom is dit anders dan het begroten van traditioneel uitgevoerde projecten?

  • Be the first to comment

Begroten van agile projecten, technical meeting Sogeti 2013-09

  1. 1. Agile Begroten. SEC.
  2. 2. 2 Voorspelling?
  3. 3. 3 Agile & Begroten?
  4. 4. 4 Agile Manifest Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd. Mensen en hun onderlinge interactie boven processen en tools Werkende software boven allesomvattende documentatie Samenwerking met de klant boven contractonderhandelingen Inspelen op verandering boven het volgen van een plan
  5. 5. 5 Agile Manifest Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd. Samenwerking met de klant boven contractonderhandelingen Inspelen op verandering boven het volgen van een plan
  6. 6. 6 Uitgangspunten
  7. 7. 7 Altijd 7% Vaak 13% Soms 16% Vrijwel niet 19% Nooit 45% Gebruik van gebouwde requirements Requirements
  8. 8. TM Begroten van agile projecten
  9. 9. 14 september 2013 Waarom? Hoe? Wanneer? Wie? Wat?
  10. 10. Harold van Heeringen Software Cost Engineer, Sogeti Nederland B.V. ISBSG president COSMIC IAC, NL afgevaardigde NESMA bestuur wg COSMIC wg Benchmarking wg FPA in contract(ing) harold.van.heeringen@sogeti.nl @haroldveendam haroldveendam haroldvanheeringen
  11. 11. 11 Introductie Het belang van het begroten van projecten Traditioneel begroten (binnen Sogeti) Agile begroten – Waarom is dit anders? Onze visie op agile begroten Case – RPU aanbieding
  12. 12. 12 Begroten van software Zo denken veel klanten erover als ze om een begroting voor softwarerealisatie vragen. Sogeti wil haar klanten een realistische, onderbouwde, objectieve en verdedigbare begroting aanbieden!
  13. 13. 13 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!
  14. 14. 14 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.
  15. 15. 15 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! Sogeti CoE’s: RVO’s fixed price, fixed date, risico’s!! Sogeti PM’s: verantwoordelijk voor succes van projecten bij de klant.
  16. 16. 16 Overschatten/onderschatten Onderschatten Overschatten Lineaire extra kosten Extra uren worden besteed Te lage schattingen ExtraKosten 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
  17. 17. 17 Traditioneel begroten
  18. 18. 18 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
  19. 19. 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)
  20. 20. 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
  21. 21. 21 Sogeti begrotingen CoE expertbegroting Functioneel ontwerper: F.O. uren Technisch architect: coding +UT uren Tester: testuren Projectleider: PL uren Cost engineering begroting (SEC) Omvangmeting (FP / CFP) Methodische begroting - Uren, doorlooptijd, FTE, kosten - Scenario’s - Risico’s Challenge Aanbieding ABF Plan van aanpak
  22. 22. 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!
  23. 23. 23 Begroten van agile projecten Is de documentatie uit agile projecten geschikt om te meten m.b.v. (traditionele) omvangbepalingsmethoden?
  24. 24. 24 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.
  25. 25. 25 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?
  26. 26. 26 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.
  27. 27. 27 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?).
  28. 28. 28 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?
  29. 29. 29 Ras Hondpunten Poedel 5 Schnautzer 6 Duitse herder 10 Chihuahua 2 Labrador 11 Sint Bernhard 12 Bulldog 7 Story points Relatieve omvangsmaat, meet de omvang van user stories t.o.v. elkaar. VB: Hondpunten (o.b.v. hoogte). 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
  30. 30. 30 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.
  31. 31. 31 Vragen Wie heeft er ervaring met planning poker? Hoe nauwkeurig zijn de begrotingen n.a.v. planning poker ? Hoe vaak wordt alle geplande functionaliteit tijdens een sprint ook daadwerkelijk gerealiseerd? Wat zijn de voordelen van planning poker t.o.v. een cost engineering begroting (methodische begroting)?
  32. 32. 32 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.
  33. 33. 33 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!
  34. 34. 34 Onze visie
  35. 35. 35 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.
  36. 36. 36 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.
  37. 37. 37 Velocity/Burn down charts
  38. 38. 38 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
  39. 39. 39 Begroten van een 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
  40. 40. 40 Case – SNS Bank RPU Aanbieding 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).
  41. 41. 41 425 FP, 3 maanden Staffing & Probability Analysis Avg Staff (people) <Single Goal - Life Duration 3,5 incl FO> 1 2 3 jul '13 aug sep okt nov dec 0 5 10 15 20 AvgStaff(people) 654321 D Act R 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> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 70 80 90 100 SOLUTION PANEL - <Single Goal - Life Duration 3,5 incl FO> Duration Effort Cost Peak Staff MTTD Start Date R Act 3,4 7.925 673,7 17,0 0,468 2-9-2013 Life Cycle 3,5 10.779 916,2 23,1 0,468 2-9-2013 Months MHR EUR (K) people Days 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 vast Doorlooptijd vast Effort variabel
  42. 42. 42 7 FTE, 3 maanden Staffing & Probability Analysis Avg Staff (people) <Control Panel - Peak = 7,0, incl fo> 1 2 3 jul '13 aug sep okt nov dec 0 1 2 3 4 5 6 AvgStaff(people) 654321 D Act R 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> Duration Effort Peak Staff Quality % 0 10 20 30 40 50 60 70 80 90 100 SOLUTION PANEL - <Control Panel - Peak = 7,0, incl fo> Duration Effort Cost Peak Staff MTTD Start Date R Act 3,5 2.477 210,6 5,2 0,977 2-9-2013 Life Cycle 3,5 3.369 286,4 7,0 0,977 2-9-2013 Months MHR EUR (K) people Days 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 variabel Doorlooptijd vast Effort vast
  43. 43. 43 Voorbeeld project control SEI Core Metrics Schedule 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 29-05 '10 12-0626-0610-0724-0707-0821-0804-0918-0902-1016-1030-1013-1127-1111-1225-1208-01 '11 22-01 ELABORATION CONSTRUCTION TRANSITION Phases 87654321 321 8765 Milestones 1 - ELAB1 2 - ELAB2 3 - CONS1 4 - CONS2 5 - CONS3 6 - CONS4 7 - TRAN1 8 - TRAN2 Milestones 1 - ELAB1 2 - ELAB2 3 - CONS1 4 - CONS2 5 - CONS3 6 - CONS4 7 - TRAN1 8 - TRAN2 Milestones 1 - ELAB1 2 - ELAB2 3 - CONS1 4 - CONS2 5 - CONS3 6 - CONS4 7 - TRAN1 8 - TRAN2 % Complete 3 6 9 12 15 18 21 24 27 30 33 29-05 '10 19-06 10-07 31-07 21-08 11-09 02-10 23-10 13-11 04-12 25-12 15-01 '11 0 20 40 60 80 100 120 140 % 87654321 Cum Effort Life Cycle 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 29-05 '10 12-0626-0610-0724-0707-0821-0804-0918-0902-1016-1030-1013-1127-1111-1225-1208-01 '11 22-01 0 1.000 2.000 3.000 4.000 5.000 6.000 MHR 87654321 Date 4-9-2010 (14,86 weeks) % Complete (%) Cum Effort Life Cycle (MHR) PI MBI Plan 36,1 2.429,6 18,9 4,6 Actual/ Forecast 44,4 2.530,0 19,9 4,4 Est. to Complete 55,6 830,8 Current Plan Actuals Current Forecast Green Control Bound Yellow Control Bound Project: Project X
  44. 44. 44 Project benchmark Ook 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 SpeedofDelivery Project XProject X Microsoft Totaal Special Project QSM Business Avg. Line Style 1 Sigma Line Style 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 Style 1 Sigma Line Style
  45. 45. 45 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. Voorheen MD en AS. Nu ondersteunend aan de hele Sogeti organisatie.
  46. 46. 46 Services voor jullie! Begroten project (Agile / traditioneel) Reality check project Project Control Project Benchmark Trainingen Awareness sessies Consultancy .
  47. 47. 47 Handouts! Agile vs. traditional development projects – 10 ‘take aways’. SEC Report: Begroten van Agile projecten Flyer SEC diensten Projectmanagers in het veld
  48. 48. Agile begroten doe je samen met Shared SEC! SEC@sogeti.nl
  49. 49. Harold van Heeringen Software Cost Engineer, Sogeti Nederland B.V. ISBSG president COSMIC IAC, NL afgevaardigde NESMA bestuur wg COSMIC wg Benchmarking wg FPA in contract(ing) harold.van.heeringen@sogeti.nl @haroldveendam haroldveendam haroldvanheeringen
  50. 50. Lagerhuis. Voor. Tegen.
  51. 51. 51
  52. 52. 52 Value/risk relationship avoid do first do seconddo last Backlog met features 200 FP 100 FP 100 FP 400 FP Cost engineering begroting: 250 FP is mogelijk. Welke? Of toch groter team/langere doorlooptijd?
  53. 53. 53 Voortgangsrapportage?
  54. 54. 54 Stelling 1 Agile projecten kun je niet begroten!
  55. 55. 55 Stelling 2 Begroten is altijd zoeken naar schijnveiligheid!
  56. 56. 56 Stelling 3 Agile is een hype en dus binnenkort voorbij
  57. 57. Vragen? Discussie? Chaos?
  58. 58. 58 Opleidingen Functionele omvang bepalen Methodisch begroten Controle houden Functiepuntanalyse (NESMA, IFPUG) Consultancy Realisatie Beheer Benchmarking Methodisch begroting o.b.v. omvang, ervaringscijfers, modellen en tools COSMIC Omvangschatting Overige methodieken (CP, IBRA, UCP, TPA, TCP, MKII) Second opinion & verschilanalyse Metrics Desk Detachering Meten is Weten! Markt (ISBSG), Sogeti, of eigen ervaringscijfers Estimating Wizard, QSM-Slim, Seer-SEM Project Control Portfolio Control Scope Management Supplier Performance Measurement Estimation & Performance Management (E&PM) Wat doet (Shared) SEC?
  59. 59. 59 Sizing, Estimating & Control Software Metrics 3 FTE: Harold van Heeringen, Theo Prins, Edwin van Gorp Gecertificeerd in FPA, COSMIC, QSM Jarenlange ervaring Profilering: NESMA, COSMIC, ISBSG, ICEAA Methodes: FPA, COSMIC, TPA, UCP, CP, IBRA, etc. Tools: QSM toolsuite, Galorath SEER-SEM, ISBSG repositories, eigen wizards Het Sogeti kenniscentrum op het gebied van meten, begroten, bewaken en benchmarken van software realisatie en beheerprojecten. Wat is (Shared) SEC?

×