Extreme Programming (XP): de ontwikkelingsmethode en wat deze voor uw winstmarge betekent

Extreme Programming (XP) is een agile methode voor softwareontwikkeling die de nadruk legt op samenwerking, betrokkenheid van de klant en aanpassingsvermogen. In een dienstverlenend bedrijf worden hiermee een deel van de inspanningen naar de beginfase van het project verplaatst om late en kostbare aanpassingen te voorkomen, en draagt deze methode bij aan de ontwikkeling van de vaardigheden van junior medewerkers.

In een digitale dienstensector hangt de kwaliteit van de opgeleverde code niet alleen af van de technische netheid: ze is bepalend voor de winstgevendheid van een opdracht. Een fout die tijdens de ontwikkeling onopgemerkt blijft, komt bij de klant terecht zodra de software in gebruik is. Deze moet dan worden verholpen, en deze correctie was noch voorzien, noch begroot. Bij een vast-prijscontract gaat dit direct ten koste van de projectmarge. Bij een tijd- en materiaalbasis ondermijnt het het vertrouwen van de klant, leidt het tot meer crediteringen en maakt het de verlenging van de opdracht onzeker.

Extreme Programming (XP) is een agile methode voor softwareontwikkeling die eind jaren negentig door Kent Beck is ontwikkeld. Deze methode drijft twee principes tot het uiterste door: technische kwaliteit en voortdurende feedback. De logica erachter: meer investeren tijdens het ontwerpen van de code, door middel van pair programming (twee ontwikkelaars die samen aan één taak werken) en het schrijven van tests vóór de code, om zo later veel minder kosten te maken, op het moment dat het herstellen van een fout het duurst is.

Wat is Extreme Programming (XP): waarden en werkwijzen

Extreme Programming is gebaseerd op vijf waarden (communicatie, eenvoud, feedback, moed, respect) die zijn uitgewerkt in twaalf technische werkwijzen. Volgens de Agile Alliance is XP het meest gedetailleerde agile raamwerk voor het bouwen van software: waar andere methoden het hebben over de organisatie van het werk en de teams, legt XP uit hoe de code moet worden geschreven, getest en opgeleverd. (bron: Agile Alliance)

De vijf waarden van Extreme Programming

Deze vijf waarden vormen de leidraad voor alle werkwijzen van XP.

• Communicatie. XP verspreidt informatie via directe uitwisseling (mondeling, whiteboard, pair programming) in plaats van via omvangrijke documentatie, omdat de meeste projectafwijkingen voortkomen uit een misverstand over de behoefte, niet uit een technisch probleem. Bij een project op basis van een vaste prijs is een functionaliteit die buiten de opdracht om wordt ontwikkeld, niet-factureerbare tijd die later opnieuw moet worden gedaan.
• Eenvoud. Bouw het eenvoudigste systeem dat aan de huidige behoefte voldoet, zonder functies te programmeren ‘voor het geval dat’. Elke functie die wordt ingebouwd maar waar de klant niet om heeft gevraagd, kost ontwikkelingsbudget voor een onzekere opbrengst.
• Feedback. Vroeg en vaak om feedback vragen: tests geven continu inzicht in de status van de code, en frequente opleveringen geven bij elke iteratie de mening van de klant weer. Bij een vast-prijscontract waarborgt deze korte feedbackcyclus de winstgevendheid van het project: een misverstand dat al bij de eerste oplevering wordt opgemerkt, kan binnen de reeds verkochte scope worden gecorrigeerd, terwijl hetzelfde misverstand dat pas bij de eindoplevering aan het licht komt, een herstelwerkzaamheid met zich meebrengt die niet in het budget was voorzien.
• Houd moed. Durf code die niet werkt weg te gooien in plaats van hem te lappen, herstructureer een kwetsbaar onderdeel, en vertel de waarheid over de werkelijke voortgang, ook al is die vervelend. Een overschrijding die vroeg wordt gemeld, kan nog met de klant worden heronderhandeld; dezelfde overschrijding die tot aan de oplevering verborgen blijft, leidt tot niet-gefactureerde dagen.
• Respect. Elk lid respecteert het werk van de anderen. Dat is de concrete voorwaarde voor pair programming en collectieve verantwoordelijkheid voor de code: zonder dat accepteert niemand dat een collega ‘zijn’ code wijzigt, en blijft de kennis opgesloten in één enkel hoofd.

