Het meten van de prestaties van een ontwikkelteam

[frG]

Ik vraag mij sinds kort af, hoe zouden jullie eigenlijk bepalen hoe goed jouw ontwikkel team het eigenlijk doet en daar een financiële consequentie aan verbonden kan zijn?

Op wat voor manier kan je dat echt meten? Er is hier wel eens getracht om dat via total sprint effort (in geval van scrum) te meten, echter gaat dit natuurlijk tegen het principe van scrum in, en zal het team altijd voor meer effort gaan en minder kwaliteit.

Hebben jullie hier ervaring mee? Concreet is mijn vraag dus eigenlijk, hoe meet je de prestaties van een ontwikkelteam die werken volgens de scrum methodiek?

[Rockster34]

uit eigen ervaring werkt SCRUM zeer optimaal op kleinere groepen omdat je dan better 1 on 1 groeps verband hebt waardoor je dus goede Code kan outputten

[Nick_S]

Ik denk dat je eerst moet bepalen, wat "goed" is in jullie ogen.

- Zoveel mogelijk features opleveren
- Zo min mogelijk bugs opleveren
- Sustainable pace aanhouden

Voor features heb je PKI's KPI's als metrieken, voor bugs heb je je eigen issue tracking systeem, voor sustainable pace wordt het al ingewikkelder. Hier valt m.i. goed onderhoudbare code onder. Goed onderhoudbare code is vrij lastig te kwantificeren, hier zijn al vele pogingen voor geweest. Geen issues op gebied van statische code checkers, hoge test coverage, SIG/CQA scores bijhouden. Vele metrieken mogelijk, maar ze zijn (bijna?) allemaal te gamifyen oftewel te omzeilen, en dat moet niet het doel worden. (Dit wordt wel vrij snel het doel, als er consequenties aan hangen)

Voor goede code heb je ontwikkelaars nodig die daar ook in geloven, bijvoorbeeld door het onderschrijven van Software Craftsmanship.

Thanks Gonadan, ik had de verkeerde term gebruikt.

[ Voor 3% gewijzigd door Nick_S op 19-10-2016 15:54 ]

[Gonadan]

De kwaliteit leg je vast in je standaarden en de definition of done. Daar kan je niet zomaar onder tijdsdruk van af gaan wijken, want dan gaat inderdaad de kwaliteit achteruit. Dat is geen specifieke eigenschap van Scrum, dat is een algemene waarheid in het bedrijfsleven. Zodra men snelheid boven de afspraken en processen gaat stellen hol je achteruit in kwaliteit.

Los daarvan is het prima mogelijk om een aantal KPI's op te stellen om een ontwikkelteam op te beoordelen. Denk aan het aantal bugs/afwijkingen van spec, het aantal emergency releases, de velocity, effectiviteit omtrent releases, etc.
Daar kan je dan op sturen, mits je wel in de gaten houdt of de standaarden nog voldoende gevolgd worden. Ook daar zou je een indicator op kunnen zetten, vaak is het reviewen van zaken aan te raden.

[Nick_S]

Martin Fowler heeft ook een mooi artikel geschreven over het meten van productiviteit.

En ook anderen hebben hier vele artikelen over geschreven:
- The Myth of Developer Productivity
- The Secrets of Measuring Developer Productivity
- We can’t measure Programmer Productivity… or can we?

[ Voor 60% gewijzigd door Nick_S op 19-10-2016 16:04 ]

[DJMaze]

Tja, wat is "productief"?
Ik ken een websitebouwer die er maanden over doet, en ken er één die het zelfde werk in 1 week doet.
In beide gevallen waren ze 100% productief.

Op basis van dit gegeven mag jij financiële consequenties bepalen.
Hint: ongeacht je consequenties zijn aan het einde van de maand hun bankrekeningen toch evenveel aangevuld.

Het geeft maar aan hoe complex de programmeer wereld is. Met puur de bovenstaande gegevens mag jij nu alles bepalen zoals ik met zo weinig gegevens een volledige website moet bouwen

spoiler:

De één is verlamd en maakt de website puur met oog bewegingen en spraak commando's

[ Voor 29% gewijzigd door DJMaze op 19-10-2016 17:26 ]

[Croga]

frG schreef op woensdag 19 oktober 2016 @ 15:42:
Hebben jullie hier ervaring mee? Concreet is mijn vraag dus eigenlijk, hoe meet je de prestaties van een ontwikkelteam die werken volgens de scrum methodiek?

Dan is de wedervraag: Wat is het doel? Wat wil je bereiken door dit te meten?

Houdt er vervolgens rekening mee:
Maakt niet uit wat je meet, je zult er meer van krijgen.

Ga je dus velocity gebruiken als metric hiervoor dan zal de velocity omhoog gaan. Dat betekend niet dat de prestaties verbeteren, alleen dat de velocity omhoog gaat (en per onmiddelijk zinloos is geworden).
Ga je lines of code gebruiken dan zal het aantal lines of code omhoog gaan (zonder dat het iets zinvols toevoegd; ofwel: Je code wordt ingewikkelder en dus moeilijker onderhoudbaat).
Ga je aantal bugs meten dan zal dat omlaag gaan (er zullen niet minder bugs zijn. Er zullen er wel minder geregistreerd worden).

Bottom line: Als je iets gaat meten zal de rest automatisch onder druk komen te staan. Dat gaat dus ten koste van alles wat je niet meet. Daarnaast gaat het ten koste van de effectiviteit van het team aangezien meten vanzelf betekend dat risico meidend gedrag gaat optreden en er dus nooit meer innovatieve oplossingen voor problemen zullen komen.

