Als je naar Google gaat en zoekt naar “het meten van de productiviteit van softwareontwikkelaars” je zult heel veel niets vinden. Ernstig — niets.
Nick Hodges, De productiviteit van ontwikkelaars meten

Dat zouden we inmiddels allemaal moeten weten we weten niet hoe we de productiviteit van programmeurs moeten meten.

Er is geen duidelijke manier om te meten welke programmeurs doen het beter of sneller, of om de productiviteit tussen teams te vergelijken. We "weten" wie de sterren in een team zijn, op wie we kunnen vertrouwen, en wie worstelt. En we weten of een team in de kont schopt - of aan het slepen is. Maar hoe bewijzen we het?? Hoe kunnen we het kwantificeren??

Er kunnen allerlei domme en slechte dingen gebeuren als je probeer de productiviteit van de programmeur te meten.

Maar laten we het toch doen.

We schrijven meer code, dus we moeten productiever zijn

Ontwikkelaars worden betaald om code te schrijven. Dus waarom niet meten hoeveel code ze schrijven - hoeveel regels code afgeleverd worden?

Omdat we dat zijn bekend sinds de jaren 80 dat dit een slechte manier is om productiviteit te meten.

Regels met code kunnen niet tussen talen worden vergeleken (natuurlijk), of zelfs tussen programmeurs die dezelfde taal gebruiken die in verschillende frameworks werken of verschillende stijlen volgen. Daarom Functiepunten werden uitgevonden - een poging om de omvang van het werk in verschillende omgevingen te standaardiseren en te vergelijken. Klinkt goed, maar functiepunten heb het niet gehaald in de mainstream, en waarschijnlijk ook nooit - heel weinig mensen weet hoe functiepunten werken, hoe ze moeten worden berekend en hoe ze moeten worden gebruikt.

Het meer fundamentele probleem is het meten van de productiviteit aan de hand van lijnen (of functiepunten of andere afgeleiden) getypt heeft geen zin. Veel belangrijk werk bij softwareontwikkeling, het belangrijkste werk, impliceert denken en leren - niet typen.

De beste programmeurs besteden veel tijd aan het begrijpen en oplossen van moeilijke problemen, of andere mensen helpen moeilijke problemen te begrijpen en op te lossen, in plaats van te typen. Ze vinden manieren om code te vereenvoudigen en duplicatie te elimineren. En veel van de code die ze schrijven, telt sowieso niet, terwijl ze door experimenten herhalen en prototypes bouwen en alles weggooien om tot een optimale oplossing te komen.

De tekortkomingen in deze maatregelen zijn duidelijk als we kijken naar de ideale resultaten: zo min mogelijk regels code om een ​​probleem op te lossen, en het creëren van vereenvoudigd, gemeenschappelijke processen en klantinteracties die de complexiteit van IT-systemen verminderen. Onze meest productieve mensen zijn degenen die ingenieuze manieren vinden om helemaal geen code te schrijven.
Jez Humble, De Lean Enterprise

Dit is duidelijk een van die gevallen waarin de grootte er niet toe doet.

We maken (of sparen) meer geld,
dus we moeten beter werken

We zouden kunnen proberen de productiviteit op een hoog niveau te meten met behulp van winstgevendheid of financieel rendement op wat elk team levert, of een andere zakelijke maatstaf, zoals hoeveel klanten het systeem gebruiken - als ontwikkelaars meer geld verdienen voor het bedrijf (of meer geld besparen), ze moeten iets goed doen.

Het gebruik van financiële maatregelen lijkt een goed idee op uitvoerend niveau, vooral nu "elk bedrijf is een softwarebedrijf”. Dit zijn organisatorische maatregelen waaraan ontwikkelaars zouden moeten deelnemen. Maar ze zijn geen effectieve - of eerlijke - maatstaven voor de productiviteit van ontwikkelaars. Er zijn te veel zakelijke factoren waar het ontwikkelingsteam geen controle over heeft. Sommige producten of diensten slagen zelfs als de mensen die ze afleveren slecht werk leveren, of falen, zelfs als het team geweldig werk heeft geleverd. Door vooral te focussen op kostenbesparingen, snijden veel managers mensen af ​​en proberen ze “meer te doen met minder” in plaats van te investeren in echte productiviteitsverbeteringen.

