Wat is de stand van de techniek?

Agile-methodologieën winnen tegenwoordig aan populariteit en zijn een hoofdstroom van softwareontwikkeling geworden vanwege het vermogen om hoge klanttevredenheid te genereren. Estimation and metrics consultancy krijgt steeds meer ‘Agile opdrachten’ en moet met waardevol advies komen voor agile projectomgevingen. Maar Agile-methodologieën verschillen van traditionele Waterfall-methodologieën, vooral in de manier waarop schattingen en het verzamelen van statistieken worden gedaan. Een onderzoek via literatuur en internet voor deze onderwerpen geeft inzicht in de verschillen en zal onze kennis verbreden en mogelijk onze capaciteiten versterken. Er zijn nieuwe benaderingen gevonden over hoe bestaande technieken en instrumenten kunnen worden toegepast in Agile-omgevingen. Het resultaat van dit onderzoek omvat drie artikelen. Dit eerste artikel toont de state-of-the-art van metrische gegevens in agile softwareontwikkeling.

Softwarestatistieken in het algemeen

Software-metrics of software-meting is een concept uit de software-industrie. Het kan als volgt worden beschreven:: waarden toepassen op eigenschappen van producten of processen volgens gedefinieerde principes om statistische of vergelijkende analyses uit te voeren ten behoeve van een vooraf gedefinieerd doel.

Software Metrics ondersteunt gewoonlijk drie interessegebieden.

• Planning, voorspelling
• Toezicht houden & controle
• Prestatieverbetering, benchmarking

Er zijn veel softwarestatistieken in gebruik voor verschillende situaties. Putnam en Myers leggen prachtig uit waar het allemaal om draait bij de ‘5 kernstatistieken‘ voor softwareontwikkeling: men ontwikkelt een Product van acceptabel kwaliteit met een bepaalde inspanning in zekere zin tijd. De relatie tussen product, kwaliteit, inspanning en tijd, wordt bepaald door de productiviteit, die dus ook gemeten moet worden. We gaan deze kernstatistieken nader bekijken.

Product(grootte)
Meet kwantitatieve eigenschappen, die de grootte van het product bepaalt. Vooraf of achteraf te doen.
Voorbeelden: LOC, Functie punten, aantal gebruiksscenario's, aantal functies, Gebruikersverhalen.

Kwaliteit
Het product moet enige kwaliteit hebben, meestal bepaald door middel van ‘aantal gebreken per tijdsperiode’, de gemiddelde tijd tot defect (MTTD) en de ‘defectdichtheid’ (aantal defecten per KLOC).

Inspanning
Gemeten in persoonsmaanden die uitsluitend aan zijn project waren gewijd.

Looptijd
Dit is de doorlooptijd zonder onderbreking tussen startdatum en einddatum van het project (bv. in maanden).

produktiviteit
Dit is een eigenschap van het proces, d.w.z. het softwareontwikkelingsproces in de organisatie. Benadrukt wordt dat dit niet de productiviteit is van één of meerdere personen die voor de realisatie zorgen! Productiviteit bepaalt de relatie tussen het product (grootte), inspanning en tijd in de zogenaamde Software Equation in zijn basisvorm:

Productivity = product size (with a known Quality) / (effort * time)
(refer to the book for explanation)

Deze kernstatistieken ondersteunen de eerder genoemde (hoofd) interessegebieden als volgt:.
Planning en voorspelling: productiviteit en productgrootte (bij een gewenste kwaliteit) bepalen indirecte kosten, doorlooptijd en inspanning.
Monitoring en controle: allerlei metingen worden gebruikt als onderdeel van het product, procentuele inspanning per geleverd product vergeleken met de totale productomvang op een bepaald moment, aantal fouten gevonden tijdens ontwikkeling vergeleken met het verwachte aantal fouten. Dit soort metingen kenmerkt de prestaties van het projectteam.
Verbetering, benchmarking: door een historie op te bouwen met kerninformatie uit eigen gerealiseerde projecten kan een referentiepunt worden bepaald waarmee toekomstige projecten kunnen worden vergeleken. Ook de eigen prestatie kan worden vergeleken met een prestatie van andere bedrijven (benchmarking). Met deze tweede vergelijking kan worden bepaald of de organisatie marktconform presteert.

Metrieken in Agile-projecten