Je hebt het over financiële consequenties..... Je weet ook dat ALLE onderzoek van de afgelopen eeuw keer op keer weer bewijst dat dat averechts werkt? Er is GEEN ENKEL onderzoek wat aangetoond heeft dat er ook maar de kleinste positieve effecten zijn van dit soort bonussen terwijl er hele bergen onderzoeken zijn die aantonen dat dit soort bonussen de effectiviteit van je team compleet ten gronde richten. Doe dat dus alsjeblieft niet, tenzij je van je goede programmeurs af wilt.

[Hydra]

Croga schreef op woensdag 19 oktober 2016 @ 17:28:
Houdt er vervolgens rekening mee:
Maakt niet uit wat je meet, je zult er meer van krijgen.

Met als toevoeging "ten koste van wat je niet meet".

Als je je code hoeveelheid gaat meten krijg je meer met minder kwaliteit. Meet je de scrum punten afgewerkt in een sprint dan krijg je punten-inflatie. Meet je test-coverage in percentages dan wordt er meer tijd besteed aan het maken van vaak waardeloze tests.

En natuurlijk merk je dat niet omdat je het niet meet. Dus dit soort zaken lijken in eerste instantie een groot succes. Helemaal als er een financieel incentive aan hangt; hoe serieus je developers hun werk ook nemen, als je meer geld kan verdienen door slechtere code te produceren gaat dat door het kudde-effect (een schaap met meer geld, twee schapen met meer geld, alle schapen) vanzelf gebeuren.

Rockster34 schreef op woensdag 19 oktober 2016 @ 15:44:
uit eigen ervaring werkt SCRUM zeer optimaal op kleinere groepen omdat je dan better 1 on 1 groeps verband hebt waardoor je dus goede Code kan outputten

Heb je de vraag gelezen of heb je een bot die op het keyword Scrum reageert?

DJMaze schreef op woensdag 19 oktober 2016 @ 17:20:
Tja, wat is "productief"?
Ik ken een websitebouwer die er maanden over doet, en ken er één die het zelfde werk in 1 week doet.
In beide gevallen waren ze 100% productief.

spoiler:

De één is verlamd en maakt de website puur met oog bewegingen en spraak commando's

Als dat de tweede is dan mag je best wel eens een goed gesprek met die eerste hebben

[ Voor 31% gewijzigd door Hydra op 19-10-2016 19:09 ]

[frG]

Bedankt voor de reacties zover, het gaat in dit geval zeker niet om een bonus systeem, maar ik ben erg benieuwd of de output van een ontwikkelteam wel te meten is.

Zou een NPS meting over het product het dichts in de buurt komen?

[Onbekend]

Het is erg afhankelijk of iedereen in het ontwikkelteam een ander specialisme heeft, of dat iedereen ongeveer het zelfde hoort te kunnen leveren.

Financieel gezien is het afhankelijk van het businessmodel van het bedrijf hoeveel je afhankelijk bent van jouw ontwikkelteam. (Maak je bijvoorbeeld steeds klantgerichte websites waardoor de prestaties van de ontwikkelaar direct financiële invloed heeft, of lever je 1 softwarepakket af die je aan de klanten verkoopt waarbij de verkoopafdeling voornamelijk de financiële invloed heeft?)

[Nick_S]

Dat zegt volgens mij niks over je ontwikkelaars, maar meer over je PO. Dat die de juiste functionaliteit aan het ontwikkelteam vraagt.

[Gonadan]

De eerder genoemde KPI's zijn prima bruikbaar om de prestaties te meten. Men moet hier niet gaan doen alsof programmeurs zo speciaal zijn. Het is niets anders dan andere beroepen.

Wel ben ik het helemaal eens met de waarschuwing dat je het niet direct aan beloning of straf moet koppelen. Ook al zijn veel mensen met integer dan hier afgespiegeld, men zal toch naar de KPI gaan werken en niet het doel op zich.

Daarom moet je ze ook alleen maar gebruiken als indicatoren ter verbetering. Geen straf als het slecht loopt, maar samen met het team op zoek naar hoe het beter kan. Dat is ook scrum. Een dan koppel je beloning aan de inzet die men toont binnen de ontwikkeling en de zoektocht naar verbetering. Niet aan de waarde van de KPI zich.

[downtime]

Gonadan schreef op woensdag 19 oktober 2016 @ 21:32:

Daarom moet je ze ook alleen maar gebruiken als indicatoren ter verbetering. Geen straf als het slecht loopt, maar samen met het team op zoek naar hoe het beter kan.

Zelfs dat is riskant. Zodra mensen merken dat je iets meet, en dat de resultaten op individuen terug te voeren zijn, zijn ze ook overtuigd dat ze daarop beoordeeld worden. En dus veranderen ze hun gedrag.

Het lijkt wel quantum mechanica. Zodra je gaat meten beïnvloed je ook de uitkomst.

[Hahn]

frG schreef op woensdag 19 oktober 2016 @ 21:12:
Bedankt voor de reacties zover, het gaat in dit geval zeker niet om een bonus systeem, maar ik ben erg benieuwd of de output van een ontwikkelteam wel te meten is.

Zou een NPS meting over het product het dichts in de buurt komen?

Nee, allesbehalve. Je kan niet een product laten ontwikkelen door ontwikkelaars en hun afrekenen op het feit dat het product een lage NPS behaalt. Als er iemand daarop afgerekend kan worden, dan ben jij als eigenaar/bedenker van het product dat.

Maar laten we eerst eens dieper in gaan op jouw waarom: je wilt het meten, maar wat wil je daarmee bereiken?

