Elk productief software engineering team houdt hun verbeteringen bij door middel van een set van gekozen indicatoren genaamd KPI engineering metrieken. Dit zijn de 5 meest essentiële Key Performance Indicator (KPI) ontwikkelmetrieken die u vandaag nog zou moeten gaan bijhouden.

Heeft u ooit gewerkt met een engineeringteam waar geen KPI-metrieken werden gemeten? Als dat zo is, dan weet je waarschijnlijk hoe moeilijk het is om te bepalen of het team op schema ligt voor de release of niet.

De waarheid is dat als u uw zakelijke doelen wilt bereiken, u ervoor moet zorgen dat uw software aan alle eisen voldoet. Om dit te doen, moet u KPI engineering metrieken implementeren in de ontwikkelingsprocessen.

Door het opzetten van KPI engineering metrieken voor uw software-ontwikkelingsteam, zult u slechte kwaliteit en gemiste deadlines te voorkomen. Wat je krijgt is een productief team en een product van hoge kwaliteit.

Hier zijn vijf essentiële KPI-ontwikkelingsmetrieken die u zou moeten bijhouden om uw zakelijke doelen te bereiken.

Sprint Burndown

Wat is Sprint Burndown?

Agile teams organiseren hun ontwikkeling in sprints. Een sprint burndown meet hoeveel werk het team heeft voltooid tijdens een sprint.

Wat zijn de voordelen?

• Een sprint burndown is geweldig om het team bewust te houden van eventuele wegversperringen die zich voordoen.
• Door het meten van sprint breakdown, kunt u controleren of uw team zijn prognose haalt.
• Met behulp van een sprint breakdown chart kan het team zijn voortgang managen. Als het team zich realiseert dat het misschien niet het sprint doel te bereiken, kunnen de teamleden passende maatregelen nemen om op schema te blijven.

Hoe meet je het?

Agile teams gebruiken sprint burndown grafieken om hun workflow te visualiseren. De grafiek heeft een x-as die de tijd vertegenwoordigt en een y-as die de hoeveelheid werk vertegenwoordigt die nog moet worden voltooid. U kunt de tijd meten in uren of story points. Of u kunt uw eigen statistieken bedenken. Het belangrijkste doel hier is om al het voorspelde werk voltooid te hebben tegen het einde van de sprint.

Een tool die je kunt gebruiken is de Jira Sprint Breakdown chart. Om het te gebruiken, moet u een Jira Software-account maken, en een Jira Software Scrum-project.

U zult een verticale as zien die story points vertegenwoordigt. De horizontale as toont de tijd. De rode lijn in de grafiek vertegenwoordigt de hoeveelheid werk die over is in de sprint. De grijze lijn is de werkelijke werk lijn. Als de rode lijn onder de grijze lijn ligt, dan betekent dit dat het team op schema ligt. Als de rode lijn echter boven de grijze lijn ligt, betekent dit dat het project achterloopt op schema.

Release Burndown

Wat is Release Burndown?

Release burndown biedt een overzicht van de voortgang van de release. Het is vergelijkbaar met de Sprint burndown, maar het is groter van opzet. Het helpt teams te controleren of ze erin zullen slagen om het product op een bepaalde datum vrij te geven. Als ze zich realiseren dat ze achterlopen op schema, kunnen ze gebruikers en stakeholders informeren over de vertraging. Of, zo niet, dan kunnen ze de omvang van het werk verminderen om het product op tijd uit te brengen.

Wat zijn de voordelen?

• U kunt nagaan hoe snel uw team door de backlog werkt.
• U kunt inzicht krijgen in hoe toegevoegd en verwijderd werk de voortgang van uw team beïnvloedt.
• Voorspellingen doen over het aantal sprints dat uw team nodig heeft om het werk te voltooien.

Hoe meet je het?

Release burndown wordt gemeten met behulp van een grafiek die vergelijkbaar is met de sprint breakdown chart. Het verschil is dat nu de horizontale as de sprints voorstelt, en de verticale as het resterende werk (dagen, uren, of story points).

Open voorbeeld, laten we eens kijken naar de afbeelding hieronder. Het is een Jira release burndown grafiek. U kunt zien dat het team in eerste instantie vier sprints en 43 story points heeft vastgesteld. Over die vier sprints, heeft het team het aantal stories teruggebracht van 43 naar 26. Het team heeft ook voorspeld dat de release van het product nog zeven sprints zal duren, wat resulteert in 11 in totaal.

Cycle Time

Wat is Cycle Time?

Cycle time is een KPI-ontwikkelingsmetriek die meet hoeveel tijd het team besteedt aan het werken aan een taak. Cycle time grafieken worden gebruikt door Scrum Masters en Product Owners om de efficiëntie van het ontwikkelingsproces te controleren.

Wat zijn de voordelen?

• Het geeft informatie over de algehele prestaties van het team.
• Het maakt het mogelijk om de voltooiing van toekomstige taken te schatten.
• Je kunt eventuele knelpunten en vertragingen in de workflow opmerken.

Hoe meet je het?

De cyclustijd is gelijk aan de einddatum min de startdatum. Bijvoorbeeld, als het team begint te werken op 1 december en eindigt op 10 december, dan is de cyclustijd is negen dagen.

Als het team op 1 december met het werk begint en de taak dezelfde dag afrondt, dan is de cyclustijd niet nul maar één. Voor projecten die op dezelfde dag beginnen en eindigen, is de cyclustijd gelijk aan de einddatum min de begindatum +1.