De twaalf werkwijzen van XP

De vijf waarden komen tot uiting in twaalf concrete werkwijzen, het ‘hoe’ van XP. Er zijn drie categorieën te onderscheiden: planning, de manier waarop code wordt ontworpen en geschreven, en de organisatie van het team. Elke technische term wordt bij de eerste vermelding toegelicht.

Van deze twaalf werkwijzen leveren er vier het grootste deel van de economische winst op in een dienstverlenend bedrijf: pair programming, testen, continue integratie en refactoring. Juist deze werkwijzen verleggen de inspanning naar een vroeger stadium in het proces en zorgen ervoor dat het aantal herhalingswerkzaamheden afneemt.

Welke zijn al standaard bij IT-dienstverleners, welke komen nog maar zelden voor?

In 2026 past een modern ontwikkelingsteam vaak al een deel van Extreme Programming toe zonder het bij naam te noemen. Continue integratie, geautomatiseerde tests, refactoring en coderingsregels zijn inmiddels de norm geworden in het vakgebied, gedragen door de huidige tools en werkwijzen.

Drie werkwijzen komen nog steeds aanzienlijk minder vaak voor, elk om een specifieke reden. Systematisch pair programming stuit op het idee dat de kosten dubbel zo hoog zijn, omdat er twee ontwikkelaars worden betaald voor één taak. Een klant die daadwerkelijk continu beschikbaar is, veronderstelt een toegewijde contactpersoon, en maar weinig klanten zijn bereid om iemand fulltime hiervoor in te zetten. Tot slot wordt de metafoor vaak als te abstract beschouwd en in de praktijk achterwege gelaten.

De invoering van XP betekent dus zelden dat alles opnieuw moet worden uitgevonden. Meestal gaat het erom datgene wat het team al gedeeltelijk doet, te formaliseren en aan te vullen, door de ontbrekende werkwijzen toe te voegen die het verschil maken op het gebied van kwaliteit.

Extreme Programming, Scrum of waterval: welke rol spelen ze in projectmanagement?

Binnen de projectmanagementmethodieken staan deze drie benaderingen niet op hetzelfde niveau, en als je ze door elkaar haalt, leidt dat tot wankele keuzes. Wat de projectcyclus betreft, staan twee opties tegenover elkaar: taken in een waterval volgorde rangschikken (waterfall), waarbij elke fase wacht tot de vorige is afgerond, of in iteratieve cycli te werk gaan via een agile methode zoals Scrum. XP is op zich geen projectcyclus: het is een reeks engineeringpraktijken die op een iteratieve cyclus worden toegepast. XP vormt dus een aanvulling op Scrum, maar is slecht toepasbaar op een project dat volgens de watervalmethode is georganiseerd, waarbij de projectomvang vanaf het begin vastligt.

Kun je XP en Scrum combineren?

Ja, en dat is zelfs de meest gangbare combinatie om beter presterende agile teams op te bouwen. Scrum organiseert het werk (sprints, rollen, tempo) zonder voor te schrijven hoe er geprogrammeerd moet worden; XP biedt juist die technische werkwijzen. De twee vullen elkaar aan: Scrum biedt het kader voor de sprint, XP waarborgt de kwaliteit van de deliverables binnen deze projectorganisatie.

„Scrum is slechts een raamwerk voor productontwikkeling, een kader waaraan andere werkwijzen kunnen worden toegevoegd. XP is een van die werkwijzen [voor het schrijven van code] die binnen het Scrum-raamwerk kunnen worden toegepast.” (Bron: scrum.org)