En als Martin Fowler wijst erop er is een vertraging, vooral in grote organisaties - het kan soms maanden of jaren duren om echte financiële resultaten van een IT-project te zien, of van productiviteitsverbeteringen.

We moeten ergens anders zoeken om zinvolle productiviteitsstatistieken te vinden.

We gaan sneller, dus we moeten productiever worden

Ontwikkelingssnelheid meten - snelheid in Agile - ziet eruit als een andere manier om productiviteit op teamniveau te meten. Ten slotte, het punt van softwareontwikkeling is om werkende software te leveren. Hoe sneller een team levert, des te beter.

Maar snelheid (hoeveel werk, gemeten in verhaalpunten of kenmerkpunten of ideale dagen, dat het team levert in een bepaalde tijd) is echt een maat voor voorspelbaarheid, niet productiviteit. Velocity is bedoeld om door een team te worden gebruikt om te meten hoeveel werk ze kunnen aannemen, om hun schattingen te kalibreren en hun werk vooruit te plannen.

Zodra de snelheid van een team is gestabiliseerd, jij kan meten veranderingen in snelheid binnen het team als relatieve maatstaf voor productiviteit. Als de snelheid van het team afneemt, het kan een indicator zijn van problemen in het team of het project of het systeem. Of u kunt snelheid gebruiken om de impact van procesverbeteringen te meten, om te zien of training of nieuwe tools of nieuwe praktijken het werk van het team daadwerkelijk meetbaar sneller maken.

Maar je zal wel moeten rekening houden met veranderingen in het team, als mensen toetreden of vertrekken. En je zult moeten onthouden dat snelheid een maat is die alleen binnen een team zin heeft - dat je kunt de snelheid tussen teams niet vergelijken.

Hoewel dit mensen er niet van weerhoudt het te proberen. Sommige winkels gebruiken het idee van een bekend referentieverhaal dat alle teams in een programma begrijpen en gebruiken om hun geschatte verhaalpunten op te baseren. Zolang teams niet veel vrijheid krijgen bij het maken van schattingen, en zolang de teams in hetzelfde project of programma werken met dezelfde beperkingen en aannames, je zou in staat zijn om de snelheid tussen teams ruw te vergelijken. Maar Mike Cohn waarschuwt dat

Als teams de minste aanwijzing voelen dat snelheden tussen teams zullen worden vergeleken, zal er een geleidelijke maar consistente "puntinflatie" zijn.

ThoughtWorks legt dat uit snelheid <> productiviteit in hun nieuwste Technology Radar:

We blijven zien dat teams en organisaties snelheid gelijkstellen aan productiviteit. Bij correct gebruik, velocity maakt het mogelijk om "het weer van gisteren" op te nemen in het interne iteratieplanningsproces van een team. De sleutel hier is dat snelheid een interne maat is voor een team, het is slechts een schatting van de capaciteit voor dat gegeven team op dat moment. Organisaties en managers die interne snelheid gelijkstellen aan externe productiviteit, beginnen doelen te stellen voor snelheid, vergeten dat het eigenlijk gaat om werkende software in productie. Snelheid behandelen als productiviteit leidt tot onproductief teamgedrag dat deze maatstaf optimaliseert ten koste van daadwerkelijk werkende software.

Blijf gewoon bezig

Een manager die ik ken, zegt dat in plaats van de productiviteit te meten

'We blijven gewoon bezig. Als we het druk hebben met werken als maniakken, we kunnen problemen en bottlenecks opsporen en oplossen en doorgaan ".

In dit geval zou u meten - en optimaliseren voor - cyclustijd, zoals bij Lean Manufacturing.

