Extreme programming (ook wel XP genoemd) is een vorm van agile-softwareontwikkeling, een softwareontwikkelingsmethodiek.
Geschiedenis De belangrijkste grondleggers van extreme programming zijn Kent Beck, Ken Auer, Ward Cunningham, Martin Fowler en Ron Jeffries. Zij ontwikkelden XP 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"). XP is een methodiek die vooral geschikt is voor projecten waarbij de exacte applicatie-eisen niet bij voorbaat vastliggen.
Ontwikkelprincipes, best practices Extreme programming dankt zijn naam aan het feit dat een aantal beproefde ontwikkelprincipes (zogenaamde best practices) tot in het extreme wordt doorgevoerd. De optimale kracht van XP komt voort uit het in samenhang toepassen van twaalf best practices van software ontwikkeling. De best practices zijn gegroepeerd in vier groepen.Beck, K. Extreme Programming Explained: Embrace Change 2nd. ed. Addison-Wesley, 2000 pp. 54 (feedback, continu proces, gedeelde kennis en het welzijn van de ontwikkelaars).
Feedback Pair programming XP stelt dat uiteindelijk alles om code draait bij het maken van software. 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; pair programming genoemd. Dit is meteen ook een van de meest extreme en controversiële aspecten van XP, omdat men denkt dat het dan langzamer gaat. Maar 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 nog 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 softwareontwikkeling 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 softwareproces. Het gevolg is dat het uiteindelijk opgeleverde systeem niet langer bestaat uit een met 'touwtjes' aan elkaar gebonden verzameling van 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.
Planning Het planningsproces is het belangrijkste proces. De planning gebeurt eens per week en bestaat uit een releaseplanning en een iteratieplanning.
Release Planning: hierbij wordt bepaald welke functionaliteit in welke release gerealiseerd wordt. Zowel de ontwikkelaars als de gebruikers zijn hierbij aanwezig. De Release Planning bestaat uit 3 fasen: Onderzoeksfase (Exploration Phase): hierbij maken de gebruikers een korte lijst met de belangrijkste eisen voor het nieuwe systeem. Dit gebeurt in de vorm van user story's. Concept besluitvorming (Commitment Phase): hierbij wordt besloten welke user story's in de volgende release meegenomen worden en wanneer deze release zal zijn. Wijzigingsfase (Steering Phase): hierbij kan het plan nog worden aangepast en nieuwe story's worden toegevoegd en anderen verwijderd. Iteration Planning: hierbij worden de user story's die in de release planning voor de komende sprint zijn opgenomen uitgesplitst in taken voor de ontwikkelaars. Hierbij zijn geen gebruikers betrokken, alleen ontwikkelaars. Iteration Planning bestaat ook uit drie fasen: Onderzoeksfase (Exploration Phase): de story's worden naar taken vertaald en deze taken worden op kaarten geschreven, zogenaamde taak-kaarten. Toewijzingsfase (Commitment Phase): van deze taken wordt ingeschat hoelang het duurt om dit te realiseren en de taken worden aan de ontwikkelaars (paren) toegewezen. Ontwikkelfase (Steering Phase): de taken worden uitgevoerd en het resultaat wordt vergeleken met de originele tijdsplanning van de userstory.
Het doel van de planning is om te zorgen dat het product afgeleverd kan worden. Het gaat niet zozeer om het afgeven van exacte data als wel om het opleveren van het product.Grigori Melnik & Frank Maurer. Introducing Agile Methods: Three Years of Experience, Proceedings of the 30th Euromicro Conference, pages=334–341, year=2004, publisher=IEEE, doi=10.1109/EURMIC.2004.1333388
Releaseplanning Onderzoeksfase (exploration phase) Dit is het proces van het verzamelen van vereisten en het inschatten van de hoeveelheid tijd die het kost om die te realiseren. Onderdelen zijn:
Schrijf een verhaal (user story): de gebruikers komen met een probleem of wens; tijdens een overleg zullen de ontwikkelaars proberen dit probleem volledig te begrijpen. Op grond hiervan wordt er een user story geschreven. Dit wordt door de gebruikers gedaan, hierbij geven zij aan wat zij van een (gedeelte van) het systeem verwachten. Het is belangrijk dat de ontwikkelaars zich hier niet mee bemoeien. Inschatten van de user story (estimate a story): de ontwikkelaars schatten hoeveel tijd het kost om dit te maken. Door de ontwikkelaars kunnen nu ook korte onderzoeken, "spikes" genoemd, benoemd worden, om delen van het probleem of de oplossingsrichting te onderzoeken. Deze spikes worden gebruikt om tot betere tijdsschattingen te komen en worden weggegooid zodra het probleem en/of de oplossing voor iedereen duidelijk is. Splitsen van een user story: een story moet volledig duidelijk zijn, alle onduidelijkheden moet eruit zijn voordat met de iteratie planning begonnen kan worden. Als de ontwikkelaars wegens onduidelijkheden geen tijdsschatting kunnen afgeven voor de story, moet de story gesplitst worden.
Als de gebruikers al hun wensen hebben beschreven kan men verder met de concept besluitvorming (commitment fase).
Concept besluitvorming (commitment phase) In deze fase wordt uitgezocht wat de kosten zijn, de opbrengsten en wat voor tijdsconsequenties dat heeft. Deze fase heeft vier onderdelen namelijk:
Sorteren op waarde: de gebruikers zetten de user story's in volgorde van wat zij belangrijk vinden. Sorteer op basis van risico: de ontwikkelaars geven een inschatting van de risico's en sorteren de story op basis daarvan. Bepaal de ontwikkelsnelheid (velocity): de ontwikkelaars bepalen met welke snelheid zij dit project kunnen uitvoeren. Scope: er wordt bepaald welke user story's in de komende release worden gerealiseerd. Op grond hiervan wordt de releasedatum bepaald.
Sorteren op waarde voor de gebruikers (business value) De gebruikers geven de prioriteit aan van de user story's. Zij maken 3 stapels: Kritisch: zonder deze story's kan het systeem niet werken of heeft het geen waarde. Belangrijk: user story's die belangrijk zijn voor het bedrijf. Nice to have: User story's waarmee minder belangrijke eigenschappen worden gerealiseerd.
Sorteren op basis van risico De ontwikkelaars sorteren de user story's op basis van het risico. Zij maken ook drie stapels: klein, medium en hoog risico. In het volgende een voorbeeld: Bepaal de Risk Index: geef elke user story een index van 0 tot 2 op elk van de volgende variabelen. Volledigheid (hebben we alle details boven tafel?) Volledig (0) Onvolledig (1) Onbekend (2) Kwetsbaarheid (zijn wijzigingen waarschijnlijk?) laag (0) Medium (1) Hoog (2) Moeilijkheid (hoe moeilijk is het te realiseren?) Eenvoudig (0) Standaard (1) Moeilijk (2)
Alle waarden voor de user story worden bij elkaar opgeteld, waardoor de user story een risico waarde krijgt van laag (0–1), medium (2–4), of hoog (5–6).
Wijzigingsfase (steering phase) In deze fase kunnen de ontwikkelaars samen met de gebruikers het proces "sturen". Met andere woorden, zij kunnen nog iets wijzigen. Individuele gebruiker story's, of de belangrijkheid van de verschillende story's kunnen veranderen; schattingen kunnen verkeerd zijn. Deze wijzigingen kunnen aangebracht worden.
Iteration planning Afhankelijk van de snelheid van het team kan er bepaald worden hoeveel story punten het team kan doen per iteratie. Iteraties kunnen 1 tot 3 weken duren.
Onderzoeksfase (exploration phase) Tijdens de onderzoeksfase van de iteratieplanning worden de user story's opgedeeld in taken en van de taken wordt geschat hoelang ze duren. Werkzaamheden: Vertaal de user story's in taken en schrijf deze op taak-kaartjes. Voeg taken samen of splits ze: Als de ontwikkelaar niet goed kan inschatten hoelang de taak duurt omdat deze te groot of te klein is, moet daar iets aan gedaan worden. Schat de taak: maak een tijdsschatting van de uitvoering van de taak.
Toewijzingsfase (commitment phase) In de toewijzingsfase (commitment phase) van de iteratie planning, worden de taken over de ontwikkelaars verdeeld.
Een ontwikkelaar (programmeur) accepteert een taak: elke ontwikkelaar pakt een taak waarvoor hij dan verantwoordelijk wordt. De ontwikkelaar geeft een tijdsplanning: Omdat de ontwikkelaar nu verantwoordelijk is, is hij nu het best in staat om een tijdsschatting te geven. Bepaal de effectieve werktijd (Set load factor): de effectieve werktijd bepaalt het aantal uren dat de ontwikkelaar/programmeur kan ontwikkelen gedurende een iteratie. Bijvoorbeeld, in een 40-urige werkweek, waarin er 5 uren vergaderd wordt, wordt de effectieve werktijd 35 uur. Balancing: zodra alle taken zijn toegewezen wordt er bekeken hoeveel uur elke ontwikkelaar heeft gekregen in vergelijking ook met hoeveel uur hij effectief beschikbaar is (load factor). Dan worden de taken eventueel opnieuw verdeeld om te zorgen dat iedere ontwikkelaar ongeveer evenveel werk heeft. Als een ontwikkelaar te veel werk heeft wordt er iets verschoven.
Uitvoeringsfase (steering phase) De uitvoering van de taken wordt tijdens de uitvoeringsfase (steering phase) van de iteratieplanning gedaan. Pak een taakkaart: de ontwikkelaar krijgt de kaart met de beschrijving van de taak van een van de taken waarvoor hij zich heeft aangemeld. Zoek een partner: de ontwikkelaar zal een partner zoeken om het samen te ontwikkelen. ontwerp de taak: indien noodzakelijk zal er een (kort) ontwerp gemaakt worden. Schrijf de unit test: voordat er geprogrammeerd wordt moeten alle tests gemaakt worden. Bij voorkeur zijn dit automatische tests omdat die vaak (automatisch) uitgevoerd moeten worden.. Schrijf de code: de programmeur/ontwikkelaar maakt het programma. Test het programma: de gemaakte (unit)tests worden uitgevoerd. Refactoring: Pas de refactoringregels toe en zorg dat de code aan de standaards voldoet. Doe de functionele tests/integratietests: Na de unit test worden alle mogelijke andere test gedraaid. integratietests, regressietests etc. De code moet worden aangepast totdat deze aan de tests voldoet.
Test Driven Development Bij test-driven development (TDD) wordt er eerst getest en pas daarna geprogrammeerd. TDD zegt dat als testen goed is: schrijf dan eerst de testcode voordat je ook maar een regel code (functionaliteit) schrijft.
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.