Extreme programming (XP) levert resultaten op, maar is het geschikt voor jou?

Als de term extreme programming mentale beelden van de X-games en actiesporten oproept, dan zit je niet ver weg. Extreme programming (XP) is in feite een behoorlijk extreme manier van programmeren. Net als andere Agile-softwareontwikkelingsmethoden maakt XP gebruik van aanpasbare, testgedreven ontwikkeling voor software-engineering. Maar in tegenstelling tot andere methoden, heeft extreme programming strikte regels en leidende waarden die bepalen hoe het werk wordt gedaan. 

Wat is extreme programming (XP)?

Extreme programming is een Agile-projectbeheermethode die gericht is op snelheid en eenvoud met korte ontwikkelingscycli en minder documentatie. De processtructuur wordt bepaald door vijf leidende waarden, vijf regels en 12 XP-praktijken (die we verderop in dit artikel zullen bespreken). 

Net als andere Agile-methoden is XP een softwareontwikkelingsmethodologie die is opgesplitst in werksprints. Agile-raamwerken volgen een iteratief proces - je voltooit en beoordeelt het raamwerk na elke sprint, verfijnt het voor maximale efficiëntie en past het aan veranderende vereisten aan. Net als bij andere Agile-methoden, stelt het ontwerp van XP ontwikkelaars in staat om in realtime te reageren op klantverhalen, aan te passen en te veranderen. Maar XP is veel gedisciplineerder, met frequente codebeoordelingen en unit-testen om snel wijzigingen aan te brengen. Het is ook zeer creatief en collaboratief, waarbij teamwork in alle ontwikkelingsstadia prioriteit krijgt.

Extreem programmeren versus Scrum

Scrum is een ander veel voorkomend type Agile-methodologie dat wordt beheerd door een Scrummaster. Net als XP voert Scrum sprints uit op basis van gebruikersverhalen om nieuwe product- of softwarefuncties te ontwikkelen. XP is echter rigider dan Scrum, met strikte regels en richtlijnen die constant contact tussen ontwikkelaars en de klant aanmoedigen. Je kunt Scrum ook gebruiken voor elk proces dat iteratie en klantinvoer vereist, terwijl je alleen XP-programmering zou gebruiken.

Wie heeft extreme programming gemaakt?

De oorsprong van XP dateert uit de late jaren negentig, toen Kent Beck het creëerde om de ontwikkeling van een salarissoftwaresysteem voor Chrysler te beheren, het zogenaamde C3-project. Het doel met XP was (en is nog steeds) om de weerstand tegen het veranderen van code binnen ontwikkelingsprojecten te verwijderen. In meer traditionele softwareontwikkelingsmethoden laat je code vaak met rust zodra deze is geschreven (behalve voor het debuggen). Met XP onderzoek je de code zo zorgvuldig dat ontwikkelaars kunnen besluiten om deze na een enkele iteratie volledig opnieuw te schrijven. 

Wanneer moet je extreme programming gebruiken?

Omdat extreme programming zich richt op softwareontwikkeling, wordt het meestal alleen gebruikt door engineeringteams. Zelfs in softwareteams werkt het alleen in bepaalde instellingen. Om de meeste waarde uit extreme programming te halen, kun je het het beste gebruiken wanneer je: 

• Een kleiner team leidt. Vanwege het zeer collaboratieve karakter werkt XP het beste in kleinere teams van minder dan 10 personen. 

• Je staat voortdurend in contact met je klanten. XP neemt de vereisten van de klant op in het hele ontwikkelingsproces en vertrouwt er zelfs op voor testen en goedkeuringen.

• Een flexibel team hebt dat verandering kan omarmen (zonder wrok). Door zijn aard vereist extreme programming vaak dat je hele team hun harde werk weggooit. Er zijn ook regels die andere teamleden toestaan om op elk moment wijzigingen aan te brengen, wat niet werkt als je teamleden dat persoonlijk opvatten.

• Goed thuis zijn in de technische aspecten van codering. XP is niet voor beginners. Je moet snel kunnen werken en wijzigingen kunnen aanbrengen.

Levenscyclus van XP

De XP-levenscyclus moedigt continue integratie aan waarbij het teamlid bijna constant integreert, zo vaak als per uur of dagelijks. Maar de volledige levenscyclus is als volgt:

• Haal onvoltooid werk uit gebruikersverhalen 

• Je geeft prioriteit aan de belangrijkste items 

• Begin met iteratieve planning  

• Eerlijke planning opnemen  