Maar deze werkwijzen moeten dan ook daadwerkelijk worden toegepast, anders vervalt men in ‘ceremoniële Scrum’. Een team dat de Scrum-rituelen (sprints, dagelijkse stand-ups, retrospectieven) overneemt zonder de best practices van XP (geautomatiseerde tests, continue integratie, refactoring…) in te voeren, zal technische schuld opbouwen en deze op de lange termijn moeten compenseren door een beroep te doen op de projectmarge. Wanneer de code namelijk niet gaandeweg wordt getest en opgeschoond, stapelt elke sprint nieuwe functionaliteiten op een kwetsbare basis op, en kost de kleinste aanpassing steeds meer tijd. Het team lijkt weliswaar wendbaar, maar mist de technische kwaliteit die dit duurzaam maakt en waarmee projectafwijkingen kunnen worden voorkomen. (bron: Mountain Goat Software)

Vergelijkingstabel: XP versus Scrum versus watervalmethode

De onderstaande tabel geeft een overzicht van wat elke aanpak inhoudt en voor welk soort opdracht deze geschikt is. Hieruit blijkt dat XP eerder een aanvulling is op Scrum dan dat het deze vervangt, en dat de watervalmethode alleen geschikt is voor werkgebieden die werkelijk stabiel zijn.

Hoeveel kost XP op het gebied van projectmanagement, en wat beschermt het wat de marges betreft?

XP verlegt de ontwikkelingsinspanning naar een vroeger stadium. Er wordt meer geïnvesteerd tijdens de ontwikkeling (pair programming bij risicovolle onderdelen, tests die vóór de code worden geschreven) om achteraf veel minder te hoeven uitgeven aan correcties en technische schuld. De extra kosten die in het begin lijken te ontstaan, worden later terugverdiend, op het moment dat het herstellen van een fout het duurst is. De vraag is nog hoeveel elke werkwijze werkelijk kost, en onder welke voorwaarden deze rendabel is.

Pair programming, oftewel twee ontwikkelaars inhuren voor één en dezelfde taak: is dat rendabel?

Twee ontwikkelaars die aan dezelfde taak werken, wekken de indruk dat de projectkosten hierdoor stijgen. Dit is de belangrijkste rem op de invoering van pair programming, en het berust op een rekenfout: de veronderstelling dat het produceren van code neerkomt op het schrijven ervan. Het grootste deel van de tijd wordt echter elders besteed: het bedenken van de oplossing, het anticiperen op randgevallen en het opsporen van fouten voordat deze de productie bereiken. Bij pair programming schrijft slechts één ontwikkelaar de code, maar denken beiden na over het ontwerp, en vindt de controle tegelijkertijd plaats, op het moment dat de fout ontstaat in plaats van weken later. Bij complexe of zeer technische projecten vermindert deze aanpak van ontwerpen + continue controle het risico op fouten aanzienlijk, en daarmee ook de directe kosten (tijdrovende correcties omdat de context ontbreekt) en indirecte kosten (vertragingen bij de oplevering, regressies in de code) die daarmee gepaard gaan.

Naast dit voortdurende herlezen is er nog een minder zichtbaar effect: code die door twee personen is geschreven, is nooit alleen bij één persoon bekend. Dit dubbele voordeel is echter niet vanzelfsprekend. De meta-analyse van Hannay, waarin achttien empirische studies zijn samengevat, concludeert dat pair programming „niet overal voordelen oplevert”: het verbetert de kwaliteit maar verhoogt de totale inspanning, en het nut ervan hangt af van de context (bron: The effectiveness of pair programming: A meta-analysis, 2009). Pair programming moet daarom worden voorbehouden aan onderwerpen waar het het meeste oplevert: de 20 % risicovolle taken (betalingen, beveiliging, gegevensmigratie) die 80 % van de moeilijkheidsgraad van het project uitmaken, en de integratie van junior-medewerkers. Om te weten of pair programming zich bij een bepaalde opdracht terugverdient, moet de tijd per opdracht worden bijgehouden en in verhouding tot de marge worden bekeken.