[farlane]

Gonadan schreef op woensdag 19 oktober 2016 @ 21:32:
De eerder genoemde KPI's zijn prima bruikbaar om de prestaties te meten. Men moet hier niet gaan doen alsof programmeurs zo speciaal zijn. Het is niets anders dan andere beroepen.

Bij andere beroepen zie je ook dezelfde effecten lijkt me. Programmeurs zijn eigenlijk net mensen.

Wel ben ik het helemaal eens met de waarschuwing dat je het niet direct aan beloning of straf moet koppelen.

Ook indirect niet, want dan krijg je hetzelfde averechtse effect. De vraag is dan, wat moet je nog met zo een meting?

[DJMaze]

frG schreef op woensdag 19 oktober 2016 @ 21:12:
ik ben erg benieuwd of de output van een ontwikkelteam wel te meten is.

Tuurlijk is dat te meten, maar dat zou ik anders aanpakken.

- team A van 1 personen
- team B van 2 personen
- team C van 3 personen
- team D van 4 personen

Zet elk team in een hoek van zaal en laat alle teams de zelfde opdracht uitvoeren.
Kijk daar bij naar:
- overleg/discussie tijd
- uitvoering
- resultaat
- functioneren teamleider
- functioneren leidinggevenden die de teams leiden
- jezelf

In theorie is Team A qua tijdspanne langer bezig dan de andere teams omdat hij al het werk alleen moet doen.
Maar als Team A het in 7 uur doet zou Team B er in theorie 3,5 uur over moeten doen, maar is dat ook zo?
Verder: wie zet je in welk Team? Kunnen die personen goed samenwerken? En wat kost elk individu afzonderlijk per uur?
En hoe neem je dat mee in de uiteindelijke prijsberekening naar de klant?

Uiteindelijk weet je wel welke personen goed in een bepaald team passen.
Niet iedereen kan met iedereen overweg

[ Voor 11% gewijzigd door DJMaze op 20-10-2016 01:23 ]

[farlane]

DJMaze schreef op donderdag 20 oktober 2016 @ 01:19:
verhaal

Wat test je met de aanpak dan? Dat overlegtijd in een team met 1 persoon iha minder is dan in een team met 2 of meer personen?
Volgens mij kun je aan dit experiment geen enkele conclusies verbinden.

[GrooV]

Het enige wat je goed kan meten is lopende band werk, complexe zaken zijn lastig te meten.

[chime]

DJMaze schreef op donderdag 20 oktober 2016 @ 01:19:
[...]

Tuurlijk is dat te meten, maar dat zou ik anders aanpakken.

- team A van 1 personen
- team B van 2 personen
- team C van 3 personen
- team D van 4 personen

Zet elk team in een hoek van zaal en laat alle teams de zelfde opdracht uitvoeren.
Kijk daar bij naar:
- overleg/discussie tijd
- uitvoering
- resultaat
- functioneren teamleider
- functioneren leidinggevenden die de teams leiden
- jezelf

In theorie is Team A qua tijdspanne langer bezig dan de andere teams omdat hij al het werk alleen moet doen.
Maar als Team A het in 7 uur doet zou Team B er in theorie 3,5 uur over moeten doen, maar is dat ook zo?
Verder: wie zet je in welk Team? Kunnen die personen goed samenwerken? En wat kost elk individu afzonderlijk per uur?
En hoe neem je dat mee in de uiteindelijke prijsberekening naar de klant?

Uiteindelijk weet je wel welke personen goed in een bepaald team passen.
Niet iedereen kan met iedereen overweg

Als we jou verhaaltje doortrekken: 1 vrouw is een baby op 9 maanden, 2 vrouwen is een baby op 4,5 maanden, 3 ...

Productiviteit meten bij software is moeilijk, men is productiever als:
- de dev het framework goed kent
- de interne structuur (serverpark, manier van werken) goed gekend is
- de klant weet wat hij wilt
- de analyse goed is uitgevoerd
- de werkomgeving het toelaat om snel en makkelijk te testen
- de dev blij gezind is
- de dev niet wordt afgeleid door (mensen met rare vragen, iemand die belachlijk luid op zijn telefoon bezig is, ... )
- de dev vindt het een interessante business case
- ...

Kortom, er zijn al relatief veel externe factoren en zaken die moeilijk meetbaar zijn.

Bij repetitieve, gekende taken is productiviteit meten relatief makkelijk - zogauw er echt nagedacht moet worden is het vrij lastig.


Ah ja - vaak gaat het meten van productiviteit ten koste van dezelfde productiviteit, zeker bij iets dat lastig te meten is.


Wil je financiele consequenties gaan toevoegen => werk dan eerder met realistische milestones of doelstellingen die je voorop stelt - waarbij je het team ook de mogelijkheid en ondersteuning geeft om zichzelf productiever te maken.

Let er ook mee op: ergens een beloning aan vasthaken dat eigenlijk niet haalbaar is doordat men onredelijk moet presteren gaat ook het omgekeerde teweeg brengen.
"Dat kunnen we toch niet halen => dan steken we er ook geen moeite in".

[CodeCaster]

Het lijkt erop dat je het boek The Mythical Man-Month eens moet lezen.

Niet dat dat boek specifiek gaat over hoe je performance van een team kunt meten, maar wel de misvattingen daaromtrent die er bestaan.

[ Voor 40% gewijzigd door CodeCaster op 20-10-2016 12:31 ]

[frG]

Hahn schreef op donderdag 20 oktober 2016 @ 00:01:
[...]

