eXtreme Programming

Inleiding

eXtreme Programming (XP) is een jonge ontwikkelmethodiek die uit Amerika is komen overwaaien. Na Object Oriented Development (OOD) en Component Based Development (CBD) zou XP kunnen uitgroeien tot de volgende hype binnen software engineering. Het is zowel een logisch vervolg als een ontwikkelmethodiek die breekt met de principes van de traditionele ontwikkelmethodieken. Zonder twijfel staat XP nog in de kinderschoenen en de methodiek zal wel een aantal jaren nodig hebben om tot wasdom te komen. Eén ding kan echter wel worden gezegd, XP is revolutionair en controversieel.

De belangrijkste bedenkers van XP zijn Kent Beck, Ken Auer, Ward Cunningham en Martin Fowler. Zij omschrijven XP als "a humanistic discipline of software development, based on principles of simplicity, communication, feedback, and courage". Ze behoren tot de groep van mensen die een stuwende kracht zijn achter de innovatie van software ontwikkelmethodieken in het afgelopen decennium; bijvoorbeeld het boek "Design Patterns".

Tot op heden zijn er een handvol bedrijven in Amerika die het gewaagd hebben XP toe te passen. Voor zover bekend, zijn er in Nederland slechts een aantal bedrijven die experimenteren met XP. Het is de vraag of XP zal aanslaan in het overwegend conservatieve Nederlandse IT klimaat, waar men liever gaat voor de winst op de korte termijn, dan te kiezen voor een diepte-investering.

De mythe van de exponentiële kostencurve

Alvorens in te gaan op de dagelijkse werkwijze van XP, is het belangrijk te onderkennen dat de huidige software ontwikkelmethodieken zijn gebaseerd op de veronderstelling dat de kosten om software aan te passen, exponentieel toenemen in de tijd. Met andere woorden, het kost veel meer een fout te herstellen wanneer een systeem eenmaal in gebruik is, dan toen het systeem in ontwerpfase was. In het geval XP wordt beweerd dat met de huidige technologieën deze veronderstelling niet langer hoeft op te gaan. Alle methodieken binnen XP hebben tot doel en zijn gebaseerd op het kunnen aanpassen van code zonder dat dit extra kosten tot gevolg heeft. Een consequentie is dat de noodzaak om eerst een doordacht ontwerp te maken, alvorens over te gaan tot de implementatie, verdwijnt. En daarmee is het ook niet nodig op voorhand een sluitende specificatie beschikbaar te hebben. Dit laatste betreft veelal de meest kritische stap in het hele software ontwikkelproces.

Wat is eXtreme Programming

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 worden door gevoerd, zoals:

Geen van deze `best practices' zijn uniek voor XP. Stuk voor stuk zijn ze decennia geleden al vele malen toegepast. Het blijkt echter dat ze in combinatie resulteren in een stabiele, voorspelbare en flexibele methodiek. Behaalde resultaten waren uitstekend evenals de tevredenheid van klanten, projectleiders en programmeurs. Alvorens hierop dieper in te gaan, eerst een praktijkvoorbeeld uit Amerika.

Het Chrysler C3 Payroll project

In 1997 is de bouw van het salarisuitbetaling systeem van Chrysler stop gezet. Alle code is weggegooid en een team van slecht 10 mensen heeft gebruikmakend van XP het systeem volledig van `scratch' af aan opnieuw gebouwd. Voor 86.000 werknemers diende op verschillende termijnen een salarisafhandeling plaats te vinden. De applicatie die door dit project in Smalltalk werd ontwikkeld omvat circa 1800 klassen en 25000 methoden. Kernwoord in het succesverhaal is dat communicatie centraal heeft gestaan en dat dit met XP mogelijk was.

Op welke wijze drukt XP de kostencurve?

Om te begrijpen hoe het komt dat XP de claim waar kan maken dat de kosten voor ontwikkeling niet exponentieel hoeven toe te nemen, is het belangrijk te zien op welke wijze de belangrijkste ingrediënten van XP samenwerken en elkaar ondersteunen. Hieronder gaan we in op de ingrediënten: feedback, stapsgewijze herschrijvingen (refractoring), 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 er vanuit 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 ten alle tijden 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.

Refractoring

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 gedocume nteerd. 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 unit tests