Een senior ontwikkelaar die samen met een junior aan een cruciale factureringsmodule werkt, ontdekt een ontwerpfout voordat deze in productie gaat, en leidt de junior daarbij tegelijkertijd op. Als diezelfde junior alleen aan deze module had gewerkt, zou hij waarschijnlijk code hebben geproduceerd die op het eerste gezicht correct leek, maar die na het eerste incident met een klant volledig opnieuw moest worden geschreven.

Vertraagt het schrijven van tests vóór het programmeren de opleveringen echt?

In het begin wel. Testgedreven ontwikkeling (TDD), waarbij de test wordt geschreven vóór de code die deze moet valideren, kost ongeveer 15 tot 35 % extra tijd in de beginfase van de ontwikkeling. Maar deze extra kosten worden terugverdiend zodra de code langdurig moet meegaan of verder moet worden ontwikkeld: het aantal fouten vóór oplevering daalt met 40 tot 90 % in vergelijking met vergelijkbare teams die geen TDD toepassen, zo blijkt uit onderzoek bij vier industriële teams bij Microsoft en IBM (bron: onderzoek van Nagappan et al.) .

Het voordeel stapelt zich op gedurende de levensduur van de code: elke test fungeert als een vangnet waardoor de code later kan worden aangepast zonder de bestaande code te verstoren, terwijl een team zonder tests steeds trager wordt naarmate de codebasis groeit. In de wetenschappelijke literatuur wordt de balans van TDD echter als „gemengd“ beschreven, afhankelijk van de context, en die nuance is belangrijk: TDD loont vooral bij code die vaak verandert. Bij wegwerpcode, een prototype of een snelle ideeëntest heeft het geen zin om eerst de tests te schrijven.

Bij een module die vaak moet worden aangepast, kan een ontwikkelaar de code zonder aarzelen grondig herschikken: bij het minste afwijkende gedrag mislukt een test onmiddellijk en wijst deze op de regressie. Zonder dit vangnet wordt dezelfde wijziging een gok, en durft het team uiteindelijk de kwetsbare code niet meer aan te raken.

In een dienstverlenend bedrijf is dit eerder regel dan uitzondering. Een groot deel van wat u levert, is bedoeld om lang mee te gaan en verder te worden ontwikkeld: een product dat de klant jarenlang zal gebruiken, een applicatie die u vervolgens in onderhoud neemt (TMA, oftewel het onderhoud en de verdere ontwikkeling van reeds opgeleverde software). Dit is precies het terrein waarop TDD het meest rendabel is.

De werkelijke kosten van een defect en de technische schuld bij een IT-project

Een fout kost des te meer geld naarmate deze later wordt ontdekt. Als deze al in de ontwerpfase wordt gecorrigeerd, is het een kwestie van een paar minuten overleg; als deze pas tijdens de productie wordt ontdekt, vereist dit een analyse, een correctie, regressietests en een herimplementatie, vaak met spoed en onder druk van de klant. Dit principe is al oud en blijft altijd gelden. De precieze vermenigvuldigingsfactoren die er vaak aan worden gekoppeld (6×, 15×, 100×) doen overal de ronde, maar hebben geen verifieerbare primaire bron; het is dus beter om je aan het mechanisme zelf te houden. Twee cijfers zijn daarentegen wel degelijk vaststaand: bijna 50 % van de totale kosten van software gaat naar het opsporen en verhelpen van fouten, waardoor dit de grootste kostenpost in de geschiedenis van de software is (bron: An Ounce of Prevention); en TDD vermindert de foutdichtheid met 40 tot 90 % (Nagappan et al., 2008). Een team dat kwaliteit nastreeft, werkt dus – tegen de intuïtie in – sneller en goedkoper, omdat het niet voortdurend achter zichzelf aan moet lopen. De XP-praktijken behoren tot de methoden die deze vermindering tot stand brengen.