Nee, allesbehalve. Je kan niet een product laten ontwikkelen door ontwikkelaars en hun afrekenen op het feit dat het product een lage NPS behaalt. Als er iemand daarop afgerekend kan worden, dan ben jij als eigenaar/bedenker van het product dat.

Maar laten we eerst eens dieper in gaan op jouw waarom: je wilt het meten, maar wat wil je daarmee bereiken?

Het gaat mij persoonlijk ook niet om het meetbaar te maken, maar om de vraag of het überhaupt (goed) mogelijk is. Ik zelf zou dit dan ook nooit inzetten, maar volgens mij is het wel heel goed mogelijk om een SCRUM team te meten aan de hand van een NPS.

[farlane]

Klanttevredenheid zou nog de beste maatsstaf zijn. Maar dan nog, wat ga je er mee doen? Op het moment dat je het in enige vorm gaat gebruiken om te 'vergelijken' ben je weg.

[Hahn]

frG schreef op donderdag 20 oktober 2016 @ 13:07:
[...]


Het gaat mij persoonlijk ook niet om het meetbaar te maken, maar om de vraag of het überhaupt (goed) mogelijk is.

Of het mogelijk is, hangt helemaal af van wat je ermee wilt bereiken. Dus op deze manier komen we niet echt verder

Ik zelf zou dit dan ook nooit inzetten, maar volgens mij is het wel heel goed mogelijk om een SCRUM team te meten aan de hand van een NPS.

Leg uit, want zoals ik al zei: ik zie het niet voor me hoe NPS zou kunnen vertellen hoe goed je developers werken.

[pedorus]

frG schreef op woensdag 19 oktober 2016 @ 15:42:
Ik vraag mij sinds kort af, hoe zouden jullie eigenlijk bepalen hoe goed jouw ontwikkel team het eigenlijk doet en daar een financiële consequentie aan verbonden kan zijn?

Het gaat goed als er duidelijk meer winst binnenkomt en/of meer plezier is (bijvoorbeeld door het opleveren van mooie features), en dat verdeelt zich dan over het personeel. Dit is iets dat al automatisch gebeurd, en iets anders zou ik niet aan beginnen

Gezien het noemen van "een financiële consequentie" raad ik de volgende video aan:

frG schreef op woensdag 19 oktober 2016 @ 21:12:
Bedankt voor de reacties zover, het gaat in dit geval zeker niet om een bonus systeem, maar ik ben erg benieuwd of de output van een ontwikkelteam wel te meten is.

Stel dat je een goede inschatting van grootte hebt (zoals functiepunten of andere inschattingen), dan zou je de output kunnen meten natuurlijk. Enkel het gaat vast mis als er financiële consequenties aan hangen. Dus zoiets werkt vooral om verschillende werkwijzen of tools te vergelijken, en alleen als je genoeg data hebt om mee te vergelijken.

Zou een NPS meting over het product het dichts in de buurt komen?

Waarom zou dat überhaupt in de buurt komen?

[GrooV]

Ik ben ook wel benieuwd hoe je een scrum team kan meten met NPS.

Bij dit soort vragen krijg ik toch altijd kriebels, wat wil de TS nu eigenlijk weten? Of zijn team geld op brengt? Of de eind klant tevreden is? Of er geen bugs zijn? Of het team hard werkt? Of dat er minder developers nodig zijn? Of dat er juist geld bespaart moet worden?

[Lethalis]

Het is veel beter om developers op hun kwaliteiten en inzet te waarderen dan concrete resultaten.

Zoals al eerder gezegd in dit topic, is al het overige (aantal regels code aantal bugs opgelost, test coverage etc) te manipuleren en gebeurt dat ook in de praktijk.

PS:
Ik kan met 1 stored procedure soms dingen doen waar anderen hele dagen een programma voor gaan schrijven. Ga je mij er dan op afrekenen dat ik te weinig regels code schrijf?

Been there, done that, left the building for a better job

[ Voor 31% gewijzigd door Lethalis op 21-10-2016 10:40 ]

[DJMaze]

Lethalis schreef op vrijdag 21 oktober 2016 @ 10:37:
PS:
Ik kan met 1 stored procedure soms dingen doen waar anderen hele dagen een programma voor gaan schrijven. Ga je mij er dan op afrekenen dat ik te weinig regels code schrijf?

Been there, done that, left the building for a better job

Herkenbaar!
Iemand had 3000 regels code om een agenda te vullen met reserveringsgegevens.
En die gegevens werden elke minuut ververst.
Het "verversen" van dat agenda koste 10 seconde.
Ik ben een week bezig geweest om een database query te schrijven en de 3000 regels code verwijderen en een netwerk event handling.
Resultaat: agenda "verversen" in 100ms en alleen als er een "update" event plaats vind.

Nou leg dan maar eens uit aan de klant en de baas waarom het zoveel tijd/geld heeft gekost en of het het waard was.
Op dat moment vonden ze dat ik slecht werk leverde en dat ik de tijd nuttig had moeten besteden.
Paar jaar verder blijkt dat wel de #1 unique selling point en zijn er veel functionaliteiten omgezet naar het netwerk event handling systeem

[ Voor 11% gewijzigd door DJMaze op 21-10-2016 12:42 ]

[Morrar]

Helemaal eens met de stelling dat je meer krijgt van wat je meet, ten koste van andere zaken. In de zorg bijvoorbeeld zie je ook dat lijstjes handelingen afgewerkt worden, ongeacht of de client daar beter of gelukkiger van wordt. Alles om het management maar het idee te geven dat er hard gewerkt wordt.