Agile methoden hebben hetzelfde uitgangspunt als de watervalmethode, namelijk: men ontwikkelt een Product van acceptabel kwaliteit met een bepaalde inspanning in zekere zin tijd.

De aanpak en processen kunnen verschillen, maar in principe is het een andere weg die naar dezelfde bestemming leidt. Het is niet verwonderlijk dat in een agile omgeving software metrics hun plaats hebben. Echter, er zijn enkele opmerkelijke verschillen met de watervalbenadering. In de eerste plaats, vermeld moet worden dat agile methoden hun grootste successen hebben in kleine tot middelgrote projecten voor commerciële toepassingen.

De focus van agile metrics is in lijn met deze beperkte omvang en focus vooral op het team, de huidige iteratie, de huidige release. Minder op het project en misschien helemaal niet op een heel programma van projecten. In het kort, de focus is intern gericht. Dit is belangrijk om op te merken omdat agile op dit punt duidelijk verschilt van de watervalbenadering. Een tweede opvallend verschil tussen agile-metrieken en waterval-statistieken is het verschil in gebruikte maateenheden. Agile-statistieken voor product(grootte) en productiviteit worden uitgedrukt in subjectieve eenheden (verhaalpunten en verhaalpunten per iteratie of snelheid) die alleen van toepassing zijn op dit project en dit team. Dit maakt vergelijking tussen teams mogelijk, projecten en organisaties onmogelijk. Watervalstatistieken worden vooral uitgedrukt in gestandaardiseerde eenheden voor benchmarkdoeleinden.

De volgende matrix toont de kernstatistieken van Putnam en Myers in beide omgevingen:.

Kernstatistiek	Behendig	Waterval
Product(grootte)	Kenmerken, verhalen	FP, GVB, UCP
Kwaliteit	defecten/iteratie, gebreken, MTTD	defecten/release, gebreken, MTTD
Inspanning	verhaal punten *)	persoon maanden
Tijd	duur (maanden)	duur (maanden)
produktiviteit	snelheid (verhaalpunten/iteratie) **)	uur/FP ****)

*)	Verhaalpunten zijn subjectief en zijn alleen van toepassing op dit project en dit team
**)	Snelheid is subjectief en is alleen van toepassing op dit project en dit team, benchmarking niet mogelijk.
***)	FP en CFP zijn objectief en zijn internationale standaarden om functionele omvang uit te drukken.
****)	Uren/FP wordt gebruikt door verschillende schattingen & metrische tools voor benchmarkingdoeleinden.

 

Een rondgang op het web voor het gebruik van metrics in de Agile community levert een gevarieerd beeld op. Sommige consultants stellen metrics voor die ‘dicht bij de’ blijven manifest ‘. In deze categorie komen doelen naar voren als ‘inzicht in het vertrouwen van de sponsor’, ‘ inzicht in klanttevredenheid’ en ‘motivatie van het team’. Het perspectief van waaruit ‘agilists’’ kijk naar statistieken, wordt goed geïllustreerd door de presentatie over Agile-statistieken door Mike Griffith. Naast de ‘agilists’ zijn er consultants die zich focussen op de traditionele metrics, hoewel deze statistieken gebruik maken van agile-eigen concepten en eenheden zoals functies, iteraties, verhaalpunten en snelheid.

Een opmerkelijk document in deze context, de recente proefschrift van Hanna Kulas. Dit document legt uit waarom Agile zo speciaal is en hoe bepaalde productstatistieken kunnen worden opgenomen in agile projecten. Bovendien wat er zal worden gemeten en welke voordelen kunnen worden vastgesteld?. De toepassing van deze productstatistieken kan leiden tot een toename van de klanttevredenheid als gevolg van een hogere productkwaliteit en lagere ontwikkelingskosten, wat op zijn beurt het resultaat is van een beter begrip van het softwareontwikkelingsproces.

Opmerkelijk en kenmerkend voor agile is het ontbreken van metrics voor benchmarking of enige andere vorm van externe vergelijking. De maateenheden die voor het product worden gebruikt (grootte) en productiviteit zijn subjectief en gelden uitsluitend voor het project en het team in kwestie. Vanuit het perspectief van een acquisitiemanager of sponsor is er geen mogelijkheid om ontwikkelteams of aanbestedende aannemers te vergelijken op productiviteit. Dus het selectieproces voor een aannemer op rationele gronden (productiviteit) is vrijwel onmogelijk.