Op 1 augustus 2012 implementeerde de Amerikaanse effectenmakelaar Knight Capital een nieuwe versie van zijn handelssoftware, maar vergat deze op één van zijn acht servers te installeren. Op die server draaide nog steeds een oud stukje code dat nooit was verwijderd; dit werd geactiveerd en verstuurde in hoog tempo een stortvloed aan foutieve orders naar de markten. Zonder tests of veiligheidsmaatregelen om dit te stoppen, verliest het bedrijf in 45 minuten ongeveer 440 miljoen dollar en raakt het bijna failliet. Continue integratie, geautomatiseerde tests en het simpelweg verwijderen van verouderde code – allemaal XP-praktijken – hadden deze orders kunnen onderscheppen voordat ze werden verzonden. (bron: SEC, Release No. 34-70694)

Het bedrag is buitengewoon hoog, maar het patroon herhaalt zich bij elke opdracht. Een bug die tijdens de ontwikkeling niet is opgemerkt, duikt bij de klant op zodra de software in gebruik is. Die moet dan worden verholpen, en niemand had die correctie voorzien of begroot: het is extra werk, puur verlies. Volgens het contract komt dat verlies niet in dezelfde zak terecht.

• Bij een vast bedrag is elke dag die wordt besteed aan het verhelpen van een reeds opgeleverde bug een gewerkte maar onbetaalde dag: deze wordt rechtstreeks van de winst van het project afgetrokken. Bij een vast bedrag van 50 dagen met een marge van 8 dagen zijn 8 dagen onvoorziene herstelwerkzaamheden voldoende om de volledige marge teniet te doen en de opdracht naar een break-even-situatie of zelfs een verlies te brengen.
• Bij regie wordt de correctie aan de klant in rekening gebracht, dus heeft dit geen invloed op de lopende opdracht. Maar de klant ziet de bugs zich opstapelen, verliest zijn vertrouwen en loopt het risico de opdracht niet te verlengen. De werkelijke kosten liggen hier: in toekomstige contracten die verloren gaan, veel meer dan in de uren die aan correctie worden besteed.

Door in een vroeg stadium wat aandacht te besteden aan kwaliteit (peer programming bij risicovolle onderdelen, geautomatiseerde tests, continue integratie) wordt de marge van de opdracht dus juist beschermd, in plaats van aangetast – op voorwaarde dat men de rentabiliteit van een project kan berekenen om dit te controleren.

De invloed van XP op de personeelsbezetting en de winstgevendheid van een project bij een IT-dienstverlener

Naast de kwaliteit van de code pakt Extreme Programming twee welbekende zwakke punten van een ontwikkelingsproject aan: de afhankelijkheid van één enkele expert en de trage ontwikkeling van junior medewerkers. Collectieve verantwoordelijkheid en pair programming zorgen ervoor dat kennis binnen het team wordt verspreid. Een afwezigheid legt het project niet langer stil, en een junior medewerker wordt sneller zelfstandig, waardoor hij of zij gemakkelijker in te zetten is.

Minder afhankelijkheid van specialisten op het gebied van een bepaalde technologie

Zonder XP wordt een vaardigheid of technologie die slechts één persoon beheerst, een knelpunt zodra die persoon afwezig is. De enige ontwikkelaar gaat in de week van de oplevering met verlof, en het team kan dan niet meer zonder risico aan „zijn“ module werken.

Pair programming en collectief eigendom van de code neutraliseren dit risico door kennis continu te verspreiden. Als de ontwikkelaar die een bepaald onderwerp beheerst met verlof gaat, neemt een teamgenoot die al met hem aan dat onderwerp heeft gepair-programmed het stokje over zonder de opdracht te onderbreken. Collectieve verantwoordelijkheid heeft hier een direct effect op het beheer van de middelen: door te garanderen dat elk deel van de code door ten minste twee personen wordt gekend, vangt het onvoorziene omstandigheden (ziekte, verlof) op en beperkt het de kosten van personeelsverloop, aangezien het vertrek van een ontwikkelaar niet langer betekent dat kennis die niemand anders bezit, verloren gaat. (bron: Véronique Messager, Gestion de projet agile, Eyrolles, p. 197-199)