Bij programmeren is het meten van het concept productiviteit nog lastiger, aangezien het een redelijk complexe job is. Iemand kan heel snel werkende code opleveren, maar jaren later kan pas blijken dat de code amper gedocumenteerd is en daardoor lastig te onderhouden. Zie ook het voorbeeld hierboven.

Daarnaast vind ik dat je met het metingen en controles het vertrouwen in je werknemers behoorlijk opzegt; dat gaat ten koste van hun intrinsieke motivatie. Het is maar helemaal de vraag of je dat verlies gaat compenseren met je metingen en controles. Kans is groot dat men dan precies gaat doen wat je meet en geen stap meer.

Moet je werknemers dan geloven op hun blauwe ogen? Volgens mij hoeft dat niet, want onder werknemers zelf is vaak prima duidelijk wie hard werkt en wie de kantjes er vanaf loopt. Je moet alleen als manager wel genoeg binding hebben met de werkvloer en het product dat je maakt om die informatie op vangen.

Ik vind het invoeren van allerlei metingen, controles, doelstellingen en KPI's daarom vooral een teken van falend management. Zorg als manager dat je meer aanwezig bent op de werkvloer en steek wat minder tijd in interressant doen met andere managers, strategiemeetings, heidagen, synergiesessies of met punten op de horizon zetten

[frG]

pedorus schreef op donderdag 20 oktober 2016 @ 22:59:
[...]

Gezien het noemen van "een financiële consequentie" raad ik de volgende video aan:
[video]

Erg inspirerende video, ben ik het helemaal mee eens

Het product is de output van het SCRUM team, daar valt op zich wel wat aan te meten (klanttevredenheid/nps), wat hier echter wel mis kan gaan is dat de verkeerde dingen goed gebouwd worden, de klant zit hier bijvoorbeeld niet op te wachten (dan zit de fout dus waarschijnlijk bij de product owner/feedback gathering).

Ik denk dat de eindconclusie is dat je je output/performance helemaal niet zou moeten meten, en als je dat dan toch zo graag wilt er rekening mee houden dat er richting de KPI gestuurd gaat worden.

[ThomasG]

Waar wat mij betreft vooral naar gekeken moet worden is de tijd/kwaliteit verhouding. Wat is de kwaliteit van de code, en hoeveel tijd heeft dat in beslag genomen. Idealiter wil je zoveel mogelijk kwaliteit in zo min mogelijk tijd. Maar iemand die hoge kwaliteit levert, maar daar lang over doet, is daarbij minder productief dan kwaliteit wat goed genoeg is en aan alle eisen voldoet, maar sneller klaar is. Het probleem is alleen dat dit lastig te meten is.

Ik denk dat ervaringen en vooral inzichten wellicht belangrijker zijn dat productiviteit op zichzelf, omdat je daarmee mogelijke problemen die zouden kunnen ontstaan vroegtijdig kunt vermeiden en daardoor effectief productiever kunt zijn.

[Hahn]

frG schreef op vrijdag 21 oktober 2016 @ 20:32:
[...]

Het product is de output van het SCRUM team, daar valt op zich wel wat aan te meten (klanttevredenheid/nps), wat hier echter wel mis kan gaan is dat de verkeerde dingen goed gebouwd worden, de klant zit hier bijvoorbeeld niet op te wachten (dan zit de fout dus waarschijnlijk bij de product owner/feedback gathering).

'Kan mis gaan'? Als je NPS meet dan meet je voor een heel groot deel het idee en voor een klein deel de uitvoering, terwijl jij alleen de uitvoering wilt meten. Dus ik blijf erbij dat ik niet snap waarom je dit een goed idee vindt.

Ik denk dat de eindconclusie is dat je je output/performance helemaal niet zou moeten meten, en als je dat dan toch zo graag wilt er rekening mee houden dat er richting de KPI gestuurd gaat worden.

Ik vind dit nogal een makkelijke conclusie. Waarom ga je niet in op de vraag wat je nou eigenlijk precies wilt bereiken?

[farlane]

ThomasG schreef op vrijdag 21 oktober 2016 @ 20:55:
Waar wat mij betreft vooral naar gekeken moet worden is de tijd/kwaliteit verhouding. Wat is de kwaliteit van de code, en hoeveel tijd heeft dat in beslag genomen. Idealiter wil je zoveel mogelijk kwaliteit in zo min mogelijk tijd. Maar iemand die hoge kwaliteit levert, maar daar lang over doet, is daarbij minder productief dan kwaliteit wat goed genoeg is en aan alle eisen voldoet, maar sneller klaar is. Het probleem is alleen dat dit lastig te meten is.

Daar kun je ook niet van uitgaan : super kwaliteit code die te laat komt voor een klant is waardeloos.

[Lethalis]

farlane schreef op vrijdag 21 oktober 2016 @ 23:23:
[...]
Daar kun je ook niet van uitgaan : super kwaliteit code die te laat komt voor een klant is waardeloos.

Dat klopt. Ook moet je je afvragen wat "kwaliteit" nou precies is en bij wie de verantwoordelijkheid voor bepaalde aspecten daarvan ligt.

Als het belangrijkste aspect de klant tevreden houden is, dan kan de meest gare VB6 code van super kwaliteit zijn, als hij maar goed werkt en op tijd opgeleverd is.

Het hangt heel erg van de setting af waar je kwaliteit aan afmeet (Hoe groot is het team? Wat is het kennisniveau? Hoe lang is de levenscyclus van het project? Hoe groot is de scope ervan? Etc)

[ThomasG]

Lethalis schreef op zaterdag 22 oktober 2016 @ 10:39:
[...]