• Blijf in constante communicatie met alle belanghebbenden en versterk het team  

• Werk vrijgeven  

• Feedback ontvangen 

• Keer terug naar de iteratieve planningsfase en herhaal indien nodig.

5 waarden van extreme programming

Extreme programming is waardegedreven. In plaats van externe motivatoren te gebruiken, stelt XP je team in staat om op een minder gecompliceerde manier te werken (gericht op eenvoud en samenwerking boven complexe ontwerpen), allemaal gebaseerd op deze vijf waarden.

1. Eenvoud

Voordat je met extreme programmering begint, vraag jezelf eerst af: wat is het eenvoudigste dat ook werkt? Het 'dat werkt'-gedeelte is een belangrijke onderscheidende factor - het eenvoudigste is niet altijd praktisch of effectief. In XP is je focus om het belangrijkste werk eerst gedaan te krijgen. Dit betekent dat je op zoek bent naar een eenvoudig project waarvan je weet dat je het kunt voltooien.

2. Communicatie

XP is gebaseerd op snelle reactiviteit en effectieve communicatie. Om te kunnen werken, moet het team open en eerlijk tegen elkaar zijn. Als er problemen zijn, wordt er van je verwacht dat je iets zegt. De reden hiervoor is dat andere teamleden vaak al een oplossing hebben. En als ze dat niet doen, kom je er als groep sneller mee dan alleen.

3. Feedback

Net als andere Agile-methoden neemt XP gebruikersverhalen en feedback rechtstreeks op in het proces. De focus van XP is om snel en eenvoudig werk te produceren en het vervolgens te delen om bijna onmiddellijk feedback te krijgen. Als zodanig staan ontwikkelaars tijdens het hele proces bijna voortdurend in contact met klanten. In XP lanceer je frequente releases om vroeg en vaak inzichten te krijgen. Wanneer je feedback ontvangt, pas je het proces aan om het op te nemen (in plaats van het project). Als de feedback bijvoorbeeld onnodige vertragingstijd vermindert, zou je je proces aanpassen om een paar ontwikkelaars de vertragingstijd te laten verbeteren in plaats van het project als geheel aan te passen.

4. Moed

XP vereist een zekere mate van moed. Er wordt altijd van je verwacht dat je eerlijke updates geeft over je voortgang, wat behoorlijk kwetsbaar kan zijn. Als je een deadline mist in XP, zal je teamleider waarschijnlijk niet willen bespreken waarom. In plaats daarvan zou je hen vertellen dat je de deadline hebt gemist, jezelf verantwoordelijk houden en weer aan het werk gaan. 

Als je een teamleider bent, is het jouw verantwoordelijkheid aan het begin van het XP-proces om de verwachting voor succes in te stellen en 'klaar' te definiëren. Er is vaak weinig planning voor mislukking omdat het team zich richt op succes. Dit kan echter eng zijn, omdat dingen niet altijd gaan zoals gepland. Maar als er dingen veranderen tijdens het XP-proces, wordt van je team verwacht dat het zich aanpast en mee verandert. 

5. Respect

Gezien de hoge prioriteit die XP geeft aan communicatie en eerlijkheid, is het logisch dat respect belangrijk is. Om teams in staat te stellen effectief te communiceren en samen te werken, moeten ze het oneens kunnen zijn. Maar er zijn manieren om dat vriendelijk te doen. Respect is een goede basis die leidt tot vriendelijkheid en vertrouwen, zelfs in de aanwezigheid van veel eerlijkheid. Voor extreme programming zijn de verwachtingen: 

• Wederzijds respect tussen klanten en het ontwikkelteam. 

• Wederzijds respect tussen teamleden. 

• Een erkenning dat iedereen in het team iets waardevols aan het project toevoegt.

5 regels van de extreme programmeermethodologie

De waarden van extreme programming zijn de meer filosofische aspecten. De regels daarentegen zijn de praktische toepassingen voor hoe het werk wordt gedaan. Je hebt beide nodig om een effectief XP-team te runnen. 

1. Planning

In de planningsfase van XP bepaal je of het project levensvatbaar is en het beste geschikt is voor XP. Om dit te doen, kijk je naar:

• User stories om te zien of ze overeenkomen met de eenvoudswaarde en om te controleren of de klant beschikbaar is voor het proces. Als de gebruikersverhaal complexer is of door een anonieme klant is gemaakt, werkt het waarschijnlijk niet voor XP.

