[vc_row padding_top=”0″ padding_bottom=”0″][vc_column][vc_column_text]
To #Estimate or to #NoEstimate, is that really a question?
Al zolang er software ontwikkeld wordt is het begroten van software realisatie projecten een lastige exercitie. Hoewel er wel degelijk beproefde methoden en technieken zijn om projecten professioneel te begroten zijn er in de markt weinig organisaties die deze expertise en vaardigheden hebben. In de praktijk worden veel projecten daarom begroot door middel van ‘human judgement’, oftewel experts die een inschatting geven op basis van hun ervaring.
De cijfers van onderzoeken*) wijzen uit dat deze begrotingen tot wel 30% te optimistisch zijn, wat leidt tot (grote) overschrijdingen van budget en doorlooptijd. Omdat projecten zo vaak fout gaan is er een hele stroming opgestaan van mensen met de stelling: “begroten is zo lastig, en begrotingen komen nooit uit, daarom is het beter om geen enkele energie te stoppen in het begroten van software realisatie projecten”. Dit is de zogenaamde #NoEstimates beweging.[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”20″ padding_bottom=”20″][vc_column width=”1/2″][vc_single_image image=”23758″ img_size=”large”][/vc_column][vc_column width=”1/2″][vc_column_text]Ik vind het erg interessant om te zien hoe de hardcore ‘#NoEstimates’ fanaten van deze wereld het durven voor te stellen om fundamentele principes overboord te zetten. Ik zou zelf in ieder geval niet zo snel een aannemer een blanco cheque geven om een nieuw huis voor mij te bouwen. Zodra het geld van iemand anders is, worden dit soort zaken kennelijk makkelijker.
Ik heb met grote interesse een twitter discussie gevolgd tussen Glen B. Alleman (@galleman) en Vasco Duarte (@Duarte_Vasco) over de zin en de onzin van het begroten van software projecten. Vasco Duarte is een Agile, Lean and Scrum Speaker en een voorstander van #NoEstimates. Hij heeft hier zelfs een boek over geschreven. Glen B. Alleman is een ervaren projectmanager die o.a. het boek ‘Performance-Based Project Management: Increasing the Probability of Project Success’ heeft geschreven en een groot voorstander is van het toepassen van professionele cost estimation methoden, ook voor software. Even een paar tweets om erin te komen:[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”20″ padding_bottom=”20″][vc_column width=”1/2″][vc_column_text]In mijn ogen heeft Glen B. Alleman daarom helemaal gelijk. Iemand besteed geld en wil begrijpen of datgene waar hij het aan uitgeeft ook zinvol is en of het Value for Money opbrengt. Volgens Steve McConnell’s boek ‘Software estimation, demystifying the black art’ is een realistische begroting juist een zeer belangrijke voorwaarde voor het slagen van het project. Een optimistische begroting leidt tot correcties die veel groter zijn dan het optimisme in de begroting en bij een pessimistische begroting geldt de wet van Parkinson (extra tijd/geld wordt opgemaakt, ook als dit niet nodig is).
In onze praktijk zien we agile projecten net zo vaak in de problemen komen als de traditionele watervalprojecten, alleen wordt dit vaak minder zichtbaar omdat er meestal geen vaste prijs en vaste opleverdatum zijn vastgesteld. Soms is dat niet erg, maar wat nou als er een grote marketingcampagne gepland is waar de gevraagde functionaliteit voor nodig is, of wat als er een wet ingaat en de functionaliteit is nodig voor de uitvoering daarvan?[/vc_column_text][/vc_column][vc_column width=”1/2″][vc_single_image image=”23759″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”0″][vc_column][vc_column_text]Bij Software Cost Estimation van agile projecten gaat het vooral om het begroten van de hoeveelheid functionaliteit die klaar is op moment X en welke kosten daarmee gemoeid zijn. Een belangrijke eerste stap is het vaststellen van de omvang van hetgeen ontwikkeld moet worden in een standaard omvangmaat, zodat het mogelijk is om parametrische modellen en relevante data te gebruiken.
Een kleine analogie:
Het zal voor een schilder lastig zijn in te schatten hoe veel tijd het kost een lange en hoge muur te schilderen. Pas als hij de vierkante meters heeft opgemeten kan hij zijn eigen ervaringscijfers (x vierkante meter per dag) gebruiken om de inschatting te maken. En als hij vanwege een korte doorlooptijd met 2 of 3 man moet werken, dan heeft dat impact op de prijs, maar dat is uit te rekenen.
Het gestandaardiseerd vaststellen van de omvang van een product backlog kan snel (high-level) worden uitgevoerd en maakt het mogelijk om professionele begrotingstechnieken toe te passen. Het professioneel begroten van softwareprojecten is een belangrijk vakgebied en toepassing van de juiste methodes, technieken en data beïnvloedt voor een groot deel de slagingskans van projecten.
De vraag is daarom niet “#Estimates or #NoEstimates?”, maar “hoe kunnen we het meten en begroten van software realisatieprojecten professioneel inrichten in de organisatie, zodat we op basis van een realistische begroting de projecten zo succesvol mogelijk gaan uitvoeren?”
Bronnen
*) IDC Metri[/vc_column_text][vc_column_text]
Een bijdrage van
Harold van Heeringen: mijn passie is het meetbaar en voorspelbaar maken van applicatieontwikkelingstrajecten, of dit nu waterval, agile of op een andere manier gebeurt. Veel organisaties vinden dit moeilijk en ik help hen met het maken van de juiste keuzes gebaseerd op objectieve metingen, beproefde parametrische modellen en relevante data. Daarom ben ik ook al jaren bestuurslid in not-for-profit organisaties als Nesma (internationale ISO/IEC standaard voor functional size measurement) en de International Software benchmarking Standards Group (internationale organisatie die data verzamelt van afgeronde projecten, releases en sprints). Binnen IDC Metri ben ik de practice lead van de afdeling IT-intelligence, waardoor ik dagelijks met deze materie bezig mag zijn.
Ik ben Principal Consultant bij IDC Metri en ben verantwoordelijk voor de dienstverlening rondom het meten, begroten en benchmarken van applicatieontwikkeling en beheer teams en projecten. Ik heb meer dan 20 jaar ervaring met het meten en begroten van softwareprojecten, en het meten van de performance en kwaliteit van (agile) teams.[/vc_column_text][kleo_social_share][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_single_image image=”23760″ img_size=”large” onclick=”custom_link” img_link_target=”_blank” link=”https://connect.ipma.nl/local/pages/?id=186″][/vc_column][vc_column width=”1/2″][vc_single_image image=”21123″ img_size=”large” onclick=”custom_link” img_link_target=”_blank” link=”https://www.hdmwp-demo.nl/lid-worden/”][/vc_column][/vc_row][vc_row padding_top=”0″][vc_column][vc_posts_grid loop=”size:12|order_by:date|post_type:post|categories:717″][/vc_column][/vc_row]