Als het belangrijkste aspect de klant tevreden houden is, dan kan de meest gare VB6 code van super kwaliteit zijn, als hij maar goed werkt en op tijd opgeleverd is.

En toch levert dat op ten duur problemen op. Op het eerste gezicht is de klant tevreden, omdat hij snel zijn product geleverd krijgt. Vervolgens wilt de klant een nieuwe feature, en omdat de code slecht in elkaar zit duurt het relatief lang om dat te implementeren. Probeer dat maar eens aan je klant uit te leggen.

[Onbekend]

ThomasG schreef op zaterdag 22 oktober 2016 @ 10:58:
[...]
En toch levert dat op ten duur problemen op. Op het eerste gezicht is de klant tevreden, omdat hij snel zijn product geleverd krijgt. Vervolgens wilt de klant een nieuwe feature, en omdat de code slecht in elkaar zit duurt het relatief lang om dat te implementeren. Probeer dat maar eens aan je klant uit te leggen.

Maar anders was de klant eerder al niet blij omdat de code te laat klaar was.
En zoals altijd, de klant vraagt daarna altijd een nieuwe feature aan wat niet lekker in de huidige code past.

[ThomasG]

Onbekend schreef op zaterdag 22 oktober 2016 @ 11:06:
[...]

Maar anders was de klant eerder al niet blij omdat de code te laat klaar was.
En zoals altijd, de klant vraagt daarna altijd een nieuwe feature aan wat niet lekker in de huidige code past.

Als dat gebeurt, dan is het gewoon tijdens de ontwerpfase al fout gegaan. En dat is nu juist de reden waarom zoveel ICT projecten (ver) over het budget gaan en/of falen. De klant heeft vaak geen verstand van techniek, en weet op het moment dat hij naar een softwarebouwer gaat vaak niet eens wat er allemaal mogelijk is. De klant vraagt daarom niet bij de eerste versie om een bepaalde feature, omdat hij er niet bij stil staat dat het überhaupt mogelijk is. Juist daarom zijn er mensen nodig die de techniek op een goede en juiste manier kunnen vertalen naar de klant, en visa versa. Zodat je een goed beeld krijgt wat de klant nu precies wilt hebben, en niet afgaat op aannames. Natuurlijk kun je niet alles in de eerste versie bouwen, want dan duurt het een aantal jaar voordat de klant zijn product krijgt. Je kunt er wel rekening mee houden dat de software in de toekomst (mogelijk) uitgebreid gaat worden. Dat kost vrijwel geen extra tijd, maar scheelt een hoop tijd en problemen in de toekomst.

[ Voor 3% gewijzigd door ThomasG op 22-10-2016 11:17 ]

[DJMaze]

ThomasG schreef op zaterdag 22 oktober 2016 @ 11:16:
Als dat gebeurt, dan is het gewoon tijdens de ontwerpfase al fout gegaan. En dat is nu juist de reden waarom zoveel ICT projecten (ver) over het budget gaan en/of falen.

Dat hoeft helemaal niet. Ik kan een enorm uitgebreide ontwerpfase hanteren met miljoenen opties om rekening te houden met de toekomstige wensen van de klant.
Als ik dan in de inschatting zeg dat een project 2000 uur kost en de klant krijgt van een ander bedrijf een offerte van 1000 uur, nou ga dat maar eens uitleggen.

Je moet gewoon niet altijd alles "perfect" willen doen in het begin, zeg gewoon eerlijk dat het project in 1000 uur kan doen met een duidelijke waarschuwing dat dit kan oplopen tot 2000 uur als de klant met nieuwe wensen/features aan komt.
En dit gebeurt heel vaak, want ze denken allemaal "oh dat kan je er nog wel even bij doen".

[orf]

Hahn vraagt het al een paar keer: Wat zijn prestaties precies?

• Gebruiksvriendelijkere software?
• Minder bugs?
• Meer klanttevredenheid?
• Meer medewerkerstevredenheid?
• Snellere doorlooptijden voor nieuwe features?
• Toekomstbestendigheid?
• Codekwaliteit?
• Minder overhead nodig?
• Betere marges / meer geld verdienen?

Je moet eerst goed bepalen waarop je wil sturen voordat je kunt gaan proberen te sturen. Je kunt dan de prestaties wellicht gaan meten en een stok of wortel gebruiken om de resultaten omhoog te krijgen. Je kunt ook vragen wat mensen nodig hebben om beter te kunnen presteren. Je kunt ze op cursus sturen, of je kunt een deel van de mediors vervangen met seniors.

Ik heb een eigen bedrijf waarin ik veel dingen zie gebeuren. Sommige developers zetten dingen té abstract op omdat ze heel kwaliteitsgericht en perfectionistisch zijn. Dat pakt vaak niet goed uit omdat je te veel tijd kwijt bent aan dingen herbruikbaar opzetten maar nooit te hergebruiken. Ik zie ook dat er soms te ver ingezoomd wordt waardoor mensen het grote idee kwijt raken. Klanten willen nog wel eens van koers veranderen of ineens een ander toepassingsgebied zien.

In teamverband werken is lastig. Je wil goede communicatie, maar niet te veel overleg. Soms werkt een combinatie van mensen (typen) niet omdat ze elkaar kunnen versterken in negatieve zin. Bij scrum heb je een goede scrummaster nodig en een product owner die voldoende kennis heeft en mandaat heeft.

Ikzelf ben erg voorstander van korte iteraties. Snel werken naar een eerste versie en je idee toetsen bij echt gebruik. Op basis daarvan verder ontwikkelen. Klein beginnen, maar groot proberen te denken. Niet te veel aan optimalisaties doen tijdens de bouw, maar wel steeds creatief proberen te blijven denken.