• De bedrijfswaarde en prioriteit van het project om ervoor te zorgen dat dit in overeenstemming is met 'het belangrijkste werk eerst gedaan krijgen'. 

• In welk ontwikkelingsstadium je je bevindt. XP is het beste voor ontwikkeling in een vroeg stadium en werkt niet zo goed voor latere iteraties.

Zodra je hebt bevestigd dat het project geschikt is voor XP, maak je een releaseschema, maar houd er rekening mee dat je vroeg en vaak moet vrijgeven om feedback te krijgen. Om dit te doen:

• Splits het project op in iteraties en maak voor elke iteratie een plan. 

• Stel realistische deadlines en een duurzaam tempo. 

• Deel updates terwijl ze plaatsvinden, zodat je team eerlijk en transparant kan zijn. 

• Deel realtime updates die het team helpen sneller te identificeren, aan te passen en wijzigingen aan te brengen. 

• Gebruik een pojectbeheertool om een Kanbanbord of tijdlijn te maken om je voortgang in realtime bij te houden. 

2. Beheren

Een van de belangrijkste elementen van XP is de fysieke ruimte. XP-puristen raden aan om een open werkruimte te gebruiken waar alle teamleden in één open ruimte werken. Omdat XP zo collaboratief is, heb je baat bij een ruimte waar je fysiek samen kunt komen. Maar dat is niet altijd praktisch in deze tijd. Als je in een extern team werkt, overweeg dan het gebruik van een platform dat asynchrone samenwerking op afstand aanmoedigt. Op deze manier kunnen alle leden samen aan het project blijven werken, zelfs als ze niet fysiek samen zijn.

Gebruik, net als bij andere Agile-methoden, dagelijkse standup-vergaderingen om in te checken en constante, open communicatie aan te moedigen. Je wilt zowel een wekelijkse cyclus als een driemaandelijkse cyclus gebruiken. Tijdens je driemaandelijkse cyclus zullen jij en je Team verhalen bekijken die je werk zullen begeleiden. Je bestudeert ook je XP-proces, op zoek naar hiaten of mogelijkheden om wijzigingen aan te brengen. Vervolgens werk je in wekelijkse cycli, die elk beginnen met een klantvergadering. De klant kiest het gebruikersverhaal waaraan programmeurs die week moeten werken. 

Als manager of teamleider ligt je focus op het handhaven van de voortgang van het werk, het meten van het tempo, het verplaatsen van teamleden om bugs of problemen aan te pakken wanneer ze zich voordoen, of het wijzigen van het XP-proces zodat het past bij je huidige project en iteratie. Onthoud dat het doel van XP is om flexibel te zijn en actie te ondernemen, zodat je werk sterk gericht is op het huidige werk van het team en reageert op eventuele veranderingen.

3. Ontwerpen

Als je net begint met extreme programming, begin dan met het eenvoudigste mogelijke ontwerp, wetende dat latere iteraties ze complexer zullen maken. Voeg in dit stadium geen vroege functionaliteit toe om het zo kaal mogelijk te houden.

XP-methodologieteams gebruiken vaak CRC-kaarten (class-responsibility-collaboration) om te laten zien hoe elk object in het ontwerp met elkaar omgaat. Door elk veld in de kaart in te vullen, krijg je een visuele interactie van alle functies zoals ze zich verhouden en interageren. CRC-kaarten bevatten: 

• Klasse (verzameling van vergelijkbare objecten)

• Verantwoordelijkheden (gerelateerd aan de klasse)

• Medewerkers (klasse die hiermee interageert)

CRC's zijn nuttig voor het stimuleren van het proces en het opsporen van potentiële problemen. Ongeacht hoe je ontwerpt, wil je een systeem gebruiken dat potentiële knelpunten vermindert. Om dit te doen, moet je ervoor zorgen dat je proactief op zoek bent naar risico's. Zodra een potentiële dreiging zich voordoet, wijs je één tot twee teamleden aan om een oplossing te vinden voor het geval de dreiging zich voordoet.

4. Programmeren

Een van de meer unieke aspecten van XP is dat je tijdens het coderingsproces voortdurend in contact blijft met de klant. Met dit partnerschap kun je feedback testen en opnemen in elke iteratie, in plaats van te wachten tot het einde van een sprint. Maar de coderingsregels zijn vrij streng in XP. Enkele van deze regels zijn:

• Alle code moet voldoen aan coderingsnormen.

• Een unit-test gebruiken om vereisten vast te leggen en alle aspecten van het project te ontwikkelen.

