Het ontwikkelen van software is voor leken vaak een mythische aangelegenheid. Jongens met t-shirts en brillen zitten dagen achter elkaar achter een computer ingewikkelde tekens in te kloppen. Ze stoppen alleen voor cola en pizza. En als je maar lang genoeg wacht dan is de software plotseling klaar. Degene die eerder met ontwikkelaars werkten, weten dat het zo niet gaat.

Programmeurs zijn serieuze  mannen die serieus met hun vak bezig zijn. Ja, er zijn in de westerse wereld relatief weinig vrouwen die software maken. Ontwikkelaars hebben in de afgelopen decennia geleerd dat de buitenwacht een beetje transparantie op prijs stelt. Die combinatie van professioneel werken en de vraag naar openheid heeft geleid tot een scala aan manieren waarop de opdrachtgever mee kan sturen in het ontwikkelproces. Maar hoe meet je nou of een ontwikkelaar productief is?

Productie wordt vaak uitgedrukt in stuks per uur, als in: een persoon plukt 20 kilo tomaten per uur. Productiviteit kun je dus uitdrukken in de hoeveelheid output die je krijgt bij een bepaalde hoeveelheid input. Werkt dit ook voor programmeurs? Wat produceren ontwikkelaars dan, wat is hun output? Een aantal mogelijkheden: het aantal regels code, het aantal computerprogramma’s of bijvoorbeeld het aantal nieuwe functionaliteiten of verholpen bugs.

Volgens Microsoft oprichter Bill Gates is het meten van productiviteit in regels code een onzinnige exercitie: “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.” Een groot programma heeft inderdaad veel regels code, maar veel regels code wil niet zeggen dat het programma groot is. Het kan ook gewoon slecht ontworpen zijn. En daar komt nog bij dat het aantal regels code de opdrachtgever niets zegt.

Softwareontwikkelaars produceren geen regels code, maar functi0naliteiten. En die kun je tellen. Je kunt heel grof het aantal tellen, en je kunt dit verder verfijnen door functionaliteiten in te delen in groepen: klein, middel en groot. Als je een stapje verder gaat kun je iedere functionaliteit een waardering geven. Bijvoorbeeld van 1 tot 100. Zo heb je een kleine functionaliteit van 12 punten en een grote van 64. Samen goed voor een productie van 76. En als de ontwikkelaar daar 4 dagen mee bezig is geweest dan is zijn productiviteit 19 punten per dag.

Deze methode lijkt bijzonder (dat is hij ook), maar wordt eigenlijk al heel lang toegepast. Vroeger noemde men dit een functiepuntenanalyse, de tegenwoordige veel hippere term is scrum-punten. En dan maar zeggen dat programmeurs niet trend-gevoelig zijn! Hoe je het ook noemt en wat de subtiele verschillen ook mogelijk zijn, het idee is het zelfde: presenteer een functi0nele vraag aan ontwikkelaar en vraag hem hoeveel punten de bouw kost. Aan de hand van bepaalde tellingen kan vrij nauwkeurig een aantal punten worden bepaald.

Een softwareontwikkelaar levert functionaliteiten op waarbij de hoeveelheid uitgedrukt wordt in punten. Dit meet je iedere week om een gevoel te krijgen van de productiviteit. En daarmee dus ook wat de productie voor de komende week zal worden. Door met punten te werken is het mogelijkheid om redelijk exact te schatten hoeveel werk er af kan komen in een bepaalde periode. Of omgekeerd: hoeveel tijd nodig is om een bepaalde functionaliteit te bouwen.

Deze verbluffend simpele truc werkt in de praktijk erg goed en steeds meer ontwikkelaars passen hem toe. Te crux blijft echter zitten in het continu meten om een goede statistiek op te bouwen. Meten is weten.