Wat het projectmanagement betreft, is het voordeel duidelijk en meetbaar: het ontbreken van een sleutelfiguur zorgt er niet langer voor dat de opdracht vastloopt of dat de planning uit de hand loopt, omdat de kennis met ten minste één andere persoon wordt gedeeld. Het project blijft op schema ondanks onvoorziene omstandigheden op HR-gebied. Dit mechanisme speelt een rol op het niveau van de opdracht; het mag niet worden verward met de totale bezettingsgraad van het bedrijf, die in de eerste plaats wordt gestuurd door de orderportefeuille en het vullen van de planningen.

Een snellere ontwikkeling van de vaardigheden van juniormedewerkers

Bij pair programming tussen senior en junior vindt er voortdurend kennisoverdracht plaats, juist tijdens het programmeren zelf. De junior schrijft code van betere kwaliteit, die minder vaak door de senior hoeft te worden aangepast, en wordt sneller zelfstandig dan wanneer hij in zijn eentje zou leren. Wat de personeelsbezetting betreft, heeft dit een direct voordeel: een junior die eerder zelfstandig is geworden, kan worden ingezet voor een breder scala aan opdrachten, waaronder veeleisendere opdrachten met een hogere factureerbare waarde.

Zonder pair programming levert een junior die in zijn eentje aan een te gespecialiseerd onderwerp werkt, code op die moet worden herzien, en duurt het lang voordat hij zelfstandig kan werken. Hij moet eerst worden ingewerkt in het project en de technologie, vaak tijdens zijn werkuren, voordat hij aan veeleisende opdrachten kan worden toegewezen. Pair programming verkort dit traject door de leerfase te versnellen.

Deze overdracht brengt echter kosten met zich mee die moeten worden beheerst en niet uit de hand mogen lopen. Concreet betekent dit dat er voor de betreffende kritieke taken tijds- en budgetkaders moeten worden vastgesteld, dat wil zeggen dat ze duidelijk in het werkplan moeten worden afgebakend, zodat de investering in opleiding beheersbaar en overzichtelijk blijft in de voortgangscontrole van de opdracht, in plaats van te vervagen in een diffuse overschrijding.

Wat de opdrachtportefeuille betreft

Wat er op het niveau van een opdracht speelt, is ook terug te zien op portefeuilleniveau. Opdrachten die minder afhankelijk zijn van een senior medewerker met de sleutelcompetenties, en die minder kans lopen op budgetoverschrijdingen omdat ze meer op kwaliteit gericht zijn, zorgen ervoor dat er bij de portefeuillebeoordeling minder projecten in de ‘rode zone’ terechtkomen en dat er minder personeel vastzit aan het redden van projecten. Medewerkers die niet langer bezig zijn met het inhalen van achterstanden, komen weer beschikbaar om factureerbare waarde te creëren.

Er is enige terughoudendheid geboden om de methode niet te overschatten: de goede codepraktijken die XP met zich meebrengt, zijn gunstig voor het bedrijf, maar hun invloed op de marge blijft indirect; ze verminderen een risico zonder een concrete winst te garanderen. De berekening gebeurt per opdracht, waarbij de vooraf geïnvesteerde tijd (het anticiperen op tests, het werken met pair programming aan gevoelige onderdelen, waar de grootste winst te behalen valt) wordt afgewogen tegen de verwachte kosten van een fout die achteraf moet worden hersteld. Alleen door de tijd en de marge per opdracht bij te houden, kan hierover een definitief oordeel worden gevormd, in plaats van een ruwe schatting te maken.

Wanneer moet je voor XP kiezen, en wanneer is het geen goede keuze?

Extreme Programming komt het best tot zijn recht wanneer de behoeften snel veranderen, het team klein is en de tests kunnen worden geautomatiseerd. Het is minder geschikt voor een auditopdracht, puur advieswerk of een eenmalig project. En het contractuele model – op basis van uren of een vast bedrag – verandert de economische verhoudingen van de methode, zonder deze echter ongeschikt te maken.