[Lethalis]

ThomasG schreef op zaterdag 22 oktober 2016 @ 10:58:
[...]
En toch levert dat op ten duur problemen op. Op het eerste gezicht is de klant tevreden, omdat hij snel zijn product geleverd krijgt. Vervolgens wilt de klant een nieuwe feature, en omdat de code slecht in elkaar zit duurt het relatief lang om dat te implementeren. Probeer dat maar eens aan je klant uit te leggen.

Dat weet je niet. Vaak valt het erg tegen hoeveel tijdswinst je behaalt door code wel helemaal OO te maken bijv.

Het belangrijkste is het afsplitsen van code die mogelijk aan verandering onderhevig is. Als iemand dat goed kan inschatten - door veel ervaring te hebben met de materie en de klanten - dan is er geen probleem.

En dat kan heel simpel met een wrapper functie die afhankelijk van de situatie een andere aanroept.

Dan kan je met modernste technieken een interface definiëren, deze implementeren, er tests voor schrijven en een factory maken, maar dan is bijna bejaarde Henkie met zijn VB6 dus sneller dan jij als hij een beetje slim is.

Zelf werk ik 10 keer liever met C# dan met VB6 hoor, maar dat is echt liefhebberij van ons programmeurs

Wel ben ik een beetje OO sceptisch geworden en zie ik steeds meer in functioneel programmeren.

[ Voor 4% gewijzigd door Lethalis op 22-10-2016 12:53 ]

[Crazy D]

ThomasG schreef op zaterdag 22 oktober 2016 @ 11:16:
Als dat gebeurt, dan is het gewoon tijdens de ontwerpfase al fout gegaan. En dat is nu juist de reden waarom zoveel ICT projecten (ver) over het budget gaan en/of falen.

En andersom zie je het gebeuren dat zaken zo flexibel wordt opgezet om in de toekomst met alle mogelijke uitbreidingen rekening te houden... en blijkt dat de zaken er na een jaar niet zo goed meer voorstaan en besluit de klant niets meer te investeren en het doen met wat ze hebben. Zit je dan, met je superflexibel perfect opgezette applicatie waarvan de code nooit meer bekeken wordt. Waaraan je initieel meer werk hebt besteed "zodat uitbreidingen makkelijker en sneller mogelijk zijn".

Mijn ervaring is dat een klant liever nu snel en goedkoop iets opgeleverd krijgt. Wil hij volgend jaar toch iets erbij? Dan snapt ie meestal heus wel dat dat geld kost. En een klant weet niet of iets een kleine of grote aanpassing is. Als hij dat wel kan, mag ie het lekker zelf doen, succes ermee.

[ThomasG]

Crazy D schreef op zaterdag 22 oktober 2016 @ 15:03:
[...]

En andersom zie je het gebeuren dat zaken zo flexibel wordt opgezet om in de toekomst met alle mogelijke uitbreidingen rekening te houden... en blijkt dat de zaken er na een jaar niet zo goed meer voorstaan en besluit de klant niets meer te investeren en het doen met wat ze hebben. Zit je dan, met je superflexibel perfect opgezette applicatie waarvan de code nooit meer bekeken wordt. Waaraan je initieel meer werk hebt besteed "zodat uitbreidingen makkelijker en sneller mogelijk zijn".

Mijn ervaring is dat een klant liever nu snel en goedkoop iets opgeleverd krijgt. Wil hij volgend jaar toch iets erbij? Dan snapt ie meestal heus wel dat dat geld kost. En een klant weet niet of iets een kleine of grote aanpassing is. Als hij dat wel kan, mag ie het lekker zelf doen, succes ermee.

Het gaat erom om goed in kaart te brengen wat de klant precies wilt hebben. Klanten beschrijven wat ze willen hebben, maar dat is vaak slechts een deel van het uiteindelijke product. Het is niet zo omdat de klant vraagt om A, dat je enkel A bouwt. Je moet samen toch een goed product komen. Het is dan ook de taak van de consultants om aan te bel te trekken. De klant weet vaak niet precies wat hij wilt hebben, daarom komen ze naar een bepaald bedrijf om het voor ze te doen. Dat zie je gewoon te vaak gebeuren, dat projecten tijdens het opstellen van de requirements eigenlijk al gedoemd zijn te mislukken. Wanneer je het goed aanpakt, krijg je (bijna) geen situaties dat het niet in de architectuur past. En dat heeft niets te maken met super flexibiel zijn, want dat is gewoon flauwekul.

[ Voor 3% gewijzigd door ThomasG op 22-10-2016 15:36 ]

[Lethalis]

orf schreef op zaterdag 22 oktober 2016 @ 12:43:
Ik heb een eigen bedrijf waarin ik veel dingen zie gebeuren. Sommige developers zetten dingen té abstract op omdat ze heel kwaliteitsgericht en perfectionistisch zijn. Dat pakt vaak niet goed uit omdat je te veel tijd kwijt bent aan dingen herbruikbaar opzetten maar nooit te hergebruiken.

Sowieso is herbruikbaarheid een hekel onderwerp.

Want 9 van de 10 keer wil je een paar jaar later heel andere technieken gebruiken.

Daarnaast leidt een groot abstractieniveau vrijwel altijd tot moeilijk leesbare code. Mooi dat het flexibel is, maar als niemand het meer snapt, schiet het zijn doel ook voorbij.