Hierna worden de 'agile'-statistieken samengevat die op het web zijn aangetroffen; hun doel en hoe ze worden gemeten. Merk op dat de meeste statistieken 'monitoring' ondersteunen & controle'. Het is duidelijk dat met betrekking tot dit interessegebied de agile omgeving niet zoveel verschilt van de traditionele watervalomgeving.

'Agile'-statistieken, resultaten van een enquête op het web

De volgende tabellen tonen statistieken die in veel gevallen worden aanbevolen door verschillende 'agile consultants' volgens hun eigen praktijk. De statistieken zijn gegroepeerd rond de interessegebieden die eerder in dit document zijn genoemd.

Statistieken voor Planning, voorspelling

Metriek	Doel	Hoe te meten
aantal functies	1. Inzicht in de maat van het product (en de hele release). 2. Wanneer status wordt toegepast op functies: inzicht in vooruitgang.	Het product bevat functies die op hun beurt verhalen bevatten. Functies zijn gegroepeerd als 'te doen', 'bezig', en 'aanvaard'.
aantal geplande verhalen per iteratie/release	1. Inzicht in de maat van het product (en de hele release). 2. Wanneer status wordt toegepast op verhalen: inzicht in vooruitgang.	Het werk wordt beschreven in verhalen, die worden gekwantificeerd in verhaalpunten. Verhalen zijn gegroepeerd als 'te doen', 'bezig', en 'aanvaard'.
aantal geaccepteerde verhalen per iteratie/release	Om de voortgang van de iteratie/release te volgen	Formele registratie van geaccepteerde verhalen.
Teamsnelheid	Raadpleeg Bewaking & Controle
LOC	Geeft de hoeveelheid voltooid werk aan (vooruitgang), berekening van andere statistieken, d.w.z. defect dichtheid.	Volgens de overeengekomen regels welke LOC's moeten worden geteld.

Statistieken voor Toezicht houden & Controle (voortgang en prestaties)