Cyclustijd - doorlooptijd of doorlooptijd wijzigen, vanaf het moment dat het bedrijf iets vraagt ​​tot het moment dat ze het in handen krijgen en het zien werken - is iets waar het bedrijf om geeft, en iets dat iedereen kan zien en meten. En als je eenmaal goed begint te kijken, verspilling en vertragingen zullen verschijnen als u wachttijd / inactiviteit meet, toegevoegde waarde vs.. werk zonder toegevoegde waarde, en procescyclus efficiëntie (totale tijd voor toegevoegde waarde / totale cyclustijd).

"Het is niet belangrijk om productiviteit te definiëren, of om het te meten. Het is veel belangrijker om niet-productieve activiteiten te identificeren en deze tot nul terug te brengen. "
Erik Simmons, Intel

Teams kunnen gebruiken Kanban om onderhanden werk te monitoren en te beperken en vertragingen en knelpunten te identificeren. En Value Stream Mapping om de stappen te begrijpen, wachtrijen, vertragingen en informatiestromen die moeten worden geoptimaliseerd. Effectief zijn, je moet kijken naar het end-to-end-proces vanaf het moment dat verzoeken voor het eerst worden gedaan tot het moment dat ze worden afgeleverd en uitgevoerd, en optimaliseer het hele pad, niet alleen het werk in ontwikkeling. Dit kan betekenen dat u moet veranderen hoe het bedrijf prioriteiten stelt, hoe beslissingen worden genomen en wie de beslissingen neemt.

In bijna alle gevallen hebben we gezien, het efficiënter maken van een procesblok heeft een minimaal effect op de totale waardestroom. Omdat nabewerking en wachttijden enkele van de grootste bijdragen aan de totale levertijd zijn, het adopteren van "agile" processen binnen een enkele functie (zoals ontwikkeling) heeft over het algemeen weinig impact op de totale waardestroom, en dus op de resultaten van de klant.
Jezz nederig, De Lean Enterprise

De keerzijde van het gelijkstellen van bezorgsnelheid aan productiviteit? Het op zichzelf optimaliseren van de cyclustijd / snelheid van levering kan op de lange termijn tot problemen leiden, omdat dit mensen ertoe aanzet om op korte termijn te denken, en om te bezuinigen en technische schulden aan te gaan.

We schrijven betere software, dus we moeten productiever zijn

“De paradox is dat wanneer managers zich richten op productiviteit, verbeteringen op de lange termijn worden zelden aangebracht. Anderzijds, wanneer managers focussen op kwaliteit, productiviteit verbetert continu. "
John Seddon, geciteerd in De Lean Enterprise

We weten dat het later repareren van bugs kost meer. Of het nu is 10x of 100 + x, het maakt eigenlijk niet uit. En dat projecten met minder bugs worden sneller opgeleverd - in ieder geval tot een punt van afnemende opbrengsten voor veiligheidskritische en levenskritische systemen.

En we weten dat de kosten van bugs en fouten in software voor het bedrijf aanzienlijk kunnen zijn. Niet alleen kosten voor herwerking van ontwikkeling en onderhouds- en ondersteuningskosten. Maar directe kosten voor het bedrijf. Uitvaltijd. Inbreuken op de beveiliging. IP verloren. Verloren klanten. Boetes. Rechtszaken. Zakelijke mislukking.

Haar gemakkelijk te meten dat u goede - of slechte - software schrijft. Defecte dichtheid. Defecte ontsnappingspercentages (vooral defecten - inclusief beveiligingsproblemen - die ontsnappen naar de productie). Statische analysestatistieken op de codebasis, met behulp van tools zoals SonarQube.

En we weten hoe we goede software moeten schrijven – of we zouden het nu moeten weten. Maar is softwarekwaliteit voldoende om productiviteit te definiëren?

Devops - IT-prestaties meten en verbeteren

