XP Extreme Programming Een introductie Algemene informatie voor medewerkers van SYSQA B.V.
Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING...3 2. EXTREME PROGRAMMING...4 3. FASERING...5 4. KENMERKEN...6 5. XP EN ANDERE METHODES...9 6. LITERATUURVERWIJZINGEN...10
Organisatie SYSQA B.V. Pagina 3 van 10 1. Inleiding De traditionele systeemontwikkelmethodes zoals SDM I, SDM II en LAD hebben, zo bleek in de praktijk, een aantal nadelen. Zo wordt de fasering als rigide ervaren, is de doorlooptijd vaak langer dan gewenst, zijn de kosten hoog en is de gebruikersparticipatie te laag. Ook worden riskante activiteiten, zoals de integratie van modules en een load test, pas in een laat stadium uitgevoerd. Als gevolg hiervan zijn er aan het einde van de 20 e eeuw een aantal systeemontwikkelmethodes ontstaan die tegemoetkomen aan deze tekortkomingen. De methodes worden gekenmerkt door een hoge gebruikersparticipatie en het incrementeel en iteratief ontwikkelen. Met dit laatste wordt bedoeld dat er meerdere ontwikkelrondes na elkaar plaatsvinden. In plaats van ernaar te streven in één keer het systeem te bouwen worden meerdere versies gemaakt en steeds verbeterd en verfijnd. Deze methodes staan bekend als Iterative and Incremental Development (IID). Verwant aan IID zijn de zogenaamde agile methodes, waarbij agile staat voor snel en flexibel reagerend op veranderingen. Deze agile methodes zijn behalve iteratief (en incrementeel) ook gebaseerd op evolutionaire ontwikkelmethodes. Daarnaast speelt flexibiliteit een grote rol, het vermogen om het systeem tijdens de ontwikkeling snel aan te passen aan veranderende eisen. Agile ontwikkelmethodes zijn dus iteratief, evolutionair en flexibel.
Organisatie SYSQA B.V. Pagina 4 van 10 2. Extreme Programming Binnen de groep van agile ontwikkelmethodes (iteratief, evolutionair en flexibel) behoort extreme programming (XP), samen met Scrum, tot de meest toegepaste methodes. XP is zelfs de bekendste van de agile ontwikkelmethodes. Bij XP ligt de nadruk vooral op: Samenwerking; Snelle en vroegtijdige ontwikkeling van software; Professionele ontwikkelmethodes. XP is gebaseerd op vier principes: Communicatie; Eenvoud; Feedback; Moed. Behalve het iteratief en incrementeel ontwikkelen van software kent XP twaalf andere kenmerken: Teams van ontwikkelaars en gebruikers; Kleine, regelmatige opleveringen; Testdriven development; Releaseplanningspel; Iteratieplanningspel; Eenvoudig ontwerp; Paarsgewijs programmeren (pair programming); Veelvuldige uitsplitsing; Beheer van code; Voortdurende integratie; Duurzaam werktempo; Programmeer standaards; Systeemmetaforen. Deze kenmerken worden verder uitgewerkt in hoofdstuk 4. XP is ontstaan uit de samenwerking tussen Beck en Cunningham in het midden van de jaren 80 van de twintigste eeuw. Beck bracht hun ideeën in het midden van de jaren 90 in de praktijk bij de ontwikkeling van een salarissysteem voor Chrysler.
Organisatie SYSQA B.V. Pagina 5 van 10 3. Fasering XP bestaat uit vijf fasen: Onderzoek, Planning, Iteraties, Productie en Onderhoud. In de fase Onderzoek wordt er op de zogenaamde story cards (zie hoofdstuk 4) een beschrijving gemaakt van de functionaliteit van het te ontwikkelen systeem. In eerste instantie moeten er voldoende (schetsmatige) kaarten zijn voor een eerste oplevering en moet de haalbaarheid van het project worden vastgesteld. In de fase Planning wordt bepaald welke functionaliteit er precies bij de eerste oplevering gerealiseerd gaat worden en wanneer die eerste oplevering plaatsvindt. In het releaseplanningspel (zie hoofdstuk 4) voltooien ontwikkelaars en gebruikers de story cards voor de eerste oplevering en wordt er nagedacht over wat er voor de volgende oplevering moet gaan gebeuren. In de fase Iteraties vindt de ontwikkeling van het systeem plaats in iteratiestappen met een lengte van 1-3 weken. Aan het einde van elke stap wordt er een geteste tussenversie van het systeem opgeleverd. In het iteratieplanningspel kiezen de gebruikers uit de hele verzameling story cards de kaarten die zij in de volgende iteratiestappen opgeleverd willen hebben. Hun keuze van kaarten wordt bepaald door de status van het project en de meeste recente prioriteiten. Zodra de gebruikers een keuze hebben gemaakt, wordt door de ontwikkelaars nog wel bekeken of de oplevering daarvan realistisch is. Overwerk wordt sterk ontraden in XP. Overwerk wordt beschouwd als een teken van een slecht functionerend project, toenemende onvrede onder de ontwikkelaars, met als gevolg een afname van de productiviteit en kwaliteit van het werk. Tijdens de omzetting van de story cards in software blijven de ontwikkelaars voortdurend in gesprek met de gebruikers over tests en eisen. In de fase Productie wordt het uiteindelijk opgeleverde systeem operationeel gemaakt. In deze fase wordt het systeem voorzien van documentatie, wordt er training gegeven aan gebruikers en wordt de marketing van het systeem geregeld. In de fase Onderhoud worden er nog fouten uit het systeem gehaald en wordt het systeem voortdurend verbeterd.
Organisatie SYSQA B.V. Pagina 6 van 10 4. Kenmerken De XP-methode kan het best aan de hand van een aantal typische elementen worden geïllustreerd. Team van ontwikkelaars en gebruikers Het hele team van zowel ontwikkelaars als gebruikers werkt in een gezamenlijke projectkamer. Een deel van de gebruikers dient voortdurend als klankbord voor de ontwikkelaars. De ontwikkelaars kunnen tijdens hun werk constant overleggen met de gebruikers en in detail uitleg krijgen over wat er wordt bedoeld met de functionaliteit die beschreven staat op de story cards. Zo kunnen ze exact bepalen wat er ontwikkeld moet worden en welke zaken de hoogste prioriteit hebben. Kleine, regelmatige opleveringen De tussenversies worden evolutionair opgeleverd, waarbij de nieuwste versie telkens aanpassingen bevat die voortkwamen uit beoordeling van de vorige versie. Testdriven development Voortdurend en geautomatiseerd testen is een van de belangrijkste kenmerken van XP. Modules worden afzonderlijk getest, meteen geïntegreerd en dan ook als geheel getest. Zowel de afzonderlijke modules als het gehele systeem worden met behulp van testtools getest, in principe komt er geen mens meer aan te pas. Gebruikers moeten dus al voor de bouw van het systeem precies aangeven onder welke voorwaarden zij het accepteren. Voor de modules worden van tevoren testscripts geschreven, vóór er daadwerkelijk ontwikkeld wordt. Dit wordt test-driven ontwikkeling genoemd. Releaseplanningspel In het releaseplanningspel wordt voor elke op te leveren operationele tussenversie bepaald wat er gebouwd gaat worden. Dit gebeurt aan de hand van de story cards waarop de gebruikers hun gewenste functionaliteit beschrijven. Voor elke tussenversie kunnen er nieuwe kaarten worden gemaakt. Maar er zijn vaak ook nog eerder gemaakte kaarten, met functionaliteit die tot nog toe niet is gerealiseerd. Iteratieplanningspel In het iteratieplanningspel wordt voor een iteratiestap bepaald welke functionaliteit precies gebouwd gaat worden en worden taken gepland en toegewezen. Voor elke iteratiestap (1-3 weken) wordt dit spel met story-cards opnieuw gespeeld. De ontwikkelaars maken bij elke gekozen kaart een takenlijst om de bijhorende functionaliteit te realiseren. Daarna kunnen de ontwikkelaars op vrijwillige basis een favoriet takenpakket kiezen. Ze maken een schatting van de benodigde tijd en als een taak niet in een halve dag tot twee dagen kan worden uitgevoerd, wordt de taak uitgesplitst. Eenvoudig ontwerp Het ontwerp moet zo eenvoudig mogelijk zijn: begrijpelijk, met zo weinig mogelijk classes en methods, geen dubbele programmacode. Ook geen ontwerpen voor mogelijke, toekomstige functionaliteit. En geen algemeen bruikbare modules als die niet direct nodig zijn.
Organisatie SYSQA B.V. Pagina 7 van 10 Paarsgewijs programmeren Al het programmeerwerk wordt door twee ontwikkelaars op één computer gedaan. Om de beurt mogen ze aan het werk en de ander kijkt daarbij toe. De toekijker kan meteen adviseren en corrigerend optreden en heeft waarschijnlijk een bredere kijk op het probleem dan degene die zit te typen. De paren kunnen regelmatig van samenstelling veranderen. Bij XP wordt ervan uitgegaan dat paarsgewijs programmeren leidt tot 1) wederzijds leren, 2) collegiale druk om gedisciplineerd te werk te gaan, 3) een hogere productiviteit, 4) minder fouten door gelijktijdige beoordeling en 5) direct beschikbare hulp bij vastlopen. Dit alles leidt tot kwaliteitsverbetering van het team. Veelvuldige uitsplitsing Uitsplitsing van taken is een cruciale factor binnen XP, bedoeld om het ontwerp en de programmacode verregaand te vereenvoudigen. Het is de bedoeling de code en het ontwerp te verfijnen, zonder de bijbehorende functionaliteit te veranderen. Hierop wordt voortdurend getest. Beheer van code Het hele team is gezamenlijk verantwoordelijk voor de code. Elk programmeerpaar kan dus een willekeurig stuk software bouwen en/of aanpassen. Het afschuiven van verantwoordelijkheid is zo niet mogelijk. Verder geldt dat wie een probleem signaleert, ook moet zorgen voor een oplossing. Het feit dat iedereen een willekeurig deel van de code kan bouwen/aanpassen, brengt natuurlijk ook risico s met zich mee. Deze risico s worden ondervangen door het voortdurend testen van de modules en het hele systeem. Ook de gelijktijdige beoordeling van het programmeerwerk door een collega en het gebruik van programmeerstandaards bevordert de uniformiteit en kwaliteit van de code. Voortdurende integratie Zodra een ontwikkelaar klaar is met een stuk code, volgt er een test. Al het programmeerwerk wordt voortdurend geïntegreerd en getest op aparte infrastructuur. Dit gebeurt in een geautomatiseerd proces dat 24 uur per dag, 7 dagen per week doorloopt. Duurzaam werktempo Het werktempo en de omvang van taken moet dusdanig zijn, dat er niet hoeft te worden overgewerkt. Het werkplezier van de ontwikkelaars staat voorop. Programmeerstandaards Het gebruik van programmeerstandaards is noodzakelijk vanwege het collectieve beheer van de code, uitsplitsing van taken en veranderingen in de samenstelling van de paren programmeurs. Systeemmetaforen Communicatie over het ontwerp van het systeem wordt bevorderd door het gebruik van metaforen. Abstracte begrippen worden concreet gemaakt door vergelijkingen met alledaagse zaken zoals fabriek, machines, lopende band.
Organisatie SYSQA B.V. Pagina 8 van 10 Andere elementen van XP zijn: Beschikbaarheid van gebruikers voor direct advies en commentaar; Snelle aanpassing van het systeem aan veranderde eisen; Keuze van taken door ontwikkelaars alleen op basis van vrijwilligheid, ter verhoging van de betrokkenheid; Zo weinig mogelijk ontwerp (hooguit 10-20 minuten) voorafgaand aan het programmeren; Minimale documentatie; Dagelijkse meting van kwaliteit en voortgang (door iemand die hier speciaal verantwoordelijk is); Grafieken met kwaliteit en voortgang worden voor iedereen zichtbaar op borden weergegeven; Incrementele ontwikkeling; Een gezamenlijke projectkamer; Een dagelijkse, staande vergadering (net als bij Scrum); Schattingen van de hoeveelheid werk per taak worden gedaan in ideale uren : werkelijk benodigde tijd, zonder afleiding, onderbreking et cetera.
Organisatie SYSQA B.V. Pagina 9 van 10 5. XP en andere methodes De XP-methode voor softwareontwikkeling biedt een aantal voordelen ten opzichte van andere methodes: Communicatie Aangezien de meeste problemen bij projecten voortkomen uit communicatieproblemen, wordt er alles aan gedaan om de communicatie te bevorderen. Paarsgewijs programmeren, het planningppel tussen gebruikers en ontwikkelaars, de dagelijkse vergadering en de betrokkenheid van gebruikers bij het opstellen van de acceptatietestscripts moeten daarvoor zorgen; Eenvoud Op alle terreinen wordt gestreefd naar eenvoud: eenvoudig ontwerp, eenvoudige code, eenvoudige hulpmiddelen (zoals kaarten en wandborden); Feedback Binnen XP wordt op allerlei manieren gezorgd voor feedback. Feedback door test-driven ontwikkeling en voortdurende integratie van software. Gebruikers krijgen feedback van ontwikkelaars, doordat de ontwikkelaars bij het beschrijven van functionaliteit op een story card meteen schatten hoeveel werk de functionaliteit kost. Het team krijgt op borden feedback over de kwaliteit en voortgang van het werk. Ook de door gebruikers gedefinieerde acceptatie-eisen zijn een vorm van feedback. De korte iteratiestappen en regelmatige opleveringen bieden de gebruikers de mogelijkheid het veranderende systeem te becommentariëren en zo de eisen te verduidelijken of bij te stellen; Moed Er is moed nodig om snel software te ontwikkelen en die ook telkens snel aan te passen. Deze werkwijze wordt ondersteund door het gebruik van geautomatiseerde testtools, die voortdurend zorgen voor werkende software. Ook de eenvoud in het ontwerp van het systeem draagt hieraan bij. De XP-methode kan eventueel gecombineerd worden met (elementen uit) andere agile ontwikkelmethodes zoals Scrum, Evo, UP. Wel is bijvoorbeeld de nadruk van Evo op specificaties in strijd met de uitgangspunten van XP. En bij XP zijn bijvoorbeeld de iteratiestappen korter dan bij Scrum. Verder blijft bij XP het ontwerpen voorafgaand aan het programmeren beperkt tot hooguit 20 minuten, terwijl daar bij UP een halve dag voor uitgetrokken mag worden.
Organisatie SYSQA B.V. Pagina 10 van 10 6. Literatuurverwijzingen Beck, K. 2000. Extreme Programming Explained Embrace Change. Addison-Wesley. Larman, C. 2004. Agile and Iterative Development. A Manager s Guide. Addison-Wesley.