Hoewel praktische vaardigheden en kennis van specifieke programmeertalen, tools en technologieën de sleutel zijn tot het vinden van een fulltime baan als softwareontwikkelaar, is er nog een andere waardevolle indicator die in veel opzichten kan worden gezien als een voorwaarde voor succes in dit beroep: productiviteit. Productiviteitsmeting is iets dat alle professionele softwareontwikkelaars moeten begrijpen en waarmee ze rekening moeten houden, aangezien prestatiestatistieken van nature belangrijk zijn voor elk softwareontwikkelingsteam in de huidige zakelijke omgeving.
Waarom is uw productiviteit als ontwikkelaar belangrijk?
In het tijdperk van Agile-ontwikkeling, DevOps en krimpende softwarereleasecycli, waarin ontwikkelaars zo snel mogelijk nieuwe versies van producten moeten leveren, gebruiken bedrijven meerdere verschillende productiviteitsstatistieken om de prestaties van individuele programmeurs en een team als geheel te evalueren. Als we dit vanuit het oogpunt van een ontwikkelaar bekijken, kan prestatiemeting een aantal waardevolle doelen dienen, omdat het u helpt de voortgang van uw programmeervaardigheden bij te houden, waardoor u een consistente professionele groei kunt realiseren. Zeer productieve programmeurs zijn degenen die uiteindelijk verbluffende salarisaanbiedingen ontvangen en aan de meest opwindende projecten gaan werken. Maar zelfs als je niet bepaald een grote presteerder bent en gewoon een baan in softwareontwikkeling wilt en er redelijk succesvol in wilt zijn, u moet nog steeds op zijn minst een basiskennis hebben van prestatie-indicatoren en hoe ze worden gebruikt om de productiviteit van uw input op het werk te meten. Dat is waar we het vandaag over gaan hebben.
Productiviteitsmeetstatistieken voor softwareontwikkeling
Wat zijn productiviteitsstatistieken voor softwareontwikkeling?
Metrieken voor softwareontwikkeling zijn de gebieden van programmeerwerk waar kwantitatieve metingen kunnen worden toegepast om de prestaties, kwaliteit van het werk en productiviteit van een ontwikkelaar bij te houden. Elke productiviteitsstatistiek is gebaseerd op gegevens uit het ontwikkelingsproces en deze gebruiken om de productiviteit te meten. Aangezien vrijwel niets met betrekking tot softwareontwikkeling eenvoudig en ongecompliceerd is, zou je kunnen zeggen dat het meten van programmeerproductiviteit ook nogal inconsistent en gefragmenteerd is in de branche. Of, simpel gezegd, verschillende teams en bedrijven kunnen totaal verschillende prestatie-indicatoren gebruiken en dit vraagstuk vanuit meerdere invalshoeken benaderen. U hoeft zich dus niet bezig te houden met het leren van elke statistiek die door softwareontwikkelingsteams kan worden gebruikt.
Welke soorten productiviteitsstatistieken voor softwareontwikkeling zijn er?
Natuurlijk zijn er meerdere verschillende productiviteitsstatistieken die het meten van prestaties op verschillende niveaus en invalshoeken benaderen. Dit zijn de meest voorkomende typen van dergelijke productiviteitsstatistieken:
Formele maatgerichte statistieken.
Deze statistieken zijn gericht op het meten van de omvang van het werkresultaat van een programmeur, zoals coderegels (LOC), lengte van code-instructies, codecomplexiteit, enz. Deze statistieken worden in de huidige softwareontwikkelingsindustrie steeds meer als achterhaald beschouwd.
Tijd- en functiegerichte productiviteitsstatistieken.
Er is een selectie van traditionele productiviteitsstatistieken die worden gebruikt bij de ontwikkeling van watervalsoftware, zoals actieve dagen, de reikwijdte van de functionaliteit die binnen een bepaalde periode wordt verzonden, codeverlooppercentages, aantal toegewezen taken, enz.
Agile ontwikkelprocesstatistieken.
Agile-ontwikkelingsprocesstatistieken, zoals het sprint-burndown-rapport, snelheid, doorlooptijd, cyclustijd en andere, zijn tegenwoordig waarschijnlijk de meest gebruikte statistieken onder softwareontwikkelingsteams. We zullen later in het artikel meer in detail over Agile-statistieken praten.
Operationele analytische statistieken.
Deze set statistieken is gericht op het meten van softwareprestaties in de huidige productieomgeving. Mean time between failures (MTBF), mean time to recovery (MTTR) en het crashpercentage van applicaties zijn hier de meest gebruikte statistieken.
Statistieken testen.
Softwaretesten hebben hun eigen set statistieken om de kwaliteit van systeemtesten te meten, zoals het percentage geautomatiseerde tests, codedekking, enz.
Klanttevredenheidsstatistieken.
Ten slotte is de ultieme maatstaf voor elk stuk software de ervaring van de eindklant, en daar is ook een hele reeks maatstaven voor, zoals klantinspanningsscore (CES), klanttevredenheidsscore (CSAT), net promoter score (NPS). en anderen.
Agile softwareontwikkelingsstatistieken
Zoals u kunt zien, is het vrij eenvoudig om te verdwalen in alle fijne kneepjes van softwareproductiviteitsstatistieken. De enige waar een reguliere softwareontwikkelaar goed bekend mee zou moeten zijn, zijn echter de Agile-statistieken, die tegenwoordig vaak door softwareontwikkelingsteams worden gebruikt als standaarden voor het meten van teamproductiviteit in verschillende delen van de levenscyclus van softwareontwikkeling. Laten we de belangrijkste en meest gebruikte Agile-statistieken opsommen.
1. Sprint-burndown.
Sprint Burndown-rapporten zijn een van de belangrijkste statistieken voor agile scrum-ontwikkelingsteams. Zoals in agile het ontwikkelingsproces wordt georganiseerd door tijdgebonden sprints, wordt Sprint Burndown gebruikt als een manier om de voltooiing van taken tijdens een sprint bij te houden. Uren of verhaalpunten worden gebruikt als meeteenheid. Het doel is om consistente vooruitgang te boeken en werk af te leveren in overeenstemming met de aanvankelijke prognoses. Sprint Burndown helpt teams om het werktempo te meten en bij te sturen wanneer dat nodig is.
2. Teamsnelheid.
Snelheid is een andere belangrijke indicator, die ook is gebaseerd op uren of verhaalpunten als meeteenheid. Het meet de gemiddelde hoeveelheid werk die een team voltooit tijdens een sprint en wordt gedurende het hele project gebruikt voor schattingen en planningen. De volgsnelheid is belangrijk om ervoor te zorgen dat het team consistente prestaties levert.
3. Verhaalpunten.
Op het niveau van een individueel ontwikkelingsteamlid zijn verhaalpunten een waardevolle maatstaf, aangezien de grootte van de verhalen die een programmeur tijdens elke release levert een indicator is van de productiviteit van deze codeur.
4. Cycluscontrolekaart.
Meet de totale tijd vanaf het moment dat het werk aan een taak of een ander achterstandsitem is begonnen tot aan de voltooiing ervan. Maakt het mogelijk om cyclustijden bij te houden en te controleren voor meer voorspelbare resultaten.
5. Doorvoer en geleverde waarde.
Projectmanagers analyseren taken die zijn toegewezen aan ontwikkelaars en kennen er waarde aan toe. Deze statistiek wordt vervolgens gebruikt om de doorvoer van het team te meten, of met andere woorden, de hoeveelheid werk met toegevoegde waarde.
6. Codeverloop.
Codeverloop is een andere statistiek die het vermelden waard is, omdat deze wordt gebruikt om zowel de productiviteit van een team als geheel te meten als om de prestaties van individuele programmeurs bij te houden. Codeverloop meet hoe vaak een ontwikkelaar eerder toegevoegde coderegels verwijdert of wijzigt, en welk percentage van eerder geschreven code uiteindelijk wordt gewijzigd of weggegooid.
Meningen van deskundigen
Tot slot, om enig perspectief toe te voegen, een paar citaten over de kwestie door ervaren professionals uit de softwareontwikkelingsindustrie. “Ik hoop echt dat je je statistieken niet wilt 'vergelijken' met een soort standaard of zelfs met de prestaties van een ander team in een ander bedrijf. Overal waar ik heb gewerkt, waren er unieke variaties in hun definities van verhaalpunten, snelheid, schattingen per uur, taken, enz. die het echt bijna onmogelijk zouden maken om de prestaties van het ene team van het ene bedrijf rechtstreeks te vergelijken met die van een ander team bij een ander bedrijf”, merkte Cliff Gilley, voormalig technisch productmanager en Agile Coach, op. “Ik ben een beetje huiverig voor statistieken als het gaat om het sturen van teamprestaties. Als je eenmaal op slechts één of twee variabelen hebt gelet, wordt het heel gemakkelijk om (opzettelijk of anderszins) te vervallen in het spelen van de metriek en jezelf voor de gek te houden dat je aan het verbeteren bent - terwijl je alleen maar de metriek verbetert. Statistieken op basis van snelheid kunnen bijvoorbeeld "verbeteren" doordat het team naar kleinere verhalen gaat (minder werk per verhaal - dus meer voltooide verhalen - dus de snelheid gaat omhoog). Dat zou een goede zaak kunnen zijn als de verhalen nuttige gebruikersverhalen zijn die kleinere hoeveelheden bedrijfswaarde opleveren. Dat zou een slechte zaak kunnen zijn als de verhalen kleiner worden en meer "technische" taken worden die op zichzelf geen echte waarde opleveren, " zei Adrian Howard, een andere professional uit de industrie.. “Als ik in een op pull gebaseerd systeem werk, waardeer ik doorvoer en cyclustijd. De eerste geeft me algemene informatie over de capaciteit van ons team en kan na verloop van tijd een zeer krachtige voorspellende maatstaf worden. De tweede is nuttig als algemene maatstaf voor de efficiëntie van onze pijpleidingen. Als de cyclustijd hoog is, is het tijd om naar de pijplijn te kijken, omdat er een beperking is die we waarschijnlijk kunnen toewerken naar versoepeling/exploitatie. Maar statistieken zijn slechts hulpmiddelen. Verdwaal er niet in en begin zeker niet met het plannen van een specifieke statistiek. Denk na over wat je als team maakt en hoe je van nature werkt, en bouw vervolgens het systeem rond de mensen. De statistieken moeten u helpen te zien hoe uw systeem ieders werk ondersteunt. Of niet”, concludeerde Dave Cerra, een producent van videogameontwikkeling .