Ik heb ook zo'n periode gehad en als ik die code nu zie, dan zie ik vooral erg veel kleine classes die allemaal *iets* doen en zoek ik mij de rambam om de samenhang goed te begrijpen.

Tegenwoordig zijn mijn classes algemener en bevatten ze vooral veel functies die met elkaar samenwerken. Het is nog net niet dat het verkapte namespaces worden

Maar veel dingen staan nu dus gewoon bij elkaar. Heel fout misschien, maar daardoor veel leesbaarder en makkelijker te onderhouden.

Ik heb OO analysis and design op wo niveau bestudeerd, maar negeer nu bewust bepaalde aspecten ervan om code goed leesbaar te houden

[ThomasG]

DJMaze schreef op zaterdag 22 oktober 2016 @ 12:28:
[...]

Dat hoeft helemaal niet. Ik kan een enorm uitgebreide ontwerpfase hanteren met miljoenen opties om rekening te houden met de toekomstige wensen van de klant.
Als ik dan in de inschatting zeg dat een project 2000 uur kost en de klant krijgt van een ander bedrijf een offerte van 1000 uur, nou ga dat maar eens uitleggen.

Je moet gewoon niet altijd alles "perfect" willen doen in het begin, zeg gewoon eerlijk dat het project in 1000 uur kan doen met een duidelijke waarschuwing dat dit kan oplopen tot 2000 uur als de klant met nieuwe wensen/features aan komt.
En dit gebeurt heel vaak, want ze denken allemaal "oh dat kan je er nog wel even bij doen".

En dat is dus precies wat er gebeurd wanneer het tijdens het ontwerpen al fout gaat. De klant krijgt een half systeem, omdat hij daar om gevraagd heeft, maar zich dat niet realiseert. En dan krijg je situaties van: oh dit en dat moet er nog bij. Dat heeft niets met perfect te maken. Het heeft te maken met het goed informeren van de klant, en samen tot een product te komen. Omdat de klant vaak niet wilt wat hij nu eigenlijk nodig heeft.

[Crazy D]

ThomasG schreef op zaterdag 22 oktober 2016 @ 15:34:

Het gaat erom om goed in kaart te brengen wat de klant precies wilt hebben. Klanten beschrijven wat ze willen hebben, maar dat is vaak slechts een deel van het uiteindelijke product.

Dat sowieso maar dat staat los van hoe je dat in code oplost...

[ThomasG]

Crazy D schreef op zaterdag 22 oktober 2016 @ 16:15:
[...]

Dat sowieso maar dat staat los van hoe je dat in code oplost...

Je weet daardoor wel waar je heen gaat.. Bepaalde features hebben prioriteit, omdat het anders geen werkbaar systeem is. Maar je weet tegelijkertijd dat bepaalde features in een later stadium ingebouwd gaan worden, en daar kun je dus al rekening mee houden. Wanneer je niet precies weet wat de klant nu eigenlijk nodig heeft, omdat er enkel gebouwd wordt waar hij initieel om vraagt, levert dat gewoon problemen op. Dus indirect heeft dat er een relatie tot.

[ Voor 0% gewijzigd door ThomasG op 22-10-2016 16:22 . Reden: Typo ]

[defiant]

Aangezien software maken een creatief proces is, zal het met metrieken inzichtelijk maken van kwaliteit en snelheid nooit een compleet beeld schetsen. Zoals genoemd, de black box methodiek van Scrum/Agile komt nog het dichtst bij een methodiek om prestaties (nog geen kwaliteit) te meten.

Ik kan de de uitdaging op management niveau begrijpen, als je medewerkers transparant wilt belonen (wat een nobel streven is), dan wil graag meetbare resultaten anders is er ruimte voor subjectieve discussie. Ik denk echter niet dat je ontkomt aan subjectieve menselijke beoordeling van het proces en de medewerkers.

Om voorbeelden te geven van scenario's waardoor de Scrum/Agile niet goed werkt als input voor beloning. Stel je beste programmeur zit in een scrum team dat een legacy product moet onderhouden met een lastige klant, waardoor de scrum velocity laag is, maar hij toch z'n uiterste best doet. Is het dan logisch het team en daarmee je beste programmeur af te rekenen op de velocity?

Ander voorbeeld, stel je hebt een club junioren die toevallig op een niet zo ingewikkeld project mogen doen, wat dus qua velocity goed loopt en opeens commercieel (buiten de invloed van het team) een succes wordt. Is het logisch dit team te belonen? Ieder andere werknemer in het bedrijf had hetzelfde werk en daarmee dezelfde successen kunnen boeken.

Afrekenen op team niveau heeft dus ook z'n beperkingen. Zeker ook omdat teamleden altijd verschillen, zie ook het meest extreme voorbeeld wat Microsoft ooit had: Microsoft Abandons 'Stack Ranking' of Employees. Aangezien je bij MS dus werd geranked door je manager ten opzichte van andere medewerkers, was het dus van belang om ervoor te zorgen dat je in een team terecht kwam waar je beter was dan anderen. Niemand wil in een team werken waar je moet samenwerken met topmensen, want dat betekend automatisch dat jezelf slechter werd beoordeeld, terwijl het juist op ervaring en invloed positief is om samen te werken met de beste mensen.

Beloning en prestatie van teams en medewerkers blijft dus een lastig probleem, ook tot frustratie van menig werknemer. Je ziet tegenwoordig wel de trend terug om veel meer kijken naar het interne proces van organisaties, aangezien daar de grootste winst is te boeken als bedrijf. Een team kan bijvoorbeeld veel sneller als het CICD proces gestroomlijnd is, maar dat is iets wat de organisatie en niet het team moet faciliteren.