Het is algemeen bekend dat veel softwarerealisatie projecten, die uitbesteed zijn aan een leverancier spaak lopen en minder rendement opleveren dan vooraf gedacht en gehoopt. Het is minder bekend dat de plank al misgeslagen wordt door keuzes bij de start van een project. In deze aflevering wordt belicht hoe je productiviteit in een agile project het beste meet en inbrengt in een contract met een leverancier.

Productiviteit in een agile softwarerealisatie project is het beste te baseren is op functiepunten, zoals in de vorige aflevering van de blogserie uiteengezet is. Het is een objectieve eenheid, die direct gerelateerd is aan de hoeveelheid functionaliteit die door de gebruiker wordt gevraagd. Een prijs per functiepunt is beter dan kosten die gebaseerd zijn op de omvang, uurtarieven en kwaliteit van het ontwikkelteam. De risico’s worden op deze manier eerlijker verdeeld tussen leverancier en klant. De leverancier geeft een prijs per functiepunt af en heeft daarmee een prikkel om de productiviteit en de winstmarge hoog te houden. De opdrachtgever neemt het risico op een correcte inschatting van de omvang. Meer requirements en meer wijzigingen zadelen uiteindelijk alleen de klant met extra kosten op.

Meten is weten

Meten is weten, ook bij applicatieontwikkeling. METRI, een fact based IT adviesorganisatie gespecialiseerd in sourcing en benchmarking, is een samenwerking aangegaan met CAST, een vooraanstaande internationale leverancier van hulpmiddelen voor het doormeten van softwarecode. De samenwerking heeft tot doel organisaties te helpen op een kostenefficiënte manier inzicht te krijgen in de objectief vastgestelde omvang en kwaliteit van applicaties. Hiermee zijn de prestaties te meten van leveranciers die het onderhoud en beheer van applicaties uitvoeren ook vanuit de agile ontwikkelmethode. Op CIODay 2016 zal METRI volop aandacht besteden aan het adequaat sourcen van applicatieontwikkeling in het agile tijdperk. Kijk voor meer informatie op https://metrigroup.com/events/

Versterken

Om die reden is het raadzaam om concreet zicht te krijgen op de omvang voordat een agile softwaretraject van start gaat. In de blog ‘Scrum and function points: friends or foe?’ laten Jolijn Onvlee en Rini van Solingen overtuigend zien dat de scrum-methode en functiepunten elkaar niet in de wielen rijden maar elkaar juist versterken. Volgens de scrum-methode wordt het te ontwikkelen product alleen in algemene termen beschreven in een zogenaamde product backlog. Dit lijkt ver weg van de systeemspecificaties die nodig zijn om een functiepunten analyse te kunnen doen en die eerder met de waterval-methode geassocieerd worden. Maar de soep wordt in de praktijk nooit zo heet gegeten als hij wordt opgediend.

In de praktijk valt dat specificeren heel erg mee. Door alleen de productonderdelen die de hoogste business value toegewezen krijgen concreet en gedetailleerd uit te werken, wordt het uitvoeren van een functiepunten analyse wel mogelijk. Als je dit doet voor een substantieel deel van het eindproduct, dan kun je een verantwoorde uitvergroting met een indicatieve functiepunt analyse te maken naar de omvang van het totale product. Dit komt in de plaats voor het oorspronkelijke idee dat een softwareproduct in zijn geheel gespecificeerd moet worden voordat het programmeren begint. Het voorkomt dat organisaties vast blijven zitten aan dit beginidee en niet meer wendbaar zijn. Met een relevante inschatting van de functiepunten krijgen klanten een relevant criterium in handen om leveranciers met elkaar te vergelijken. Organisaties die hun contracten op basis van een prijs per functiepunt hebben ingestoken, hebben hun projectkosten aanmerkelijk verlaagd. Ook de prijs per functiepunt is in de loop van de tijd gedaald.Deze manier van contractering wordt ook door een aantal overheden wereldwijd toegepast.

Sinds 2000 werkt de overheid van de staat Victoria in Australië bij de aankoop van softwareontwikkeling met een prijs per functiepunt. Leveranciers krijgen de vraag een inschatting te geven van de omvang van de software die opgeleverd moet worden. Daarnaast wordt verzocht een vaste prijs per functiepunt op te geven. De leverancier wordt vervolgens geselecteerd op basis van de prijs per functiepunt en een aantal andere relevant geachte selectiecriteria. Ook hier staan de ontwikkelingen niet stil. De internationale branchevereniging Nesma (www.nesma.org) stelt op dit moment een richtlijn op om software metrieken op te nemen in de contractvoorwaarden.

Als de voordelen zo groot zijn, waarom wordt deze meeteenheid in de praktijk dan zo weinig toegepast? Symons en Stephens geven als belangrijkste reden dat het in de praktijk vaak lastig is om functiepunt analyse toe te passen op moderne softwaresystemen. Het concept van functiepunten is in de jaren zeventig van de vorige eeuw door Allan Albrecht van IBM geïntroduceerd om aan te tonen dat destijds nieuwe programmeertalen de productiviteit van programmeurs niet aantastten. Juist omdat deze eenheid losstaat van de programmeertaal en de methode is deze ook vandaag de dag uiterst relevant.

Geautomatiseerd tellen

Een punt dat veel organisaties in de wielen rijdt, is dat gecertificeerde functiepunt analisten steeds minder beschikbaar zijn. Om de moeilijkheden zoveel mogelijk te ondervangen, maakt METRI gebruik van een hulpmiddel voor source code analyse van CAST Software. Naast een gedetailleerd inzicht in de structurele kwaliteit van de code, krijgen organisaties met dit hulpmiddel ook inzicht in de functionele omvang door functiepunten geautomatiseerd uit te lezen volgens de internationale standaard (OMG/CISQ) voor automated function points. METRI en CAST zijn dit jaar een partnership aangegaan om de tooling toe te passen bij het geautomatiseerd meten van functiepunten in een sprintafronding. Dit maakt het mogelijk om de performance van een leverancier doorlopend te meten.

Om de functionele omvang van de backlog initieel vast te stellen zijn functiepunt analisten nog steeds nodig. Op dat moment is er immers nog geen code aanwezig. Geautomatiseerd meten van functiepunten na afloop van de sprint geeft grip op de voortgang en maakt het meten van de productiviteit van de leverancier mogelijk. Functiepunt analyse werd altijd gezien als lastig, omdat de accuraatheid van de omvangmeting wordt bepaald door de volledigheid en kwaliteit van de functionele documentatie en omdat er (schaarse) gecertificeerde functiepunt analisten nodig zijn om de analyses te doen. Met de komst van de internationale OMG/CISQ standaard voor automatische functiepunten zijn deze nadelen er niet meer. Organisaties die de moeite nemen om de functionele omvang vooraf te bepalen of te meten tijdens de realisatie van een project kunnen profiteren van alle genoemde voordelen van ‘unit based pricing’ zoals het prijsmodel gebaseerd op de eenheid functiepunt ook wel genoemd wordt.