Extreme programming

EXtreme Programming (ook wel XP genoemd) is een softwareontwikkelingsmethodiek en een vorm van agile-software-ontwikkeling.

De belangrijkste grondleggers van eXtreme Programming zijn Kent Beck, Ken Auer, Ward Cunningham, Martin Fowler en Ron Jeffries tijdens het Chrysler Comprehensive Compensation System (C3) project in 1996. Zij omschrijven XP als "a humanistic discipline of software development, based on principles of simplicity, communication, feedback, and courage" (vrij vertaald: "een humanistische discipline van software-ontwikkeling, gebaseerd op de beginselen van eenvoud, communicatie, feedback, en moed").

Ontwikkelprincipes

XP is een methodiek die vooral geschikt is voor projecten waarbij de exacte applicatie-eisen niet bij voorbaat vastliggen. EXtreme Programming dankt zijn naam aan het feit dat een aantal beproefde ontwikkelprincipes tot in het extreme wordt doorgevoerd. Voorbeelden zijn:

Als het goed is dat ontwikkelaars code bij elkaar reviewen, doe het dan voortdurend: ontwikkel alle software in koppels. Met andere woorden, twee mensen achter één computer.
Als testen goed is, schrijf dan unit tests en voer ze iedere keer uit als er ook maar een regel code is veranderd.
Als ontwerpen goed is, maak het dan onderdeel van ieders dagelijks werk: verbeter het ontwerp stapsgewijs, zodra de noodzaak zich voordoet.
Als eenvoud goed is, houd dan het ontwerp zo simpel mogelijk. XP werkt veel met het KISS (Keep It Short & Simple)-principe.
Als architectuur zo belangrijk is, laat dan iedereen werken aan het ontwikkelen van de architectuur.
Als integratietesten belangrijk is, integreer de code dan zo vaak mogelijk, liefst meerdere keren per dag.
Als korte iteratieslagen goed zijn, maak ze dan werkelijk heel erg kort: seconden, minuten, uren, in plaats van weken, maanden, jaren.