Is uw context geschikt voor Extreme Programming?

XP komt pas volledig tot zijn recht als aan vier cumulatieve voorwaarden is voldaan. Als aan al deze voorwaarden is voldaan, worden de extra kosten van deze werkwijzen omgezet in rendabele kwaliteit. Als deze voorwaarden niet zijn vervuld, worden deze extra kosten niet terugverdiend en wordt de methode een last.

• Behoeften die gaandeweg veranderen. XP is ontworpen voor projecten waarbij de eisen veranderen: een klant die nog geen vastomlijnd beeld van het product heeft, functies die om de paar maanden veranderen. Juist daar blinkt het uit waar de watervalmethode faalt, omdat het verandering opvangt door middel van korte iteraties in plaats van deze pas aan het einde van het project te ondergaan, wanneer alles al vastligt.
• Een hecht team van 2 tot 20 personen. XP is afgestemd op kleine groepen: 2 tot 12 ontwikkelaars, maximaal een twintigtal. De methode werkt niet bij een te groot team: bij meer dan dat verwateren het pair programming en de collectieve verantwoordelijkheid voor de code, en wordt de directe communicatie – die juist de kracht van de methode vormt – onuitvoerbaar.
• Automatiseerbare tests. XP gaat ervan uit dat er geautomatiseerde unit- en acceptatietests kunnen worden geschreven: programma’s die zelfstandig controleren of een wijziging in de code nog steeds het juiste resultaat oplevert. Deze tests zijn onmisbaar wanneer een ontwikkelaar code herstructureert (refactoring) of zijn werk samenvoegt met dat van het team (continue integratie), omdat ze onmiddellijk aangeven of er iets kapot is gegaan. Tegenwoordig zijn er maar weinig projecten die niet testbaar zijn; maar zonder deze testbaarheid worden veel fouten pas laat ontdekt, tijdens de acceptatietest of in de productie, waar het verhelpen ervan het duurst is.
• Een klant die echt betrokken is. XP is gebaseerd op voortdurende communicatie tussen ontwikkelaars, managers en de klant, om de scope vast te stellen, deadlines af te spreken en functionele tests goed te keuren. De methode vereist een strakke discipline en een constante uitwisseling van informatie. Zonder een aanspreekpunt dat beslissingen kan nemen, loopt de feedbacklus vast en verliest de methode haar drijvende kracht.

Vast tarief of forfaitair bedrag: wat levert het op?

Het contractmodel beïnvloedt wat XP te bieden heeft, en hier moet een onderscheid worden gemaakt tussen drie zaken die vaak door elkaar worden gehaald wanneer men zegt dat „een vast bedrag zich slecht leent voor agile“.

Bij een vast tarief is dit onderscheid doorslaggevend:

• Het contractuele kader. Bij een vast-prijscontract wordt de omvang van het project vooraf vastgelegd, in ruil voor een vaste prijs. De agile-methode in strikte zin, die uitgaat van voortdurend veranderende en onderhandelde behoeften, past daarom slecht binnen dit kader. Dat klopt, en dat is wat we bedoelen als we zeggen dat een vast-prijscontract en agile-werken moeilijk samengaan.
• Engineeringpraktijken. Geautomatiseerde tests, pair programming bij risicovolle onderdelen, continue integratie en refactoring lenen zich daarentegen uitstekend voor een vast-prijscontract. Juist daar leveren ze het meeste op: elke fout die in een vroeg stadium wordt voorkomen, is een dag minder herstelwerk waarvoor niet wordt gefactureerd, en dus een dag winstmarge die behouden blijft. Het contractuele kader legt beperkingen op aan de wendbaarheid, maar niet aan de kwaliteitspraktijken.
• De facturering van pair programming. Bij een vast bedrag koopt de klant een eindproduct, geen uren. Hij ziet niet – en hoeft ook niet te zien – hoeveel mensen aan een taak werken. Het inzetten van twee ontwikkelaars voor een cruciale module is een interne kwaliteitskeuze, die voor de klant onzichtbaar is en geen invloed heeft op de verkoopprijs.

