Niet alles gaat snel met Extreme Programming
Extreme programming is een softwareontwikkelingsproces dat rekening houdt met snel veranderende omstandigheden zoals de wisselende samenstelling van het ontwikkelingsteam, de veranderende wensen van de klant en de daaruit volgende aanpassing van de software. Om snel zo veel mogelijk economische waarde voor de klant te leveren, gaat XP uit van vier principes: snelle feedback, eenvoud, moed en kwaliteit. Een ontwikkelingsteam bestaat uit maximaal tien ontwikkelaars, die intensief met elkaar en de klant samenwerken en hun kennis onderling delen. Elke korte iteratie ( een ontwikkelingscyclus van één tot vier weken) levert het team een zo eenvoudig mogelijk en degelijk getest product op, dat het stukje bij beetje uitbreidt en herstructureert als aanvullende functionaliteit gewenst is. Steeds meer bedrijven beginnen aan de invoering van deze vrij recente ontwikkelingsmethodiek. De werkwijzen van XP leveren ontwikkelaars veel houvast en ze blijken zich thuis te voelen in XP-projecten. De methodiek blijkt echter ook een aantal haken en ogen te hebben, met name op het organisatorische vlak. Er zijn bijvoorbeeld in Nederland nog weinig bedrijven die alle werkwijzen die XP beschrijft, gebruiken. Een ander punt is dat managers een goed zicht hebben op hetgeen het team op korte termijn produceert, maar het uiteindelijke product is niet op voorhand duidelijk. Verder kan binnen een iteratie heel wat geherstructureerd (refactoring) worden, hetgeen nogal wat flexibiliteit vraagt van de bij het product betrokken partijen. Ten slotte gaat XP niet uit van specialisten, maar van een team van generalisten die verscheidene rollen vervullen. Wat te doen met de specialisten in de organisatie? Specialismen Een van de specialismen waarbij dit problemen kan geven, is dat van het gebruikersinterface-ontwerp. Het ontwikkelen van dat deel van de software waar de gebruiker mee interacteert, is van oudsher een gebied waar bruikbaarheidsexperts (usability engineers) zich mee bezig houden. XP kent echter geen technieken voor ontwerpen van gebruikersinterfaces. De aanpak besteedt er geen aandacht aan. De rechtvaardiging hiervoor is dat XP een ‘minimale’ aanpak is, die voorschrijft alleen te doen wat echt noodzakelijk is om waarde voor de klant (business value) te creëren. Bruikbaarheid (usability) kan echter een belangrijke economische waarde hebben en steeds meer bedrijven ondervinden dat aan den lijve. Een voorbeeld: Waarom komen mensen terug op een website? Volgens onderzoek van Forrester zijn de topvier-factoren: goede inhoud, goede bruikbaarheid, hoge download-snelheid en regelmatige vernieuwing. Andere factoren zijn relatief onbelangrijk. Over het algemeen laat de bruikbaarheid van systemen te wensen over. Hoe is bruikbaarheid in te passen en te waarborgen in de XP-aanpak? Zoals gesteld, kenmerkt XP zich door intensieve samenwerking en korte iteraties. Door samenwerking op één locatie, kan het team de behoefte aan papieren documentatie minimaliseren, waardoor het sneller kan werken. In de filosofie van XP gebruikt het team slechts modellen om vast te leggen wat nodig is en met de precisie die nodig is om tijd te sparen, kwaliteit te verhogen of het oplossen van het probleem te vereenvoudigen. Rolverdeling XP kent twaalf werkwijzen en een rolverdeling. Elke projectdeelnemer, behalve klant en projectmanager, kan verscheidene rollen vervullen. De belangrijkste rollen zijn: klant, programmeur, projectmanager, XP-coach en tracker. Vanuit een bepaalde rol brengt een persoon zijn ervaring in en draagt deze ook over. Degene met de klantrol is verantwoordelijk voor het opstellen van en prioriteiten geven aan wensen in de vorm van gebruiksverhalen (user stories). Dit zijn concrete, quasi-realistische scenario’s; plausibele ‘verhaaltjes’ over het gebruik van het voorgestelde systeem. De rol van programmeur omvat het ontwerpen, programmeren, herstructureren en testen. De projectmanagersrol is faciliterend. Deze zorgt voor goede werkomstandigheden en schermt het team af van organisatorische zaken. De XP-coach draagt zorg voor inpassing van de twaalf XP-werkwijzen in het project. De trackersrol tot slot waarborgt de werkwijzen en belangrijke productkenmerken door actief te meten aan bekende knelpunten in het project. XP dankt haar naam aan haar principes en werkwijzen die ver worden doorgevoerd. Van de twaalf werkwijzen zijn (voor het inpassen van bruikbaarheid) de drie belangrijkste: de planning game, pair programming en test-first programming. De planning game is een onderhandeling tussen klant en programmeurs voorafgaand aan een iteratie. Hierin bedenkt de klant nieuwe gebruiksverhalen, schatten de programmeurs de voor de bouw benodigde tijd en plant het team de belangrijkste gebruiksverhalen voor de komende iteratie. Pair programming houdt in dat programmeurs altijd samenwerken aan een taak. Kennis over het systeem moet namelijk bij verschillende personen aanwezig zijn voor het geval het ontwikkelingsteam van samenstelling verandert. Test-first programming houdt in dat programmeurs voor elke functionele eenheid (unit) die zij willen bouwen, eerst een automatische unit-test programmeren. Daarnaast bedenkt de klant van tevoren acceptatiecriteria voor elk gebruiksverhaal. Programmeurs helpen de klant deze criteria om te zetten in geautomatiseerde acceptatietests. Hogere kosten Het ontwerpen van een bruikbare gebruikersinterface is een onderdeel dat gedurende het gehele softwareontwikkelingstraject aandacht behoeft, van analyse tot testen. Bruikbaarheid, als vertaling van ‘usability’, laat zich samenvatten in drie factoren: efficiëntie, effectiviteit en tevredenheid van de gebruiker. Wat moet er gebeuren in een ontwikkelingstraject om bruikbaarheid te waarborgen? Traditioneel werken bruikbaarheidsexperts aan het interface-deel, terwijl ontwikkelingsteams de producten ontwikkelen. Meestal beginnen bruikbaarheidsspecialisten bij het ontwerpen van een gebruikersinterface – na een probleemanalyse – met het in kaart brengen van technische randvoorwaarden. Daarna volgt een analyse die resulteert in een model van de taken die de gebruiker uitvoert, de objecten die hij daarbij manipuleert en een beeld van de gebruikersgroep. Op basis hiervan maken bruikbaarheidsexperts een eerste schets van de interface, waarna het ontwikkelingsteam een prototype kan maken. Testen van bruikbaarheidsaspecten gebeurt onder leiding van de experts en leidt tot ontwerpaanpassingen in de volgende iteratie van ontwikkeling. Bij het ontwerpen denken de experts meestal eerst goed na over interactie met het gehele systeem en maken ze een aantal modellen en een ontwerp. Bruikbaarheid is namelijk iets dat voor het gehele systeem geldt. Zo is de responstijd een eigenschap die in de gehele applicatie van belang is. Consistent uiterlijk en werking is een ander voorbeeld. Bruikbaarheidstesten kunnen de vorm hebben van een expert die het systeem beoordeelt. De grootste onvolkomenheden en voor de hand liggende problemen worden dan gevonden. Om meer onverwachte problemen te vinden, werkt een bruikbaarheidsspecialist meestal met ‘echte’ gebruikers. Dit kan bijvoorbeeld door in een gecontroleerde omgeving enige tijd hun handelingen te observeren of hen na een periode van werken met het systeem een enquête te laten invullen. XP daarentegen zegt niets over bruikbaarheid. In de praktijk bestaat zelfs een algemeen gebrek aan aandacht voor bruikbaarheid, ook bij het gebruik van andere ontwikkelingsmethoden dan XP. Vele bedrijven die websites maken, hebben geen bruikbaarheidsexpert in dienst en bouwen sites die meetbaar onbruikbaar zijn. Bij het maken van bruikbare software komen naast kennis van software engineering allerlei psychologische en ergonomische aspecten kijken. Wat echter gebeurt, is dat ontwikkelaars zonder de benodigde kennis van deze aspecten de interface gaan ontwerpen en bouwen. In het geval van websites zijn het vaak grafisch ontwerpers die zich te buiten gaan aan de mogelijkheden van hulpmiddelen als Flash. Beiden nemen niet de benodigde maatregelen om de bruikbaarheid van de software te waarborgen. Dit is een rol die de bruikbaarheidsspecialist kan vervullen. Organisaties zien de kosten van slecht bruikbare software vaak niet. Slecht bruikbare software is moeilijk te leren en te gebruiken. Voor een interne applicatie betekent dit hoge kosten voor training en lage productiviteit van de medewerkers. Zichtbaarder is dit bij webapplicaties: websurfers gaan weg als ze niet tevreden zijn of niet snel genoeg kunnen bereiken wat ze willen. Bruikbaarheid is een eigenschap van software die kosten kan besparen en inkomsten kan genereren. Samenwerking Het is dus van belang de bruikbaarheid van softwareproducten te waarborgen, en bruikbaarheidsexperts spelen daarbij een belangrijke rol. De vraag is hoe dit binnen XP is vorm te geven, ervan uitgaande dat er reeds bruikbaarheidsspecialisten aanwezig zijn binnen de organisatie. Er is samenwerking tussen deze experts en de ontwikkelaars nodig. XP is een goede voedingsbodem voor samenwerking. Het verschil tussen de werkwijzen van een XP-team en die van bruikbaarheidsexperts kan echter enkele knelpunten opleveren. Traditioneel bevinden zij zich vaak in verschillende teams en verloopt de samenwerking moeizaam. Ontwikkelaars hebben meestal een meer functionele aanpak, terwijl bruikbaarheidsspecialisten denken over uiterlijke en menselijke aspecten. Dit is een knellend probleem bij technieken als Active Server Pages of Java Server Pages. Omdat hierbij de functionaliteit en vormgeving in hetzelfde bestand staan, vereisen deze technieken op één plek de vaardigheiden van beide partijen. Ontwikkelingsprocessen voor gebruikers-interfaces gaan traditioneel uit van het maken van veel modellen. Deze documenten worden niet alleen gemaakt voor het vastleggen van afspraken, maar ook voor het overdragen van kennis. Een XP-team echter, wisselt kennis niet uit via documentatie, maar door middel van zeer intensieve samenwerking. Verder probeert XP te voorkomen dat het team lang na moet denken over globale zaken (globaal over de applicatie). Het team maakt niet eerst een groot ontwerp, maar begint met ontwerpen van een klein stuk functionaliteit, bouwt dit en breidt zo in korte iteraties de functionaliteit uit. Men is niet bang om de software te moeten herstructureren bij voortschrijdend inzicht. Het punt met bruikbaarheid is dat het een globale eigenschap is. De gebruiker moet bijvoorbeeld op een consistente manier kunnen werken in alle delen van het systeem. Om deze reden beschouwen bruikbaarheidsexperts graag de applicatie als geheel, alvorens te beginnen met de bouw. Gezien de globale aard van bruikbaarheid kan herstructurering in een deel van de interface vervelend zijn, want dit kan verstrekkende gevolgen hebben op vele plaatsen elders in de interface. Tot slot is er het eerder genoemde punt waardoor een bruikbaarheidsexpert lastig past in een XP-project: XP gaat niet uit van specialisten, maar van een team van generalisten die meer dan één rol vervullen. Coach Een manier om met deze knelpunten om te gaan is de bruikbaarheidsexpert in XP de rol van ‘bruikbaarheidscoach’ te geven. Deze coach brengt zijn kennis over bruikbaarheid in en draagt deze over op anderen. Iemand die deze rol vervult, werkt aan interface-ontwerp, maar doet ook mee aan het programmeerwerk, wat gebruikers-interfaces betreft. De bruikbaarheidscoach is dus generalistischer dan een traditionele bruikbaarheidsspecialist. Is er geen bruikbaarheidsspecialist aanwezig, dan zal een ontwikkelaar zich moeten specialiseren in bruikbaarheid om deze rol te kunnen vervullen. Door ook aan de andere activiteiten van XP deel te nemen, waarborgt de bruikbaarheidscoach de bruikbaarheid op alle noodzakelijke plekken in het proces. Hij brengt zijn ontwerpvaardigheid in en draagt de gedachten achter de interface over op andere ontwikkelaars. Daarbij leert hij snel wat de technische implicaties zijn van een ontwerp. In de ‘planning game’ bevraagt hij de klant om de gebruikerstaken te achterhalen en te zorgen dat de gebruikers in voldoende mate afdekken. Als de ontwikkelaars objectmodellen schetsen, assisteert hij bij het schetsen van gebruikers-interfaces. Tijdens een iteratie werkt de bruikbaarheidscoach samen met de ontwikkelaars aan de implementatie van de gebruikersinterface en zorgt hij ervoor dat bruikbaarheidsrichtlijnen worden nageleefd. Bruikbaarheid van software is meer dan de gecombineerde bruikbaarheid van alle geïmplementeerde gebruiksverhalen; de bruikbaarheidscoach bewaakt de consistentie over de gehele applicatie. In lijn met de XP-filosofie mag niemand tussen de klant en programmeur in staan. Bruikbaarheidsexperts staan traditioneel echter juist vaak op de plek tussen klant, programmeur en gebruiker. De bruikbaarheidscoach daarentegen treedt niet op als tussenpersoon, maar als adviseur. Zowel de klant, de programmeurs als de gebruikers kunnen deze coach om adviezen en meningen vragen. Hij helpt de klant bruikbaarheidscriteria af te spreken en te controleren en hij betrekt de gebruikers bij de feedback. Het waarborgen van bruikbaarheid is van belang en de inzet van een bruikbaarheidscoach blijkt een praktische manier om dat te doen. Drs. Rob Maijers en ir. Willem van den Ende zijn beiden werkzaam als adviseur bij Software Engineering Research Centre SERC (www.serc.nl) te Utrecht. Maijers (maijers@serc.nl) ondersteunt organisaties op het gebied van de mens/machine-interactie en intranet-/internettechnologie. Van den Ende (ende@serc.nl) coacht teams bij het toepassen van XP. Planning game Periodiek onderhandelingsspel tussen klanten en ontwikkelaars. De klanten bepalen welke functionaliteit ze wanneer willen, de ontwikkelaars bepalen hoeveel tijd het maken van die functionaliteit kost. Test First Programming Voordat er functionaliteit mag worden geprogrammeerd, moet daarvoor eerst een automatische (unit)test worden geprogrammeerd. Refactoring Stapsgewijs herstructureren van code, zonder de functionaliteit te veranderen. Dit wordt vaak gedaan alvorens functionaliteit toe te voegen, zodat het ontwerp eenvoudig kan blijven (simple design). Collective ownership Alle code mag door elke ontwikkelaar worden aangepast. Niemand is eigenaar van delen van het systeem. Pair programming Alle productiecode wordt geschreven door twee ontwikkelaars die samen aan een werkstation werken. Ontwikkelaars zijn wel individueel verantwoordelijk voor een taak, maar vragen iemand anders bij de realisatie van die taak te helpen. Coding standards Naamgeving en dergelijke worden op een eenduidige manier toegepast, zodat alle ontwikkelaars elkaars code kunnen lezen. On site customer Vertegenwoordigers van de klant en de gebruikers zijn continu aanwezig in de werkruimte van de ontwikkelaars. Metaphor Door gebruik te maken van een metafoor kunnen ontwikkelaars en klanten op een eenduidige manier over het systeem communiceren. Een metafoor is een elektronische tegenhanger van een object uit de werkelijke wereld (denk bijvoorbeeld aan de prullenbak in Windows). Simple design Bouw alleen die zaken die nuttig zijn voor de klant, en bouw die op een zo eenvoudig mogelijke, nette manier. Continuous integration Als de ontwikkelaars een taak hebben afgerond en getest, stellen ze het resultaat ter beschikking door het toe te voegen aan het geheel. Dit gebeurt verscheidene malen per dag. Small releases Geef de gebruikers regelmatig een klein stukje nieuwe functionaliteit. Er moet voor hen wel een zichtbaar verschil zijn met de vorige release. Sustainable pace Werk in een tempo dat lang is vol te houden. Overwerken mag maximaal twee weken achter elkaar.