Metriek	Doel	Hoe te meten
Iteratie Burn-down	Prestaties per iteratie, 'zijn we op de goede weg'?’.	Resterende inspanning (over uur) voor de huidige iteratie (bestede/geplande inspanning drukt prestatie uit).
Teamsnelheid per iteratie	Om historische snelheid voor een bepaald team te leren. Kan niet worden gebruikt om verschillende teams te vergelijken.	Aantal gerealiseerde verhaalpunten per iteratie binnen deze release. Velocity is team- en projectspecifiek.
Laat burn-down los	Om de voortgang van een release van iteratie naar iteratie te volgen 'liggen we op schema voor de hele release'.	Aantal verhaalpunten 'te doen' na voltooiing van een iteratie binnen de release (extrapolatie met bepaalde snelheid toont de einddatum).
Laat Burn-up los	Hoeveel 'product' kan worden geleverd binnen het opgegeven tijdsbestek?.	Aantal gerealiseerde verhaalpunten na voltooiing van een iteratie over het totale aantal verhaalpunten (van de vrijlating). Op een tijdlijn toont het de voortgang van 'scope-voltooiing'.
Aantal testgevallen per iteratie	Om de hoeveelheid testwerk per iteratie te leren. Om de voortgang van het testen te volgen.	Aantal testgevallen per Iteratie geregistreerd als 'duurzaam', 'mislukt' en 'te doen'.
Cyclustijd (Capaciteit van het team)	Knelpunten van het proces bepalen; de discipline met de laagste capaciteit is de bottleneck.	Aantal verhalen dat per discipline kan worden afgehandeld binnen een iteratie (d.w.z. analyse- UI-ontwerp-codering - hoofdstuk toets- syst.-test).
De wet van Little - 'cyclustijden zijn evenredig met de lengte van de wachtrij'.	Inzicht in looptijd; we kunnen de voltooiingstijd voorspellen op basis van de wachtrijlengte.	Lopende werkzaamheden (# verhalen) gedeeld door de capaciteit van de processtap.

Statistieken voor Verbetering (productkwaliteit en procesverbetering)

Metriek	Doel	Hoe te meten
Cumulatief aantal defecten	Om de effectiviteit van testen te volgen.	Elk defect in het defectbeheersysteem registreren.
Aantal testsessies	Testinspanningen volgen en vergelijken met het cumulatieve aantal defecten.	Extractie van gegevens uit de defectrepository.
Defecte dichtheid	Om de kwaliteit van de software te bepalen in termen van 'gebrek aan defecten'.	Het cumulatieve aantal defecten gedeeld door 1000LOC's (BLOK).
Defectverdeling per herkomst	Om te beslissen waar middelen voor kwaliteitsborging worden toegewezen.	Door de oorsprong van defecten te loggen in de defectrepository en de gegevens te extraheren door middel van een geautomatiseerde tool.
Defectverdeling per type	Om erachter te komen welk type defecten het meest voorkomen en om ze in de toekomst te helpen voorkomen.	Door het type defecten in de defectrepository te loggen en de gegevens te extraheren door middel van een geautomatiseerde tool.
Cyclustijd defect	Inzicht in de tijd om een ​​defect op te lossen (snelheid van het oplossen van defecten:). Hoe sneller de resolutie, de kleinere codering 'on top' wordt geproduceerd.	Openingsdatum van het defect minus de datum van de oplossing (meestal de sluitingsdatum in de defectrepository).

Opmerking: er zijn ook 'statistieken'’ vond die maatstaf ’inzicht in het vertrouwen van de cliënt’ ‘ en ‘ inzicht in klanttevredenheid’. Echter voor deze metrics slaagt de agile community er niet in om aannemelijk te maken waarom deze aspecten specifiek van toepassing zijn op agile en daarom niet worden meegenomen.. Verwijzend naar mijn eigen ervaring van meer dan 30 jaar worden deze aspecten gemeten in allerlei projectomgevingen. Voor het gebruik van de Earned Value Methode geldt min of meer hetzelfde.

conclusies

Deze rondgang op het web en door publicaties leidt tot de volgende conclusies:.

1. De metrieken die worden gebruikt binnen de Agile-methoden en de gebruikte eenheden (verhaal punten, snelheid) zijn niet gestandaardiseerd. Dit maakt benchmarking problematisch, zo niet onmogelijk.
2. Wanneer gerealiseerde verhaalpunten worden uitgedrukt als LOC's, kan een overeenkomst worden vastgesteld met gestandaardiseerde functionele maateenheden (FPn); zelfs de productiviteit van een organisatie of teamproductiviteit kan worden bepaald.
3. Agile-methoden kunnen baat hebben bij het opnemen van productstatistieken als gevolg van een toename van de klanttevredenheid als gevolg van een hogere productkwaliteit en lagere ontwikkelingskosten door een beter begrip van het softwareontwikkelingsproces.
4. Binnen de Agile community worden veel metrics ontwikkeld, die in wezen hetzelfde zijn als metrieken binnen de watervalmethode, hoewel ze agile-eigen eenheden en concepten gebruiken.
5. Agile methoden herkennen ‘functionele omvang’ niet. De ‘grootte’ van een release wordt uitgedrukt in aantal features of stories. De meting ‘verhaalpunten’ levert geen (functioneel) grootte, maar eerder een hoeveelheid vereiste inspanning.

Links naar enkele van de websites

• Groot zichtbaar – Agile-statistieken en diagnostiek
• Geschaald Agile Framework – metriek
  Deze website van Dean Leffingwell neemt een bijzondere positie in. Het Scaled Agile Framework is een filosofie en methodologie die agile ontwikkeling kadert in een 'lean' enterprise-strategie. Sommige van de 'Kunst'-statistieken die in het diagram worden genoemd, zijn opgenomen in de bovenstaande tabellen.
• Instituut voor software-engineering – Zeven categorieën Agile-statistieken
• Toonaangevende antwoorden – Kwaliteitsprojectmanagement

 

 

Over de auteur

John Kammelar is Metrics Consultant bij metrieken.nl, dat helpt organisaties om inzicht en controle te krijgen over kosten en tijd voor softwareontwikkeling en -beheer. Ze kwantificeren functionaliteit met functiepuntanalyse. Op basis van deze analyse kan een realistische inschatting worden gemaakt van tijd en kosten. Deze blog maakt deel uit van een serie van drie artikelen naar aanleiding van een uitgebreide enquête. Dit eerste deel toont de state-of-the-art metrieken in agile softwareontwikkeling. Alle artikelen kunnen worden gedownload van de metrieken.nl website.

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