Geen van deze `best practices' zijn uniek voor XP. Stuk voor stuk zijn ze decennia geleden al vele malen toegepast.

Best practices

De optimale kracht van XP komt voort uit het in samenhang toepassen van twaalf best practices, doordat deze elkaar versterken. Elke andere softwareontwikkelmethode zal ook voordeel hebben bij het toepassen van één of meerdere genoemde best practices.

XP is gebaseerd op de volgende twaalf best practices:

gebruik een zo simpel mogelijk ontwerp dat werkt;
schrijf eerst de testcode ('unit test') voordat je functionaliteit codeert (TDD, Test-driven development);
continue herstructurering ('refactoring') van de programmacode;
continue integratie van alle programmacode;
iedere ontwikkelaar heeft gelijke rechten over alle programmacode;
iedere ontwikkelaar gebruikt dezelfde codeerstandaard;
programmeurs werken in paren ('pair programming');
de klant is onderdeel van het ontwikkelteam en moet dus continu voor vragen beschikbaar zijn;
de software wordt in een vaste regelmaat in releases van beperkte omvang aan de klant opgeleverd voor beoordeling;
ontwikkelaars plannen aan de hand van kleine brokjes functionaliteit ('user stories');
alle teamleden (ontwikkelaars en de klant) delen een gemeenschappelijk beeld van het systeem ('metafoor');
overwerken is een uitzondering.

Elementen

XP claimt dat de kosten voor ontwikkeling niet exponentieel hoeven toe te nemen. Dit poogt ze te bereiken middels feedback, stapsgewijze herschrijvingen (refactoring), automatische unit testen, eenvoud van ontwerp en het werken in koppels (pair programming).

Feedback

XP stelt dat uiteindelijk alles om code draait bij het maken van software. XP gaat ervan uit dat deze code dusdanig klantspecifiek is, dat de klant zo dicht mogelijk bij het ontwikkeltraject dient te staan. Bij XP wordt ontwikkeld op basis van testcases die de klant samenstelt. Geen functionele specificaties; er zal enkel worden gecodeerd wat de klant wil dat er uit de testcases moet komen. Niet meer en ook niet minder. Bij voorkeur dient een toekomstige gebruiker te allen tijde aanwezig te zijn, zodat er voor gezorgd kan worden dat de applicatie exact dat wordt wat de klant wenst. Om dit proces zo goed mogelijk te laten verlopen, werkt XP met korte ontwikkelcycli, waarin steeds een aantal geselecteerde testcases wordt geïmplementeerd tot een werkend systeem. Aan het eind van iedere cyclus kan de klant het systeem beoordelen en desnoods de ontwikkeling bijsturen.

Refactoring

Een belangrijke techniek waarmee XP zich verder onderscheidt van traditionele ontwikkelmethodieken is refactoring: het herschrijven van code in kleine precies afgemeten stapjes zonder dat daarbij de zichtbare functionaliteit wordt aangetast. Refactoring voegt kortom niets aan de functionaliteit toe, maar het verbetert de eenvoud van het ontwerp. Door de herschrijfstapjes regelmatig uit te voeren is het overall effect vaak verbluffend. Er zijn inmiddels een zeventigtal herschrijfregels ontdekt en gedocumenteerd. Ze dragen welluidende namen zoals "Introduce Null Object", "Replace Temp with Query", en "Replace Conditional with Polymorphism". De randvoorwaarde voor het succesvol toepassen van refactoring is dat er unit tests voorhanden zijn, die automatisch uitgevoerd kunnen worden na iedere herschrijfstap om zeker te stellen dat de functionaliteit niet is veranderd. Voor Smalltalk bestaat er inmiddels een Refactoring Browser waarmee herschrijfregels automatisch kunnen worden toegepast, zonder dat de gebruiker zich al te zeer om de correctheid hoeft te bekommeren. Refactoring wordt vaak gebruikt als voorbereiding op het doorvoeren van een uitbreiding of verandering van de functionaliteit.

Automatische unittests

Binnen XP neemt het schrijven van automatische unittests een belangrijke plaats in. Het schrijven van deze unittests wordt gedaan voordat begonnen wordt aan het daadwerkelijke programma. In Test-Driven development (TDD) wordt dit: de programmeur maakt één of twee testen, schrijft een stuk programma, maakt een aanvullende testcase, herwerkt het programma tot deze nieuwe test passeert, ontwerpt weer een nieuwe test etc.

Het voordeel hiervan is dat de programmeur verplicht wordt na te denken over de functionaliteit en de uitzonderingen waar zijn programma rekening mee dient te houden, dus eerst denkt over wat het programma moet doen en dan pas hoe het programma zal werken. De tests leggen als het ware de gevraagde functionaliteit vast. Belangrijk is dan ook dat elk programma maar net voldoende functionaliteit bevat om de test te laten slagen. Indien alle tests slagen voldoet het programma dus precies aan de eerder gedefinieerde eisen (deze zijn immers gedefinieerd in de geschreven en geslaagde unittests).

Wanneer refactoring nodig blijkt te zijn, vormen de al geschreven unittests een garantie dat wijzigingen geen ongewenste neveneffecten veroorzaken in de werking van het programma.

Mocht het nodig zijn om het programma uit te breiden met nieuwe functionaliteit, wordt wederom als eerste begonnen met het schrijven van nieuwe unittests welke de nieuw te schrijven functionaliteit definiëren. Deze nieuwe functionaliteit is pas gerealiseerd als zowel de nieuwe als de oude unittests allemaal slagen.

Als er in een later stadium tijdens een functionele test een 'bug' wordt gevonden, is het schrijven van een unit test, die deze bug aan het licht brengt, het eerste wat wordt gedaan. Een 'bug' is dus eigenlijk geen fout in het programma, wel het ontbreken van de geschikte test.

Eenvoud van ontwerp

Wil een systeem makkelijk te veranderen zijn, dan dient het ontwerp zo eenvoudig mogelijk te zijn. Dit is makkelijker gezegd dan gedaan. De traditionele ontwikkelmethodieken hebben ons geleerd vooruit te denken en bij het ontwerp steeds na te denken over functionaliteit die misschien in de toekomst moet worden gerealiseerd. Maar deze methodieken gaan uit van de veronderstelling dat de kosten voor veranderingen exponentieel toenemen. Daarom hamert XP er op steeds het meest eenvoudige ontwerp te kiezen om de functionaliteit, die nu gerealiseerd moet worden, mogelijk te maken. Eventuele toekomstige uitbreidingen kunnen met XP namelijk zonder de gebruikelijke extra kosten worden doorgevoerd. Tevens blijkt dat bij de realisatie van een doordacht ontwerp maar al te vaak dat het eigenlijk niet (meer) voldoet. Dit kan enerzijds gebeuren doordat tijdens de analyse en het ontwerpen bepaalde details over het hoofd zijn gezien of anderzijds doordat de eisen zijn bijgesteld. Bij XP loopt ontwerp niet voorop, maar volgt het de code.

Pair programming

Eén van de meest extreme en controversiële aspecten van XP is het voorschrift dat alle ontwikkeling gedaan wordt in koppels: twee mensen achter een computer.

Onderzoek heeft aangetoond dat peer-review en code-inspectie de krachtigste wapens zijn tegen bugs, veel krachtiger zelfs dan systematisch testen. Toch worden deze technieken maar mondjesmaat toegepast en roepen ze vaak grote weerstand op bij de programmeurs zelf, en bij managers die bang zijn voor een stijgend aantal arbeidsuren. Door af te dwingen dat alle software-ontwikkeling in koppels wordt uitgevoerd, die bovendien regelmatig van samenstelling wisselen, ontstaat er een collectief 'eigendomsgevoel' en worden peer-review en code-inspectie als van nature onderdeel van het normale software proces. Het gevolg is dat het uiteindelijk opgeleverde systeem niet langer bestaat uit een met 'touwtjes' aan elkaar gebonden verzameling van idiosyncratische stukjes code, die slecht onderhoudbaar zijn.

Daarnaast is er nog een ander voordeel van deze manier van werken: er zijn altijd minstens twee mensen die ieder stuk code volledig doorgronden. Het inwerken van nieuwe mensen gaat als vanzelf. Er vindt een voortdurende training-on-the-job plaats. RSI zal met deze ontwikkelmethodiek minder kans krijgen werknemers te vellen, doordat er afgewisseld kan worden. Het moge duidelijk zijn dat het ogenschijnlijke verlies aan productiviteit zich op deze manier dubbel en dwars terugbetaalt.

Iteratie

Een gemiddelde iteratie van XP duurt twee weken, alhoewel dit volgens extremeprogramming.org kan variëren van één tot drie weken. De cyclus van XP bestaat uit 6 fases: Exploration, Planning, Iterations to Release, Productionizing, Maintenance and Death.

Nadelen

Er worden vanuit de praktijk ook nadelen van XP onderkend:

De belangrijkste is misschien wel dat het niet eenvoudig is XP in te voeren. Omdat de verschillende elementen van XP zo op elkaar ingrijpen, wordt er alleen een goed resultaat bereikt als ze allemaal worden toepast.
Er is nog relatief weinig ervaring met XP.
Code ontwikkelen met enkel oog voor de wensen van de gebruikers kan problemen geven wanneer een einddoel in het oog moet worden gehouden. Het einddoel kan ondersneeuwen met de tijdelijke doelen van de te realiseren iteraties. Dit leidt gemakkelijk tot uitloop van de oplevering van het uiteindelijke systeem. Veel aandacht van de projectleider is vereist om dit nadeel van XP te managen.
Bovenstaande heeft ook zijn weerslag op de verwachtingen van de opdrachtgever. Deze dienen eveneens aandacht te krijgen zolang XP nog geen bekende ontwikkelmethodiek is.
Niet elke ontwikkelaar is een teamspeler. Om volgens de principes van XP te werken zal zorgvuldig een team moeten worden samengesteld. Twee junior ontwikkelaars bij elkaar of twee eigenwijze ontwikkelaars zullen niet de beoogde programmatuur opleveren.
Er dienen strakke afspraken gemaakt te worden omtrent de gebruikersparticipatie om enige vorm van vrijblijvendheid in de kiem te smoren. Het schrijven van unit test moet de uitgangssituatie zijn en blijven voor het ontwikkelen van programmatuur. Wanneer gebruikers niet in staat zijn geweest unit tests te schrijven en ontwikkelaars toch doorgaan met ontwikkelen, ontstaat een systeem waar niet door de gebruikers over is nagedacht.
Verwachte problemen bij het ontwikkelen van standaardpakketten en in combinatie met legacy-code.

Er is een aantal zeer succesvolle projecten bekend, maar er wordt betwijfeld of deze projecten succesvol waren vanwege de kwaliteiten van de mensen die er aan mee deden of vanwege de kwaliteit van XP.

Externe links