Je kunt dagen vervangen door weken, uren, of zelfs sprints.

Overweeg het gebruik van cyclustijddiagrammen om je workflow te visualiseren. Deze grafieken laten zien hoe lang een probleem duurde om te voltooien versus de dag van voltooiing.

Kijken we bijvoorbeeld eens naar de onderstaande grafiek. Op de x-as, ziet u de datum waarop de taak werd afgesloten, en op de y-as, ziet u de bestede tijd. De groene cirkels zijn taken. Een dichte cirkel geeft een cluster van problemen aan, terwijl een open cirkel een enkel probleem aangeeft. Als u een tool als Jira gebruikt, kunt u de sleutel van de taak, de code en de doorlooptijd zien door met uw muis over de cirkel te bewegen. De rode lijn geeft de gemiddelde doorlooptijd aan, en de blauwe lijn geeft de voortschrijdende gemiddelde doorlooptijd aan.

Het einddoel is voor het team om consistente cyclustijden te hebben voor werkitems die vergelijkbare story point waarden hebben. Lagere waarden betekenen dat het team efficiënt werkt, terwijl hogere waarden kunnen wijzen op knelpunten in het werkproces.

Team Velocity

Wat is Team Velocity?

Velocity is een andere agile KPI engineering metric die de hoeveelheid werk meet die een team voltooit tijdens een sprint. De hoeveelheid werk wordt meestal gemeten in story points of uren.

Producteigenaren gebruiken velocity om te berekenen hoe snel een team door de backlog kan werken. De velocity index is uniek voor elk team, en je moet velocity niet vergelijken tussen teams.

Bijvoorbeeld, laten we zeggen dat je 300 story points in de backlog wilt voltooien. Je weet dat het ontwikkelteam, gemiddeld, ongeveer 50 story points per iteratie afwerkt. Met die informatie bij de hand, kunt u voorspellen dat het team zal zes iteraties nodig hebben om het vereiste werk te voltooien.

Wat zijn de voordelen?

• Het is zeer nuttig voor het voorspellen.
• Het kan helpen bij het plannen van toekomstige sprints.
• Het kan u helpen te begrijpen of het team geblokkeerd is of dat uw proceswijzigingen werken.

Hoe meet je het?

Als je een stabiel team hebt, lukt het je om een gemiddelde snelheid vast te stellen door ten minste 5-7 sprints te meten. Als uw gebruikelijke sprint wekelijks is, en het team voltooit 250 story points over een periode van vijf weken, dan is uw gemiddelde velocity rate 50 story points per week.

Laten we eens kijken naar de Jira Velocity Chart hieronder. De blauwe balken vertegenwoordigen de inzet, en de groene het daadwerkelijk voltooide werk. In sprint nummer 1, plande het team 16 story points en voltooide 16 story points. Dit geeft aan dat hun schattingen correct waren. Echter, in de tweede sprint plande het team 19 story points, maar voltooide er slechts 12. Dit suggereert dat de volgende keer, ze moeten hun plan te verminderen.

Een inconsistente flow is een indicator dat je problemen hebt in de ontwikkeling en dat je veranderingen moet doorvoeren.

Cumulative Flow

Wat is Cumulative Flow?

Cumulative flow visualiseert de status van uw tickets over een bepaalde periode. Het toont de verschuiving van uw tickets van de ene status naar de andere als uw project vordert.

Wat zijn de voordelen?

• Het is nuttig voor het identificeren van knelpunten.
• Helpt teams ervoor te zorgen dat de stroom van werk consistent is.
• Het laat zien hoe stabiel uw workflow is.
• Het helpt u te begrijpen hoe u uw proces meer voorspelbaar kunt maken.

Hoe meet je het?

De eenvoudigste manier om cumulatieve workflow te meten is door gebruik te maken van grafieken. Ze visualiseren de drie belangrijkste software engineering metrieken van uw flow, met inbegrip van cyclustijd, throughput, en work in progress.

Laten we eens kijken naar de grafiek hieronder. De horizontale x-as geeft de tijd aan, terwijl de verticale y-as de work items aangeeft. De verschillende kleuren vertegenwoordigen de verschillende workflow-states. Als de banden parallel lopen, betekent dit dat uw doorvoer stabiel is. Het geeft aan dat het aantal nieuwe taken dat uw workflow binnenkomt, gelijk is aan het aantal taken dat deze verlaat.

Als een band snel smaller wordt, betekent dit dat u meer capaciteit hebt dan u nodig hebt. U moet de capaciteit verplaatsen om de stroom te optimaliseren.

Als een band snel breder wordt, betekent dit dat er meer kaarten het overeenkomstige stadium binnenkomen dan er opdrachten zijn die het verlaten.

Summing Up

Het bijhouden van de hierboven geschetste KPI-ontwikkelingsmetrics kan leiden tot een succesvolle uitkomst van het productontwikkelingsproces. U zult erin slagen om uiteindelijk te stoppen met het achteraf beoordelen van de voortgang van uw project en een gedetailleerd inzicht te krijgen in elke fase van de ontwikkelingslevenscyclus.

Als u een einde wilt maken aan de vicieuze cirkel van lage kwaliteit producten, gemiste deadlines, en code mislukkingen, begin dan vandaag nog met het implementeren van KPI ontwikkeling. U zult erin slagen een topproduct uit te brengen zonder de bijbehorende risico’s.