Devops-teams die systemen bouwen / onderhouden en bedienen / ondersteunen, breiden de productiviteit uit van dev naar ops. Ze meten de productiviteit over twee dimensies die we al hebben bekeken: snelheid van levering, en kwaliteit.

Maar devops is niet alleen beperkt tot het bouwen en leveren van code, maar kijkt naar prestatiestatistieken voor end-to-end IT-dienstverlening:

1. Levering doorvoer: inzetfrequentie en doorlooptijd, het maximaliseren van de stroom van werk naar productie
2. Service kwaliteit: mislukkingstarief wijzigen en MTTR

Het is niet een kwestie van software alleen sneller of beter leveren. Het zijn dev en ops die samenwerken om services beter en sneller te leveren, een balans vinden tussen te snel bewegen of te veel tegelijk proberen te doen, en buitensporige bureaucratie en overdreven voorzichtigheid resulterend in verspilling en vertragingen. Dev en ops moeten de verantwoordelijkheid en aansprakelijkheid voor het resultaat delen, en voor het meten en verbeteren van productiviteit en kwaliteit.

Zoals ik al aangaf een eerder bericht dit maakt operationele statistieken belangrijker dan statistieken voor ontwikkelaars. Volgens Recent onderzoek, succes bij het bereiken van deze doelen leidt tot verbeteringen in zakelijk succes: niet alleen productiviteit, maar marktaandeel en winstgevendheid.

Meet resultaten, geen uitvoer

In De Lean Enterprise (waarvan je kunt zien dat ik net klaar ben met lezen), Jez Jumble heeft het over het belang van het meten van productiviteit op resultaat - het meten van dingen die belangrijk zijn voor de organisatie - niet op output.

"Het maakt niet uit hoeveel verhalen we voltooien als we niet de bedrijfsresultaten behalen die we wilden bereiken in de vorm van doelvoorwaarden op programmaniveau".

Stop met meten individuele ontwikkelaarsproductiviteit. Het is tijdsverspilling.

• Iedereen weet wie de beste artiesten zijn. Wijs ze in de goede richting, en houd ze tevreden.
• Iedereen kent de mensen die het moeilijk hebben. Geef ze de hulp die ze nodig hebben om te slagen.
• Iedereen weet wie er niet bij past. Haal ze weg.

Het meten en verbeteren van de productiviteit bij het team of (beter) op organisatieniveau krijgt u veel zinvollere resultaten.

Als het om productiviteit gaat:

1. Meten dingen die ertoe doen - dingen die het verschil maken voor het team of voor de organisatie. Maatregelen die duidelijk zijn, belangrijk, en dat is niet gemakkelijk te gamen.
2. Gebruik statistieken ten goede, niet voor het kwaad - om leren en verbeteren te stimuleren, niet om output tussen teams te vergelijken of om mensen te rangschikken.

Ik begrijp waarom het meten van productiviteit zo verleidelijk is. Als we dat zouden kunnen, zouden we software veel gemakkelijker en objectiever kunnen beoordelen dan nu. Maar valse maatregelen maken het alleen maar erger.
Martin Fowler, CannotMeasureProductivity

Over de auteur

Jim Bird is een ervaren softwareontwikkelingsmanager, projectmanager en momenteel CTO bij een financiële dienstverlener. Hij is gefocust op harde problemen bij softwareontwikkeling en onderhoud, softwarekwaliteit en beveiliging. Als laatste 15 jarenlang heeft hij teams geleid die hoogwaardige financiële systemen bouwen en exploiteren. Zijn speciale interesse is hoe kleine teams het meest effectief kunnen zijn in het bouwen van echte software: van hoge kwaliteit, veilige systemen met de uiterste grenzen van betrouwbaarheid, prestatie, en aanpassingsvermogen. Software die moet werken, dat is goed gebouwd, en gebouwd om lang mee te gaan. Dit artikel is oorspronkelijk op zijn eigen blog geplaatst Echte software bouwen.

Een blogpost vertegenwoordigt de persoonlijke mening van de auteur
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.