Hoe wendbaar zijn functiepunten?

Veel organisaties hebben geleerd dat ze meer grip kunnen krijgen op hun softwareprojecten door deze in te schatten met functiepunten. Tegelijkertijd, we zien dat steeds meer organisaties een Agile manier van werken hebben, meestal door Scrum toe te passen. De grote vraag is of Functiepunten blijven staan. Gooit Scrum ze overboord?? Of hebben Functiepunten nog waarde in een Agile wereld? In deze blog laten Jolijn Onvlee en Rini van Solingen zien welke fricties en overeenkomsten er zijn.

Agile / Scrum

Behendig (met Scrum als meest gebruikte aanpak) wordt door een groeiend aantal organisaties omarmd als de oplossing voor het mislukken van grote IT-projecten. Door direct software te gaan leveren, elke twee weken krijgt een klant direct inzicht in de voortgang en toegevoegde waarde. Gebruikers hoeven niet langer te wachten op de functionaliteit met de hoogste bedrijfswaarde. In aanvulling op, de continue stroom van feedback leidt tot waardevolle systemen die werken, veel sneller. In feite, met het gebruik van Scrum, een groot IT-project is opgedeeld in veel kleine projecten. Dit maakt het makkelijker om in te spelen op nieuwe inzichten en vermindert de complexiteit van het hele project enorm.

Scrum behandelt systeemspecificaties op een drastisch andere manier. Het product wordt alleen in algemene termen beschreven (genaamd de Productachterstand).Vervolgens, in eerste instantie alleen die delen zijn in detail uitgewerkt die de hoogste business value te hebben en scripties worden snel geleverd. Na deze oplevering wordt opnieuw de hoogste bedrijfswaarde bepaald, ontwikkeld en geleverd, enzovoort. Op deze manier is een constante afstelling mogelijk. Dit vervangt het oorspronkelijke idee van een project dat een vooraf bepaald resultaat oplevert. De schatting van de volledige leveringsomvang heeft geen zin meer, simpelweg omdat de hele scope niet meer in detail is uitgewerkt. De plek aan de horizon kan op elk moment verschuiven.

Wrijving

Scrum gaat anders om met schatten en budgetteren dan bij een meer traditionele en systematische aanpak. De traditionele benadering maakt vaak gebruik van functiepuntanalyse (FPA) voor kwantificering. FPA wordt gebruikt om in te schatten hoeveel het maken van de software gaat kosten en hoe lang het duurt om deze op te leveren. Een functiepunt wordt gebruikt als een metriek om de grootte van het systeem te bepalen. Deze dimensionering gebeurt op basis van de functionele specificaties. Een zekere mate van detail van wat u gaat maken, is noodzakelijk voor FPA.

Het lijkt er dus op dat Functiepunten en Scrum niet bij elkaar passen. Ten slotte, de eerste wil vooraf een volledige specificatie en de ander wil de specificatie op elk moment in twijfel trekken en bijwerken en gaat niet te ver in detail. De sprints binnen de Scrum-aanpak zijn te kort en te gevarieerd om op basis van functiepunten in te schatten. Tegelijkertijd, ook binnen de Agile organisaties, er is behoefte om de kosten te beheersen. ‘We zullen aan het eind zien hoeveel het heeft gekost’ is voor de meeste organisaties onaanvaardbaar. Dat zou betekenen dat Agile anarchie creëert in IT-uitgaven, dat is onzin. Zelfs bij Scrum heeft een klant behoefte aan controle. De productowner wil het overzicht houden op de resultaten van al deze inspanningen (doel) en hoeveel tijd en geld het uiteindelijk heeft gekost (begroting). En dat is precies waar traditionele FPA uitkomst biedt.

Overeenkomsten

Als je in detail kijkt naar de combinatie van FPA en Scrum, je ziet dat ze elkaar versterken in plaats van verzwakken. Ten slotte, FPA helpt bij het vaststellen van de algehele reikwijdte (de plek aan de horizon) en het juiste budget. Scrum helpt om binnen dat budget als eerste de functies met de hoogste businesswaarde te realiseren. Zo snel mogelijk wordt feedback in het leveringsproces ingevoerd. Feedback op twee fronten: eerste, of de algemene reikwijdte correct is en, ten tweede, of het hele probleem binnen budget kan worden opgelost.

In de praktijk betekent dit dat de achterstand voor het project op mondiaal niveau wordt bepaald. Binnen Scrum is het gebruikelijk dat het deel van het product met de hoogste bedrijfswaarde al een behoorlijke hoeveelheid detail heeft. Dit detailniveau (bij voorkeur voor een aantal sprints) is meestal voldoende om een ​​functiepuntanalyse uit te voeren. Die analyse kun je vervolgens gebruiken om door extrapolatie het totaal aantal functiepunten voor de gehele backlog te bepalen. Binnen de FPA-methode, dit zal worden toegestaan.

Scrum en FPA zijn vrienden

In het kort, Scrum en FPA kunnen elkaar uitstekend helpen en versterken. De functiepunten helpen je grip te houden op de totale lasten. Door Scrum te gebruiken blijf je flexibel op basis van inzichten. Uiteindelijk is het aan jou om het algemene probleem op te lossen. Zo snel, zo goed en zo goedkoop mogelijk. In dat gebied, functiepunten en Scrum hebben een gemeenschappelijk doel.
Dus Scrum en FPA zijn vrienden. Verlies van controle en overschrijding van het budget is het (gemeenschappelijk) vijand!

Snelle winsten