• Programmeren als een paar - twee ontwikkelaars werken tegelijkertijd samen op dezelfde computer. Dit voegt geen tijd toe, maar gebruikt eerder de dubbele focus om de hoogste kwaliteitsresultaten te produceren. 

• Gebruik continue integraties om nieuwe code toe te voegen en deze onmiddellijk te testen.

• Slechts één paar kan code op een bepaald moment bijwerken om fouten te verminderen.

• Collectief code-eigendom - elk lid van het team kan je code op elk moment wijzigen.

5. Testen

Je moet tijdens het hele extreme programmeerproces testen. Alle code moet unit-tests doorstaan voordat deze wordt vrijgegeven. Als je tijdens deze tests bugs ontdekt, maak je nieuwe, aanvullende tests om ze op te lossen. Later configureer je dezelfde gebruikersverhaal waaraan je hebt gewerkt in een acceptatietest. Tijdens deze test bekijkt de klant de resultaten om te zien hoe goed je de gebruikersverhaal hebt vertaald naar het product.

Wat zijn de 12 extreme programmeerpraktijken?

Om het proces verder te verfijnen, gebruikt XP ook een reeks van 12 praktijken gedurende het hele proces. Ze zijn gebaseerd op het agile manifest, maar aangepast aan de behoeften van XP:

1. Het planningsspel: XP-planning wordt gebruikt om het werk te sturen. De resultaten van de planning moeten zijn wat je hoopt te bereiken en wanneer, en wat je vervolgens gaat doen.

2. Klantentests: wanneer je een nieuwe functie afrondt, ontwikkelt de klant een acceptatietest om te bepalen hoe dicht deze bij zijn oorspronkelijke gebruikersverhaal ligt.

3. Kleine releases: XP gebruikt kleine, routinematige releases om inzichten te krijgen tijdens het proces. Vaak gaan releases rechtstreeks naar de klanten, hoewel ze ook intern kunnen plaatsvinden.

4. Eenvoudig ontwerp: het XP-systeem is ontworpen voor eenvoud - je produceert alleen wat nodig is en niets meer. 

5. Paarprogrammering: Alle programmering komt van een paar ontwikkelaars die naast elkaar zitten. Er is geen solowerk in extreme programming.

6. Testgedreven ontwikkeling (TDD): XP is afhankelijk van feedback en vereist zwaar testen. Door korte cycli geven programmeurs geautomatiseerde tests vrij en reageren ze onmiddellijk.

7. Refactoring: Hier besteed je aandacht aan de fijnere details van de codebase, verwijder je duplicaten en zorg je ervoor dat de code samenhangend is. Dit resulteert in goede, eenvoudige ontwerpen.

8. Collectieve verantwoordelijkheid: elk coderingspaar kan de code op elk moment wijzigen, ongeacht of ze deze hebben ontwikkeld. XP produceert code als een team en ieders werk wordt gehouden aan de hogere collectieve normen.

9. Continue integratie: XP-teams wachten niet op voltooide iteraties, ze integreren voortdurend. Vaak integreert een XP-team meerdere keren per dag.

10. Duurzaam tempo: de intensiteit van XP-werk vereist dat je een duurzaam tempo instelt. Teams moeten beslissen hoeveel werk ze op deze manier per dag en per week kunnen produceren, en dat gebruiken om deadlines te stellen.

11. Metafoor: De metafoor is, letterlijk, een metafoor. Het wordt als team besloten en gebruikt taal om te beschrijven hoe het team moet functioneren. We zijn bijvoorbeeld mieren die als een collectief werken om de mierenhoop op te bouwen. 

12. Coderingsstandaard: XP-teams volgen één standaard. Op dezelfde manier dat schrijvers de stem van een merk moeten aannemen om te klinken alsof dezelfde persoon altijd schrijft, coderen XP-ontwikkelaars op dezelfde, uniforme manier, zodat het leest als één ontwikkelaar.

Intens, maar effectief

Op dit punt heb je waarschijnlijk begrepen dat extreme programming, nou ja, extreem is. Het proces is rigoureus en zeer gestructureerd, maar de resultaten zijn het misschien wel waard. Het unieke ontwikkelingsproces van XP, waarin feedback van klanten en intensieve, gezamenlijke programmering zijn verwerkt, resulteert in software van hoge kwaliteit. 

Stroomlijn je XP-planning en -beheer met een werkbeheertool die in realtime wordt bijgewerkt en aangepast, net als je werk.