Een eenvoudige manier om het fixed-price-model te verzoenen met de agile-filosofie: behandel elke functionaliteit in de backlog als een volwaardige opdracht, met eigen korte opleveringen en vooraf vastgestelde tests. Zo worden XP-praktijken en een iteratief element geïntroduceerd zonder het hele contract te herzien.

Facturering in Stafiz: omzet uit opdrachtwerk en projectmarge per opdracht.

Bij regie betaalt de klant voor de bestede tijd. Een later verholpen fout kan hem, afhankelijk van de contractvoorwaarden, mogelijk in rekening worden gebracht, waardoor de kwaliteit geen marge oplevert voor de lopende opdracht. Zijn belang ligt elders, en dat is heel reëel:

• Reputatie en verlenging. Betrouwbare opleveringen en weinig bugs in de productie: dat is wat ervoor zorgt dat de opdracht wordt verlengd en dat u wordt aanbevolen. Dat is de sterkste hefboom, die op middellange termijn de grootste invloed heeft op de omzet.
• Prijsbepalingsmacht. Een team dat bekendstaat als betrouwbaar weet betere gemiddelde dagtarieven (TJM) te bedingen voor zijn opdrachten en de daaropvolgende verlengingen. De winst komt voort uit de reputatie die een beter tarief mogelijk maakt: we factureren dagen, geen coderegelingen.
• Inzet van personeel. Een consultant die dankzij een succesvol afgeronde opdracht eerder vrijkomt, kan sneller worden ingezet voor de volgende opdracht, mits dit aansluit bij de commerciële mogelijkheden. Er is echter een duidelijk nadeel: als er geen volgende opdracht in het vooruitzicht is, leidt een snellere afronding zelfs tot een lager aantal gefactureerde dagen.

In welke gevallen moet je er niet aan beginnen?

XP is niet overal zinvol, en het op het verkeerde moment opleggen ervan kost meer dan het oplevert.

• Te groot personeelsbestand. Bij een groot team raakt de kennis versnipperd in plaats van dat er gericht aan vaardigheidsontwikkeling kan worden gewerkt, en worden collectieve activiteiten onbeheersbaar.
• Een klant die pair programming afwijst. Als de klant er niet mee instemt dat twee medewerkers, een senior en een junior, aan dezelfde taak werken, wordt de kostenbeperking een belemmering, met name bij uurtariefberekening, waarbij het aantal gefactureerde personen zichtbaar is.
• Te trage reacties van klanten. Zonder snelle reacties van de klant werkt de feedbacklus niet meer en verliest XP zijn drijfveer.
• Een puur audit- of adviesopdracht. Als er maar weinig code moet worden geschreven, zijn de meeste XP-werkwijzen simpelweg niet van toepassing.

De les die we hieruit kunnen trekken is genuanceerd: zelfs als we niet het volledige raamwerk overnemen, loont het bij vrijwel alle ontwikkelingsopdrachten de moeite om de nuttigste afzonderlijke werkwijzen (geautomatiseerde tests, continue integratie, refactoring) te behouden.

Moet u Extreme Programming toepassen in uw IT-projecten?

De keuze om XP al dan niet in te voeren komt in de eerste plaats neer op een afweging van de marge: wat je vooraf in kwaliteit investeert, bespaar je achteraf aan herstelwerk en technische schuld. Er blijft één vraag over die voor een dienstverlenend bedrijf telt: loont het voor jullie? De enige manier om daar achter te komen, is door het te meten. Door de daadwerkelijk bestede tijd, de marge bij oplevering en de bezettingsgraad per opdracht bij te houden, kun je per opdracht bepalen of pair programming en Test Driven Design hun extra kosten hebben terugverdiend. Dat is de rol van een projectmanagementtool, die de bestede tijd koppelt aan de marge zonder dat je gegevens opnieuw hoeft in te voeren, en zo een intuïtie omzet in een onderbouwde beslissing.