Quick wins in de combinatie Scrum en Function Points

  1. Snellere concretisering van de Product Backlog
    De Product Backlog is de beschrijving van alle niet geïmplementeerde eisen die gemaakt moeten worden. Bovenaan de Product Backlog staan ​​de items die voor de business het belangrijkst zijn en alleen die items worden in detail uitgewerkt. Met FPA kan de omvang van de Product Backlog concreet worden gemaakt. FPA laat zien wat functionaliteit is vereist. FPA geeft daarmee een functioneel overzicht van de Product Backlog.
  2. Meetbaar doel
    Een gedetailleerde Product Backlog voor de eerste zes sprints is voldoende om een ​​geschatte FPA te maken (ISO / IEC 24570 Nesma functionele maatmeetmethode). Het aantal functiepunten kan vervolgens naar het totaal worden geëxtrapoleerd. Dus, het ultieme doel (de plek aan de horizon) kan worden gekwantificeerd, en het uiteindelijke resultaat wordt tastbaar gemaakt, zonder dat er gedetailleerde specificaties voor het hele product nodig zijn.
  3. Makkelijker meten van ‘toegevoegde waarde’
    De snelheid waarmee een team software levert, wordt gemeten in verhaalpunten. Dit zijn relatieve schattingen van de omvang van het werk. Deze verhaalpunten moeten niet worden verward met functiepunten. Ze lijken niet eens op elkaar (behalve in naam, natuurlijk). Functiepunten zijn naar buiten gericht en houden rekening met het totale project. Verhaalpunten zijn naar binnen gericht en helpen voorkomen dat een Scrum-team meer bijt dan ze kunnen kauwen. In Scrum echter, het is moeilijk om de geleverde waarde uit te drukken. Echter, dit kan uitstekend gedaan worden in termen van: Functiepunten!
  4. Hulp bij het prioriteren van functionaliteit
    Een belangrijk aspect van Scrum is het bepalen van de gewenste functionaliteit met de hoogste bedrijfswaarde, die dan wordt opgepikt in de volgende sprint. Met de geschatte FPA de totale verlanglijst – en daarbinnen, de volgende sprints – kan op een eenvoudige manier worden gemeten, ook met betrekking tot de groepering van functionaliteit. Het totaalbeeld blijft behouden en verschuivingen zijn traceerbaar.
  5. Hulp bij het maken van schattingen
    Schatten is de taak van het team. Schatten is altijd zo (en blijft) een lastige zaak. Ten slotte, een team heeft geen glazen bol en voor je het weet, schattingen worden gebruikt alsof het garanties zijn. Scrum-schattingen met verhaalpunten, maar deze zijn relatief: vergelijkbaar met het team, maar niet daarbuiten. Functiepunten, echter, zijn absoluut en vergelijkbaar. Functiepunten zijn vergelijkbaar tussen projecten en kunnen niet alleen vooraf worden gemeten, maar ook tijdens en na een project. Dus, het team krijgt een extra hulp bij het maken van schattingen.
  6. Verbeteringen detecteren
    Omdat FPA een objectieve maatstaf biedt, kan deze in de retrospectieve van het Scrum-proces worden gebruikt om verbetering aan te tonen. Zo help je de teams van elkaar te leren en de belangrijkste remmende factoren op te sporen.
  7. Businesscase voor Scrum bevestigen
    Terwijl veel organisaties enthousiast zijn over Scrum, onrust is te horen via de grapevine dat Scrum-processen meer herwerk omvatten (door inzicht te bevorderen) waardoor ze duurder worden. Het aantal functiepunten van de nieuwe en verbeterde functionaliteit kan worden bepaald en daarmee kan de productiviteit van zowel de aanpassing als het gehele proces worden vastgesteld. Vervolgens kan de businesscase objectief worden bepaald.

Deze blog is oorspronkelijk gepost als opinieartikel in AutomatiseringGids (in het Nederlands).

 

Over de Auteurs

Jolijn Onvlee (jolijn@onvlee.com) is een onafhankelijke FPA-specialist en adviseur, auditor en docent op het gebied van kwaliteit, budget- en productiviteitsbeheer. Jolijn is ook jarenlang werkzaam geweest als voorzitter en bestuurslid van Nesma.

Rini van Solingen is CTO at Prowareness (rini@scrum.nl) en hoogleraar aan de Technische Universiteit Delft. Rini is de auteur van het boek “De kracht van Scrum”; nu ook in het Frans gepubliceerd, Duits en Engels.

Deel deze post op:

4 Opmerkingen

Laat een reactie achter
  1. Ian Alyss zegt:

    Hi Jolijn and Rini,

    Leuk artikel, maar toch is er binnen de ontwikkelaarsgemeenschap veel weerstand tegen het gebruik van functiepunten. Er is een leuk artikel van Jean-Pierre Fayolle dat dit uitlegt: http://qualilogy.com/en/do-developers-dream-of-automated-function-points-1/ Hoe denk je hierover?.

    Ian

  2. Hoi Ian, ja ik herken de weerstand bij ontwikkelaars als FPA wordt geïntroduceerd in de organisatie. Ze zijn bang dat hun (individueel) productiviteit zal worden gemeten en tegen andere ontwikkelaars gelden. Maar…. FPA kan niet worden gebruikt om de productiviteit van een individu te meten. Het is altijd de teaminspanning die u meet. FPA is een hulpmiddel voor de producteigenaar! En er zijn verschillende manieren om FPA in uw srum-project te implementeren!
    Ik betwist dat FPA een erg moeilijke methode is, vooral de geschatte FPA zoals vermeld in de blog.

Laat een antwoord achter