Binnen XP neemt het schrijven van automatische unit tests een belangrijke plaats in. In eerste instantie maakt het refractoring mogelijk. Maar wat minstens zo belangrijk is de te implementeren functionaliteit op deze manier wordt vastgelegd. Bij het doorvoeren van een uitbreiding worden eerst de noodzakelijke unit tests geschreven of aangepast. Een bepaalde functionaliteit is pas gerealiseerd wanneer alle unit tests, zowel de oude als de nieuwe, voor 100% slagen. Als er in een later stadium tijdens een f unctionele test een `bug' wordt gevonden, is het schrijven van een unit test, die deze bug aan het licht brengt, het eerste wat wordt gedaan.

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 één computer! In deze tijd van schaarste aan goed IT personeel, gruwelt waarschijnlijk iedere software projectmanager bij de gedachte aan pair programming. Toch maakt het een essentieel onderdeel uit van XP zonder welke het niet zo kan werken.

Menig onderzoek (zie "Rapid Development") 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. 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 insp ectie 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 totaal niet onderhoudbaar zijn. Pair programming is daarmee het krachtigste middel tegen de toenemende kostenspiraal.

Daarnaast zijn er nog een aantal andere voordelen 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.

eXtreme Programming vanuit de praktijk

Ondanks de grote belofte die XP lijkt te zijn, worden er vanuit de praktijk ook nadelen onderkend:

  1. 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.
  2. Er is nog relatief weinig ervaring met XP.
  3. 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.
  4. Bovenstaande heeft ook zijn weerslag op de verwachtingen van de opdrachtgever. Deze dienen eveneens aandacht te krijgen zolang XP nog geen bekende ontwikkelmethodiek is.
  5. 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.
  6. 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 uitgangsituatie 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, onstaat een systeem waar niet door de gebruikers over is nagedacht.
  7. Is XP te gebruiken om standaard pakketten te ontwikkelen? Kan XP ook overweg met legacy code?

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

Conclusie

Resumerend, XP belooft dat het projectrisico's reduceert, dat bedrijfsmatige veranderingen soepel worden opgevangen, en dat het de productiviteit verbetert gedurende de gehele life-cycle van een systeem. Bovendien wordt gesteld dat door in teams te werken het echt leuk wordt om software te ontwikkelen.

Referenties

Kent Beck - Extreme Programming Explained: embrace change, Addison-Wesley, 2000
Martin Fowler - Refactoring: improving the design of existing code, Addison-Wesley, 1999
Steve McConnell - Rapid Development: Taming Wild Software Schedules, Microsoft Press, 1996
XP websites: www.xprogramming.com en www.extremeprogramming.org.

XP en CMM (Capability Maturity Model)

In de afgelopen decennia zijn er twee hoofdrichtingen geweest waarin gezocht is naar oplossingen voor de software crisis. De ene richting zocht het vooral in het ontwikkelen van technieken. Hierbij moet gedacht worden aan Object Oriented Development (OOD), Component Based Development (CBD), Design Patterns, maar ook aan ontwikkelingen als de Unified Modeling Language (UML). De andere richting heeft de oplossing vooral gezocht in de stroomlijning van het software proces, met aan het hoofd daarvan het Capa bility Maturity Model (CMM).

CMM is een model om de volwassenheid van een bepaald software ontwikkelproces te beoordelen. In Amerika staan dergelijke "Models", waarmee tot een hoge mate van kwaliteit kan worden gekomen, hoog aangeschreven. CMM kent 5 niveaus van volwassenheid, waarbij er voor ieder niveau bepaalde voorwaarden worden gesteld. Het toepassen van een bepaalde software ontwikkelmethodiek kan de volwassenheid van een bepaald software ontwikkelproces bevorderen. Hieronder staat kort beschreven wat XP zegt over ie der van de CMM niveaus.

  1. Voor het initiële niveau van CMM heeft XP een planningsmethodiek en de rol van de projectleider vastgelegd. Verder stelt XP dat het, mede door het toepassen van werken in koppels, niet afhankelijk is van 1 zeer getalenteerde programmeur.
  2. XP kent een grote verzameling van regels, welke de basis voor het tweede CMM niveau is. Er worden binnen XP een viertal metrics bijgehouden: middelen, bereik, kwaliteit en tijd. Training en coaching worden ook gedefinieerd.
  3. XP voorziet voor het derde niveau: de voortgang van het project, de benodigde input, standaarden, procedures, verificatie mechanismen en uitgangskriteria. De metrics geven een duidelijk inzicht in de actuele staat van het project.
  4. Voor het vierde niveau, het beheersbare niveau, kan worden gezegd dat XP een zeer sterke nadruk legt op het beheersen van de kwaliteit van de software en het software proces.
  5. Er zijn in de wereld niet veel bedrijven die het vijfde niveau, het optimaliserende niveau hebben bereikt (12 bedrijven in totaal zoals NASA). Het is een niveau wat niet makkelijk bereikt kan worden, maar door de best-practices die XP tot in het extreme doorvoert toe te passen, zou het vijfde niveau kunnen worden bereikt.

CMM heeft onderander geleidt tot het V-model dat van de gebruikersspecificatie via het ontwerp afdaalt naar de codering om vervolgens weer omhoog te kruipen via de Alpha, Beta en Gamma tests. Dat dit model zijn beperkingen heeft, blijkt uit de vele iteratieve varianten die er van zijn afgeleid. De jongste in deze stroming is het "Rational Unified Process" (RUP). Ondanks de verschillende ontwikkelingen zijn veel van de problemen gebleven en is het maar de vraag of de huidige belangstelling voor architectuur ("the new A-word") een uitkomst zal bieden.

Hoewel XP gestoeld is op recentelijke inzichten, zoals Design Patterns, maakt het ook korte metten met sommige principes uit de traditionele ontwikkelmethodieken. Sommige ideeën van XP worden ook gevonden bij RUP en het "Just In Time Software Process". In zekere zin kan ook gezegd worden dat XP doorgaat daar waar Rapid Prototyping ophoud.