Gaat het lukken binnen de afgesproken tijd?

In de wereld van softwareontwikkeling is het een veelbesproken onderwerp: projecten die altijd uitlopen. We horen regelmatig in het nieuws dat projecten van bijvoorbeeld de overheid niet worden voltooid binnen de gestelde termijnen. Ik moet eerlijk toegeven dat ik op dit gebied ook schuldig ben.

Er zijn talloze excuses die developers gebruiken om deze vertragingen te rechtvaardigen: onvolledige of gewijzigde informatie, moeilijkheden bij het gebruik van bestaande software en afhankelijkheid van externe partijen. De lijst is eindeloos. Af en toe kunnen veranderingen in de planning natuurlijk ook positief uitpakken: we zagen beren op de weg die er simpelweg niet waren.

Een straat leggen

Helaas bestaat er geen formule om een nauwkeurige inschatting te maken van de duur van het ontwikkelen van een stukje software. Vergelijkbaar met het leggen van een straat, waarbij we grofweg kunnen uitgaan van een aantal m² per uur, zijn er vele factoren om rekening mee te houden. Denk hierbij aan verschillende niveau’s van ervaring van de stratenmakers of extra tijd voor opruimen en het egaliseren van de ondergrond, om maar enkele randzaken te noemen die de inschatting kunnen beïnvloeden.

In de wereld van software engineering zijn deze randzaken niet altijd zichtbaar, waar dat bij een berg puin naast een mooi gelegd straatje wel het geval is. Het is daardoor gemakkelijk om randzaken over het hoofd te zien tijdens het maken van schattingen en implementaties. En wat nog erger is, het puin kan bewust genegeerd worden om binnen de geschatte uren te blijven.

Sneeuwbaleffect

Het negeren van deze randzaken staat in software termen bekend als ‘technische schuld’. Hoe meer van deze schuld er ontstaat, hoe moeilijker het wordt om realistische schattingen te maken. Dit leidt tot een sneeuwbaleffect: het wordt bijna onmogelijk om een inschatting te maken voor het aanleggen van een ‘straat’ vol puin, kruiwagens en gebroken beloftes. Het vertrouwen in het project slinkt aan alle kanten. Voor de volgende meter straat ben ik dan snel geneigd om maar gewoon op dezelfde voet verder te gaan. Ik ben niet gemotiveerd om puin te ruimen en de kans is groot dat er nog meer puin bij komt om maar geen vertraging op te lopen. Wat willen we nu eigenlijk? Binnen de uren blijven of kwaliteit leveren zodat het ook nog te onderhouden valt?

Punten

Een betere benadering voor het inschatten van softwareprojecten is het gebruik van punten in plaats van uren. Hierbij wordt een totaal aantal punten toegekend aan een functionaliteit op basis van de inspanning en complexiteit ervan. Deze benadering maakt de inschatting relatief in plaats van concreet. We zijn als mensen beter in het maken van vergelijkingen, het is duidelijk dat een volledige straat meer tijd kost dan mijn oprit.

Online is er genoeg te vinden over Agile-methodologieën en ‘story points’. Het grootste voordeel hiervan is dat het vertrouwen wordt gegeven aan de ontwikkelaar, zodat deze zijn uiterste best kan doen om de functionaliteit op te leveren en de tijd mag nemen om zijn ‘straatje’ schoon op te leveren.

Het maken van een goede inschatting vergt tijd en inspanning. Het kan niet worden afgehandeld bij de koffieautomaat. Het vereist gezamenlijke inzet van het team, gebaseerd op bestaande criteria en afbakening. Het doorlopen van checklists per functionaliteit als team is enorm belangrijk. De kwaliteit van oplevering is hierbij essentieel om gedurende de looptijd van het project de punten relatief hetzelfde te houden, misschien zelfs naar beneden af te kunnen stellen.

Het kan beter

Het schrijven van deze blog is voor mijzelf een wake-up call: ik moet erkennen dat ik af en toe nog steeds neig naar het baseren van mijn inschattingen op uren. Hiervoor bied ik mijn excuses aan. Ik ga mijn uiterste best doen om dit in de toekomst te voorkomen!

Ps: Veel succes voor de sales teams die softwareprojecten verkopen op basis van uren 😉

Eric Pinxteren
Technologie